Отладка сетевой проблемы

У меня была эта проблема с тех пор, как я получил этот новый роутер и прошил его dd-wrt.
Это не особо впечатляет (я опишу сценарий), но мне это интересно ...

это это схема настройки сети:

• Manjaro Linux, работающий на VMware Fusion (на хосте Mac / OSX), подключен через Wi-Fi
• 3 Raspberry Pis (под управлением Raspbian) подключены к коммутатору 1 (а затем к маршрутизатору)
• 1 NAS (WDCloud) подключен к коммутатору 1
• 1 Raspberry Pi подключен к коммутатору 2 (который подключен к коммутатору 1)

Учитывая настройку, проблема:

• Mac через Wi-Fi, Manjaro VM в мостовом режиме
  • Пинг любого из 4 символов показывает потерю пакетов менее чем за 5 минут - иногда 20%, иногда больше
  • Pinging NAS показывает отсутствие потери пакетов
• Mac через Wi-Fi, Manjaro VM в NAT
  • без потери пакетов при любом сценарии
• Mac через локальную сеть, Manjaro VM в NAT или в режиме моста
  • без потери пакетов при любом сценарии

Итак, я изначально предполагал, что это связано с мостовым режимом Fusion, потому что пинг напрямую с Mac (хоста) никогда не приводил к потерям (ни при использовании виртуальной машины с NAT).

• Пробовал Virtualbox, происходит то же самое (мост показывает потерю пакетов, NAT - нет).
• Много играл с настройками DDWRT WiFi, но, похоже, ничего не изменилось.

Я понял, что при pinging NAS не было потери пакетов, поэтому он выглядел как что-то только в комбинации Bridged + WiFi + Raspberry, поэтому я запустил tcpdump icmp на одной из малин и начал пинговать с ВМ

Вывод 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

Вывод tcpdump в Pi:

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 + виртуальная машина с мостом), поскольку Pi остается постоянным?