[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[lwip-devel] [bug #31367] Cannot send a UDP datagram to a different vali

From: Simon Goldschmidt
Subject: [lwip-devel] [bug #31367] Cannot send a UDP datagram to a different valid subnet
Date: Sun, 21 Nov 2010 13:27:27 +0000
User-agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; de; rv: Gecko/20101026 Firefox/3.6.12

Follow-up Comment #8, bug #31367 (project lwip):

Pardon me for the confusion, but when trying to find an RFC that tells me
how/when to update the ARP information on incoming IP packets, I found none.
And this got me to the point again: updating the ARP table from non-ARP
packets is not standardized since it is not recommended (unclear when routers
are involved, high overhead for every incoming packet). I would even drop the
whole code for that, but since we already have it...

As to RFC 1122, it does not forbid adding the source of your broadcast to the
ARP cache, but it *is* quite clear about outbound routing. See chapter
 Local/Remote Decision:

"(b)  If the IP destination address bits extracted by the
address mask match the IP source address bits extracted
by the same mask, then the destination is on the
corresponding connected network, and the datagram is to
be transmitted directly to the destination host.
(c)  If not, then the destination is accessible only through
a gateway."

To me, it's quite clear that in this case, an ARP entry for the address in
question would not help, as the packet would have to be sent to a gateway
according to the RFC.

However, in your special case, there's really a bug in lwIP: according to RFC
3927, there's a bug in our AutoIP implementation (I've filed a bug for that:
bug #31722). See 2.6.2.  Forwarding Rules:

"If for any reason the host chooses
to send the packet with an IPv4 Link-Local source address (e.g., no
routable address is available on the selected interface), then it
MUST ARP for the destination address and then send its packet, with
an IPv4 Link-Local source address and a routable destination IPv4
address, directly to its destination on the same physical link.  The
host MUST NOT send the packet to any router for forwarding."

While this helps you for mixed communication of AutoIP/non-AutoIP devices, it
does not help in the case where an application uses global broadcasts to find
devices that are configured with an invalid IP address (like I did). The only
solution here that does not violate the routing RFCs is to reply with a global
broadcast, too.


Reply to this item at:


  Nachricht geschickt von/durch Savannah

reply via email to

[Prev in Thread] Current Thread [Next in Thread]