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 c
R. David Murray added the comment:
I'm not a networking expert at this level, but I believe what is happening here
is that the network stack does an arp, and has a timeout waiting for the arp
response that is longer than your socket timeout. So at some point its arp
timeout expires while the
desbma added the comment:
Yes, you are right: I tried with a small C program, and compared with strace
log of the Python program.
In both cases poll sometimes returns -1 (error), or sometimes 0 (timeout).
This is a weird behavior (at least for me) of the TCP stack, but clearly Python
is not th
R. David Murray added the comment:
Have you tried the equivalent C program? I'm guessing this is happening at the
OS layer and Python is just reporting it. On my system a timeout of 5 will
always report the OS error.
--
nosy: +r.david.murray
___
P
New submission from desbma:
When trying to connect a classic TCP socket to a non reachable peer, the
exception reported is inconsistent if the socket has a timeout set.
See the attached program, on my system (Arch Linux with Linux 4.9 & Python
3.6.2) it outputs:
timeout timed out
timeout time
