[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