Home Original page

Problem receiving UDP broadcast packets.

Grant Edwards invalid at invalid.invalid
Tue Apr 19 21:15:14 EDT 2011 
On 2011-04-20, Chris Angelico <rosuav at gmail.com> wrote:
> On Wed, Apr 20, 2011 at 10:09 AM, Grant Edwards <invalid at invalid.invalid> wrote:
>> The management program can then send another broadcast packet to
>> configure the IP address of a device. After that, the management
>> program switches over to normal unicast TCP and UDP protocols (HTTP,
>> TFTP, etc.) to set up the device.
>>
>
> Wonder if it would be possible to (ab)use DHCP for this. If every
> device registers itself with a central DHCP server, you could query
> that to find out what's around, and configuring of IP addresses would
> then be out of your hands.

I can't require the presense of a DHCP server, and many installations
won't have one.

> 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.

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. :/

-- 
Grant
More information about the Python-list mailing list