What is the IP Fragment Offset?
This is a soft test question from a group member about IP datagram fragmentation. The main points are as follows. The answers are B and A. When an IP datagram exceeds the Maximum Transmission Unit (MTU) of a network link, it must be fragmented. A key component of this process is the IP Fragment Offset, which determines the position of each fragment within the original datagram. Correctly calculating the IP Fragment Offset is critical for ensuring smooth data transmission, but discrepancies can occur, especially when using packet analysis tools like Wireshark.
(1) A.2 B.3 C.4 D.5
(2) A.370 B.740 C.1480 D.2960
Mainly the second answer. When I studied IPv4 Fragment Offset before, I also understood it as the actual data frame length of 2960 bytes. But after carefully reading the RFC document, I found that it was not the case. After further research, I also found a Wireshark problem, which I will simply record.
Analyzing IP Fragment Offset in Wireshark
Test method
A large packet was simply pinged on a Windows host. The ICMP data field was 3992 bytes, plus the 8-byte ICMP header, for a total length of 4000 bytes. Wireshark was also used to capture the packet.
$ ping -l 3992 www.baidu.com
Pinging www.a.shifen.com [180.101.49.11] with 3992 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Ping statistics for 180.101.49.11:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),The problem of ICMP
packet fragmentation causing incompatibility can be ignored here, as it is caused by security policy control.
Fundamental analysis
Data Frame 1 and Data Frame 2
14 bytes (Ethernet II header length) + 20 bytes (IPv4 header length) + 1480 bytes (Data length) = 1514 bytes
Data Frame 3
14 bytes (Ethernet II header length) + 20 bytes (IPv4 header length) + 1040 bytes (Data length) = 1074 bytes
ICMP 1480+1480+1040 = 4000 bytes, which is divided into 3 pieces, data frame 1 off = 0, data frame 2 off = 1480, data frame 3 off = 2960.
Theoretically, there seems to be no problem after this analysis, including the binary displayed in data frame 3 0 1011 1001 0000 is indeed decimal 2960 , and the hexadecimal should be 0b 90 , but wireshark shows it is 01 72 , what is wrong???
Query RFC 791 , quoted as follows:
Fragment Offset: 13 bits This field indicates where in the datagram this fragment belongs.The fragment offset is measured in units of 8 octets (64 bits). The first fragment has offset zero.
The unit of fragment offset is 8 bytes . Where does 8 bytes come from? First of all, we have to start with the Total Length of the IPv4 header. Because the Total length is 16 bits, the maximum value that can be represented is 2 to the 16th power. Taking 1 byte as the unit, it means that the maximum length of an IPv4 data packet may be 65536 bytes. The fragment offset is designed to be only 13 bits, and the maximum value that can be represented is 2 to the 13th power, which can only represent 8192. Therefore, it is defined in units of 8 bytes, so that the maximum fragment offset can represent 65536 bytes.
So the correct binary value of data frame 3 should be 0 0001 0111 0010 , the decimal value should be 370 , and the hexadecimal value should be 01 72. Therefore, the current version of Wireshark (Version 3.6.3) has some problems in displaying binary values here, which is ambiguous .
…0 1011 1001 0000 = Fragment Offset: 2960 x
…0 0001 0111 0010 = Fragment Offset: 370 √
I don’t know how Wireshark defines this logic. The binary of the original data packet is directly shifted left by 3 bits, so the decimal value calculated is directly 2960. Is it just to show the real offset length in the packet details? ? ?
Further analysis
To verify this problem, the same data packet is displayed in Colai as follows. The binary of data frame 3 is 0 0001 0111 0010 , and then it will display a prompt of 2960 offset bytes, which is completely correct~
Then I checked the Wireshark version notes and verified the old version. I found that before Version 3.0.5, they were all 370, but after Version 3.0.6, they all became 2960…
Wireshark 3.0.6 Release Notes
https://www.wireshark.org/docs/relnotes/wireshark-3.0.6.htmlUpdated Protocol SupportAgentX, BT L2CAP, ERSPAN, GRE, IPv4, IS-IS, NAS 5GS, OpcUa, SNMP, and SRT. It is possible that IPv4 is just mentioned in passing. . .
Summarize
The software test is so difficult. If I really encounter it, I will definitely fail. Hey, my basic knowledge is not solid.