ping in network

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.

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.


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


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.


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.

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.

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.


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.


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.

Echo request

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

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.

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.

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