Wireshark TS | SYN-SYN/ACK-RST 问题二

7ACE

已于 2024-03-23 18:06:11 修改

阅读量3k

点赞数 1

分类专栏： NetShark 文章标签： wireshark 网络网络协议 tcp/ip tcpdump

于 2022-06-17 08:12:38 首次发布

本文链接：https://blog.csdn.net/weixin_47627078/article/details/125326457

版权

NetShark 专栏收录该内容

92 篇文章 18 订阅

订阅专栏

问题背景

用户反馈说观察到一个设备连接的奇怪问题，客户端（172.18.0.122）尝试连接到服务器（172.18.50.1），之后服务器回复 SYN-ACK，再收到消息后不久，客户端直接发送 RST，并在一段时间后又重复尝试连接。总结下来就是一段 SYN-SYN/ACK-RST 的异常问题，用户因此请求帮助。

案例取自 Wireshark 官方问答论坛
https://osqa-ask.wireshark.org/questions/57774/syn-synack-rst-reason/

首先结论先行，该问题是由于 TCP Options 时间戳不匹配而导致的故障，类似的案例其实在以前文章《SYN-SYN/ACK-RST 问题》中详细分析过，有熟悉 TCP Options 时间戳或者看过之前文章的同学完全可以忽略本章。

问题信息

还是惯例，跟踪文件基本信息如下：

$ 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

跟踪文件在 linux 上通过 tcpdump 所捕获，数据包数量并不多，只有 42 个，结合专家信息的简单浏览，确实符合用户所说的一些现象，SYN、SYN/ACK 和 RST 现象，计数为 14 ，比例 1:1:1 ，无法正常建立连接。

SYN-01

问题分析

通过 Wireshark 查看数据包列表信息，

SYN-02

主要分析如下：

捕获是在客户端上进行，因为 RST 数据包 length 只有 54 字节，进入网卡传输之前并未填充至以太网帧最小标准 60 字节长度；
TCP 握手阶段，以规律性的 SYN-SYN/ACK-RST 进行重复，并未成功建立起连接；
服务器能正常返回 SYN/ACK，排除服务端口未打开问题；
客户端主动发起 RST；
RTT 时间约 2.7-3.2ms 之间；
Seq num 和 Ack num 未见异常；
客户端不断尝试发起新连接，因源端口号复用的原因，所以会产生一些 TCP Port number reused 、TCP Retransmission 以及 TCP Previous segment not caputred 的提示信息。实际上考虑到上下文，这些连接并没有直接相关性，判断并不是完全准确。可以通过临时关闭 Analyze TCP sequence numbers 选项后查看，如下图可能更加清晰。

SYN-03

考虑到每个人不同的着色规则习惯，以下分析禁用着色规则可能看得更加清楚，红红绿绿的一大片有时会看得不太习惯 🤣

直接进入问题所在，Server 的 SYN/ACK 中 TSOPT 存在异常，TSecr 值 1072693248，不同于 Client 的 SYN 中 TSval 值 147472368 ，正常情况下应该相同，造成客户端 RST 此连接。其他连接 RST 均是相同原因。

SYN-04

进一步查看 Timestamp Value , 其中 No.1 和 No.2 数据帧信息如下，服务器 SYN/ACK 中的时间戳值左移了 2 字节，可能是服务器内核协议栈实现有问题，也可能是中间传输设备错误修改导致。

SYN-05

SYN-06

解决方式可以在客户端或服务器端关闭 TCP Timestamp 选项支持。TSOPT 值仅在客户端和服务器两端均支持该选项的情况下，才会在会话中一直携带。如果在客户端关闭选项的情况下，则服务器因此也不会发送带有 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.