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 個位元組，造成一系列連續問題。

問題總結

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

以上就是Wireshark TS FTP 傳輸失敗問題解決的詳細內容，更多關於Wireshark TS FTP 傳輸的資料請關注it145.com其它相關文章！