I. Overview
The ping command is probably well-known to programmers, right? When we check network conditions, the first command we’re likely to use is the ping command. Generally, when we use ping to view network conditions, we check two main indicators: first, to see if there is a timeout, and second, to check if the latency is too high. If there’s a timeout, there is definitely a network issue (except when ping is blocked), and if the latency is too high, the network situation is bound to be poor as well. So, what is the principle behind the ping command, and how does ping check the network? Have you ever learned about it before? Let’s take a tour with the ping command and see how this works.
II. Environment Preparation and Packet Capture
2.1 Environment Preparation
1. Packet capture tool. I am using Wireshark here.
2. I prepared two computers to perform the ping operation. Their IP addresses are as follows:
Computer A: 192.168.2.135
MAC Address: 98:22:EF:E8:A8:87
Computer B: 192.168.2.179
MAC: 90:A4:DE:C2:DF:FE
2.2 Packet Capture Operation
Open Wireshark, select the specified network card for packet capture, and perform the ping operation. On Computer A, ping the IP of Computer B.
Image a
The packet capture situation is as follows:
Image b
Let’s briefly introduce the Wireshark control panel. This panel includes 7 fields, which are:
- NO. Number
- Time: Packet timestamp
- Source: Source address
- Destination: Destination address
- Protocol: Protocol
- Length: Packet length
- Info: Packet additional information
III. In-depth Analysis
The packet capture numbers 54-132 shown in the above image illustrate the entire ping command process. We know that the ping command does not rely on TCP or UDP as transport layer protocols but rather on the ICMP protocol. So, what is the ICMP protocol? Here is a brief introduction:
3.1 Background of the ICMP Protocol
The reasons for the creation of ICMP are explained in [RFC792]: Since communication between the internet involves many gateways and hosts, the ICMP protocol was created to report data errors. In other words, the ICMP protocol was developed to forward IP datagrams more efficiently and increase the chance of successful delivery.
3.2 Format of the ICMP Protocol Data
Image c
According to the image above, we know that the ICMP header contains 4 bytes. The header is mainly used to specify the type and check ICMP messages. The following image is a corresponding type and code explanation list that we will use when analyzing packet captures later.
Image d
After briefly introducing ICMP, what is the ARP protocol that appears during packet capture? Let’s also provide a simple explanation:
3.3 ARP Protocol
We know that in a local area network, computer communication actually relies on MAC addresses for communication. The role of ARP (Address Resolution Protocol) is to find the MAC address corresponding to an IP address.
3.4 Analysis of the Ping Process
After understanding the basic concepts above, let’s analyze the captured data. The flow of Image b is as follows:
- Computer A (192.168.2.135) initiates a ping request, pinging 192.168.2.179.
- Computer A broadcasts an ARP request to query the MAC address of 192.168.2.179.
- Computer B responds to the ARP request, sending a unicast response to Computer A, informing it that its MAC address is 90:A4:DE:C2:DF:FE.
- After obtaining the MAC address, the real ping request begins, as Computer B can determine the source MAC address from the request sent by Computer A and thus can respond based on the source MAC address.
I have illustrated the above request process in a flowchart for better visualization:
img
Those observing carefully may have noticed that after the four ping requests and responses, there is another ARP request from Computer B to Computer A. Why is this? I guess there are two reasons:
1. Due to ARP caching, to prevent ARP expiration, the ARP cache is updated after completion to ensure that the next request reaches the correct path. If ARP expires, it will result in an error, affecting test accuracy.
2. The response time of the ping command is calculated based on the timestamps of the request and response packets, so an ARP process also consumes time. Here, caching the latest ARP result in advance saves the ARP time for the next ping.
To verify our speculation, I performed another ping operation to capture the packet and see if it matches our guess. At this point, there is already an ARP cache in the computer. We execute ARP -a to check the cached ARP list:
Let’s look at the packet capture for the second ping
We see that before the actual ping in the image above, there was no ARP request, indicating that the cached ARP was directly used. Additionally, before Computer B’s response, an ARP request was still conducted to confirm the previous ARP cache’s accuracy. After completing the ping operation, an ARP request is also sent to update its ARP cache. This behavior aligns with our assumption.
After understanding the ping process, let’s analyze whether the previously explained ICMP data results match the packet capture. We click on a ping request to examine the ICMP protocol details
The red box in the image shows the ICMP protocol details with Type=8, code=0, and the checksum is correct. Comparing it with Image d, we know that this is a request message. We then click on Response frame:57, indicating that the response message is at sequence number 57. The details are as follows:
The response message in the image above is Type=0, code=0. This indicates it is a response message, and finally, the response delay is calculated based on the request and response timestamps. 3379.764 ms – 3376.890 ms = 2.874 ms.
IV. Summary
We analyzed a complete ping request process. The ping command relies on the ICMP protocol, which exists to forward IP datagrams more efficiently and enhance the chance of successful delivery. Besides relying on ICMP, the ping command also utilizes the ARP protocol in a local area network. The ARP protocol can identify a computer’s MAC address based on its IP address. ARP has a cache; to ensure the accuracy of ARP, the computer will update the ARP cache.