Background
If you’re encountering the TCP SYN-SYN/ACK-RST problem during device connection attempts, you’re not alone. This issue typically arises when the client sends a SYN packet, receives a SYN-ACK response from the server, but then immediately resets the connection (RST). The root cause of this problem is often related to mismatched TCP Options timestamps (TSOPT), which can be easily diagnosed and resolved.
The example is taken from the Wireshark official Q&A forum
https://osqa-ask.wireshark.org/questions/57774/syn-synack-rst-reason
First of all, let me give you the conclusion. This problem is caused by the mismatch of TCP Options timestamps. Similar cases have been analyzed in detail in the previous article “SYN-SYN/ACK-RST Problem”. Students who are familiar with TCP Options timestamps or have read previous articles can completely ignore this chapter.
What is the TCP SYN-SYN/ACK-RST Problem?
As usual, the basic information of the tracking file is as follows:
$ capinfos 47-02-capture.pcap
File name: 47-02-capture.pcap
File type: Wireshark/tcpdump/... - pcap
File encapsulation: Ethernet
File timestamp precision: microseconds (6)
Packet size limit: file hdr: 262144 bytes
Number of packets: 42
File size: 3468 bytes
Data size: 2772 bytes
Capture duration: 27.523737 seconds
First packet time: 2016-11-30 13:29:37.486887
Last packet time: 2016-11-30 13:30:05.010624
Data byte rate: 100 bytes/s
Data bit rate: 805 bits/s
Average packet size: 66.00 bytes
Average packet rate: 1 packets/s
SHA256: 03cb0e89dc8e85cff6039e4e92e143dd2dc5c1ee8586c016cc7930ba0f9d3db8
RIPEMD160: 95f9199bbab6773e56e3e03de0e24d98caed1e7f
SHA1: 27abebf77b7135ab244f390ce3b5d59bc718f6fc
Strict time order: True
Number of interfaces in file: 1
Interface #0 info:
Encapsulation = Ethernet (1 - ether)
Capture length = 262144
Time precision = microseconds (6)
Time ticks per second = 1000000
Number of stat entries = 0
Number of packets = 42
The trace file was captured by tcpdump on Linux. The number of packets is not large, only 42. Combined with a simple browse of the expert information, it does match some of the phenomena described by the user, SYN, SYN/ACK and RST phenomena, the count is 14, the ratio is 1:1:1, and the connection cannot be established normally.
Diagnosing the TCP SYN-SYN/ACK-RST Problem Using Wireshark
View the data packet list information through Wireshark.
The main analysis is as follows:
- The capture was performed on the client because the RST packet length is only 54 bytes and is not padded to the minimum standard Ethernet frame length of 60 bytes before entering the network card for transmission;
- In the TCP handshake phase, the SYN-SYN/ACK-RST is repeated regularly, but the connection is not successfully established;
- The server can return SYN/ACK normally, eliminating the problem of the service port not being opened;
- The client actively initiates RST;
- RTT time is about 2.7-3.2ms;
- Seq num and Ack num showed no abnormality;
- The client keeps trying to initiate new connections. Due to the reuse of source port numbers, some prompts such as TCP Port number reused
, TCP Retransmission
, and TCP Previous segment not caputred are generated
. In fact, considering the context, these connections are not directly related, and the judgment is not completely accurate. You can temporarily turn off the Analyze TCP sequence numbers
option to view it, as shown in the following figure, which may be clearer.
Considering that everyone has different coloring rules, the following analysis may be more clear if
the coloring rules are disabled . Sometimes you may not be used to seeing a large area of red and green.
Directly into the problem, the TSOPT in the Server’s SYN/ACK is abnormal, the TSecr value is 1072693248 , which is different from the TSval value 147472368 in the Client’s SYN . Under normal circumstances, they should be the same, causing the client to RST this connection. Other connections RST are all due to the same reason.
Further checking the Timestamp Value, the information of No.1 and No.2 data frames is as follows. The timestamp value in the server SYN/ACK is shifted left by 2 bytes. This may be caused by a problem in the server kernel protocol stack implementation or an incorrect modification of the intermediate transmission device.
The solution is to turn off the TCP Timestamp option support on the client or server. The TSOPT value will only be carried in the session if both the client and the server support the option. If the client turns off the option, the server will not send packets with TSOPT.
RFC 7323
TCP Timestamps option (TSopt):
Kind: 8
Length: 10 bytes
Timestamp Value (TSval). 32 bits. This field contains the current value of the timestamp clock of the TCP sending the option.
Timestamp Echo Reply (TSecr). 32 bits. This field is only valid if the ACK bit is set in the TCP header. If it is valid, it echos a timestamp value that was sent by the remote TCP in the TSval field of a Timestamps option. When TSecr is not valid, its value must be zero. The TSecr value will generally be from the most recent Timestamp option that was received; however, there are exceptions that are explained below. A TCP may send the Timestamp option in an initial SYN segment (i.e., segment containing a SYN bit and no ACK bit), and may send a TSopt in other segments only if it received a TSopt in the initial SYN segment for the connection.
Again, two simple examples are shown for connections where both ends support TSOPT. The subsequent interactions all include TSOPT values.
Only one end of the connection supports TSOPT , and there is no TSOPT value in the subsequent exchanges.
Summary of the problem
TCP TSOPT cases are indeed rare, but the judgment, analysis and solution are relatively simple.