TOTAL
Since dec 2006
1'942'871 Visitors
4'218'042 Pages

Nov 2010 Stats
82'909 Visitors
146'476 Pages
196 countries
Full statistics



Help us translate
our tutorials!

JOIN the
OpenManiak Team.
OM TEAM
Director:
Blaise Carrera
Tutorials creation:
Blaise Carrera
Translaters:
Giovanni Fredducci
Angel Chraniotis
Moham. H. Karvan
Alexandro Silva
Blaise Carrera
Andrei Chertolyas
Sergiy Uvarov
Nickola Kolev
Łukasz Nowatkowski
Ivo Raisr
Catalin Bivolaru
Bogdan A. Costea
Kirill Simonov
Oliver Mucafir
JaeYoung Jeon
Seungyoon Lee
Jie Yu & Si Cheng
Tao Wei
YukiAlex
Fumihito Yoshida
Muhammad Takdir
Çağdaş Tülek
Auditors
Leslie Luthi
Joe Anderson
Jennifer Ockwell
Nigel Titley
Alison Rees
Sabrina Barbey
Webmaster:
Blaise Carrera
PING - The Easy Tutorial

Networking Ping
Last Change : Mar 23 2011




If you like our tutorials, don't hesitate to support us and visit our sponsors!
Si vous aimez nos tutoriaux, n'hésitez pas à nous supporter et visiter nos sponsors!


Ping - Table of content

INTRODUCTION
    ICMP packet overview
    Ping working
CASE STUDY
OUTPUT ANALYSIS
    Host Reachability
    Network congestion (RTT)
    Travel Length (TTL)
ICMP PACKET IN-DEPTH ANALYSIS
    Echo Request
    Echo Response
PING ARGUMENTS
    Windows
    Linux
ICMP HEADER
IP ADDRESS and HOSTNAME



INTRODUCTION

Ping is a well known tool to check network connectivity between two IP hosts. It was created in 1983 by Mike Muuss who wrote an article about his tool " The Story of the PING Program" short before dying in 2000 in a car accident.

Ping is installed by default on Windows, Apple and Linux/Unix operating systems.
It uses the ICMP protocol which has been created to check IP connectivity and get information about other machines in an IP network.
ICMP is encapsulated in an IP packet, but is considered part of the IP or Internet layer.

ICMP packet structure overview.

icmp paceket structure overview

Ping functioning

Ping sends very small packets to an IP host who will answer by sending packets back.
The ICMP packets sent to the host are called echo_request and the packets sent back echo_response.
There are also a lot of other
ICMP packets types which are described below in this page.

ping picture

Top of the page



CASE STUDY

Let's examine a case study where two machines called Paris and Berlin ping a machine called "www.google.ch".
The Wireshark sniffer is located on the way between Berlin and "www.google.ch". It will be used to capture the packets content.
Paris is a Linux Ubuntu machine and Berlin a Microsoft XP Machine.

ping tutorial scenario

Ping from the Linux machine (Paris) to "www.google.ch":

Paris: ping www.google.ch

PING www.google.ch (209.85.135.105) 56(84) bytes of data.
64 bytes from www.google.ch(209.85.135.105): icmp_seq=1 ttl=255 time=1.19 ms
64 bytes from www.google.ch (209.85.135.105): icmp_seq=2 ttl=255 time=1.25 ms
64 bytes from www.google.ch (209.85.135.105): icmp_seq=3 ttl=255 time=1.26 ms
64 bytes from www.google.ch (209.85.135.105): icmp_seq=4 ttl=255 time=1.29 ms

--- www.google.ch ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3003ms
rtt min/avg/max/mdev = 1.192/1.250/1.290/0.044 ms
Ping from the Windows machine (Berlin) to "www.google.ch":

Berlin: ping www.google.ch

Pinging www.google.ch [209.85.135.105] with 32 bytes of data:

Reply from 209.85.135.105: bytes=32 time=18 ms TTL=250
Reply from 209.85.135.105: bytes=32 time=21 ms TTL=250
Reply from 209.85.135.105: bytes=32 time=20 ms TTL=250
Reply from 209.85.135.105: bytes=32 time=33 ms TTL=250

