I ping a host:
$ ping 18.104.22.168 PING 22.214.171.124 (126.96.36.199) 56(84) bytes of data. 64 bytes from 188.8.131.52: icmp_req=1 ttl=47 time=53.8 ms 64 bytes from 184.108.40.206: icmp_req=2 ttl=47 time=54.2 ms 64 bytes from 220.127.116.11: icmp_req=3 ttl=47 time=49.1 ms ^C --- 18.104.22.168 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2003ms rtt min/avg/max/mdev = 49.112/52.401/54.202/2.329 ms
And immediately after interrupting the first ping command, I do it again:
$ ping 22.214.171.124 PING 126.96.36.199 (188.8.131.52) 56(84) bytes of data. ^C --- 184.108.40.206 ping statistics --- 3 packets transmitted, 0 received, 100% packet loss, time 2016ms
100 % packet loss. Why?
This happens every time. Only by waiting at least 30 seconds (give or take a second) after interrupting the first ping before executing the second ping will the second ping work as it should. Executing ping before the 30 seconds have passed will cause ping to fail (as seen above), even if I let it run past the 30 second mark, but the 30 second "timer" will not be reset.
Pinging different hosts in the first and second attempt changes nothing.
Running tcpdump while pinging, I see that ICMP echoes are sent and that ICMP replies are received in both cases.
I have also reproduced the problem using the Net::Ping Perl module so the problem is not restricted to /bin/ping (unless Net::Ping uses /bin/ping directly).
I use a pretty standard, current Debian installation which runs as a firewall and does NAT using what I would assume are pretty standard iptables rules.