Wireshark TS FTP 傳輸失敗問(wèn)題解決

更新時(shí)間：2023年03月05日 11:10:26 作者：7ACE

這篇文章主要為大家介紹了Wireshark TS FTP 傳輸失敗問(wèn)題解決，有需要的朋友可以借鑒參考下，希望能夠有所幫助，祝大家多多進(jìn)步，早日升職加薪

問(wèn)題背景

用戶反饋說(shuō)當(dāng)與外部客戶端進(jìn)行 FTP 傳輸時(shí)，可以成功登錄，但無(wú)法傳輸任何數(shù)據(jù)。總之 FTP 傳輸失敗，需要來(lái)弄清楚到底發(fā)生了什么。

案例取自 SharkFest 2010《Packet Trace Whispering》

問(wèn)題信息

跟蹤文件基本信息如下：

λ 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 上通過(guò) tcpdump 所捕獲，數(shù)據(jù)包數(shù)量并不多，只有 44 個(gè)，長(zhǎng)度截?cái)酁?69 字節(jié)，文件數(shù)據(jù)大小 3555 字節(jié)，捕獲時(shí)長(zhǎng) 34.49 秒，平均速率 824 bps。

專家信息如下，可以看到 Warning 信息包括很多數(shù)據(jù)分段未被捕獲，同時(shí)也有很多的(疑似)重傳、(疑似)快速重傳以及(疑似)虛假重傳等問(wèn)題，需要進(jìn)一步實(shí)際分析。

問(wèn)題分析

眾所周知，F(xiàn)TP 有主動(dòng)和被動(dòng)兩種工作模式，而在有防火墻的網(wǎng)絡(luò)環(huán)境中，經(jīng)常會(huì)因?yàn)榘踩呗猿霈F(xiàn)訪問(wèn)失敗問(wèn)題。如果排除了 FTP 主動(dòng)和被動(dòng)、防火墻安全策略等常見(jiàn)的可能性問(wèn)題之外，那么剩下的就要專項(xiàng)分析了，就像這個(gè)特殊的案例。

數(shù)據(jù)包初步信息如下，為一條 FTP 控制連接，在 No.15 之后出現(xiàn)了大量的告警信息。既然與 TCP Seq Num 相關(guān)，那么轉(zhuǎn)到專用視圖上。

首先是 TCP 三次握手，此處有個(gè)明顯問(wèn)題的是SYN 數(shù)據(jù)包的 ACK 有數(shù)值，非 0，Wireshark 也會(huì)有明顯提示 [The acknowledgment number field is nonzero while the ACK flag is not set] 。雖然有些小問(wèn)題，但此處未影響 TCP 三次握手的建立。

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

主要分析如下：

No.15 客戶端 Request 數(shù)據(jù)包，Seq Num 為 70，Next Seq Num 為 94，同時(shí) ACK Num 213 期望收到服務(wù)器 Seq 213 的數(shù)據(jù)包；
No.16 服務(wù)器 Response 數(shù)據(jù)包，Seq Num 為 213，但 Ack Num 為 97，不同于 No.15 的 94意思是服務(wù)器可能收到了客戶端發(fā)送的 Seq 70，Next Seq 94 和 Seq 94，Next Seq 97 的兩個(gè) TCP 分段，因此 No.16 ACK Num 為 97；此處只是疑似捕獲時(shí)丟失了客戶端發(fā)送的后一個(gè) 3 字節(jié)的分段（Seq 94，Next Seq 97 ），所以提示 TCP ACKed unseen segment ；
No.17 客戶端發(fā)出的 ACK 數(shù)據(jù)包 Seq Num 為 94，此處和 No.16 的期望 97 無(wú)法對(duì)應(yīng)上，同時(shí)客戶端 No.15 ACK 期望收到 Seq 213，No.16 Seq Num 也為 213，但是客戶端并不認(rèn)可 No.16 數(shù)據(jù)包，因此 No.17 ACK Num 仍為 213；

問(wèn)題貌似出現(xiàn)在服務(wù)器發(fā)送的 No.16 數(shù)據(jù)包上，需要繼續(xù)展開(kāi)部分字段輔助判斷，譬如 IP ID。

可以看到客戶端 No.15、No.17、No.19 ...... IP ID 是逐步遞增的，意味著客戶端并沒(méi)有發(fā)送過(guò) Seq 94，Next Seq 97 的 TCP 分段，因此對(duì)于服務(wù)器，上述分析 2 中的結(jié)論并不正確（可能收到了客戶端發(fā)送的 Seq 70，Next Seq 94 和 Seq 94，Next Seq 97 的兩個(gè) TCP 分段）。

那么具體問(wèn)題是什么呢？讓我們做一個(gè)假設(shè)，客戶端數(shù)據(jù)包在傳輸過(guò)程中發(fā)生了變化，額外多出來(lái)了 3 個(gè)字節(jié)，是否符合問(wèn)題現(xiàn)象。

服務(wù)器側(cè)，收到了 No.15 Seq Num 70，Next Seq Num 97，ACK Num 213的數(shù)據(jù)包，所以回復(fù)了 No.16 Seq Num 213，ACK Num 97的數(shù)據(jù)包；
客戶端側(cè)，收到了 No.16 Seq Num 213，ACK Num 97，由于 ACK Num 的異常（不同于 94），客戶端實(shí)際忽略了該數(shù)據(jù)包，產(chǎn)生一個(gè) No.17 ACK 數(shù)據(jù)包，ACK Num 仍然為 213；
服務(wù)器側(cè)，收到了 No.17 Seq Num 94，Next Seq Num 97，ACK Num 213的數(shù)據(jù)包，之后由于 No.16 發(fā)生超時(shí)重傳，重新發(fā)送了 No.18 Seq Num 213，ACK Num 97的數(shù)據(jù)包；
客戶端側(cè)，由于 No.15 超時(shí)，產(chǎn)生了重傳，所以重新發(fā)送了 No.19 Seq Num 70，Next Seq Num 94，ACK Num 213的數(shù)據(jù)包；
服務(wù)器側(cè)，收到了 No.19 Seq Num 70，Next Seq Num 97，ACK Num 213的數(shù)據(jù)包，回復(fù)了 No.20 Seq Num 243，ACK Num 97的數(shù)據(jù)包；
之后由于客戶端 -> 服務(wù)器傳輸方向上，持續(xù)的 94 -> 97 多出 3 個(gè)字節(jié)，問(wèn)題持續(xù)。

總之，問(wèn)題可能出現(xiàn)在中間傳輸路徑上的設(shè)備，可能是 NAT 或是防火墻等設(shè)備，增加了客戶端從未發(fā)送的 3 個(gè)額外字節(jié)，所以服務(wù)器回復(fù)的 ACK 也增加了 3 個(gè)字節(jié)，造成一系列連續(xù)問(wèn)題。