Ping statistics for 209.85.135.105:
      Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
      Minimum = 18ms, Maximum = 33ms, Average = 23ms
What information can be learnt from the outputs above?

- Is the remote host alive? => Host reachability
- Is the network speed good? => Network congestion
- Is the remote host far? => Travel length

See the next section "OUTPUT ANALYSIS" for full details about how to interpret the results of the ping command.

We can also say that the Ping tool will provide us the same information independently of the OS on which it is installed. However there are some little differences in the default settings and arguments of the Ping commands. See the "PING ARGUMENTS" section for details.

Let's see a summary of data captured by Wireshark (full detail in the "IN-DEPTH ANALYSIS" section).

ping tutorial scenario

This Wireshark capture gives us the following information:

- The packets have been recognized as ICMP packets. protocol column
- Four ICMP packets have been sent (echo_request) and four ICMP packets have been received (echo_reply). info column
- A packet value of 74 bytes which is composed of the headers (42 bytes) and the ICMP data part (32 bytes by default on Windows). length column

Top of the page



OUTPUT ANALYSIS



As said in the previous section, Ping gives us three major information:

Host reachability
Network congestion
Time To Live

Host reachability

The Ping results in the previous section show that four ICMP packets have been sent and four received. This result indicates you that the host is alive at the ICMP level. However, no other information, such as whether or not a a webserver is running, is given.

What's does it mean if I receive a negative result?
Let's see an example:
C:\>ping www.openmaniak.com

Pinging openmaniak.com [84.16.88.15] with 32 bytes of data:

Request timed out.
Request timed out.
Request timed out.
Request timed out.

Ping statistics for 84.16.88.15:
      Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

Host www.openmaniak.com, which has IP address 84.16.88.15, did not answer to the Ping command. It's interesting to note that the negative answer does not always mean that the recipient is not alive (in our example, it is alive and runs a webserver). In this case, the result simply means that the host just doesn't answer to ICMP request.

What could be the reason for this "no-answer" ?
It is not always possible to know the exact reason behind a "no-answer". As a matter of fact, there may be a lot of different reasons. In the following picture, we summarize the four major reasons.

ping stop scenario

In the first case, an external firewall blocks the ICMP requests. ICMP can be used as a first step in an attack because it can determine the alive hosts before attacking. In this case the network behind the firewall is hidden from the external world even it is well alive.
Blocking ICMP messages is a first security recommendation to secure a network. The external firewall is more often used to secure professional network because it is expensive and requires advanced skills for configuring.

In the second case, the workstation has a personal firewall that blocks the ICMP message. A personal firewall is recommended for home computers for the same reasons mentioned above.

In the thrid case, the "pinged" machine is not connected to the IP network, for instance, because the network cable is unplugged.
The echo_request message will be discarded on the last router of the layer 3 device before the remote host.

In the fourth case, the host is down or has its network card deactivated. Such as in the previous case, the echo_request message will die on the last router of the layer 3 device before the remote host.



If a device called Geneva can ping another called Dallas, does it mean that the opposite, in other words Dallas can ping Geneva, is always true?
The response is no. As you can see below, you can have a firewall only preventing echo_request in a single direction.

When Dallas pings Geneva, the ICMP echo_request is blocked on the firewall and Dallas receives no answer from Geneva.

When Geneva pings Dallas, the ICMP echo_request reaches Dallas and Geneva receives the echo_response in return, so the ping is successful. In this case, the ICMP packets are not blocked since the firewall only stops echo_request coming from outside. Here, we have an echo_request from inside and an echo_response from outside.

ping stop scenario

Top of the page



Network Congestion

Another very precious information provided by the Ping command is the time taken for a packet to reach the destination and come back. This measure is called the RTT (Round Trip Time) or "response time" and is displayed in milliseconds.
It should not be mistaken for the latency or delay defined as the one-way time taken for a packet to travel across the network between two hosts.

The response time will affect network applications performance. High response times will lead to poor performances.
When a network application is slow, a first basic troubleshooting step is to get the reponse time between the client and the server to know if the network is the reason of the slowness.

