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 192.168.2.3 and your netmask is
255.255.255.0, your broadcast should be 192.168.2.255, but if the
netmask were 255.255.0.0, the broadcast would be 192.168.255.255.
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
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.
The "DUP" means that "ping" received two replies to one enquiry - the
icmp_sequence number is duplicated.
The Linux man page says:
DUPLICATE AND DAMAGED PACKETS
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 192.168.11.6: icmp_seq=3 ttl=64 time=5.7 ms
64 bytes from 192.168.11.6: icmp_seq=4 ttl=64 time=14.0 ms
64 bytes from 192.168.11.6: icmp_seq=5 ttl=64 time=9.5 ms
64 bytes from 192.168.11.6: icmp_seq=6 ttl=64 time=5.1 ms
64 bytes from 192.168.11.6: icmp_seq=7 ttl=64 time=1.7 ms
64 bytes from 192.168.11.6: icmp_seq=8 ttl=64 time=53.1 ms
64 bytes from 192.168.11.6: icmp_seq=8 ttl=64 time=88.0 ms (DUP!)
64 bytes from 192.168.11.6: icmp_seq=9 ttl=64 time=2.8 ms
64 bytes from 192.168.11.6: icmp_seq=10 ttl=64 time=2.2 ms
Here's another similar issue.
SLAC Duplicate packets
You'd expect sequential responses normally:
64 bytes from 18.104.22.168: icmp_seq=0 ttl=55 time=82.358 ms
64 bytes from 22.214.171.124: icmp_seq=1 ttl=55 time=81.264 ms
64 bytes from 126.96.36.199: icmp_seq=2 ttl=55 time=82.797 ms
64 bytes from 188.8.131.52: icmp_seq=3 ttl=55 time=81.718 ms
64 bytes from 184.108.40.206: icmp_seq=4 ttl=55 time=83.187 ms
But (taken from Curious pings on SCO) here's something different:
64 bytes from kasseob4 (10.22.136.54): icmp_seq=3 ttl=62 time=40 ms
64 bytes from kasseob4 (10.22.136.54): icmp_seq=0 ttl=62 time=3080 ms
64 bytes from kasseob4 (10.22.136.54): icmp_seq=1 ttl=62 time=2080 ms
64 bytes from kasseob4 (10.22.136.54): icmp_seq=2 ttl=62 time=1090 ms
64 bytes from kasseob4 (10.22.136.54): icmp_seq=4 ttl=62 time=2240 ms
64 bytes from kasseob4 (10.22.136.54): icmp_seq=5 ttl=62 time=1240 ms
64 bytes from kasseob4 (10.22.136.54): icmp_seq=6 ttl=62 time=240 ms
64 bytes from kasseob4 (10.22.136.54): icmp_seq=7 ttl=62 time=2400 ms
64 bytes from kasseob4 (10.22.136.54): icmp_seq=8 ttl=62 time=1400 ms
64 bytes from kasseob4 (10.22.136.54): icmp_seq=9 ttl=62 time=400 ms
64 bytes from kasseob4 (10.22.136.54): icmp_seq=13 ttl=62 time=40 ms
64 bytes from kasseob4 (10.22.136.54): icmp_seq=10 ttl=62 time=3080 ms
64 bytes from kasseob4 (10.22.136.54): icmp_seq=11 ttl=62 time=2080 ms
64 bytes from kasseob4 (10.22.136.54): icmp_seq=12 ttl=62 time=1090 ms
64 bytes from kasseob4 (10.22.136.54): 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
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 Anthony Lawrence
Find me on Google+
© 2013-09-10 Anthony Lawrence