Second ping within 30 seconds of the first always fails

1

1

I ping a host:

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

user111251

Posted 2011-12-28T20:17:55.507

Reputation:

What happens if you don't interrupt the ping? – BillThor – 2011-12-30T19:56:59.007

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. – None – 2011-12-30T21:12:42.770

Might be time to look at the capabilities of netstat and lsof. – BillThor – 2011-12-30T21:18:04.857

Answers

2

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.

BillThor

Posted 2011-12-28T20:17:55.507

Reputation: 9 384

In both cases, the ICMP replies originate at 8.8.8.8, 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. – None – 2011-12-28T21:47:18.060

tcpdump may see replies that get trottled by iptables. – BillThor – 2011-12-29T17:18:31.910

There are no limits at all in the rules. Removing all iptables rules (and resetting policies) temporarily did not help. – None – 2011-12-30T14:33:50.750

Then Google or your ISP might be limiting you. – LawrenceC – 2012-05-03T16:45:14.840

Asked: 2011-12-28T20:17:55.507

Viewed: 1 136 times

Active: 2011-12-30T02:30:56.517