We should not forget another information related to the response time: the packet loss. A packet is declared as lost if the ICMP message has been discard on the way or if is returned after the timeout value equal to 2 seconds by default. Packet losses will lead to a high TCP retransmission rate with the consequence of a slow or interrupted network application.
In a LAN environment, there shouldn't be any packet loss.



What affects the response time and the packet loss?

- THE NETWORK PIPES
Cable type and cable quality will greatly affect the response time. For example, fiber cables will be much more efficiency than old copper cables. Poor quality or damaged cables can lead to packet loss. Wide pipes will also help ensure low response times for in case of high traffic, the packets will not slow down. This can be compared to cars in a traffic jam.

- THE NETWORK DEVICES
Processing devices along the way can slightly increase the response time if they process packets slowly. For example, packets crossing an overworked router will be delayed because it will not have enough available resources to manage the packets quickly.

- THE PHYSICAL REMOTENESS
A device far from you will get slower response time than an identical device close to you. Indeed, even with excellent pipes and routers, the physical remoteness and the number of routers to cross to arrive to destination obviously have an impact on the response time.
To give very approximate values, response time in a LAN environment is around 1 or 2 milliseconds whereas in very far remote internet VPNs this time amounts to around 300 milliseconds.
Here is an example:
A ping from Geneva/Switzerland to Google Switzerland only takes about 30 ms whereas a ping to Google Japan takes 130 ms.

- SOURCE AND DESTINATION DEVICES
People often believe that low response time or packet loss are due to network problems. This is often not the case since the problems can come from the source or destination devices that are simply overloaded or have a faulty network card.
The ping output gives the minimum, average and maximum response times, helping us know whether the response time remains constant or varies a lot.

Top of the page



Time-to-Live

The TTL or Time-To-Live gives you an indication of the number of routers between the source and destination.
The TTL is used to prevent an IP packet from looping inside an IP network and causing a network meltdown.
The initial TTL packet value for an IP packet is 255 and then it is decremented by 1 each time it encounters a router. When this value reaches 0, the packet is discarded by a router. The TTL value is contained in each IP packet including ICMP packets. The TTL value given by the ping command is in fact the TTL value of an echo_response packet.
By default, Windows will decrease the TTL by 128 and Ubuntu Linux by 192.

Let us study three scenarios where A pings B. B is a router (first case), a Microsoft Windows machine (case 2) and a Ubuntu Linux machine (case 3).
The TTL value is initially 255 and then decreased as described as above.

The "IN-DEPTH ANALYSIS" section provides information about the TTL location in an IP packet.

Case 1:
When A pings B, it receives a TTL of 251 because the packets crossed 4 routers (-4).
TTL=255-4=251.

openmaniak scenario ttl time-to-live router

ping B

Pinging B [1.1.1.1] with 32 bytes of data:

Reply from 1.1.1.1: bytes=32 time=18 ms TTL=251
Reply from 1.1.1.1: bytes=32 time=21 ms TTL=251
Reply from 1.1.1.1: bytes=32 time=20 ms TTL=251
Reply from 1.1.1.1: bytes=32 time=33 ms TTL=251

Ping statistics for 1.1.1.1:
      Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
      Minimum = 18ms, Maximum = 33ms, Average = 23ms
Case 2:
When A pings B, it receives a TTL of 124 because the packets crossed 3 routers (-3) and a Windows machine (-128).
TTL=255-3-128=124.

openmaniak scenario ttl time-to-live microsoft windows

ping B

Pinging B [1.1.1.1] with 32 bytes of data:

Reply from 1.1.1.1: bytes=32 time=18 ms TTL=125
Reply from 1.1.1.1: bytes=32 time=21 ms TTL=125
Reply from 1.1.1.1: bytes=32 time=20 ms TTL=125
Reply from 1.1.1.1: bytes=32 time=33 ms TTL=125

Ping statistics for 1.1.1.1:
      Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
      Minimum = 18ms, Maximum = 33ms, Average = 23ms
Case 3:
When A pings B, it receives a TTL of 62 because the packets crossed 3 routers (-3) and an Ubuntu machine (-192).
TTL=255-3-192=60.

