调试网络问题

Question

自从我得到这个新路由器并用dd-wrt闪现它之后，我就一直有这个问题。

这并不是真正的影响(我会描述)，但我对此很好奇.

这是网络设置的图表：

• 运行在VMware融合上的Manjaro (在Mac/OSX主机上)通过WiFi连接
• 3 raspberry Pis (运行Raspbian)连接到交换机1(然后是路由器)
• 连接到交换机1的NAS (WDCloud)
• 1个覆盆子Pi连接到开关2(连接到开关1)

在设置之后，问题是：

• Mac over WiFi，桥接模式下的Manjaro
  • 在4种分组中任意一种都会在5分钟内丢失，有时是20%，有时更多。
  • 轻击NAS显示根本没有丢包。

• Mac，Manjaro in NAT
  • 在任何情况下都不丢失数据包

• Mac，Manjaro中的NAT或桥接模式
  • 在任何情况下都不丢失数据包

因此，我最初的猜测是，这是与融合桥接模式有关的东西，因为直接从Mac (主机)发出的pinging不会有任何损失(也不会对NAT使用VM )。

• 尝试Virtualbox，同样发生(桥接显示数据包丢失，NAT没有)。
• 与DDWRT WiFi设置玩了很多，但似乎没有什么不同。

意识到pinging没有丢包，所以它看起来只是在Bridged+WiFi+Raspberry组合中的一些东西，所以我在一个覆盆子上运行tcpdump icmp并开始从VM中敲击。

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请求击中了覆盆子Pi，但没有回复(在此期间，大约30)。

我使用ping，因为它是显示/测试数据包丢失的最容易的方法，但在TCP中也会出现这种情况，因为SSH会话不时挂起。

有什么提示可以检查raspberry pi配置，以了解为什么它不发送ICMP回复？它使它看起来与Pi相关，但是为什么在其他情况下(Mac WiFi + VM桥接)不会发生这种情况，因为Pi保持不变？

Answer 1

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

此外，您还可以通过运行arp -a来确认，当ping是好的和坏的时，可以看到ARP表的差异。

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