Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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?

share|improve this question

2 Answers 2

up vote 5 down vote accepted

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.

share|improve this answer
    
So you are able to reproduce the described problem on your system? --- Crud. I was hoping that this was a symptom of some config issue (I've been getting less than stellar network performance lately). –  BCS Apr 26 '11 at 13:44
    
Yes, I do see the same behavior. –  chuckx Apr 26 '11 at 17:28
    
Although, I do not see the same behavior on a different system (OpenBSD). It works as expected using either hostname or IP. –  chuckx Apr 26 '11 at 17:43
1  
Maybe. Unfortunately, I'm not familiar at all with avahi-daemon (didn't even recognize it at first). I will have to do some more digging to characterize the behavior and see where things are falling apart. –  chuckx Apr 27 '11 at 0:15
1  
By the look of it, that was also causing other problems with my connection (I was having a hard time getting video to stream correctly and after turning that off, it seems fine). –  BCS Apr 27 '11 at 4:05

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. :)

share|improve this answer
    
You would think ping would cache that :b –  BCS Apr 27 '11 at 0:04

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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