Problem receiving UDP broadcast packets.

[Grant Edwards]

On 2011-04-20, Chris Angelico <rosuav at gmail.com> wrote:
> On Wed, Apr 20, 2011 at 11:15 AM, Grant Edwards <invalid at invalid.invalid> wrote:
>>> Or can you simply use a stupid netmask like /1 that picks up all the
>>> IP ranges? That way, the source-IP check wouldn't fail.
>>
>> That would require that the device somehow knows that it's not
>> configured correctly and should change the netmask to /1. ?The device
>> doesn't have any way to know that, and it must respond to the
>> discovery commands both before and after it's properly configured.
>
> Was hoping that you could make such a change _only_ on the computer
> that's receiving the data - that way it's only one change, the devices
> don't need any tweaking. But if it can't be, it can't be.

There can by any number of devices that have to receive the broadcast
packet, and any of them can be on different subnets (or have no IP
address at all).

>> I've reread the protocol documentation and noticed that the device
>> has to respond not only to broadcasts to 255.255.255.255 but also to
>> subnet broadcasts send to subnets it's not on.

It turns out that some OSes (BSD and some flavors of Windows) can't
broadcast to 255.255.255.255, only to the subnet broadcast address.
Hence the requirement for the devices to be able to receive a subnet
broadcast regardless of their IP address.

>> That pretty much clinches the requirement to use a raw socket. :/
>
> Sounds to me like someone majorly abused IP to do weird things.

Indeed.  The other option is to do something that's not based on IP
but done completely at the Ethernet layer.  Implementing management
programs that can do that can be very nasty on Windows, which
unfortunately matters to most customers.

So you bite the bullet on the device end and implement all sorts of
weirdness in order to allow the management program to use standard
UDP.

> Looks like you're stuck doing the same weirdness, in whatever way you
> can manage

Yup.  It doesn't even appear that it can be done with a raw UDP
socket. According to all of the documentation I can find, such a
socket is supposed to receive copies of all UDP packets seen by the
kernel, but it doesn't.  Even if I use a raw UDP socket, the kernel is
still dropping broadcast packets whose source address don't match any
interface's subnet.

AFAICT, I'm going to have to go completely raw and process in
user-space every single IP packet recieved.  That's going to be
brutal on the CPU...

-- 
Grant