Re: [lwip-users] OT: Windows blocking receive broadcasts

[David Empson]

OT: Windows blocking receive broadcastsBill Auerbach wrote:

> I just ran into something.  A customer programmed a "bad" static IP 
> address in his lwIP-based device.
> My ipconfig utility broadcasts a "who's there" UDP message and is 
> broadcasted back from the lwIP
> device the "here I am" packet.  The problem is, with the bad IP address as 
> the source, Windows will
> not send the packet to the program.  But, Wireshark does show both 
> broadcasts.  The user is not sure
> what was entered, I can make it happen if I set the lwIP device to 
> 250.168.1.1.  I know it's in the
> unicast range, but why is this effecting broadcasts?

That address is in the "reserved" range above the multicast addresses. It is 
quite likely that Windows has a rule where it will discard any packet with a 
source address in the multicast address range (224.0.0.0/4), since multicast 
addresses cannot be source addresses, only destination addresses. As there 
is no clear definition of the reserved addresses (240.0.0.0/4), except the 
"local network broadcast" address, 255.255.255.255, Windows may be treating 
a source address in this range as invalid, and simply discarding the packet.

Whether this is being done by the TCP/IP stack or a firewall is a question 
for further experimentation.

I haven't spotted a rule in RFCs about use of this address range. The 
relevant ones just say "reserved for future use". As most of the Internet 
infrastructure and host operating systems have probably made arbitrary 
decisions about how to handle these addresses, the likelihood is that it 
won't be practical to start using those addresses on the public Internet.

RFC5735 lists all the addresses ranges that are reserved for various 
purposes, but as far as I can see the only ones that are likely to cause 
major problems if a device was configured to use that address are:

0.0.0.0/8 (this device or network)
127.0.0.0/8 (loopback)
224.0.0.0/4 (multicast)
240.0.0.0/4 (reserved)

> From RFC5735 and referenced RFCs (5736 and 3068), it is probably a good idea 
to disallow 192.0.0.0/24 (IETF protocol assignments) and 192.88.99.0/24 
(6to4 relay anycast).

Static configuration of 169.254.0.0/16 (self-assigned) should also be 
avoided, as was discussed recently in bug #31828. (These addresses should 
only be assigned using AutoIP.)