Analyzing TCP Failures: A Sharkfest Packet Challenge Example

,

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:

Captured 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 

“Wireshark Tips and Tricks | How to Anonymize Packets”

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.

A Sharkfest Packet Challenge Example

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.

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

Analyze 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
100

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