Analysis TCP Three-Way Handshake Issue in Wireshark

Background

This case revolves around a situation where a user reported occasional server errors with data reception issues from a client. The captured network packets indicated that the TCP three-way handshake proceeded normally, but the server unexpectedly resent a SYN/ACK and eventually closed the connection using a FIN. This led the user to suspect problems with the server’s network configuration or other related factors. The discussion originates from a case shared on the Wireshark official Q&A forum.

The case is taken from the Wireshark official Q&A forum 

https://osqa-ask.wireshark.org/questions/43648/spurious-retransmission-and-dup-ack

Problem Analysis

Server Side

A brief analysis is as follows:

1. TCP three-way handshake is normal, IRTT 0.004858 s;
2. The client did not respond, and the server resent SYN/ACK after 31 seconds to confirm whether the client was still alive;
3. Miraculously, the client is still there, and the protocol stack returns an ACK;
4. But then the entire interaction fell into silence again. The server couldn’t stand it after 20 seconds and sent a FIN, but the client was still able to respond with an ACK confirmation.

Client

A brief analysis is as follows:

1. The overall phenomenon is basically the same as that on the server side;
2. TCP three-way handshake is normal, IRTT 0.005896 s;
3. After the TCP three-way handshake is completed, the client does not send any request, and receives the SYN/ACK resent by the server 31 seconds later, and returns the confirmation ACK;
4. There was no interaction after that. The client received the FIN sent by the server 20 seconds later and continued to respond with ACK.
5. Due to TCP bidirectional communication, only half of the four waves were completed. The client initiated the POST request after 1651s, and then sent its own FIN. Moreover, since no confirmation was received, the client kept resending the POST request.

Replenish

In the discussion of this post, the user also added a diagram of the data packets under normal client requests. From the diagram, we can see that the client will normally initiate a POST request after 2ms, and then the interaction will proceed normally until the end of FIN.

Similarly, for another delayed request data packet, the client will get a RST response from the server after the POST request is sent with a large delay.

Summarize

Combined with the analysis results of the above data packets, from my personal perspective, there are actually some abnormal behaviors on both the client and the server, as follows:

1. The client, as the analysis said, seemed to be asleep and fell into a state of silence, and the POST request was seriously delayed, which is also an aspect that needs to be investigated in this case;
2. On the server side, the discussion did not focus on the behavior of the server side, but I am a little confused about the retransmission behavior of SYN/ACK and the origin of 31s;

• Considering that the user emphasized that the packet capture file was indeed captured on the server, it can be confirmed that the server received the third TCP handshake data packet, but the SYN/ACK retransmission behavior is like the TCP three-way handshake was not actually completed . If it is assumed that the server has enabled the TCP option TCP_DEFER_ACCEPT, the connection is not established normally, and the client is also waiting to send a POST data request, but the server does not receive it normally, so it retransmits SYN/ACK.
• If we only consider the SYN/ACK retransmission behavior, TCP_DEFER_ACCEPTit is indeed more reasonable to explain it with , but combined with the 31s time, it will bring new questions. Assuming that due to net.ipv4.tcp_synack_retriesthe behavior of , the first retry occurs after 1 second, and then it will double in the 2nd, 4th, 8th, 16th seconds, etc., but in fact only one SYN/ACK retransmission is captured after 31 seconds. This situation is more like an end-to-end communication with devices such as proxies and load balancing (reasonable assumption)

TCP_DEFER_ACCEPT, please refer to the previous article 

“Wireshark TS | Server sends RST after three-way handshake? ! “

This case comes from the Internet. Although the scene and the truth cannot be verified, from the perspective of network data packet research, reasonable judgment and analysis is always a very interesting and continuously improving process.