Having problems with limited broadcast

[Peter Steele]

>Peter, I understand your issue with the (apparent) restriction of the 
>169.254/16 range, though I'd point out that the IPv4-LL addressing 
>scheme is considered a fall-back plan by most systems implementors.  
>Your systems could look  for DHCP first then failing that, drop back to

>IPv4-LL and get an address.  The picky customers would simply be 
>required to supply a DHCP server.  Everyone else presumably doesn't
care 
>as long as the boxes can communicate.

I personally like this idea, but I'm not sure I can sell it to the
others. Are there any restrictions to these 169.254.x.y addresses?
Although our boxes systems operate as a cluster, there do need to be
externally addressable. If there are no restrictions in how these link
local addresses appear in a company LAN, then I don't think there would
be a problem. The question is, if a picky customer doesn't want to use
this range, will they be agreeable to providing a DHCP server for our
use? The customer often has a lot of leverage in these matters
unfortunately.
 
>But there's another useful point to pickup from the ZeroConf stuff.  I 
>implemented a small standalone IPv4-LLA daemon using libevent, libnet 
>and libpcap.  IPv4-LLA needs to muck around with a completely 
>unaddressed interface (like you are doing with your DHCP-lite), sending

>and listening-for broadcast and directed ARP packets, per RFC 3927.  It

>was trivial to do this in a completely portable way using libpcap and 
>libnet.  I'd highly recommend to you that you link those libraries into

>your Python DHCP-lite app and you will be able to deploy relatively 
>painlessly on any platform that those libraries are ported to.

We need broadcast support for both Java and Python and we're currently
looking at a relatively simple solution using scapy. If that doesn't
work out I'm sure we may have to delve into libnet/libpcap.

Thanks for your feedback.

Peter