An Overview of ping

Trying to figure out if your laptop is connected to your home or office network? ping it.


ping is a diagnostic tool used for verifying connectivity between
two hosts on a network. It sends Internet Control Message Protocol
(ICMP) echo request packets to a remote IP address and watches for ICMP
responses. The author of the initial version of the ping program that
we use today was Mike Muss. Many other people have tweaked, rewritten
and variously abused ping since then.

The name ping itself is somewhat colorful. Some people claim that
it is an acronym standing for Packet INternet Groper, but this is not
the case. ping was named after the sound a sonar tracking system makes.
There even is a story claiming that a system administrator wrote a
script that repeatedly pinged a host on the network and made an audible
"pinging" alert for each success. The system administrator then was able
to go through his network methodically checking BNC connectors until he
found the dodgy connector that had been plaguing his network. When the
noises stopped, he'd found the culprit.

ping used to be a good indicator of a machine's general ability to receive
and send IP packets. If you could ping a host, you also could make an
FTP or HTTP connection. With the wider advent of packet filtering for
security, though, this is becoming less true. Many firewalls explicitly
disallow ICMP packets on the twin grounds that people don't need to know
what your internal network looks like and any protocol can be used to
launch an attack, even ICMP.

Deciding whether to let ICMP through your firewall is a tough call to
make. There certainly are good uses for ICMP, but there also are attacks
based on ICMP. For example, the "ping of Death" uses oversized ping
packets to overload the IP stack of the target--often with spectacular
results. If you choose to allow ICMP into your network, make sure you've
thought about the repercussions.

Additional flavors of the ping command exist that have been written
for other purposes. Among the most common is fping, which
was written to ping a range of addresses. It commonly is used in
network scanners and monitors, such as saint and mon. Another variation
is the Net::Ping module, which provides a Perl implementation of ping
functionality that can be used easily from within a script without
calling an external program. You might use the script something like
this:

Example 1. Using Net::Perl

#!/usr/bin/perl -w

use strict;
use Net::Ping;
	  
my $host = $ARGV[0];
	  
my $p = Net::Ping->new("icmp");
	  
if ($p->ping($host)) {
    print "$host is alive.\n";
} else {
    print "$host is not reachable.\n";
}

ping at Work
ping most often is used without additional arguments and is shut off with
Ctrl-c. The result looks like this:

[pate@cherry pate]$ ping mango
PING mango (192.168.1.1) from 192.168.1.10 : 56(84) bytes of data.
64 bytes from mango (192.168.1.1): icmp_seq=0 ttl=255 time=0.5 ms
64 bytes from mango (192.168.1.1): icmp_seq=1 ttl=255 time=0.3 ms
64 bytes from mango (192.168.1.1): icmp_seq=2 ttl=255 time=0.3 ms
64 bytes from mango (192.168.1.1): icmp_seq=3 ttl=255 time=0.3 ms
64 bytes from mango (192.168.1.1): icmp_seq=4 ttl=255 time=0.3 ms
64 bytes from mango (192.168.1.1): icmp_seq=5 ttl=255 time=0.3 ms

--- mango ping statistics ---
6 packets transmitted, 6 packets received, 0% packet loss
round-trip min/avg/max = 0.3/0.3/0.5 ms
[pate@cherry pate]$ 

This output can be split into three sections. The first section, the single
line starting with the word PING, shows an overview of the command.
The second section, the lines beginning with 64
bytes
shows a running tally of the responses received. The third
section, everything after the line --- mango ping statistics
---
, shows a summary of the results. In this case, the
results are good: none of the packets was dropped and they all were passed
fairly quickly.

This example also illustrates another important point: you should not rely on
a single packet to diagnose your network. A series of five or ten
packets is much better, as you can count up to 40% data loss as congestion
on a network. Even a single dropped packet can be attributed to a busy
host on the other end.

Several useful options can be used with the ping command. These are
summarized in the following table:

Table 1. ping Command Options
OptionDescription-c countStop sending and receiving packets after
count packets.-dSet the SO_DEBUG on the socket used.-fSend the packets as fast as possible. (flood)-i waitSet an interval of wait
seconds between packets.-I (device)Set the output interface.-l preloadSend preload packets as fast as possible, then drop
back to normal mode.-nDon't look up hostnames, just give IP addresses.
(numeric)-p patternSpecify up to 16 bytes of "pad data" to be sent with the
packet.-qOutput only summary lines. (quiet)-rDon't use routing tables to send the packet, just drop it out the local
interface.-RSet the Record Route option.-s packetsizeSet the number of data bytes sent to
packetsize.-T tsonlySend a ping with the timestamp option.-T tsandaddrCollect timestamps and addresses-T tsprespec [host1 [host2 [host3 [host4]]]]Collect timestamps and addresses from prespecified hops.
These options can be combined to make ping even more helpful. One thing
you cannot see is that the ping command used in the previous
section is likely to take several seconds to run and report back. Using
the -f option, though, can reduce the time spent waiting for the command.
Combining this with the -c 10 and the -q options can give you quicker results
and easier output to read:

	[root@cherry /root]# ping -c 10 -fq mango
PING mango (192.168.1.1) from 192.168.1.10 : 56(84) bytes of data.

