On Debian Buster, judging by the description of the -W
flag to ping
, I assumed that I could use something like:
ping -i 10 -W 5 8.8.8.8
to continuously monitor an Internet connection. If the connection goes down I would expect that 5 seconds after each ping (which are 10 seconds apart), ping
would report that there was no response. Instead what happens is that the output pauses (at least 60 seconds, maybe indefinitely) until the connection resumes, and then all the pings sent in that pause period complete and just show a long pong time. So the output looks something like this:
64 bytes from 8.8.8.8: icmp_seq=36 ttl=117 time=11.705 ms
64 bytes from 8.8.8.8: icmp_seq=37 ttl=117 time=11.963 ms
64 bytes from 8.8.8.8: icmp_seq=38 ttl=117 time=11.900 ms
64 bytes from 8.8.8.8: icmp_seq=39 ttl=117 time=11.288 ms <-- connection interrupted after this line
64 bytes from 8.8.8.8: icmp_seq=40 ttl=117 time=65697 ms <-- this line takes ~65s to appear
64 bytes from 8.8.8.8: icmp_seq=41 ttl=117 time=55880 ms
64 bytes from 8.8.8.8: icmp_seq=42 ttl=117 time=45116 ms
64 bytes from 8.8.8.8: icmp_seq=43 ttl=117 time=35949 ms
64 bytes from 8.8.8.8: icmp_seq=44 ttl=117 time=25266 ms
64 bytes from 8.8.8.8: icmp_seq=45 ttl=117 time=15943 ms
64 bytes from 8.8.8.8: icmp_seq=46 ttl=117 time=5818 ms
64 bytes from 8.8.8.8: icmp_seq=47 ttl=117 time=11.578 ms <--- connection restored before this ping
64 bytes from 8.8.8.8: icmp_seq=48 ttl=117 time=11.382 ms
64 bytes from 8.8.8.8: icmp_seq=49 ttl=117 time=11.624 ms
64 bytes from 8.8.8.8: icmp_seq=50 ttl=117 time=11.407 ms
64 bytes from 8.8.8.8: icmp_seq=51 ttl=117 time=11.864 ms
64 bytes from 8.8.8.8: icmp_seq=52 ttl=117 time=11.716 ms
Where as I expected something like this:
64 bytes from 8.8.8.8: icmp_seq=36 ttl=117 time=11.705 ms
64 bytes from 8.8.8.8: icmp_seq=37 ttl=117 time=11.963 ms
64 bytes from 8.8.8.8: icmp_seq=38 ttl=117 time=11.900 ms
64 bytes from 8.8.8.8: icmp_seq=39 ttl=117 time=11.288 ms <-- connection interrupted after this line
ping is down: no route to host
ping is down: no route to host
ping is down: no route to host
ping is down: no route to host
ping is down: no route to host
ping is down: no route to host
ping is down: no route to host
64 bytes from 8.8.8.8: icmp_seq=47 ttl=117 time=11.578 ms <--- connection restored before this ping
64 bytes from 8.8.8.8: icmp_seq=48 ttl=117 time=11.382 ms
64 bytes from 8.8.8.8: icmp_seq=49 ttl=117 time=11.624 ms
64 bytes from 8.8.8.8: icmp_seq=50 ttl=117 time=11.407 ms
64 bytes from 8.8.8.8: icmp_seq=51 ttl=117 time=11.864 ms
64 bytes from 8.8.8.8: icmp_seq=52 ttl=117 time=11.716 ms
According to these questions, this is a common question with no clear answer:
- https://stackoverflow.com/questions/20359487/why-does-ping-not-timeout-in-linux
- https://stackoverflow.com/questions/18228886/ping-timeout-issues
- https://stackoverflow.com/questions/17951182/ping-timeout-command-w-not-working-for-android
- https://stackoverflow.com/questions/32976579/how-long-is-the-interval-for-a-ping-that-results-in-destination-host-unreachabl
- https://stackoverflow.com/questions/21639576/php-ping-on-linux-timeout-not-working
- https://serverfault.com/questions/570336/android-linux-ping-sends-another-packet-before-packet-timeout
So two questions in summary:
- Is there a way to get ping to report connection failures after a timeout?
- What is
-W
designed for, if not to solve (1) ?