On 2011-04-20, Chris Angelico <ros...@gmail.com> wrote: > On Wed, Apr 20, 2011 at 11:15 AM, Grant Edwards <invalid@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 -- http://mail.python.org/mailman/listinfo/python-list