Problem receiving UDP broadcast packets.

[Dan Stromberg]

On Tue, Apr 19, 2011 at 6:15 PM, 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.

- Actually, you Might be able to configure your device to have a
netmask of 0.0.0.0, IP address of 255.255.255.255 and broadcast of
255.255.255.255.
- I've seen something a bit similar used for detecting IP address
conflicts automatically.
- A network guru I used to work with told me that you could configure
a machine with a broadcast of 255.255.255.255 more simply than messing
around with the netmask, while still achieving the same result for
general purpose networking.

> 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.  That pretty much
> clinches the requirement to use a raw socket. :/

With a netmask of 0.0.0.0, I suspect you will receive all broadcasts
on the wire, given appropriate listening code.

You could probably also modify a copy of tshark or tcpdump to flush
after every line of output (or run an unmodified one on a pty to avoid
maintaining your own copy of the binary), and parse that output in
Python.  That should make the Python code pretty simple.

There's an old program called "pty" that makes it easy to run
something on a pty, to get unbuffered output - it's in
comp.sources.unix volumes 22, 23 and 25; it's written in C.  You'd
just open a subprocess with no buffering on the python side, that runs
tcpdump or tshark under pty.  Beware though - the pty program predates
GNU autoconf, so might be a little involved to compile.

I agree though that you're kind of pushing IP in a direction it wasn't
intended to go.