Super User is a question and answer site for computer enthusiasts and power users. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I ping a host:

$ ping
PING ( 56(84) bytes of data.
64 bytes from icmp_req=1 ttl=47 time=53.8 ms
64 bytes from icmp_req=2 ttl=47 time=54.2 ms
64 bytes from icmp_req=3 ttl=47 time=49.1 ms
--- 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
PING ( 56(84) bytes of data.
--- 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.

share|improve this question
What happens if you don't interrupt the ping? – BillThor Dec 30 '11 at 19:56
Whether I interrupt or not seems to make no difference. Running two pings in parallel will produce similar results (the second ping won't work). It's as if the first ping acquires exclusive access to some unique resource required to receive ICMP echo replies. – user111251 Dec 30 '11 at 21:12
Might be time to look at the capabilities of netstat and lsof. – BillThor Dec 30 '11 at 21:18

It is likely be that your are getting rate limited on echo requests. The origin address of the ICMP replies on the failed requests should tell where you are getting limited.

Rate limiting is relatively trivial to setup in iptables.

Trying a program like mtr to do the pings should show where you are getting limited quickly.

EDIT: Check to see if you are rate limiting anything with iptables. You might want to rate limit incoming ECHO requests, but if incorrectly specified, you may be rate limiting all incoming ICMP packets. Look for limit in the output of iptables -L -n.

share|improve this answer
In both cases, the ICMP replies originate at, so it would seem the problem is local to my machine. I can see no relevant difference in tcpdump between the replies that ping sees and the replies that ping doesn't see. Somewhere between tcpdump and ping, they seem to disappear. – user111251 Dec 28 '11 at 21:47
tcpdump may see replies that get trottled by iptables. – BillThor Dec 29 '11 at 17:18
There are no limits at all in the rules. Removing all iptables rules (and resetting policies) temporarily did not help. – user111251 Dec 30 '11 at 14:33
Then Google or your ISP might be limiting you. – LawrenceC May 3 '12 at 16:45

You must log in to answer this question.