Diagnose TCP Connection Issues with Wireshark

Preface

Accessing a web page can sometimes fail, presenting a common issue in everyday online experiences. Various factors may contribute to this problem, including the client, browser, server, or network conditions. Each situation requires a detailed analysis to identify the root cause. This article focuses on TCP connection issues, showcasing a real case study from the Wireshark SharkFest 2017, which includes several intriguing TCP trace files.

Problem Information

The basic information of the packet trace file is as follows:

λ capinfos Sample04.pcapng
File name:           Sample04.pcapng
File type:           Wireshark/... - pcapng
File encapsulation:  Ethernet
File timestamp precision:  microseconds (6)
Packet size limit:   file hdr: (not set)
Number of packets:   33
File size:           6228 bytes
Data size:           5005 bytes
Capture duration:    38.709141 seconds
First packet time:   2011-01-14 01:14:52.475277
Last packet time:    2011-01-14 01:15:31.184418
Data byte rate:      129 bytes/s
Data bit rate:       1034 bits/s
Average packet size: 151.67 bytes
Average packet rate: 0 packets/s
SHA256:              48ca202b8b7c2cf0fd20fe0909cae6cd2a30fbdbdad17492a5cab7f2749bb745
RIPEMD160:           151de4053735268f9943f00403f72aef66debf42
SHA1:                a3fb91edd6db023edb2648f6d69dfafb2b7c6a27
Strict time order:   True
Capture comment:     Sanitized by TraceWrangler v0.6.4 build 808
Number of interfaces in file: 1
Interface #0 info:
                     Encapsulation = Ethernet (1 - ether)
                     Capture length = 65535
                     Time precision = microseconds (6)
                     Time ticks per second = 1000000
                     Time resolution = 0x06
                     Number of stat entries = 0
                     Number of packets = 33

λ

The data packets were captured by Wireshark, with 33 data packets, a file size of 6228 bytes, a capture time of approximately 38.7 seconds, an average rate of 1034 bits/s, and were processed by TraceWrangler anonymization software.

For an introduction to TraceWrangler anonymization software, you can check out the previous article 

“Wireshark Tips and Tricks | How to Anonymize Packets”

The expert information is as follows. What needs attention are Previous segment not caputredthe warning information, RST, (suspected) retransmission, DUP ACK, etc. Considering that the total number of packets 33 is relatively small, a small amount of suspected problematic information still needs attention.

Problem Analysis

TCP Previous segment not caputred

First of all, what is it TCP Previous segment not caputred? In fact, in previous articles, including actual cases at hand, it should be a relatively common expert tip information.

Set when the current sequence number is greater than the next expected sequence number.

As the name implies, the segment before TCP is not captured . In fact, there are two possibilities for this prompt in the packet trace file:

1. The original TCP session captured has packet loss. If this is the case, the mirrored traffic is copied as is, so some packets are missing, and naturally the captured packets are also missing accordingly.
2. The captured original TCP session data packets interact normally, but packet loss occurs during the mirroring process, that is, packet loss occurs during mirroring. If this is the case, an alarm will also be issued to indicate that some segments are not captured.

Of course, these two situations are sometimes easier to distinguish, and are briefly explained as follows:

1. The original TCP session captured has packet loss. If this is the case, the original session will naturally perform actions such as retransmission due to packet loss, and the relevant phenomenon can also be seen in the data packets captured later. (It is necessary to distinguish between retransmission and disorder)
2. The captured original TCP session data packets interact normally, but the mirror captures packet loss. If this is the case, the original session will ACK the segment normally, and the captured data packet will see this ACK and will correspondingly prompt ACKed segment that wasn’t caputred information, because this segment is actually not in the captured trace file.

Example:

There are many similar articles and cases. Students who are interested can check out 

“Packet Lost? Don’t Jump to Conclusions” , 

“Packet Lost? Don’t Jump to Conclusions (Continued)” , 

“TCP Previous Segment Lost”, etc.

Fundamental analysis

Back to this case, expand the complete data package file information as follows:

The main analysis is as follows:

1. No.1 and No.2, first a pair of DNS requests and responses, querying http://www.boerse-stuttgart.de, and the responding A record IP 217.110.67.201;

2. Starting from No.3, the client initiates HTTP 80 access to the server, which is TCP Stream 0. After the normal TCP three-way handshake, the client initiates the HTTP request, and the server responds with a 301 redirect, jumping from http -> https.

Of course, it may be a problem with the TraceWrangler anonymization application. The server IP 0.115.64.211 (which has been modified) is inconsistent with the IP in the DNS response (217.110.67.201). This is a minor problem and can be ignored.

3. Therefore, starting from No. 8, the client initiated access to the server HTTPS 443, which is TCP Stream 1. After the normal TCP three-way handshake, a problem occurred during the TLS handshake.

After client No.11 sent Client Hello, the server did not respond. After 3 seconds, client No.13 timed out and retransmitted the data packet. The server sent No.14 prompt TCP Previous segment not caputred, indicating that the server had lost segments in the transmission direction before, so the client generated No.15 DUP ACK. After that, due to the TLS handshake failure, the client actively FIN the connection, and then the session ended hastily. The abnormal phenomenon reflected in the application is that the web page access fails and cannot be opened~

Further analysis

Turn to TCP detailed analysis and open the God view to see what exactly happened

1. In the TCP three-way handshake, note the result after both parties announce that the MSS is 1380 bytes;
2. After client No.11 sends out Client Hello, it should theoretically receive Server Hello from the server, but packet loss occurs. No data packets are received, so client No.13 times out and retransmits.
3. Server No.14 Seq 4141 and TCP Previous segment not caputred, indicates that a segment of 4140 bytes is lost, that is, 4140/1380 = 3, which is exactly 3 MSS packets. This means that the data packet sent by the server according to MSS 1380 was discarded during the intermediate transmission. This is because the intermediate path MTU is less than 1420 (1380+40); ( transmission path MTU problem )
4. After that, the server did not take any remedial measures. When the client No.15 DUP ACK still requested data segment Seq 1, the server fell into silence. Of course, this is from the perspective of packet capture on the client side. From the server side, it must be retransmitting, and retransmitting continuously.
5. Finally, the client couldn’t stand it anymore after 30 seconds, FIN disconnected, Over.

Summary of the problem

The failure to access the web page in this case is a relatively simple fault scenario. The problem phenomenon is clear and easy to reproduce, and it can be solved in a few steps. Of course, there are also relatively complex scenarios, which are more brain-burning~