[Interest] Simple device discovery using UDP
Thiago Macieira
thiago.macieira at intel.com
Tue Oct 2 19:28:30 CEST 2018
On Tuesday, 2 October 2018 08:14:01 PDT coroberti . wrote:
> Hi,
> 1. As Sean has mentioned, firewall settings that do not allow broadcasts
> could be the case.
>
> 2. Yet another case could be: QHostAddress::Broadcast.
> It's so-called All-Networks-Broadcast (255.255.255.255)
> and normally requires alleviated privileges to send to (UNIX root, suid)
> and could be guarded.
>
> There's another broadcast address - so-called LAN-broadcast
> which is less sensitive and more appropriate for broadcasting.
>
> For example, at network 10.31.4.0/24, it will be 10.31.4.255,
> and you can find various rules to calculate it.
Use QNetworkInterface dor that.
But instead of using broadcast, use multicast. Then only the devices that are
interested in being discovered will join the multicast group. That will also
work in IPv6.
> 3. Instead of using a broadcast address, you can figure our all
> addresses on this network
> and send unicast requests except to the subnet broadcast address .
> At most networks, it will be sending to up to 253 address, whereas
> rarely it could come to higher numbers.
Please don't do that. That's practically "port scanning" and poking at ports
in other people's devices is impolite. Your netadmin may come knocking on your
door. Like a proper port scanning, you'd need to do proper throttling and
resending, to avoid packet loss due to collisions. Expecting that you're only
in a /24 network is also a bad design -- here in the office, the WiFi is on a
/22 so you go from 254 to 1022 IPs to scan. And of course, the solution falls
completely flat on IPv6: we're in 2018, not 2001, so designing any solution
that fails to work in IPv6 is malpractice.
If you really want to do this, install nmap.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
More information about the Interest
mailing list