ping (networking utility)
ping is a computer network administration software utility used to test the reachability of a host on an Internet Protocol (IP) network. It measures the round-trip time for messages sent from the originating host to a destination computer that are echoed back to the source. The name comes from active sonar terminology that sends a pulse of sound and listens for the echo to detect objects under water, although it is sometimes interpreted as a backronym to packet Internet groper.
Ping operates by sending Internet Control Message Protocol (ICMP/ICMP6) Echo Request packets to the target host and waiting for an ICMP Echo Reply. The program reports errors, packet loss, and a statistical summary of the results, typically including the minimum, maximum, the mean round-trip times, and standard deviation of the mean.
The command-line options of the ping utility and its output vary between the numerous implementations. Options may include the size of the payload, count of tests, limits for the number of network hops (TTL) that probes traverse, and interval between the requests. Many systems provide a companion utility ping6, for testing on Internet Protocol version 6 (IPv6) networks.
The ping utility was written by Mike Muuss in December 1983 as a tool to troubleshoot problems in an IP network. He was inspired by a remark by David Mills on using ICMP echo packets for IP network diagnosis and measurements. The author named it after the sound that sonar makes, since its methodology is analogous to sonar's echo location.
Sample ping test
The following is the output of running ping on Linux for sending five probes to the target host www.example.com:
$ ping -c 5 www.example.com PING www.example.com(2606:2800:220:1:248:1893:25c8:1946 (2606:2800:220:1:248:1893:25c8:1946)) 56 data bytes 64 bytes from 2606:2800:220:1:248:1893:25c8:1946 (2606:2800:220:1:248:1893:25c8:1946): icmp_seq=1 ttl=58 time=138 ms 64 bytes from 2606:2800:220:1:248:1893:25c8:1946 (2606:2800:220:1:248:1893:25c8:1946): icmp_seq=2 ttl=58 time=137 ms 64 bytes from 2606:2800:220:1:248:1893:25c8:1946 (2606:2800:220:1:248:1893:25c8:1946): icmp_seq=3 ttl=58 time=137 ms 64 bytes from 2606:2800:220:1:248:1893:25c8:1946 (2606:2800:220:1:248:1893:25c8:1946): icmp_seq=4 ttl=58 time=137 ms 64 bytes from 2606:2800:220:1:248:1893:25c8:1946 (2606:2800:220:1:248:1893:25c8:1946): icmp_seq=5 ttl=58 time=138 ms --- www.example.com ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 4005ms rtt min/avg/max/mdev = 137.200/137.961/138.817/0.649 ms
The output lists each probe message and the results obtained. Finally, it lists the statistics of the entire test. In this example, the shortest round trip time was 137.200 ms, the average was 137.961 ms, and the maximum value was 138.817 ms. The measurement had a standard deviation of 0.649 ms.
In cases of no response from the target host, most implementations of ping display nothing, or periodically print notifications about timing out. Possible ping outputs indicating a problem include the following:
- H, !N or !P – host, network or protocol unreachable
- S – source route failed
- F – fragmentation needed
- U or !W – destination network/host unknown
- I – source host is isolated
- A – communication with destination network administratively prohibited
- Z – communication with destination host administratively prohibited
- Q – for this ToS the destination network is unreachable
- T – for this ToS the destination host is unreachable
- X – communication administratively prohibited
- V – host precedence violation
- C – precedence cutoff in effect
In case of error, the target host or an intermediate router sends back an ICMP error message, for example "host unreachable" or "TTL exceeded in transit". In addition, these messages include the first eight bytes of the original message (in this case header of the ICMP echo request, including the quench value), so the ping utility can match responses to originating queries.
|Bits 0–7||Bits 8–15||Bits 16–23||Bits 24–31|
|Version/IHL||Type of service||Length|
|Identification||flags and offset|
|Time To Live (TTL)||Protocol||Header Checksum|
|Source IP address|
|Destination IP address|
|Type of message||Code||Checksum|
|Bits 0–3||Bits 4–7||Bits 8–11||Bits 12–15||Bits 16–23||Bits 24–31|
|Version||Traffic Class||Flow Label|
|Payload Length||Next Header||Hop Limit|
|Type of message||Code||Checksum|
Generic composition of an ICMP packet:
- IPv4 Header (in blue): protocol set to 1 (ICMP) and Type of Service set to 0.
- IPv6 Header (in blue): Next Header set to 58 (ICMP6)
- ICMP Header (in red):
- Type of ICMP message (8 bits)
- Code (8 bits)
- Checksum (16 bits), calculated with the ICMP part of the packet (the IP header is not used). It is the 16-bit one's complement of the one's complement sum of the ICMP message starting with the Type field
- Header Data (32 bits) field, which in this case (ICMP echo request and replies), will be composed of identifier (16 bits) and sequence number (16 bits).
- ICMP Payload: payload for the different kind of answers; can be an arbitrary length, left to implementation detail. However, the packet including IP and ICMP headers must be less than the maximum transmission unit of the network or risk being fragmented.
|Type = 8(IPv4, ICMP) 128(IPv6,ICMP6)||Code = 0||Header Checksum|
The Identifier and Sequence Number can be used by the client to match the reply with the request that caused the reply. In practice, most Linux systems use a unique identifier for every ping process, and sequence number is an increasing number within that process. Windows uses a fixed identifier, which varies between Windows versions, and a sequence number that is only reset at boot time.
The echo reply is an ICMP message generated in response to an echo request; it is mandatory for all hosts, and must include the exact payload received in the request.
|Type = 0(IPv4,ICMP) 129(IPv6,ICMP6)||Code = 0||Header Checksum|
- Type and code must be set to 0.(IPv4)
- The identifier and sequence number can be used by the client to determine which echo requests are associated with the echo replies.
The payload of the packet is generally filled with ASCII characters, as the output of the tcpdump utility shows in the last 32 bytes of the following example (after the eight-byte ICMP header starting with 0x0800):
16:24:47.966461 IP (tos 0x0, ttl 128, id 15103, offset 0, flags [none], proto: ICMP (1), length: 60) 192.168.146.22 > 192.168.144.5: ICMP echo request, id 1, seq 38, length 40 0x0000: 4500 003c 3aff 0000 8001 5c55 c0a8 9216 E..<:.....\U.... 0x0010: c0a8 9005 0800 4d35 0001 0026 6162 6364 ......M5...&abcd 0x0020: 6566 6768 696a 6b6c 6d6e 6f70 7172 7374 efghijklmnopqrst 0x0030: 7576 7761 6263 6465 6667 6869 uvwabcdefghi
The payload may include a timestamp indicating the time of transmission and a sequence number, which are not found in this example. This allows ping to compute the round trip time in a stateless manner without needing to record the time of transmission of each packet.
The payload may also include a magic packet for the Wake-on-LAN protocol, but the minimum payload in that case is longer than shown. The Echo Request typically does not receive any reply if the host was sleeping in hibernation state, but the host still wakes up from sleep state if its interface is configured to accept wakeup requests. If the host is already active and configured to allow replies to incoming ICMP Echo Request packets, the returned reply should include the same payload. This may be used to detect that the remote host was effectively woken up, by repeating a new request after some delay to allow the host to resume its network services. If the host was just sleeping in low power active state, a single request wakes up that host just enough to allow its Echo Reply service to reply instantly if that service was enabled. The host does not need to completely wake up all devices, and may return to low power mode after a short delay. Such configuration may be used to avoid a host to enter in hibernation state, with much longer wake up delay, after some time passed in low power active mode.
The "flood" ping option exists in many implementations, sending requests as fast as possible in an attempt to determine the response of the network under high-load conditions. That option is restricted to users having administrative privileges, but may be used in denial-of-service attacks to induce a ping flood, in which the attacker attempts to overwhelm the victim with ICMP echo requests.
Ping has been considered a security risk because merely acknowledging a host's presence turns it into a potential target. For these reasons, many systems provide means to disable the reply, despite the fact that RFC 1122 mandates hosts to always send a reply. Additionally, round-trip times calculated by ping often lack integrity checking and thus cannot be relied upon in hostile environments. An adversary could elongate or shorten the calculated delays in most ping implementations.
- Mike Muuss. "The Story of the PING Program". U.S. Army Research Laboratory. Archived from the original on 8 September 2010. Retrieved 8 September 2010.
I named it after the sound that a sonar makes, inspired by the whole principle of echo-location.
- Mills, D.L. (December 1983). Internet Delay Experiments. IETF. p. 1. STD 8. RFC 889. https://tools.ietf.org/html/rfc889#page-1. Retrieved June 26, 2015.
- "The Story of the PING Program", Mike Muuss
- Salus, Peter (1994). A Quarter Century of UNIX. Addison-Wesley. ISBN 0-201-54777-5.
- "RFC 1122 - Requirements for Internet Hosts -- Communication Layers". p. 42. Retrieved 2012-03-19.
Every host MUST implement an ICMP Echo server function that receives Echo Requests and sends corresponding Echo Replies.
- "ICMP: Internet Control Message Protocol". repo.hackerzvoice.net. January 13, 2000. Retrieved December 4, 2014.
- "RFC 792 - Internet Control Message Protocol". Tools.ietf.org. Retrieved 2014-02-02.
- "RFC Sourcebook's page on ICMP". Retrieved 20 December 2010.
- "Windows firewall: how block ICMP (echo response)".
- "redhat linux /proc/sys/net/ipv4 parameters".
- Abdou, AbdelRahman; Matrawy, Ashraf; van Oorschot, Paul (April 2017). Accurate Manipulation of Delay-based Internet Geolocation. ACM AsiaCCS. doi:10.1145/3052973.3052993.