Ping is an diagnostic tool for verifying connectivity between two
hosts on a network. It sends 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 will claim
that it is an acronym standing for the Packet INternet Groper, this
is not the case. Ping was named after the sound of a sonar tracking
system. There is even a story claiming that a system administrator
wrote a script which repeatedly pinged a host on the network and
made an audible "pinging" alert for each
success. The system administrator was then able to methodically go
through his network checking BNC connectors until he found the dodgy
connector that had been plaguing his network — when the noises
stopped, he'd found his culprit.
Ping used to be a very good indicator of a machines ability to
receive and send IP packets in general. If you could ping a host,
you could also make an ftp or http connection. With the wider advent
of packet filtering for security, this is becoming less true. Many
firewalls explicitly disallow ICMP packets on the twin grounds that,
|
1) people don't need to know what your internal network
looks like, |
|
2) 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 are certainly good uses for ICMP, but there are
also attacks based on ICMP (e.g., the
"Ping of
Death", which used oversized ping packets to overload the IP
stack of the target — with often spectacular results). If you choose
to allow ICMP into your network make sure you've thought about the
repercussions.
There are additional flavors of the ping command that have been
written for other purposes. Among the most common is the fping
command. Which was written to ping a range of addresses, and is
commonly used in network scanners and monitors like saint and mon
(both of which are covered in this chapter). Another variation is
the Net::Ping module, which provides a perl implementation of Ping
functionality that can easily be used 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 is most often used without additional arguments and shut off
with a Ctrl–c. The results
look 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 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" show 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 were dropped and they were all passed fairly quickly.
This example also shows another important point, you should not
rely on a single packet to diagnose your network. A series of five
or ten is much better, as you can count up to 40% data loss as
congestion on a network, and even a single packet dropped can be
attributed to a busy host on the other end.
There are several useful options to the ping command. These are
summarized in the following table:
Table 1. Ping Command Options
| Switch |
Description |
| -c
count |
Stop sending and receiving packets after count packets. |
| -d |
Set the SO_DEBUG on the socket used. |
| -f |
Send the packets as fast as possible. (flood) |
| -i
wait |
Set an interval of wait seconds
between packets. |
| -I
〈device〉 |
Sets the output interface. |
| -l
preload |
Sends preload packets as fast as
possible, then drops back to normal mode. |
| -n |
Don't look up hostnames, just give IP addresses. (numeric)
|
| -p
pattern |
Specify up to 16 bytes of "pad
data" to be sent with the packet. |
| -q |
Output only summary lines. (quiet) |
| -r |
Don't use routing tables to send the packet, just drop it
out the local interface. |
| -R |
Set the Record Route option. |
| -s
packetsize |
Set the number of data bytes sent to packetsize. |
| -T
tsonly |
Sends a ping with the timestamp option. |
| -T
tsandaddr |
Collects timestamps and addresses |
| -T
tsprespec [host1 [host2 [host3
[host4]]]] |
Collects timestamps and addresses from prespecified hops.
|
These options can be combined to make ping even more helpful. One
thing that 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 switch will
reduce the time spent waiting for the command. Combining this with
the -c 10 and the -q switches will give you quick 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 switches can only be used by root, as they
can cause serious network degradation if misused.
It might be of some benefit to test larger packets, using ping -c10 -s 1024 -qf will send 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. This command 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 switch is not honored by all routers
and hosts. Further, it contains only a limited space to hold router
addresses, traceroute may be a better tool for identifying the path
packets follow through a network.
