Update 2: Obviously, Comcast support's solution is to ask me to reboot the modem. They say they cannot answer more directly, because -- I kid you not -- tech support does not have access to the internet and cannot read this page.

Update: for those people who did not understand the question, let me spell it out in more detail:

  • "What might be the reasons why I'm losing about half of my ping packets on the way to the Comcast name server?"
  • And: "Why is there such a weird rectangular pattern to the packet loss?"
  • And more generally: "Has anybody seen this kind of pattern before anywhere (not just limited to Comcast) and found out what the problem was?"

Thanks to everybody who has provided insightful answers so far.

> ping   (Comcast name server)
PING ( 56 data bytes
64 bytes from icmp_seq=0 ttl=59 time=12.262 ms
64 bytes from icmp_seq=1 ttl=59 time=12.018 ms
64 bytes from icmp_seq=2 ttl=59 time=11.671 ms
64 bytes from icmp_seq=3 ttl=59 time=11.826 ms
64 bytes from icmp_seq=4 ttl=59 time=13.569 ms
64 bytes from icmp_seq=5 ttl=59 time=11.850 ms
64 bytes from icmp_seq=6 ttl=59 time=12.059 ms
64 bytes from icmp_seq=7 ttl=59 time=12.141 ms
64 bytes from icmp_seq=8 ttl=59 time=12.418 ms
64 bytes from icmp_seq=9 ttl=59 time=11.598 ms
64 bytes from icmp_seq=10 ttl=59 time=11.607 ms
64 bytes from icmp_seq=11 ttl=59 time=10.900 ms
Request timeout for icmp_seq 12
Request timeout for icmp_seq 13
Request timeout for icmp_seq 14
Request timeout for icmp_seq 15
Request timeout for icmp_seq 16
Request timeout for icmp_seq 17
Request timeout for icmp_seq 18
Request timeout for icmp_seq 19
Request timeout for icmp_seq 20
64 bytes from icmp_seq=21 ttl=59 time=13.082 ms
64 bytes from icmp_seq=22 ttl=59 time=12.650 ms
64 bytes from icmp_seq=23 ttl=59 time=12.920 ms
64 bytes from icmp_seq=24 ttl=59 time=12.497 ms
64 bytes from icmp_seq=25 ttl=59 time=17.745 ms
64 bytes from icmp_seq=26 ttl=59 time=12.116 ms
64 bytes from icmp_seq=27 ttl=59 time=12.211 ms
64 bytes from icmp_seq=28 ttl=59 time=11.455 ms
64 bytes from icmp_seq=29 ttl=59 time=11.393 ms
64 bytes from icmp_seq=30 ttl=59 time=11.429 ms
64 bytes from icmp_seq=31 ttl=59 time=11.624 ms
64 bytes from icmp_seq=32 ttl=59 time=12.239 ms
64 bytes from icmp_seq=33 ttl=59 time=11.702 ms
64 bytes from icmp_seq=34 ttl=59 time=10.930 ms
64 bytes from icmp_seq=35 ttl=59 time=11.987 ms
64 bytes from icmp_seq=36 ttl=59 time=23.932 ms
64 bytes from icmp_seq=37 ttl=59 time=14.720 ms
64 bytes from icmp_seq=38 ttl=59 time=11.730 ms
Request timeout for icmp_seq 39
Request timeout for icmp_seq 40


It creates a really nice rectangular pattern on the terminal, each state about 7-20 lines long, so it's not totally regular. It's been like this for a while.

The only explanation I can think of is that some firewall guy somewhere had a great amount of fun.

If I traceroute to, I can ping any one of the hosts in between with 100% success.

  • Looks like a route flap somewhere. It could be the far router losing routes back to you, then getting them again. But pings to the 2nd-to-last IP in the traceroute works OK? Are you pinging at a server or a router? – Skaperen Jul 28 '12 at 19:29
  • 1
    63% loss here . – Behrooz Jul 28 '12 at 20:21
  • @Skaperen: Pings to the 2nd-to-last IP in the traceroute is OK, as is for all others in the traceroute. How would the server vs router make a difference? I am pinging from the box behind my Comcast cable modem, and the behavior is the same for a MacBook and a Linux box configured as router. There's no other box between that an the Comcast modem. – Johannes Ernst Jul 29 '12 at 0:23
  • 1
    Sounds like a load balanced system where not all back-end systems respond ti pings, so it depends on just which server you're hitting with a particular packet, or group of packets. – John Gardeniers Jul 29 '12 at 0:27
  • @John Gardeniers: In this case I'd expect something less regular than what I'm seeing? There isn't really any session stickiness in ICMP is there? – Johannes Ernst Jul 29 '12 at 0:29

Just did a ping myself, the problem might not be yourself, but comcast:

--- ping statistics ---
39 packets transmitted, 17 received, 56% packet loss, time 38189ms
rtt min/avg/max/mdev = 85.606/85.778/85.942/0.317 ms

Their servers might be under great stress resulting in a sort of DoS.

  • Same here: 36 packets transmitted, 14 received, 61% packet loss, time 35121ms – basvdlei Jul 28 '12 at 21:03
  • Thanks for confirming the mystery. I doubt the DoS because in that case I'd expect 1) a more random pattern, and 2) some different behavior over time. This pattern has been identical for several days. – Johannes Ernst Jul 29 '12 at 0:22
  • Have you tried any other servers, like google ( and ? – Lucas Kauffman Jul 29 '12 at 0:23
  • All other pings that I've tried work fine. E.g. the ones you suggest. – Johannes Ernst Jul 29 '12 at 0:27
  • If google works, you have nothing to be scared of off :). Don't forget to accept an answer :) – Lucas Kauffman Jul 29 '12 at 0:30

I suspect firewall rate-limiting. In any case, who here is still using Comcast's DNS servers?

  • Good idea. But: the original ping was in 1-sec intervals. I re-ran it in 4-sec intervals. The timing is still the same, just fewer lines per state. So that seems to disqualify that theory? – Johannes Ernst Jul 29 '12 at 0:21
  • I could be wrong. It does happen sometimes. :) – Michael Hampton Jul 29 '12 at 2:01

Not the answer you're looking for? Browse other questions tagged or ask your own question.