All about ping


Ping is a very useful network diagnostic tool and is often the first thing we turn to when we have network issues. While it's true that a successful "ping" doesn't necessarily mean that higher level connectivity is working, the lack of a ping response from something that should respond almost certainly indicates network problems or a downed host. Slow ping responses usually mean slow networks, so ping is a convenient way to get some idea of network latency and congestion too.

It don't mean a thing if it ain't got that ping- Dirk Hart

At that simple level ("ping somehost"), we can't go too far wrong. The host responds or it doesn't, the speed of the response is what we expect or it isn't. There could be missing or duplicated responses (see below) but most of the time it is pretty straight forward.

Where we might get into trouble is when we want to alter pings behavior or aren't aware of its behavior. For example, Windows folk are often confused because Unix/Linux pings don't stop automatically - by default they keep pinging until you interrupt them (Ctrl-C, DEL or whatever the INTERRUPT sequence is - use CTRL-\ if all else fails).

Different systems can use very different flags for common functions:

-w deadline Specify a timeout, in seconds, before ping exits  
-t ttl Set the IP Time to Live
(Mac OS X)
-t timeout  Specify a timeout, in seconds, before ping exits 
-m ttl  Set the IP Time To Live for outgoing packets
-T ttl  Set the IP Time To Live for multicasted packets. 

You can see how that might get you in trouble! Read the man page - read it even if you think you know ping inside and out, because you may not.

What can I check if ping doesn't work at all?

(Also see A non-technical guide to understanding and fixing TCP/IP problems on a network.)

Did you try "ping localhost"? If you can't do that, you aren't going to ping anything else!

First, are you sure that the address, netmask and broadcast are correct? Your broadcast should be the inverse of of your netmask. For example, if your ip address is and your netmask is, your broadcast should be, but if the netmask were, the broadcast would be

If the netmask does not match the netmask of the OTHER machines on the network, you can have strange results like being able to ping machine X but machine X can't ping you.

Ping by ip address rather than name. If that works, your problem is name resolution, not anything else.

Are you sure your ip address is unique? Try pinging it from some other machine with this one turned off- obviously you should get nothing.

If you are on the same network and are able to, check "arp -a" on the other machine. Does it show the expected MAC address for the IP you are pinging from? Does it have any arp entry?

Do you have a physical connection? You should be seeing network traffic on the lights of your nic if you are connected to a hub (not with a switch- unless the traffic is broadcast or directed to your ip specifically), and if you unplug the patch cord, the lights at the hub or switch should go out- if they don't, obviously you aren't plugged in where you think you are.

Is your cable good? Swap it with a working system to check.

Move the machine to another place on the network- maybe the wiring is bad just here.

Routes all look good? netstat -rn shows you. If you are seeing unexpected routes, a rip enabled router may be feeding you bad info. Turn off rip by killing the routed process and make sure it doesn't restart by editing it out of /etc/tcp. Find the line that reads "/etc/routed &" and put a "#" in front of it.

Ping is slow

DNS lookups might be at fault - try "ping -n" and see Ping is really slow.

DUP ping

The "DUP" means that "ping" received two replies to one enquiry - the icmp_sequence number is duplicated.

The Linux man page says:

       ping will report duplicate and damaged packets.
       Duplicate packets should never occur, and seem to be
       caused by  inappropriate  link-level  retransmissions.
       Duplicates  may occur in many situations and are rarely
       (if ever) a good sign, although the presence of low levels
       of duplicates may not always be cause for alarm.

       Damaged packets are obviously serious cause for alarm and
       often indicate broken  hardware  somewhere  in  the ping
       packet's path (in the network or in the hosts).

This almost certainly means faulty or misconfigured equipment somewhere - for example a bad netmask setting can cause one or the other machine to be on the "wrong" subnet (whichever one is wrong).

Bonding NICS can also cause this.

VMware has also caused this sort of DUP confusion, as have other virtualization products.

An anonymous person sent this:

I've also seen this on wireless networks. The node in
question is hardwired to a wireless bridge and being pinged
across the WLAN from the router. Note the long ping time of
the previous packet. The first three packets also dropped.

64 bytes from icmp_seq=3 ttl=64 time=5.7 ms 
64 bytes from icmp_seq=4 ttl=64 time=14.0 ms 
64 bytes from icmp_seq=5 ttl=64 time=9.5 ms 
64 bytes from icmp_seq=6 ttl=64 time=5.1 ms 
64 bytes from icmp_seq=7 ttl=64 time=1.7 ms 
64 bytes from icmp_seq=8 ttl=64 time=53.1 ms 
64 bytes from icmp_seq=8 ttl=64 time=88.0 ms (DUP!) 
64 bytes from icmp_seq=9 ttl=64 time=2.8 ms 
64 bytes from icmp_seq=10 ttl=64 time=2.2 ms 

Here's another similar issue.

SLAC Duplicate packets

Pings out of order

You'd expect sequential responses normally:

64 bytes from icmp_seq=0 ttl=55 time=82.358 ms
64 bytes from icmp_seq=1 ttl=55 time=81.264 ms
64 bytes from icmp_seq=2 ttl=55 time=82.797 ms
64 bytes from icmp_seq=3 ttl=55 time=81.718 ms
64 bytes from icmp_seq=4 ttl=55 time=83.187 ms

But (taken from Curious pings on SCO) here's something different:

64 bytes from kasseob4 ( icmp_seq=3 ttl=62 time=40 ms
64 bytes from kasseob4 ( icmp_seq=0 ttl=62 time=3080 ms
64 bytes from kasseob4 ( icmp_seq=1 ttl=62 time=2080 ms
64 bytes from kasseob4 ( icmp_seq=2 ttl=62 time=1090 ms
64 bytes from kasseob4 ( icmp_seq=4 ttl=62 time=2240 ms
64 bytes from kasseob4 ( icmp_seq=5 ttl=62 time=1240 ms
64 bytes from kasseob4 ( icmp_seq=6 ttl=62 time=240 ms
64 bytes from kasseob4 ( icmp_seq=7 ttl=62 time=2400 ms
64 bytes from kasseob4 ( icmp_seq=8 ttl=62 time=1400 ms
64 bytes from kasseob4 ( icmp_seq=9 ttl=62 time=400 ms
64 bytes from kasseob4 ( icmp_seq=13 ttl=62 time=40 ms
64 bytes from kasseob4 ( icmp_seq=10 ttl=62 time=3080 ms
64 bytes from kasseob4 ( icmp_seq=11 ttl=62 time=2080 ms
64 bytes from kasseob4 ( icmp_seq=12 ttl=62 time=1090 ms
64 bytes from kasseob4 ( icmp_seq=14 ttl=62 time=820 ms

The poster commented "The ping looks like a sinus curve, running in a loop."

What happened there?

You can read that thread for various interpretations (slow DNS, DNS caching, packet caching and more) but my guess is that some of the packets may have traveled over a lower speed link (load splitting) or took a network path that just took longer to respond (busy?). Out of order delivery isn't necessarily a problem (TCP/IP expects that to happen) though obviously a lot of it will slow things down.

Intermittent ping timeout

If you see a timeout in the middle of succesful pings, what happened?

First, "ping" does have a default timeout and a very busy machine just might not have gotten around to responding in time. Internet network congestion could also. Software could cause that: here is a case where Symantec Endpoint Protection seemed to be at fault.

This case turned out to be IP conflicts.

What if the other side deliberately doesn't respond to ping?

There are other tools, but tcpping is "ping-like".

Nmap is another possibility; see How to ping a TCP or UDP port with nmap and nping..

hping is yet another.


On this Ubuntu system, ping and ping 6 are obviously different:

# ls -l /bin/ping*
-rwsr-xr-x 1 root root 34740 Nov  8  2011 /bin/ping
-rwsr-xr-x 1 root root 39116 Nov  8  2011 /bin/ping6

But their man pages are identical.

The OS X and BSD man page is different and includes this:

     The ping6 utility is intentionally separate from ping(8).

     There have been many discussions on why we separate ping6 and
     ping(8).  Some people argued that it would be more convenient to
     uniform the ping command for both IPv4 and IPv6.  The followings
     are an answer to the request.

     From a developer's point of view: since the underling raw
     sockets API is totally different between IPv4 and IPv6,
     we would end up having two types of code base.  There would
     actually be less benefit to uniform the two commands into a
     single command from the developer's standpoint.

     From an operator's point of view: unlike ordinary network
     applications like remote login tools, we are usually aware of
     address family when using network management tools.  We do not
     just want to know the reachability to the host, but want to
     know the reachability to the host via a particular network pro-
     tocol such as IPv6.  Thus, even if we had a unified ping(8)
     command for both IPv4 and IPv6, we would usually type a -6 or
     -4 option (or something like those) to specify the particular
     address family.  This essentially means that we have two
     different commands.


Ping Tunnel - For those times when everything else is blocked..

Got something to add? Send me email.


Increase ad revenue 50-250% with Ezoic

More Articles by

Find me on Google+

© Anthony Lawrence

Tue Sep 10 04:29:20 2013: 12305   anonymous


On ubuntu 10.04 after a while, a long while measured in hours I get 8 to 10 duplicated Pings that repeat for each sequence number..
If I start another window and run ping nothing is duplicated although I run bot ping simultaneously.
The command I use is
What is going on?

Tue Sep 10 10:05:13 2013: 12306   TonyLawrence


Duplicate pings are mentioned above. I don't have anything to add to that.

Kerio Samepage

Have you tried Searching this site?

Unix/Linux/Mac OS X support by phone, email or on-site: Support Rates

This is a Unix/Linux resource website. It contains technical articles about Unix, Linux and general computing related subjects, opinion, news, help files, how-to's, tutorials and more.

Contact us

privacy policy