Wireshark TS FTP传输失败问题如何解决

这篇文章主要介绍了Wireshark TS FTP传输失败问题如何解决的相关知识，内容详细易懂，操作简单快捷，具有一定借鉴价值，相信大家阅读完这篇Wireshark TS FTP传输失败问题如何解决文章都会有所收获，下面我们一起来看看吧。

问题背景

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

问题信息

跟踪文件基本信息如下：

λ capinfos FTPFinal.pcapFile name:           FTPFinal.pcapFile type:           Wireshark/tcpdump/... - pcapFile encapsulation:  EthernetFile timestamp precision:  microseconds (6)Packet size limit:   file hdr: 65535 bytesPacket size limit:   inferred: 69 bytesNumber of packets:   44File size:           3710 bytesData size:           3555 bytesCapture duration:    34.493422 secondsFirst packet time:   2007-03-22 04:37:11.513913Last packet time:    2007-03-22 04:37:46.007335Data byte rate:      103 bytes/sData bit rate:       824 bits/sAverage packet size: 80.80 bytesAverage packet rate: 1 packets/sshA256:              36512b444dacb061e0d8a661923f1323D0c778131bedaa7bbd5b2ab810e9a09fRIPEMD160:           3e14f2dd481632867eba14503a24e92b316b5cafSHA1:                771e45893504af381de89ba6b047b5cd3fa554fdStrict time order:   TrueNumber of interfaces in file: 1Interface #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 个字节，造成一系列连续问题。

关于“Wireshark TS FTP传输失败问题如何解决”这篇文章的内容就介绍到这里，感谢各位的阅读！相信大家对“Wireshark TS FTP传输失败问题如何解决”知识都有一定的了解，大家如果还想学习更多知识，欢迎关注编程网精选频道。