--- mango ping statistics ---
10 packets transmitted, 10 packets received, 0% packet loss
round-trip min/avg/max = 0.2/0.2/0.9 ms
[root@cherry /root]# 

Note: The -f and -l options can be used only by root, as they can cause
serious network degradation if misused.

If it might be of some benefit to test larger packets, using ping -c10 -s
1024 -qf
sends larger packets for you. This can be especially
useful where you suspect problems with fragmented packets.

To see the route that your packets are traversing, you can use
ping -c10 -R, which produces the following output:

PING tbr.nailed.org (206.66.240.72) from 192.168.1.10 : 56(124) bytes of data.
64 bytes from bigfun.whirlycott.com (206.66.240.72): icmp_seq=0 ttl=239 
time=217.2 ms
RR: 	192.168.1.10
	216.41.39.90
	serial0.mmgw32.bos1.Level3.net (209.244.39.25)
	208.218.130.22
	166.90.184.2
	so-6-0-0.mp2.NewYork1.level3.net (209.247.10.45)
	137.39.52.10
	180.ATM7-0.BR2.NYC9.ALTER.NET (152.63.22.229)
	lo0.XR2.NYC9.ALTER.NET (137.39.4.175)

64 bytes from bigfun.whirlycott.com (206.66.240.72): icmp_seq=1 ttl=239 
	time=1940.8 ms	(same route)
64 bytes from bigfun.whirlycott.com (206.66.240.72): icmp_seq=2 ttl=239 
	time=250.6 ms	(same route)
64 bytes from bigfun.whirlycott.com (206.66.240.72): icmp_seq=3 ttl=239 
	time=230.3 ms	(same route)
64 bytes from bigfun.whirlycott.com (206.66.240.72): icmp_seq=4 ttl=239 
	time=289.8 ms	(same route)
64 bytes from bigfun.whirlycott.com (206.66.240.72): icmp_seq=5 ttl=239 
	time=1261.4 ms	(same route)
64 bytes from bigfun.whirlycott.com (206.66.240.72): icmp_seq=6 ttl=239 
	time=469.4 ms	(same route)
64 bytes from bigfun.whirlycott.com (206.66.240.72): icmp_seq=7 ttl=239 
	time=1272.3 ms	(same route)
64 bytes from bigfun.whirlycott.com (206.66.240.72): icmp_seq=8 ttl=239 
	time=353.1 ms	(same route)
64 bytes from bigfun.whirlycott.com (206.66.240.72): icmp_seq=9 ttl=239 
time=1281.1 ms	(same route)

--- tbr.nailed.org ping statistics ---
10 packets transmitted, 10 packets received, 0% packet loss
round-trip min/avg/max = 217.2/756.6/1940.8 ms

Note: The record route option specified by the -R option is not
honored by all routers and hosts. Further, it contains limited
space to hold router addresses. Therefore, traceroute may be a better tool for
identifying the path packets take through a network.

Overall, the ping command is a useful tool for your troubleshooting kit
and should not be overlooked.

Copyright (c) 2000, Pat Eyler and New Riders Publishing. Originally published in Linux
Gazette issue 56. It is presented under the
Open Publication
License
, with no additional terms applied.

Pat Eyler is a Linux/UNIX/networking geek who enjoys
playing on the command line. When he's not puttering with or writing
about computers and networks, he likes to play with his kids, cook
and read.

______________________

--
-pate
http://on-ruby.blogspot.com

Comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Timestamp options

quique's picture

Warning: these options work with the ping command available in the iputils package, but not with the one from the netkit package.

-T tsonly Send a ping with the timestamp option.
-T tsandaddr Collect timestamps and addresses
-T tsprespec [host1 [host2 [host3 [host4]]]] Collect timestamps and addresses from prespecified hops.

Misspelled Mike's last name

Don Tidrow's picture

It's "Muuss"

And the original story of why he created it is at

http://ftp.arl.mil/~mike/ping.html

The story of ping

Network Geek's picture

Aw, you beat me to it by mere hours!

Mike was a great guy. I talked with him about other, non-computer stuff via e-mail for quite some time and never knew he was the inventor of ping. It's a shame that a senseless car accident should have taken such a genius away from us.
He's very much missed.

Webinar
One Click, Universal Protection: Implementing Centralized Security Policies on Linux Systems

As Linux continues to play an ever increasing role in corporate data centers and institutions, ensuring the integrity and protection of these systems must be a priority. With 60% of the world's websites and an increasing share of organization's mission-critical workloads running on Linux, failing to stop malware and other advanced threats on Linux can increasingly impact an organization's reputation and bottom line.

Learn More

Sponsored by Bit9

Webinar
Linux Backup and Recovery Webinar

Most companies incorporate backup procedures for critical data, which can be restored quickly if a loss occurs. However, fewer companies are prepared for catastrophic system failures, in which they lose all data, the entire operating system, applications, settings, patches and more, reducing their system(s) to “bare metal.” After all, before data can be restored to a system, there must be a system to restore it to.

In this one hour webinar, learn how to enhance your existing backup strategies for better disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible bare-metal recovery solution for UNIX and Linux systems.

Learn More

Sponsored by Storix