ping endlessly running in case the network interface is lost while the pinger is not yet finished about ping HOT 2 CLOSED

I compared the behavior to the standard ping on Ubuntu which treats these packets as lost packets:

~$ ping -c 20 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=116 time=15.0 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=116 time=14.8 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=116 time=14.9 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=116 time=14.8 ms

--- 8.8.8.8 ping statistics ---
20 packets transmitted, 4 received, 80% packet loss, time 19369ms
rtt min/avg/max/mdev = 14.835/14.884/15.004/0.069 ms

Based on that I think the PacketsSent counter should still be increased even if the write fails.

from ping.

I now had a very similar issue at a customer setup that I think has the same root cause. There the Network interface is nicely up and running but the system is directly connected to an LTE modem and the ping packets are sent but not a single response is received. Pinger in this case never reaches the .OnFinish callback.
For debugging I added the .OnSend callback in addition to the .OnRecv callback and the log output looks something like this:

264 bytes sent 8.8.8.8: icmp_seq=0
264 bytes sent 8.8.8.8: icmp_seq=1
264 bytes sent 8.8.8.8: icmp_seq=2

And that's it. --> so I think when the interface is up but not a single response is received the pinger also hangs as with a network interface that is going down during pings.

Note: I will now try at this customer my patch from the pull request to see if it also helps for this issue.
Note2: Of course I could set a general timeout to avoid this as well but when providing a count it would be great if it imply only tries count-times and then finishes without a timeout.

from ping.