問題背景

用戶反饋說當(dāng)與外部客戶端進行 FTP 傳輸時，可以成功登錄，但無法傳輸任何數(shù)據(jù)?？傊?FTP 傳輸失敗，需要來弄清楚到底發(fā)生了什么。

案例取自 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 所捕獲，數(shù)據(jù)包數(shù)量并不多，只有 44 個，長度截斷為 69 字節(jié)，文件數(shù)據(jù)大小 3555 字節(jié)，捕獲時長 34.49 秒，平均速率 824 bps。

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

問題分析

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

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

首先是 TCP 三次握手，此處有個明顯問題的是SYN 數(shù)據(jù)包的 ACK 有數(shù)值，非 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 數(shù)據(jù)包，Seq Num 為 70，Next Seq Num 為 94，同時 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 的兩個 TCP 分段，因此 No.16 ACK Num 為 97；此處只是疑似捕獲時丟失了客戶端發(fā)送的后一個 3 字節(jié)的分段（Seq 94，Next Seq 97 ），所以提示 TCP ACKed unseen segment ；
• No.17 客戶端發(fā)出的 ACK 數(shù)據(jù)包 Seq Num 為 94，此處和 No.16 的期望 97 無法對應(yīng)上，同時客戶端 No.15 ACK 期望收到 Seq 213，No.16 Seq Num 也為 213，但是客戶端并不認(rèn)可 No.16 數(shù)據(jù)包，因此 No.17 ACK Num 仍為 213；

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

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

那么具體問題是什么呢？讓我們做一個假設(shè)，客戶端數(shù)據(jù)包在傳輸過程中發(fā)生了變化，額外多出來了 3 個字節(jié)，是否符合問題現(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ù)據(jù)包，產(chǎn)生一個 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ā)生超時重傳，重新發(fā)送了 No.18 Seq Num 213，ACK Num 97的數(shù)據(jù)包；
• 客戶端側(cè)，由于 No.15 超時，產(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 個字節(jié)，問題持續(xù)。

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

問題總結(jié)

很少見的問題，但一切皆有可能。

以上就是Wireshark TS FTP 傳輸失敗問題解決的詳細(xì)內(nèi)容，更多關(guān)于Wireshark TS FTP 傳輸?shù)馁Y料請關(guān)注腳本之家其它相關(guān)文章！

最新評論