Home / server / Questions / 263367
Accepted
BCS
Asked: 2011-04-26 20:28:26 +0800 CST

Odd results from ping

  • 772

When I run this on an Ubuntu box:

sudo ping google.com -c 25  -l 25

I get about 1 line back every 2 seconds despite the fact that it should (if I'm reading things correctly) send out all 25 packets at the get go. Oddly enough it claims that I'm getting ping times of:

--- google.com ping statistics ---
25 packets transmitted, 24 received, 4% packet loss, time 0ms
rtt min/avg/max/mdev = 23.370/28.067/32.902/2.895 ms, pipe 24

Also, if I want to bail early, I need to punch ctrl-C once for each packet. Does anyone have any clue what could be causing this?

linux networking ping

2 Answers

  1. Best Answer

    If you ping via IP, as opposed to hostname, you will receive the expected behavior.

    I'm still investigating to get to the root of why this is the case.

    # find IP address of host
$ host -t a google.com
google.com has address 74.125.225.17
google.com has address 74.125.225.19
google.com has address 74.125.225.20
google.com has address 74.125.225.18
google.com has address 74.125.225.16

# pick an IP and ping it, all output is displayed at once
$ sudo ping 74.125.225.17 -c 25 -l 25
PING 74.125.225.17 (74.125.225.17) 56(84) bytes of data.
64 bytes from 74.125.225.17: icmp_seq=1 ttl=55 time=29.7 ms
64 bytes from 74.125.225.17: icmp_seq=2 ttl=55 time=30.4 ms
64 bytes from 74.125.225.17: icmp_seq=3 ttl=55 time=40.0 ms
64 bytes from 74.125.225.17: icmp_seq=4 ttl=55 time=40.4 ms
64 bytes from 74.125.225.17: icmp_seq=7 ttl=55 time=50.1 ms
64 bytes from 74.125.225.17: icmp_seq=5 ttl=55 time=50.4 ms
64 bytes from 74.125.225.17: icmp_seq=6 ttl=55 time=51.4 ms
64 bytes from 74.125.225.17: icmp_seq=8 ttl=55 time=52.4 ms
64 bytes from 74.125.225.17: icmp_seq=9 ttl=55 time=55.4 ms
64 bytes from 74.125.225.17: icmp_seq=10 ttl=55 time=56.4 ms
64 bytes from 74.125.225.17: icmp_seq=11 ttl=55 time=57.3 ms
64 bytes from 74.125.225.17: icmp_seq=13 ttl=55 time=58.3 ms
64 bytes from 74.125.225.17: icmp_seq=12 ttl=55 time=59.3 ms
64 bytes from 74.125.225.17: icmp_seq=14 ttl=55 time=60.3 ms
64 bytes from 74.125.225.17: icmp_seq=15 ttl=55 time=61.9 ms
64 bytes from 74.125.225.17: icmp_seq=16 ttl=55 time=62.3 ms
64 bytes from 74.125.225.17: icmp_seq=17 ttl=55 time=63.2 ms
64 bytes from 74.125.225.17: icmp_seq=18 ttl=55 time=64.2 ms
64 bytes from 74.125.225.17: icmp_seq=19 ttl=55 time=68.9 ms
64 bytes from 74.125.225.17: icmp_seq=20 ttl=55 time=69.2 ms
64 bytes from 74.125.225.17: icmp_seq=21 ttl=55 time=70.2 ms
64 bytes from 74.125.225.17: icmp_seq=22 ttl=55 time=75.9 ms
64 bytes from 74.125.225.17: icmp_seq=23 ttl=55 time=76.2 ms
64 bytes from 74.125.225.17: icmp_seq=24 ttl=55 time=77.2 ms
64 bytes from 74.125.225.17: icmp_seq=25 ttl=55 time=78.1 ms

    UPDATE

    After running ping through strace, I found that it was getting hung up on name resolution (no surprise). However, the thing that caught my eye was avahi-daemon. This service implements Apple's Zeroconf architecture (also known as "Rendezvous" or "Bonjour"). In other words, functionality I don't need.

    After stopping the avahi-daemon, ping behavior went back to normal.

    # sudo /etc/init.d/avahi-daemon stop

    Disabling it during startup can be accomplished with:

    # sudo update-rc.d -f avahi-daemon

    Another work around is simply using the -n flag with ping. The hang up is with reverse DNS lookups performed when processing the replies.

    • 5

  2. If you do a tcpdump while doing your ping, you'll probably see that it's pausing on the reverse-mapping lookup... ie: when it looks up the IP-to-name DNS mapping.

    I guess avahi-daemon is being queried somewhere in the chain when the packets come back in. The -l 25 only cares about the outbound packets... ping is still going to do its job and look up all the names, whether you preload or not. :)

    • 1