2

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:

So two questions in summary:

  1. Is there a way to get ping to report connection failures after a timeout?
  2. What is -W designed for, if not to solve (1) ?

1 Answers1

1

Answers to the questions:

  1. Nothing built into ping as far as I can tell. There are two workarounds:
    • Wrap a single ping (eg. ping -c1 -W 5 8.8.8.8) in a bash loop that greps the output or checks the return flag and echos some useful output. Here's a great example: https://superuser.com/a/668124
    • The -O flag shows a failure message immediately. It's unrelated to -W and has no timeout associated with it, so it's not quite the same thing, but at least connection issues should be apparent.
  2. There appears to be no purpose to -W unless -c is specified too, to limit the number of packets. If -c is specified, then -W is similar to -w except that the timeout is per ping instead of overall.