調試網路問題

自從我得到這個新路由器並用dd-wrt ​​刷新它後，我就遇到了這個問題。

它並沒有真正的影響（我會描述這個場景），但我很好奇……

這是網路設置的示意圖：

• 在通過 WiFi 連接的 VMware Fusion（在 Mac/OSX 主機中）上執行的 Manjaro Linux
• 3 個樹莓派（執行 Raspbian）連接到交換機 1（然後是路由器）
• 1 NAS (WDCloud) 連接到交換機 1
• 1 個樹莓派連接到交換機 2（連接到交換機 1）

鑑於設置，問題：

• Mac over WiFi，Manjaro VM 處於橋接模式

  • ping 4 個 Pi 中的任何一個都顯示在 5 分鐘內丟包 - 有時 20%，有時更多
  • ping NAS 顯示完全沒有丟包

• Mac over WiFi，Manjaro VM 在 NAT

  • 任何場景都不會丟包

• Mac over LAN、Manjaro VM 處於 NAT 或橋接模式

  • 任何場景都不會丟包

所以，我最初的猜測是它與 Fusion 橋接模式有關，因為直接從 Mac（主機）ping 從來沒有任何損失（也沒有使用帶有 NAT 的 VM）。

• 嘗試過 Virtualbox，同樣的情況（橋接顯示丟包，NAT 沒有）。
• 使用 DDWRT WiFi 設置玩了很多，但似乎沒有任何區別。

意識到 ping NAS 沒有丟包，所以它看起來只是橋接+WiFi+Raspberry 組合中的東西，所以我tcpdump icmp在其中一個樹莓上執行並開始從 VM ping

虛擬機中的 Ping 輸出：

64 bytes from  (192.168.1.22): icmp_seq=13 ttl=64 time=2.40 ms
64 bytes from  (192.168.1.22): icmp_seq=14 ttl=64 time=2.50 ms
===> lost sequences 15 to 42 <===
64 bytes from  (192.168.1.22): icmp_seq=43 ttl=64 time=34.1 ms
64 bytes from  (192.168.1.22): icmp_seq=44 ttl=64 time=2.31 ms

Pi 中的 tcpdump 輸出：

01:24:42.397835 IP stretch > 192.168.1.22: ICMP echo request, id 436, seq 13, length 64                                    
01:24:42.397919 IP 192.168.1.22 > stretch: ICMP echo reply, id 436, seq 13, length 64                                      
01:24:43.399899 IP stretch > 192.168.1.22: ICMP echo request, id 436, seq 14, length 64                                    
01:24:43.399948 IP 192.168.1.22 > stretch: ICMP echo reply, id 436, seq 14, length 64                                      
01:24:44.404887 IP stretch > 192.168.1.22: ICMP echo request, id 436, seq 15, length 64                                    
01:24:45.422542 IP stretch > 192.168.1.22: ICMP echo request, id 436, seq 16, length 64                                    
===> requests hit but no replay is sent... <===
01:25:12.044102 IP stretch > 192.168.1.22: ICMP echo request, id 436, seq 42, length 64                                    
01:25:13.068516 IP stretch > 192.168.1.22: ICMP echo request, id 436, seq 43, length 64                                    
01:25:13.099164 IP 192.168.1.22 > stretch: ICMP echo reply, id 436, seq 43, length 64                                      
01:25:14.071065 IP stretch > 192.168.1.22: ICMP echo request, id 436, seq 44, length 64                                    
01:25:14.071129 IP 192.168.1.22 > stretch: ICMP echo reply, id 436, seq 44, length 64                                      

結論（我認為）：ping 請求命中樹莓派，但沒有發送回复（在那段時間，大約 30 秒）。

我正在使用 ping，因為它最容易顯示/測試封包遺失，但 TCP 也會發生這種情況，因為 SSH 會話時不時掛起。

關於檢查樹莓派配置以了解它為什麼不發送 ICMP 回复的任何提示？它使它看起來與 Pi 相關，但是為什麼在其他場景（Mac WiFi + VM 橋接）中不會發生這種情況，因為 Pi 保持不變？

我認為這可能是由 ARP 衝突引起的。您可能需要檢查 4 Pi 的 MAC 地址以及路由器。通過執行ifconfig，便宜的 Pis 可能具有相同的 MAC 地址。

您也可以通過執行arp -aping 的好壞來確認 ARP 表的差異。

嘗試跑步tcpdump -i any arp也有幫助

引用自：https://serverfault.com/questions/1017231