ping, ping6 - send ICMP ECHO_REQUEST to network hosts
ping [ -LRUbdfnqrvVaAB] [ -c count] [ -i interval] [ -l preload] [ -p pattern]
[ -s packetsize] [ -t ttl] [ -w deadline] [ -F flowlabel] [ -I interface]
[ -M hint] [ -Q tos] [ -S sndbuf] [ -T timestamp option] [ -W timeout] [ hop ...]
destination
Send and ICMP ECHO_REQUEST which elicits an ICMP ECHO_RESPONSE from a host or gateway.
ECHO_REQUEST datagrams (pings) have an IP and
ICMP header, followed by a struct timeval and then an arbitrary number of pad bytes
to fill out the packet.
Implementation of ICMP protocol's ECHO_REQUEST/ECHO_RESPONSE is mandatory for an IP installation to be conformant.
Due to abuses some hosts, espically residential routers, may be configured to ignore the REQUEST.
The objective is to validate connectivity and minimaly qualify the interaction between the local host and a destination and all components in between. No authentiation is used and since the implementation is (usually) in the basic TCP/IP system
not in an associated application, many of the potential problems at the destination are avoided.
If the ping is sucessful then the
- Basic TCP/IP module in all hosts/gateways/switches/bridges/routers are installed and configured.
- NetworkInterfaceCards in all components are installed and operational
- Cabling between all components are connected
- Routing information amongst all components is (minimally) correct.
- IF a destination host name was used then name resolution, either by
/etc/hosts or
by a DomainNameServer, is working (at least for the destination).
Success does not mean that all routing table information, interfaces, cables or name resolutions are
totaly functional, but at least they work for the tested case.
Basic usage
> ping ns.hicom.net
PING ns.hicom.net (208.245.180.2) 56(84) bytes of data.
64 bytes from ns.hicom.net (208.245.180.2): icmp_seq=1 ttl=244 time=83.2 ms
64 bytes from ns.hicom.net (208.245.180.2): icmp_seq=2 ttl=244 time=101 ms
64 bytes from ns.hicom.net (208.245.180.2): icmp_seq=3 ttl=244 time=166 ms
64 bytes from ns.hicom.net (208.245.180.2): icmp_seq=4 ttl=244 time=87.3 ms
--- ns.hicom.net ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3000ms
rtt min/avg/max/mdev = 83.258/109.508/166.406/33.506 ms
RTT is round trip time, mdev is the maximun deviation
Since each ping packet may be transfered via a different set of intermediate nodes there may be
variation in time, TTL and even the succcess or failure from one ping to the next.
-a | Audible ping.
| -c count
send count ECHO_REQUESTs.
With deadline option, ping waits for count ECHO_REPLY packets, until the timeout expires.
| -n No lookup of destination names.
Use when no DomainNameServer is available.
| -F flow label ping6
Allocate and set 20 bit flow label on echo request packets. If value
is zero, kernel allocates random flow label.
| -l preload sends preload packets not waiting for reply.
Only the super-user may preload more than 3.
| -i interval
seconds between sending each packet. default 1.000
Only super-user may use less 0.200 seconds.
| -f Flood
For ECHO_REQUESTs sent a dot is displayed,
for ECHO_REPLYs received a backspace is display.
provides very brief display of how
many packets are being dropped.
If interval is not given, packets are sent as fast as they come back or
one hundred times per second, whichever is more!
Only the super-user may use this option with zero interval.
| -A Adapt interval dynamically to round-trip time,
In an attempt to keep 1 ping present in the network not more than one (or more, if preload )
Minimum 200msec for not super-user.
| -I interface address
Set source address. Argument may be numeric IP address or name of device.
Required for IPv6 link-local address .
| -r Bypass the normal routing tables and send directly to a host on an attached interface.
If the host is not on a directly-attached network, an error is returned.
ping: sendmsg: Network is unreachable
Ping a local host through an interface that has no route through it provided -I is also used.
| -L | Suppress loopback of multicast packets. if destination is a multicast address.
| -p pattern
Up to 16 pad bytes to fill out the packet . Useful for diagnosing data-dependent problems in a network.
For example, -p ff will cause the sent packet to be filled with all ones.
| -Q tos Set Quality of Service -related bits in ICMP datagrams.
tos can be either decimal or
hex number.
RFC1349, these have been interpreted as: 0 for reserved
(currently being redefined as congestion control),
1-4 for Type of Service and 5-7
for Precedence.
Possible settings for Type of Service are: minimal cost: 0x02, reliability: 0x04, throughput: 0x08, low delay: 0x10.
Multiple TOS bits should not be set simultaneously.
Possible settings for special Precedence range from priority (0x20) to net control (0xe0).
root (CAP_NET_ADMIN capability) to use Critical or higher precedence value.
You cannot set bit 0x01 (reserved) unless ECN has been enabled in the kernel.
RFC2474, these fields has been redefined as
8-bit Differentiated Services (DS), consisting of: bits 0-1 of separate data (ECN will be used, here), and bits 2-7 of Differentiated Services Codepoint (DSCP).
| -q | Quiet, only the summary lines at startup time and when finished are displayed.
| -R Record route. (IPv4 only)
Includes the RECORD_ROUTE option in the ECHO_REQUEST packet and displays the route buffer on returned packets.
The header is only large enough for 9 routes.
Many hosts ignore or discard this option.
| -s packetsize
Number of data bytes to be sent.
default 56, i.e. 64 ICMP data bytes including header.
| -S sndbuf
Set socket sndbuf
If not specified, it is selected to buffer not more than one packet.
| -t ttl | Set the IP Time to Live.
| -T timestamp_option
tsonly (only timestamps),
tsandaddr (timestamps and addresses) or
tsprespec host1 [host2 [host3 [host4]]] (timestamp prespecified hops).
| -M hint
| Select Path MTU Discovery strategy. hint may be either do (prohibit fragmentation,
even local one), want (do PMTU discovery, fragment locally when packet size is
large), or dont (do not set DF flag).
| -U Display full user-to-user latency
Normally ping prints network round trip time, which can be different f.e. due to DNS failures.
| -v | Verbose output.
| -V | Show version and exit.
| -w deadline
seconds, before ping exits regardless of how many packets have
been sent or received.
In this case ping does not stop after count packet are sent,
it waits either for deadline expire or until count probes are answered or for some
error notification from network.
| -W timeout | wait for a response seconds. The option affects only timeout in absense
of any responses, otherwise ping waits for two RTTs.
| -b | Allow pinging a broadcast address.
| -B | Bind to source address selected when ping starts.
| -d | Set the SO_DEBUG option on the socket being used. not used by Linux kernel.
| | | | | | | | | | | | | | | | | | | | | | | | | | | | |
Fault isolation:
- ping the local host at 127.0.0.0 to verify that the network interface is up and TCP/IP is running.
- ping the local host by name to verify the DomainNameResolution is working
- ping hosts and gateways further and further away or
Use traceroute
Round-trip times and packet loss statistics are computed.
Duplicate packets are not included in the packet loss calculation,
the round trip time is used in calculating the minimum/average/maximum round-trip time numbers.
When the specified number of packets have been sent
or if the program is terminated with a SIGINT, a brief summary is displayed.
Statistics are output without termination with SIGQUIT.
If ping does not receive any reply packets it exits with code 1.
If a packet count and deadline are both specified, and fewer than count packets are received by the time
the deadline has arrived, it will exit with code 1.
On other errors it exits with code 2.
Otherwise it exits with code 0.
This makes it possible to use the exit code to see if a host is alive.
Ping is intended for use in network testing, measurement and management.
It can impose excessive on the network, it is unwise to use ping during normal operations or
from automated scripts.
ICMP Packet Details
An IP header without options is 20 bytes long, an ICMP ECHO_REQUEST adds 8 .
Aditional size bytes are added, default 56 for a total of 84.
The amount of data received inside of an ICMP ECHO_REPLY is 8
bytes more than the requested size (the ICMP ECHO_REQUEST header).
If size is at least of size of struct timeval ping includes a timestamp at the beginning of
to compute round trip times.
Duplicate and DAMAGED Packets
Duplicate packets seem to be caused by inappropriate link-level retransmissions, if they occur
at low frequency it may not be cause for alarm.
Damaged packets often indicate broken hardware
somewhere in the route traceroute can aid in diagnosing the route. Remember that each ping may take a different path to and from the target.
Different Data Patterns
The network should not treat packets differently depending on the data. Data-dependent problems have been known to appear.
The pattern that will have problems is something that doesn't have sufficient transitions
such as all ones or all zeros, or a pattern right at the edge, such as almost all zeros. It
isn't necessarily enough to specify a data pattern of all zeros (for example) on the command
line because the pattern that is of interest is at the data link level, and the relationship
between what you type and what the controllers transmit can be complicated.
A find a file that either can't be
sent across your network or that takes much longer to transfer than other similar length
files indicates a data dependent problem. You can then examine this file for repeated patterns that you can test using -p.
TTL Details
Time to live is the remaining number of times a packet will be transfered from one host or router to another and has nothing to due with time.
Each transfer decrements the TTL and if it becomes 0, the packet is not transfered to the next destination.
This prevents packets from being constantly transfered in the event of a routing definition error.
For example host1 forwards to routerA which forwards to host1.
TTL is used in all protocols.
The maximun is 255, the default varies with the system and the protocol.
This may be why ping reaches a host, but telnet or ftp which (may use 30) cannot.
When the destination system receives ping, it creates an IMCP ECHO_REPLY with a TTL of
- the value from the
REQUEST
this case the TTL value in the received packet will be 255 minus the number of routers in the round-trip path.
- Set it to 255; . In this case the TTL value
in the received packet will be 255 minus the number of routers in the path from the remote
system to the pinging host.
- Set it to some other value. Some machines use the same value for ICMP packets that they
use for TCP packets, for example either 30 or 60.
To determine what each endpoint starts with and replies to, first ping each host from itself.
> ping ns.hicom.net
PING ns.hicom.net (208.245.180.2) 56(84) bytes of data.64 bytes from ns.hicom.net (208.245.180.2): icmp_seq=1 ttl=244 time=83.2 ms
64 bytes from ns.hicom.net (208.245.180.2): icmp_seq=2 ttl=244 time=101 ms
64 bytes from ns.hicom.net (208.245.180.2): icmp_seq=3 ttl=244 time=166 ms
64 bytes from ns.hicom.net (208.245.180.2): icmp_seq=4 ttl=244 time=87.3 ms--- ns.hicom.net ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3000ms
rtt min/avg/max/mdev = 83.258/109.508/166.406/33.506 ms
In the example the value of 244 indicates that there were 11 transfers FROM destination to the originating host.
This can be confirmed with traceroute.
- Many Hosts and Gateways ignore the
RECORD_ROUTE -r option.
- The maximum IP header length is too small for options like
RECORD_ROUTE to be completely useful.
- Flood pinging is not recommended in general, and flood pinging the broadcast address
should only be done under very controlled conditions.
SEE ALSO
netstat(1), ifconfig(8).
SECURITY
ping requires CAP_NET_RAWIO capability to be executed. It may be used as set-uid root.
92 bytes from hotspot.hotspot (192.168.17.1): Destination Port Unreachable
Vr HL TOS Len ID Flg off TTL Pro cks Src Dst
4 5 00 0054 7115 0 0000 3f 01 3db7 192.168.17.150 216.104.34.54