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.)
_______________________________________________
lwip-users mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/lwip-users