openmaniak scenario ttl time-to-live ubuntu linux

ping B

Pinging B [1.1.1.1] with 32 bytes of data:

Reply from 1.1.1.1: bytes=32 time=18 ms TTL=60
Reply from 1.1.1.1: bytes=32 time=21 ms TTL=60
Reply from 1.1.1.1: bytes=32 time=20 ms TTL=60
Reply from 1.1.1.1: bytes=32 time=33 ms TTL=60

Ping statistics for 1.1.1.1:
      Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
      Minimum = 18ms, Maximum = 33ms, Average = 23ms
Top of the page



IN-DEPTH ANALYSIS



This section will provide an in-depth analysis of an echo_request and an echo_response packet.

openmaniak scenario ttl time-to-live ubuntu linux

Echo request

The first array is the Wireshark capture printscreen and the second array is the Wireshark capture text output.

ping tutorial scenario

No.
Time
  
Source   
Destination  Protocol length Info
1
0.000000
192.168.1.100 209.85.135.105 ICMP 74 Echo (ping) request








Frame 1 (74 bytes on wire, 74 bytes captured)
Ethernet II, Src: Dell_11:11:11 (00:19:b9:11:11:11), Dst: ThomsonT_99:99:99 (00:18:f6:99:99:99)
Internet Protocol, Src: 192.168.1.100 (192.168.1.100), Dst: 209.85.135.105 (209.85.135.105)

Version: 4

Header length: 20 bytes

Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)


0000
00..
= Differentiated Services Codepoint: Default (0x00)


....
..0.
= ECN-Capable Transport (ECT): 0


....
...0
= ECN-CE:  0

Total Length: 60

Identification: 0x5671 (22129)

Flags: 0x00


 0..
= Reserved bit: Not Set


.0.
= Don't fragment: Not Set


..0
= More fragments: Not Set

Fragment offset: 0

Time to live: 128

Protocol: ICMP (0x01)

Header checksum: 0xc984 [correct]


[Good: True]


[Bad : False]

Source: 192.168.1.100 (192.168.1.100)

Destination: 209.85.135.105 (209.85.135.105)
Internet Control Message Protocol

Type: 8 (Echo (ping) request)

Code: 0 ()

Checksum: 0x4a5c [correct]

Identifier: 0x0200

Sequence number: 256 (0x0100)

Data (32 bytes)








0000
61 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e 6f 70
abcdefghijklmnop
0010 71 72 73 74 75 76 77 61 62 63 64 65 66 67 68 69
qrstuvwabcdefghi



Data: 6162636465666768696A6B6C6D6E6F707172737475767761...



[Length: 32]

- The Wireshark capture (in the grey first array) shows the different OSI layers (Ethernet - IP - IMCP). Also see the "ICMP packet structure overview" section.
- The packet has been recognized as ICMP in the IP layer.
- The ICMP layer is composed of an ICMP header section and ICMP data section.
- The ICMP header section is composed of the type, code, checksum, identifier and sequence numbers.
- The type has a value of 8 meaning that the packet is a echo_request packet.
- The sequence number value (here 256) is used to help match the echo request with the associated reply (echo responses).



Echo response

The first array is the Wireshark capture printscreen and the second array is the Wireshark capture text output.

ping tutorial scenario

No.
Time
  
Source   
Destination  Protocol length Info
2
0.028303
209.85.135.105 192.168.1.100 ICMP 74 Echo (ping) reply








Frame 2 (74 bytes on wire, 74 bytes captured)
Ethernet II, Src: ThomsonT_70:42:2d (00:18:f6:99:99:99), Dst: Dell_53:af:a6 (00:19:b9:11:11:11)
Internet Protocol, Src: 209.85.135.105 (209.85.135.105), Dst: 192.168.1.100 (192.168.1.100)

Version: 4

Header length: 20 bytes

Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)


0000
00..
= Differentiated Services Codepoint: Default (0x00)


....
..0.
= ECN-Capable Transport (ECT): 0


....
...0
= ECN-CE:  0

Total Length: 60

Identification: 0xf6bf (63167)

Flags: 0x00


 0..
