desbma added the comment: Thanks for the insight.
Well the most logical thing for me for the OS to do, would have been: 1. Send an ARP request 2. At the first poll call, report a timeout if no response was received 3. Repeat to 2. until the destination is considered unreachable 4. At the next connect call, fire off another ARP request 5. At the next poll call, if the response to the ARP sent in 5 was not received, report "No route to host" immediately because it is the last cached result (from 3) 6. Always report "No route to host" for the following calls (even if new ARP requests are sent) With "ip -4 neigh" I can see that the neighbor is in FAILED state when the OSError error is reported, but immediately goes to INCOMPLETE state at the next connect call (because another ARP request is sent). The behavior is the same with an IPv6 socket. By re-reading the NDP RFC (https://tools.ietf.org/html/rfc4861) I can understand why implementations behave like that. The RFC does not define the "FAILED" neighbor cache state, so "resolution failed" means "neighbor is not in the cache". Linux has a delayed garbage collection for the neighbor cache, which is why we can sometimes see entries in FAILED state, but when a new socket tries to connect to the peer, the resolution starts again like nothing happened before. So it's weird, but it conforms to the standard :) ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue31268> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
