TCP Analysis Flags 之 TCP Port numbers reused

前言

默认情况下，Wireshark 的 TCP 解析器会跟踪每个 TCP 会话的状态，并在检测到问题或潜在问题时提供额外的信息。在第一次打开捕获文件时，会对每个 TCP 数据包进行一次分析，数据包按照它们在数据包列表中出现的顺序进行处理。可以通过 “Analyze TCP sequence numbers” TCP 解析首选项启用或禁用此功能。

TCP 分析展示

在数据包文件中进行 TCP 分析时，关于 “TCP Port numbers reused” 一般是如下显示的，包括：

1. Packet List 窗口中的 Info 信息列，以 [TCP Port numbers reused] 黑底红字进行标注；
2. Packet Details 窗口中的 TCP 协议树下，在 [SEQ/ACK analysis] -> [TCP Analysis Flags] 中定义该 TCP 数据包的分析说明。

TCP Port numbers reused 定义

实际在 TCP 分析中，关于 TCP Port numbers reused 的定义非常简单，如下，针对 SYN 数据包(而不是SYN+ACK)，如果已经有一个使用相同 IP+Port 的会话，并且这个 SYN 的序列号与已有会话的 ISN 不同时设置。

Set when the SYN flag is set (not SYN+ACK), we have an existing conversation using the same addresses and ports, and the sequence number is different than the existing conversation’s initial sequence number.

注意：官方文档此处说明的是 SYN，而非 SYN/ACK，和实际代码实现的却不一样，下述展开说明。

