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

[Bill Auerbach]

Thanks David!  This is good information.  Clearly if the address is reserved
or multicast (first byte at 224 or above) windows will not pass it to an
application even if the destination is a broadcast. I would have expected
some comment about the destination being broadcast or not but I don't find
it.  Unfortunately our user "bricked" his unit. I was able to provide a
utility to just broadcast a configuration packet (our own discovery/ipconfig
protocol) and do a blind configuration and it worked.  Good thing because he
was half way around the world and already down for 3 days.  I added error
checks to disallow several bad or unusable addresses or address ranges.  I
have another widely distributed embedded product which doesn't error check
either - I bricked it too. :-)

>RFC5735

Thank you!  I'd not seen this one.  I have a few more addresses I can add to
the check.  I think if any of these in the RFC were configured, Windows
wouldn't block them.  I suppose I shouldn't assume anything about the
address.

Does anyone know if Linux or MacOS behaves the same way? Just curious.

Happy Holidays!
Bill

>-----Original Message-----
>From: address@hidden
>[mailto:address@hidden On
>Behalf Of David Empson
>Sent: Tuesday, December 21, 2010 5:08 PM
>To: Mailing list for lwIP users
>Subject: Re: [lwip-users] OT: Windows blocking receive broadcasts
>
>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
>address@hidden
>http://lists.nongnu.org/mailman/listinfo/lwip-users