= Reserved bit: Not Set


.0.
= Don't fragment: Not Set


..0
= More fragments: Not Set

Fragment offset: 0

Time to live: 251

Protocol: ICMP (0x01)

Header checksum: 0x7336 [correct]


[Good: True]


[Bad : False]

Source: 209.85.135.105 (209.85.135.105)

Destination: 192.168.1.100 (192.168.1.100)
Internet Control Message Protocol

Type: 0 (Echo (ping) reply)

Code: 0 ()

Checksum: 0x525c [correct]

Identifier: 0x0200

Sequence number: 256 (0x0100)

Data (32 bytes)








0000
61 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e 6f 70
abcdefghijklmnop
0010 71 72 73 74 75 76 77 61 62 63 64 65 66 67 68 69
qrstuvwabcdefghi



Data: 6162636465666768696A6B6C6D6E6F707172737475767761...



[Length: 32]

- The Wireshark capture (in grey first array) shows the different OSI layers (Ethernet - IP - IMCP). Also see the "ICMP packet structure overview" section.
- The TTL value of the echo_response packet is 251, which is also the TTL value displayed in the ping tool.
- The packet has been recognized as ICMP in the IP layer.
- The ICMP layer is composed of an ICMP header section and ICMP data section.
- The ICMP header section is composed of the type, code, checksum, identifier and sequence numbers.
- The type has a value of 0 meaning that the packet is a echo_response packet.
- The sequence number value (here 256) is used to help match the echo request with the associated reply (echo responses).

Top of the page



PING ARGUMENTS

Ping works the same way under windows and Linux. However there are some subtle differences in the use and presentation of the Ping command.

Default use:

- Windows only sends four ICMP request whereas Linux will send these same packets indefinitely. the "Cltr + C" command will interrupt the echo_request packet sending.
- The data field of an ICMP packet is 56 bytes under Linux and 32 under windows. It means the ICMP packet total length, which includes the headers of 42 bytes, is 98 bytes under Linux and 74 under windows.

Arguments:

Some arguments may be different between Linux and Windows. For example, the -l option is used to set the packet size under windows whereas under Linux, the "-s" argument is used for the same purpose.
See below for full details about the windows and Linux arguments.

Output:

Linux displays another value in the ping output command called the mean deviation (mdev) that is calculated using the response time values. It basically gives an indication about the response time constancy. In other words, a low mean deviation value will say that the reponse time values given by the ping command are very similar.

Ping arguments with Windows

c:/ping -h

Usage: ping [-t] [-a] [-n count] [-l size] [-f] [-i TTL] [-v TOS]
  [-r count] [-s count] [[-j host-list] | [-k host-list]]
[-w timeout] [-R] [-S srcaddr] [-4] [-6] target_name
Options:
-t  Ping the specified host until stopped.
To see statistics and continue - type Control-Break;
To stop - type Control-C.
-a     Resolve addresses to hostnames
-n count   Number of echo requests to send.
-l size  Send buffer size.
-f    Set Don't Fragment flag in packet (IPv4-only).
-i TTL Time To Live.
-v TOS Type Of Service (IPv4-only).
-r count  Record route for count hops (IPv4-only).
-s count Timestamp for count hops (IPv4-only).
-j host-list  Loose source route along host-list (IPv4-only).
-k host-list  Strict source route along host-list (IPv4-only).
-w timeout Timeout in milliseconds to wait for each reply.
-R Trace round-trip path (IPv6-only).
-S srcaddr  Source address to use (IPv6-only).
-4    Force using IPv4.
-6    Force using IPv6.

Ping arguments with Linux

#man ping

NAME


ping, ping6 - send ICMP ECHO_REQUEST to network hosts



SYNOPSIS


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



DESCRIPTION


ping uses the ICMP protocolâs mandatory ECHO_REQUEST datagram to elicit 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 used to fill out the packet



OPTIONS


-a Audible ping.




-A Adaptive ping. Interpacket interval adapts to round-trip time, so that effectively not more than one (or more, if preload is set) unanswered probes present in the network. Minimal interval is 200msec for not super-user.  On networks with low rtt this mode is essentially equivalent to flood mode.