具体的代码如下，主要作用是处理 SYN 以及 SYN/ACK 数据包，判断是新连接还是已有连接的重传，并相应地创建新会话或更新会话的序列号等，并设置相关标志位。总的来说，这是 Wireshark 分析 TCP 流量时处理 SYN 和 SYN/ACK 数据包的一个重要环节，用于正确识别连接和更新状态信息。

    /* If this is a SYN packet, then check if its seq-nr is different* from the base_seq of the retrieved conversation. If this is the* case, create a new conversation with the same addresses and ports* and set the TA_PORTS_REUSED flag. (XXX: There is a small chance* that this is an old duplicate SYN received after the connection* is ESTABLISHED on both sides, the other side will respond with* an appropriate ACK, and this SYN ought to be ignored rather than* create a new conversation.)** If the seq-nr is the same as the base_seq, it might be a simple* retransmission, reattempting a handshake that was reset (due* to a half-open connection) with the same sequence number, or* (unlikely) a new connection that happens to use the same sequence* number as the previous one.** If we have received a RST or FIN on the retrieved conversation,* create a new conversation in order to clear out the follow info,* sequence analysis, desegmentation, etc.* If not, it's probably a retransmission, and will be marked* as one later, but restore some flow values to reduce the* sequence analysis warnings if our capture file is missing a RST* or FIN segment that was present on the network.** XXX - Is this affected by MPTCP which can use multiple SYNs?*/if (tcpd != NULL  && (tcph->th_flags & (TH_SYN|TH_ACK)) == TH_SYN) {if (tcpd->fwd->static_flags & TCP_S_BASE_SEQ_SET) {if(tcph->th_seq!=tcpd->fwd->base_seq || (tcpd->conversation_completeness & TCP_COMPLETENESS_RST) || (tcpd->conversation_completeness & TCP_COMPLETENESS_FIN)) {if (!(pinfo->fd->visited)) {conv=conversation_new(pinfo->num, &pinfo->src, &pinfo->dst, CONVERSATION_TCP, pinfo->srcport, pinfo->destport, 0);tcpd=get_tcp_conversation_data(conv,pinfo);if(!tcpd->ta)tcp_analyze_get_acked_struct(pinfo->num, tcph->th_seq, tcph->th_ack, TRUE, tcpd);tcpd->ta->flags|=TCP_A_REUSED_PORTS;/* As above, a new conversation starting with a SYN implies conversation completeness value 1 */conversation_is_new = TRUE;}} else {if (!(pinfo->fd->visited)) {/** Sometimes we need to restore the nextseq value.* As stated in RFC 793 3.4 a RST packet might be* sent with SEQ being equal to the ACK received,* thus breaking our flow monitoring. (issue 17616)*/if(tcp_analyze_seq && tcpd->fwd->tcp_analyze_seq_info) {tcpd->fwd->tcp_analyze_seq_info->nextseq = tcpd->fwd->tcp_analyze_seq_info->maxseqtobeacked;}if(!tcpd->ta)tcp_analyze_get_acked_struct(pinfo->num, tcph->th_seq, tcph->th_ack, TRUE, tcpd);}}}else {/** TCP_S_BASE_SEQ_SET being not set, we are dealing with a new conversation,* either created ad hoc above (general case), or by a higher protocol such as FTP.* Track this information, as the Completeness value will be initialized later.* See issue 19092.*/if (!(pinfo->fd->visited))conversation_is_new = TRUE;}tcpd->had_acc_ecn_setup_syn = (tcph->th_flags & (TH_AE|TH_CWR|TH_ECE)) == (TH_AE|TH_CWR|TH_ECE);}/* If this is a SYN/ACK packet, then check if its seq-nr is different* from the base_seq of the retrieved conversation. If this is the* case, set the TA_PORTS_REUSED flag and override the base seq.* (XXX: Should this create a new conversation, as above with a* SYN packet? We might have received the new connection's SYN/ACK before* the SYN packet, or the SYN might be missing from the capture file.)* If the seq-nr is the same as the base_seq, then do nothing so it* will be marked as a retransmission later.* XXX - Is this affected by MPTCP which can use multiple SYNs?*/if (tcpd != NULL && (tcph->th_flags & (TH_SYN|TH_ACK)) == (TH_SYN|TH_ACK)) {if ((tcpd->fwd->static_flags & TCP_S_BASE_SEQ_SET) &&(tcph->th_seq != tcpd->fwd->base_seq)) {/* the retrieved conversation might have a different base_seq (issue 16944) *//* XXX: Shouldn't this create a new conversation? Changing the* base_seq will change how the previous packets in the conversation* are processed in the second pass.*/tcpd->fwd->base_seq = tcph->th_seq;if(!tcpd->ta)tcp_analyze_get_acked_struct(pinfo->num, tcph->th_seq, tcph->th_ack, TRUE, tcpd);tcpd->ta->flags|=TCP_A_REUSED_PORTS;}tcpd->had_acc_ecn_setup_syn_ack = ((tcph->th_flags & (TH_AE|TH_CWR)) == TH_CWR) ||((tcph->th_flags & (TH_AE|TH_ECE)) == TH_AE);}

Packetdrill 示例

首先可以通过 packetdrill 模拟出一次正常的 TCP 三次握手现象，同时经 tcpdump 捕获数据包后，得到 tcp_port_number_reused.pcap 数据包文件。

# cat tcp_port_number_reused.pkt 
0   socket(..., SOCK_STREAM, IPPROTO_TCP) = 3
+0  setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
+0  bind(3, ..., ...) = 0
+0  listen(3, 1) = 0+0  < S 0:0(0) win 10000 <mss 1460>
+0  > S. 0:0(0) ack 1 <...>
+0.01 < . 1:1(0) ack 1 win 10000
+0 accept(3, ..., ...) = 4
# 

通过 editcap 和 mergecap 对 pcap 文件做一定加工，复制出来一份之后再合并，最后得到 tcp_port_number_reused.pcapng 数据包文件。

editcap -t 0.1 tcp_port_number_reused.pcap tcp_port_number_reused_01.pcapmergecap -w tcp_port_number_reused.pcapng tcp_port_number_reused.pcap tcp_port_number_reused_01.pcap

