☰

调试网络问题

tag-icon • tag-icon networking ping packetloss raspbian
调试网络问题

自从我买了以来，我就一直有这个问题这个新路由器并闪现dd-wrt。
这实际上没有什么影响（我会描述一下场景）但我对此很好奇......

这以下是网络设置图：

  • 通过 WiFi 连接的 VMware Fusion（在 Mac/OSX 主机中）上运行的 Manjaro Linux
  • 3 个 Raspberry Pi（运行 Raspbian）连接到交换机 1（然后是路由器）
  • 1 台 NAS（WDCloud）连接到交换机 1
  • 1 个树莓派连接到开关 2（连接到开关 1）

鉴于设置，问题：

  • Mac 通过 WiFi，Manjaro VM 处于桥接模式
    • 对 4 个 Pi 中的任何一个进行 ping 操作都会在 5 分钟内显示数据包丢失 - 有时是 20%，有时更多
    • 对 NAS 进行 ping 操作，没有发现任何数据包丢失
  • Mac 通过 WiFi，Manjaro VM 通过 NAT
    • 任何情况下均无数据包丢失
  • 通过 LAN 的 Mac，NAT 或桥接模式的 Manjaro VM
    • 任何情况下均无数据包丢失

因此，我最初的猜测是这与 Fusion 桥接模式有关，因为直接从 Mac（主机） ping 不会有任何损失（使用带有 NAT 的 VM 也不会有任何损失）。

  • 尝试了 Virtualbox，发生了同样的情况（桥接显示数据包丢失，但 NAT 没有）。
  • 对 DDWRT WiFi 设置进行了很多尝试，但似乎没有任何变化。

意识到 ping NAS 没有数据包丢失，所以它看起来像是 Bridged+WiFi+Raspberry 组合中才有的东西，所以我tcpdump icmp在其中一个树莓派上运行并开始从虚拟机 ping

VM 中的 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 请求到达 Raspberry Pi，但没有发送任何回复（这段时间大约 30 秒）。
我使用 ping 是因为它最容易显示/测试数据包丢失，但这也会发生在 TCP 上，因为 SSH 会话有时会挂起。

有没有提示要检查 Raspberry Pi 配置以了解它为什么不发送 ICMP 回复？它看起来与 Pi 有关，但为什么在其他情况下（Mac WiFi + VM 桥接）不会发生这种情况，因为 Pi 保持不变？

答案1

我认为这可能是由 ARP 冲突引起的。您可能需要检查 4 个 Pis 的 MAC 地址以及路由器。通过运行ifconfig，便宜的 Pis 可能具有相同的 MAC 地址。

您还可以通过运行arp -aping 好坏来确认 ARP 表的差异。

尝试运行tcpdump -i any arp也有帮助

相关内容