目录

• 问题背景
• 问题信息
• 问题分析
• 问题总结

问题背景

用户反馈说当与外部客户端进行 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 个字节,造成一系列连续问题。

问题总结

很少见的问题,但一切皆有可能。

以上就是Wireshark TS FTP 传输失败问题解决的详细内容,更多关于Wireshark TS FTP 传输的资料请关注代码部落其它相关文章!