经 Wireshark 展示如下，可以看到 No.6 SYN 与之前 TCP 会话保持一样(源/目的 IP、源/目的端口)，且之前 TCP 会话存在 FIN/RST，则 No.6 标识成 [TCP Port numbers reused] 。

实例

关于 TCP Port numbers reused 的实例，实际上来说在客户端源端口不断变化的情况下，该现象并不是很常见，或者说就是看到了相关现象，也不是什么大问题，只是个 TCP 端口重用提示，并没有任何问题，仅仅是 Note 级别，信息为：[Expert Info (Note/Sequence): A new tcp session is started with the same ports as an earlier session in this trace]。

可能出现的场景，一是短时间客户端以固定源端口进行连接，但不断被服务器端 RST 或者客户端自身 RST 的情形，二是长时间捕获或者数据包很多时，客户端以同样的源端口又发起一次新连接，像是一些压测场景，再就是等等其他场景。

1. 短时间重复 RST

以下是一个短时间重复 SYN RST 的场景，TCP Stream 6 发起 TCP 三次握手，但被服务器直接 RST 拒绝，之后间隔了 500ms，客户端又发起一个相同 TCP 源端口 52744 的新连接，但同样被服务器直接 RST 拒绝，之后不断反复，相同的 SYN 都会标识成 [TCP Port numbers reuserd] ，这种场景下找服务器 RST 连接的真实原因即可，[TCP Port numbers reuserd] 仅仅是不断发起 SYN 相同连接的提示而已。

再看一种短时间重复 SYN/ACK RST 的场景，相对来说更加少见，但总还是有的不是嘛~

2. 长时间捕获重复 SYN

以下是一个长时间捕获的场景，TCP Stream 24 正常完成 TCP 三次握手、数据传输以及 TCP 四次挥手过程，再经过 2 个多小时的长期间捕获，客户端又发起一个相同 TCP 源端口 2266 的新连接，此时 No.48015 SYN 会标识成 [TCP Port numbers reuserd] ，这种场景下并没有任何问题，属于正常现象。

3. 重复 SYN/ACK

以下介绍一个针对 SYN/ACK 重复以及设置 [TCP Port numbers reuserd] 的场景，也就是上面所说和官方文档说明不一致的地方，但是与代码一致。

首先是一个正常的捕获场景，No.1-2 为一次会话，No.3-4 为一次会话，其中 No.3 标记为 [TCP Port numbers reuserd]，紧接着 No.5-16 为一次会话，其中 No.5 标记为 [TCP Port numbers reuserd]。

如果此时出现了 No.5 SYN 未被捕获到的场景（这里可以通过 ignore 该数据包模拟实现），你会发现此时 No.6 SYN/ACK 标识成了 [TCP Port numbers reuserd]，也就是上述 SYN/ACK 代码部分所实现的判断逻辑。而 No.5 SYN 刚好未被捕获到的这种情形，你只能说极其少见，但确实不能完全排除，只能感慨，暗叹一句 Wireshark 牛批~

4. 重复 SYN/ACK 的特例

也是在实验过程当中，发现了一个重复 SYN/ACK 的特别例子，首先基于以下数据包场景，正常两次会话，No.4 SYN 产生一次 [TCP Port numbers reuserd]。

如果此时出现了 No.4 SYN 未被捕获到的场景（这里可以通过 ignore 该数据包模拟实现），你会发现此时不仅 No.5 SYN/ACK 标识成了 [TCP Port numbers reuserd]，就连先前 No.2 SYN/ACK 也标识成了 [TCP Port numbers reuserd]，对于 No.2 这里所发生的情况百思不得其解。。。

甚至还有如下情形的，没有 RST 的情形，也会出现 [TCP Port numbers reuserd]。

待续，已提交 Issue，官方开发者确认为 Bug，静待修复。
补充：以上基于版本 4.2.x 测试，目前最新版本 4.4.0 已经解决。

总结

总结来说，以上体现了 Wireshark 代码在处理复杂 TCP 场景时的细致程度，明确区分了新老连接的不同情况。