Ping

来源:互联网 发布:博弈树搜索算法是什么 编辑:程序博客网 时间:2024/04/30 13:50

http://openmaniak.com/ping.php


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 acar 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


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 msPing 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 = 23msWhat 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 tointerpret 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 littledifferences 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



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 thenetwork 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



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 thereponse 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.



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 = 23msCase 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 = 23msCase 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


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 ProtocollengthInfo10.000000 192.168.1.100209.85.135.105ICMP74Echo(ping) request        Frame 1 (74 bytes onwire,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: 20bytes DifferentiatedServices Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)  000000..=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 MessageProtocol Type: 8 (Echo (ping)request) Code:0 () Checksum: 0x4a5c[correct] Identifier: 0x0200 Sequence number: 256(0x0100) Data (32 bytes)        000061 62 63 64 65 66 6768 69 6a 6b 6c 6d 6e 6f 70abcdefghijklmnop001071 72 73 74 75 76 7761 62 63 64 65 66 67 68 69qrstuvwabcdefghi   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 ProtocollengthInfo20.028303 209.85.135.105192.168.1.100ICMP74Echo (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: 20bytes DifferentiatedServices Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)  000000..=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 MessageProtocol Type: 0 (Echo (ping) reply) Code:0 () Checksum: 0x525c [correct] Identifier: 0x0200 Sequence number: 256(0x0100) Data (32 bytes)        000061 62 63 64 65 66 6768 69 6a 6b 6c 6d 6e 6f 70abcdefghijklmnop001071 72 73 74 75 76 7761 62 63 64 65 66 67 68 69qrstuvwabcdefghi   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).



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] [-scount] [[-j host-list] | [-k host-list]] [-w timeout] [-R] [-Ssrcaddr] [-4] [-6] target_name  Options: -t Ping the specified hostuntil stopped. To see statistics andcontinue - type Control-Break; To stop - type Control-C.-a    Resolve addresses tohostnames-ncount  Number of echo requests tosend.-lsize Send buffer size.-f   Set Don't Fragment flag inpacket (IPv4-only).-i TTLTime To Live.-v TOSType Of Service(IPv4-only).-r count Record route for counthops (IPv4-only).-s countTimestamp for count hops(IPv4-only).-j host-list Loose source route alonghost-list (IPv4-only).-k host-list Strict source route alonghost-list (IPv4-only).-w timeoutTimeout in milliseconds towait for each reply.-RTrace 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 ICMPECHO_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   pinguses the ICMP protocolâs mandatory ECHO_REQUEST datagram to elicit anICMP ECHO_RESPONSE from a host or gateway.  ECHO_REQUEST datagrams(ââpingsââ) have an  IP and ICMP header, followed by a structtimeval and then an arbitrary number of ââpadââ bytes used to fill outthe packet   OPTIONS   -aAudibleping.    -AAdaptiveping. Interpacket interval adapts to round-trip time, so thateffectively not more than one (or more, if preload is set) unansweredprobes present in the network. Minimal interval is 200msec for notsuper-user.  On networks with low rtt this mode is essentiallyequivalent to flood mode.    -bAllowpinging a broadcast address.    -BDonot allow ping to  change  source  address of  probes.   The address is bound to one selectedwhen ping starts.    -c count  Stopafter sending count ECHO_REQUEST packets. With deadline option, pingwaits for count ECHO_REPLY packets, until the timeoutexpires.       -dSet the SO_DEBUG option on the socket being used. Essentially, this socket option is not used by Linux kernel.      -F flow label  Allocateand set 20 bit flow  label  on  echo  request packets.  (Only  ping6).  If  value  is zero,kernel allocates random flow label.    -fFloodping. For every ECHO_REQUEST sent a period ââ.ââ is printed, while forever ECHO_REPLY received a backspace is printed.  This providesa  rapid  display of  how many packets are beingdropped.  If interval is not given, it sets interval to zero andoutputs packets as fast as they come back or one hundred times persecond, whichever is more.  Only the super-user may use thisoption with zero interval.     -i interval  Waitinterval seconds between sending each packet.  The default is towait for one second between each packet normally, or not to wait in  flood  mode.  Only super-user may set interval tovalues less 0.2 seconds.    -I interface address  Set source  address to specified interface address. Argument may benumeric IP address or name of device. When pinging IPv6 link-localaddress this option is required.    -l preload  Ifpreload is specified, ping sends that many packets not waiting forreply.  Only the super-user may select preload more than 3.    -L   Suppressloopback of multicast packets.  This flag only applies if the pingdestination is a multicast address.    -n   Numericoutput only.  No attempt will be made to lookup symbolic names forhost addresses.    -ppattern  Youmay specify up to 16 ââpadââ bytes to fill out the packet yousend.  This is useful for diagnosing data-dependent problems in anetwork.  For example,  -p ff will cause the sent packet tobe filled with all ones.    -Qtos  Set Quality of Service -related bits in ICMP datagrams.  tos can beeither decimal or hex number.  Traditionally (RFC1349), these havebeen interpreted as: 0 for reserved (currently being redefined ascongestion control), 1-4 for Type of Service and 5-7 forPrecedence.  Possible settings for Type  of Service  are: minimal  cost: 0x02, reliability: 0x04,throughput: 0x08, low delay: 0x10.  Multiple TOS bits should notbe set simultaneously.  Possible settings for special Precedencerange from priority (0x20) to net control (0xe0).  You must beroot (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), andbits 2-7 of Differentiated Services Codepoint (DSCP).    -q   Quietoutput.  Nothing is displayed except the summary lines at startuptime and when finished.    -R   Recordroute.  Includes the RECORD_ROUTE option in the ECHO_REQUESTpacket and displays the route buffer on returned packets.  Notethat 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 isnot on a directly-attached network, an error is
 returned. This option can be used to ping a local host through an interface thathas no route through it provided the option -I is also used.    -s packetsize  Specifiesthe number of data bytes to be sent.  The default is 56, whichtranslates into 64 ICMP data bytes when combined with the  8 bytes  of  ICMP  header data.    -S sndbuf  Setsocket sndbuf. If not specified, it is selected to buffer not more thanone packet. -tttl  Setthe IP Time to Live.     -T timestamp option  Set special  IP  timestamp  options.  timestamp optionmay be either tsonly (only timestamps), tsandaddr (timestamps andaddresses) or tsprespec host1 [host2[host3 [host4]]] (timestampprespecified hops).    -Mhint  SelectPath MTU Discovery strategy.  hint may be either do (prohibitfragmentation, even local one), want (do PMTU discovery, fragment  locally  when  packet size is large), or dont(do not set DF flag).    -UPrintfull user-to-user latency (the old behaviour). Normally ping printsnetwork round trip time, which can be different f.e. due to DNSfailures.    -v Verboseoutput.    -VShowversion and exit.    -w deadline  Specifya timeout, in seconds, before ping exits regardless of how many packetshave been sent or received. In this case ping does not stop after countpacket are sent, it waits either for deadline expire or until countprobes are answered or for some error notification from network.    -W timeout  Timeto wait for a response, in seconds. The option affects only timeout inabsense of any responses, otherwise ping waits for two RTTs.


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  0Echo reply3Destination unreachable4Source quench5Redirect8Echo request9Router advertisement10Router solicitation11Time exceeded12Parameter problem13Timestamp request14Timestamp reply15Information request16Information reply17Address mask request18Address mask reply30Traceroute


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.