Wireshark TS FTP 传输失败问题解决

问题背景

用户反馈说当与外部客户端进行 FTP 传输时，可以成功登录，但无法传输任何数据。总之 FTP 传输失败，需要来弄清楚到底发生了什么。

案例取自 SharkFest 2010《Packet Trace Whispering》

问题信息

跟踪文件基本信息如下：

λ capinfos FTPFinal.pcap
File name: FTPFinal.pcap
File type: Wireshark/tcpdump/… – pcap
File encapsulation: Ethernet
File timestamp precision: microseconds (6)
Packet size limit: file hdr: 65535 bytes
Packet size limit: inferred: 69 bytes
Number of packets: 44
File size: 3710 bytes
Data size: 3555 bytes
Capture duration: 34.493422 seconds
First packet time: 2007-03-22 04:37:11.513913
Last packet time: 2007-03-22 04:37:46.007335
Data byte rate: 103 bytes/s
Data bit rate: 824 bits/s
Average packet size: 80.80 bytes
Average packet rate: 1 packets/s
SHA256: 36512b444dacb061e0d8a661923f1323d0c778131bedaa7bbd5b2ab810e9a09f
RIPEMD160: 3e14f2dd481632867eba14503a24e92b316b5caf
SHA1: 771e45893504af381de89ba6b047b5cd3fa554fd
Strict time order: True
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
Number of stat entries = 0
Number of packets = 44
λ

跟踪文件在 linux 上通过 tcpdump 所捕获，数据包数量并不多，只有 44 个，长度截断为 69 字节，文件数据大小 3555 字节，捕获时长 34.49 秒，平均速率 824 bps。

专家信息如下，可以看到 Warning 信息包括很多数据分段未被捕获，同时也有很多的(疑似)重传、(疑似)快速重传以及(疑似)虚假重传等问题，需要进一步实际分析。

问题分析

众所周知，FTP 有主动和被动两种工作模式，而在有防火墙的网络环境中，经常会因为安全策略出现访问失败问题。如果排除了 FTP 主动和被动、防火墙安全策略等常见的可能性问题之外，那么剩下的就要专项分析了，就像这个特殊的案例。

数据包初步信息如下，为一条 FTP 控制连接，在 No.15 之后出现了大量的告警信息。既然与 TCP Seq Num 相关，那么转到专用视图上。

首先是 TCP 三次握手，此处有个明显问题的是SYN 数据包的 ACK 有数值，非 0，Wireshark 也会有明显提示 [The acknowledgment number field is nonzero while the ACK flag is not set] 。虽然有些小问题，但此处未影响 TCP 三次握手的建立。

No.4 – No.15 正常的控制交互，Request – Response 。

主要分析如下：

No.15 客户端 Request 数据包，Seq Num 为 70，Next Seq Num 为 94，同时 ACK Num 213 期望收到服务器 Seq 213 的数据包；
No.16 服务器 Response 数据包，Seq Num 为 213，但 Ack Num 为 97，不同于 No.15 的 94意思是服务器可能收到了客户端发送的 Seq 70，Next Seq 94 和 Seq 94，Next Seq 97 的两个 TCP 分段，因此 No.16 ACK Num 为 97；此处只是疑似捕获时丢失了客户端发送的后一个 3 字节的分段（Seq 94，Next Seq 97 ），所以提示 TCP ACKed unseen segment ；
No.17 客户端发出的 ACK 数据包 Seq Num 为 94，此处和 No.16 的期望 97 无法对应上，同时客户端 No.15 ACK 期望收到 Seq 213，No.16 Seq Num 也为 213，但是客户端并不认可 No.16 数据包，因此 No.17 ACK Num 仍为 213；

问题貌似出现在服务器发送的 No.16 数据包上，需要继续展开部分字段辅助判断，譬如 IP ID。

可以看到客户端 No.15、No.17、No.19 …… IP ID 是逐步递增的，意味着客户端并没有发送过 Seq 94，Next Seq 97 的 TCP 分段，因此对于服务器，上述分析 2 中的结论并不正确（可能收到了客户端发送的 Seq 70，Next Seq 94 和 Seq 94，Next Seq 97 的两个 TCP 分段）。

那么具体问题是什么呢？让我们做一个假设，客户端数据包在传输过程中发生了变化，额外多出来了 3 个字节，是否符合问题现象。

服务器侧，收到了 No.15 Seq Num 70，Next Seq Num 97，ACK Num 213的数据包，所以回复了 No.16 Seq Num 213，ACK Num 97的数据包；
客户端侧，收到了 No.16 Seq Num 213，ACK Num 97，由于 ACK Num 的异常（不同于 94），客户端实际忽略了该数据包，产生一个 No.17 ACK 数据包，ACK Num 仍然为 213；
服务器侧，收到了 No.17 Seq Num 94，Next Seq Num 97，ACK Num 213的数据包，之后由于 No.16 发生超时重传，重新发送了 No.18 Seq Num 213，ACK Num 97的数据包；
客户端侧，由于 No.15 超时，产生了重传，所以重新发送了 No.19 Seq Num 70，Next Seq Num 94，ACK Num 213的数据包；
服务器侧，收到了 No.19 Seq Num 70，Next Seq Num 97，ACK Num 213的数据包，回复了 No.20 Seq Num 243，ACK Num 97的数据包；
之后由于客户端 -> 服务器传输方向上，持续的 94 -> 97 多出 3 个字节，问题持续。

总之，问题可能出现在中间传输路径上的设备，可能是 NAT 或是防火墙等设备，增加了客户端从未发送的 3 个额外字节，所以服务器回复的 ACK 也增加了 3 个字节，造成一系列连续问题。