-b Allow pinging a broadcast address.




-B Do not allow ping to  change  source  address  of  probes.   The address is bound to one selected when ping starts.




-c count


Stop after sending count ECHO_REQUEST packets. With deadline option, ping waits for count ECHO_REPLY packets, until the timeout expires.   




-d Set  the SO_DEBUG option on the socket being used.  Essentially, this socket option is not used by Linux kernel.   




-F flow label


Allocate and set 20 bit flow  label  on  echo  request  packets.  (Only  ping6).  If  value  is zero, kernel allocates random flow label.




-f Flood ping. For every ECHO_REQUEST sent a period ââ.ââ is printed, while for ever ECHO_REPLY received a backspace is printed.  This provides a  rapid  display of  how many packets are being dropped.  If interval is not given, it sets interval to zero and outputs packets 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.




 -i interval


Wait interval seconds between sending each packet.  The default is to wait for one second between each packet normally, or not to wait  in  flood  mode.  Only super-user may set interval to values less 0.2 seconds.




-I interface address


Set  source  address to specified interface address. Argument may be numeric IP address or name of device. When pinging IPv6 link-local address this option is required.




-l preload


If preload is specified, ping sends that many packets not waiting for reply.  Only the super-user may select preload more than 3.




-L


Suppress loopback of multicast packets.  This flag only applies if the ping destination is a multicast address.




-n


Numeric output only.  No attempt will be made to lookup symbolic names for host addresses.




-p pattern


You may specify up to 16 ââpadââ bytes to fill out the packet you send.  This is 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.  Traditionally (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).  You must be 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.  In 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 output.  Nothing is displayed except the summary lines at startup time and when finished.




-R


Record route.  Includes the RECORD_ROUTE option in the ECHO_REQUEST packet and displays the route buffer on returned packets.  Note that the IP header is only large enough for nine such routes.  Many hosts ignore or discard this option.




-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.  This option can be used to ping a local host through an interface that has no route through it provided the option -I is also used.




-s packetsize


Specifies the number of data bytes to be sent.  The default is 56, which translates into 64 ICMP data bytes when combined with the  8  bytes  of  ICMP  header data.




-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


Set  special  IP  timestamp  options.  timestamp option may be either 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 Print full user-to-user latency (the old behaviour). 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


Specify a timeout, in 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


Time to wait for a response, in seconds. The option affects only timeout in absense of any responses, otherwise ping waits for two RTTs.

Top of the page



ICMP HEADER

The ICMP header is composed of a:

- Type
- Code
- Header checksum
- ID
- Sequence

Below, you can find the ICMP protocol structure.

ping icmp header

Below, you can find some ICMP types.

Type  Description
   
0 Echo reply
3 Destination unreachable
4 Source quench
5 Redirect
8 Echo request
9 Router advertisement
10 Router solicitation
11 Time exceeded
12 Parameter problem
13 Timestamp request
14 Timestamp reply
15 Information request
16 Information reply
17 Address mask request
18 Address mask reply
30 Traceroute
Top of the page



IP address and hostname

Ping is also very frequently used to determine the IP address matching a host name and vice-versa.

To know the IP address matching the openmaniak webiste:

ping www.openmaniak.com

Pinging openmaniak.com [84.16.88.15] with 32 bytes of data:

Request timed out.
Request timed out.
Request timed out.
Request timed out.

Ping statistics for 84.16.88.15:
      Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

The host does not answer, but it does not matter since in this case, the result we are looking for is the IP address displayed in the Ping output.

If you have an IP address and would like to see if there is a hostname associated with it:

ping -a 84.16.88.15

Pinging imu138.infomaniak.ch [84.16.88.15] with 32 bytes of data:

Request timed out.
Request timed out.
Request timed out.
Request timed out.

Ping statistics for 84.16.88.15:
      Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

The hostname matching the 84.16.88.15 IP address is imu138.infomaniak.ch.

Top of the page





If you liked our tutorials, don't hesitate to support us and visit our sponsors!
Si vous aimez nos tutoriaux, n'hésitez pas à nous supporter et visiter nos sponsors!