Preface
A packet example from the Sharkfest Packet Challenge. Sharkfest is an annual conference organized by Wireshark, dedicated to sharing knowledge, experience, and best practices among Wireshark developers and user communities . I remember that it was held once a year in the early days, but in recent years it has become twice a year, one in the United States and one in other regions, such as Europe or Asia. Packet Challenge is one of the more interesting activities in the conference. Through a series of packet examples, participants can perform analysis challenges and test their comprehensive analysis capabilities.
Topic Information
This case is the third topic Do it Yourself in Sharkfest 2019 EU Packet Challenge, and the packet trace file is DIY.pcapng .
The main description is as follows:
A developer programmed a microcontroller to send data via TCP. Something looks bad though…
1. What is the largest segment size that will work for both client and server?
2. Where was the capture taken (Client local/SPAN/TAP/Server local)?
3. What is the initial round trip time of the connection?
4. How many router hops are between client and server?
5. Why does the transmission of TCP data from 192.168.0.2 to 192.168.0.1 fail?
Packet information
The basic information of the packet trace file is as follows:
λ capinfos DIY.pcapng
File name: DIY.pcapng
File type: Wireshark/... - pcapng
File encapsulation: Ethernet
File timestamp precision: microseconds (6)
Packet size limit: file hdr: (not set)
Number of packets: 1210
File size: 1555 kB
Data size: 1499 kB
Capture duration: 4.495727 seconds
First packet time: 2017-03-27 19:02:12.959401
Last packet time: 2017-03-27 19:02:17.455128
Data byte rate: 333 kBps
Data bit rate: 2667 kbps
Average packet size: 1238.93 bytes
Average packet rate: 269 packets/s
SHA256: 4385a9ded3fdc9c7fa0c3015323ed6df10fb68e38dba07210ec0588bd65a5feb
RIPEMD160: 53562636f5037964e8b6a0bccb2cbf7648895e31
SHA1: a0295d1e0ff87f0e4135f4bf1a87422ff562fc04
Strict time order: True
Capture application: Sanitized by TraceWrangler v0.6.6 build 928
Number of interfaces in file: 1
Interface #0 info:
Name = \Device\NPF_{83DAFA6D-086A-4B8B-AA1D-562D69913D39}
Encapsulation = Ethernet (1 - ether)
Capture length = 262144
Time precision = microseconds (6)
Time ticks per second = 1000000
Time resolution = 0x06
Operating system = 64-bit Windows 10, build 14393
Number of stat entries = 0
Number of packets = 1210Captured by Wireshark on Win10 system, without truncation, the number of captured packets is 1210, the capture duration is 4.49 seconds, the average rate is 2667 kbps, and it has been edited by TraceWrangler anonymization tool.
For an introduction to TraceWrangler anonymization software, you can check out the previous article
The session information is shown below. There is only one TCP session.
The expert information is as follows. It can be seen that there are a large number of fast retransmission, retransmission and Dup ACK information, which account for a high proportion.
Packet Analysis
Expand the data packet file information, as shown below, and you can see that there are indeed a lot of retransmission information, from No.11 to the last No.1210.
1. What is the largest segment size that will work for both client and server?
What is the maximum segment size for both client and server?
Analysis steps
Segment naturally refers to TCP Segment, which can be tcp.lenviewed by adding a column and sorting from large to small. This value will also be reflected in Infothe Len column value.
λ tshark -r DIY.pcapng -Y "tcp.len" -T fields -e tcp.len | sort -rn | uniq
1460
735
0Analyze the answer
For both client and server, the maximum segment size is: 1460.
2. Where was the capture taken (Client local/SPAN/TAP/Server local)?
Where is the capture done (client-local/SPAN/TAP/server-local)?
Analysis steps
The answer can be known from the information in the Length column in the packet list. Since 54 bytes is less than the Ethernet minimum length of 60 bytes, it is determined that the packet capture is performed on the client 192.168.0.1. Since Wireshark captures packets locally, Wireshark captures the locally generated packets before they enter the network card, and the padding data and FCS are generally completed by the network card hardware/ driver , so the 54-byte composition does not include the padding data, which means local capture.
Regarding how to determine where the capture is after getting a packet trace file, the relevant technical article can be found in
“Wireshark Tips and Tricks | Capture Point of TCP Three-Way Handshake” .
Analyze the answer
Where is the capture done (client local/SPAN/TAP/server local)?: Client local.
3. What is the initial round trip time of the connection?
What is the Initial Round Trip Time (IRTT) of the connection?
Analysis steps
Initial Round Trip Time (IRTT) is the time for the initial TCP three-way handshake in the TCP flow.
Of course, this IRTT value will also be marked in most of the data packets in this TCP flow.
λ tshark -r DIY.pcapng -Y "tcp.analysis.initial_rtt" -T fields -e tcp.analysis.initial_rtt | sort | uniq
0.001735000Analyze the answer
What is the initial round trip time (IRTT) of the connection? : 0.001735 seconds.
4. How many router hops are between client and server?
How many routing hops are there between the client and the server ?
Analysis steps
In the network, each time a data packet passes through a routing device, the TTL value decreases by 1. In question 2, it is confirmed that the packet is captured locally on the client, so you can check the TTL value of the No.2 SYN/ACK packet.
λ tshark -r DIY.pcapng -Y "frame.number==2" -T fields -e ip.ttl
100Analyze the answer
How many routing hops are there between the client and the server?: 28.
5. Why does the transmission of TCP data from 192.168.0.2 to 192.168.0.1 fail?
Why does TCP data transmission from 192.168.0.2 to 192.168.0.1 fail?
Analysis steps
From the point of view of the packet trace file capture, the question can be said to be why the client 192.168.0.1 does not accept the data sent by the server 192168.0.2?
a. Phenomenon After the TCP three-way handshake succeeds, the client does not receive the data segments sent by the No.4-No.10 servers, but instead generates a No.11 ACK data packet still requesting the server’s Seq Num 1 segment. After that, the server generates timeout retransmissions in turn, but the client still does not receive the corresponding data packet. Then the process continues to cycle until the entire trace file ends.
b. Possible cause: The TCP CHECKSUM INCORRECT problem is rather strange. It may be that there is a problem with the No.4-No.10 data segmentation. If you try to open Validate the TCP checksum if possiblethe option in the TCP protocol, you will find that a large number of alarm messages appear TCP CHECKSUM INCORRECT.
- Client TCP CHECKSUM INCORRECT, first of all, the client TCP checksum is not a problem. This is because the data packets are captured locally on the client, and the TCP/UDP/IP checksum is performed by the network card CheckSum Offload function, so the TCP checksum of the client data packet captured by Wireshark is randomly filled, so the checksum will prompt incorrect;
- On the server side, TCP CHECKSUM INCORRECT, the checksum of data segments No.4 – No.9 is incorrect, so the client protocol stack does not receive it normally, while the checksum of data segment No.10 is normal, and the client protocol stack receives it normally, but because it is inconsistent with the expected Seq Num, it triggers No.11 client DUP ACK.
The above is an explanation of the suspected cause of TCP CHECKSUM INCORRECT, which is consistent with the packet phenomenon, but the answer is not necessarily accurate. The main reason is that the question provides very little information, and it is not possible to fully confirm whether the checksum problem is an additional unrelated problem caused by the anonymization software editing the data packet (all checksums differ by only 1, for example, No.4 checksum 0x07f5 is incorrect, and 0x07f4 is correct).
Regarding the TCP Checksum of data packets, related technical articles can also be referred to
“Wireshark Tips and Tricks | TCP Three-Way Handshake at Capture Point” .
IPTABLES iptables may also be the cause of this problem. For example, it matches a specific message length, blocks data segments No.4 – No.9 (TCP Length 1460 bytes), and receives data segment No.10 (TCP Length 735 bytes), which triggers TCP DUP ACK, and the above process is repeated.
Analyze the answer
Why does TCP data transmission from 192.168.0.2 to 192.168.0.1 fail?: TCP checksum or IPTABLES.