I've removed advertising from most of this site and will eventually clean up the few pages where it remains.
While not terribly expensive to maintain, this does cost me something. If I don't get enough donations to cover that expense, I will be shutting the site down in early 2020.
If you found something useful today, please consider a small donation.
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:
(Linux) -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.
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 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.
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.
You'd expect sequential responses normally:
64 bytes from 126.96.36.199: icmp_seq=0 ttl=55 time=82.358 ms 64 bytes from 188.8.131.52: icmp_seq=1 ttl=55 time=81.264 ms 64 bytes from 184.108.40.206: icmp_seq=2 ttl=55 time=82.797 ms 64 bytes from 220.127.116.11: icmp_seq=3 ttl=55 time=81.718 ms 64 bytes from 18.104.22.168: 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.
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.
There are other tools, but tcpping is "ping-like".
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.
If you found something useful today, please consider a small donation.
Got something to add? Send me email.
More Articles by Anthony Lawrence © 2013-09-10 Anthony Lawrence