Расширители диапазона WiFi и неудачные запросы ARP

Я работаю в сети, как описано ниже - BT HomeHub 5 и Netgear EX6150 WiFi extender. В сети есть и другие точки, хотя для краткости я их пропустил, а все розовые пунктирные линии - WiFi.

Проблема, которую я вижу, состоит в том, что ПК 1 не может ( не будет ) связываться с ПК 2, но мой телефон будет . Конечно, у моего телефона есть возможность перепрыгивать и напрямую подключаться к экстендеру, и в настоящее время я не могу исключить это, играя роль здесь.

Такая же ситуация для ПК 1, пытающегося установить связь с другими хостами с помощью WiFi-расширителя.

Все хосты имеют доступ к интернету.

Я обнаружил, что расширитель будет " взламывать " MAC-адреса, но я не совсем понимаю, почему . Например, MAC-адрес ПК 2 есть 88:b1:11:f4:e0:66, но интерфейс маршрутизатора (и хосты, подключенные к маршрутизатору) будут видеть его как 02:0f:b5:f4:e0:66. В руководстве на стр. 33 есть ужасно написанный раздел, и, похоже, нет способа его отключить. Я не вижу никакой технической причины для этого, и в настоящее время я делаю ставку на то, чтобы это было ключевой частью проблемы.

Время для технических битов.

• ПК 1 является 192.168.1.74/ 1c:3e:84:c8:0c:08(как сообщает ОС)
• ПК 2 есть 192.168.1.16/ 88:b1:11:f4:e0:66(как сообщает ОС)

Мой телефон будет весело сканировать сеть (используя Fing ), обнаруживать хост и пинговать его ... как упоминалось ранее, ПК 1 не будет.

Я попытался вручную добавить информацию об адресе ПК 2 в таблицу ARP ПК 1:

C:\WINDOWS\system32>netsh interface ip add neighbors 14 192.168.1.16 02-0f-b5-f4-e0-66   C:\WINDOWS\system32>arp -a  Interface: 192.168.1.74 --- 0xe Internet Address Physical Address Type ... 192.168.1.16 02-0f-b5-f4-e0-66 static ...  C:\WINDOWS\system32>ping 192.168.1.16  Pinging 192.168.1.16 with 32 bytes of data: Request timed out. Request timed out. Request timed out. Request timed out.  Ping statistics for 192.168.1.16: Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),  C:\WINDOWS\system32> 

Так что это явно не просто проблема ARP.

Глядя на это с точки зрения ПК 2, я принял tcpdumpво время пинга:

$ tcpdump -enr dump.cap 11:37:45.730405 1c:3e:84:c8:0c:08 > 88:b1:11:f4:e0:66, ethertype IPv4 (0x0800), length 74: 192.168.1.74 > 192.168.1.16: ICMP echo request, id 1, seq 1317, length 40 11:37:45.730468 88:b1:11:f4:e0:66 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.1.74 tell 192.168.1.16, length 28 11:37:45.764667 1c:3e:84:c8:0c:08 > 88:b1:11:f4:e0:66, ethertype ARP (0x0806), length 42: Reply 192.168.1.74 is-at 1c:3e:84:c8:0c:08, length 28 11:37:45.764678 88:b1:11:f4:e0:66 > 1c:3e:84:c8:0c:08, ethertype IPv4 (0x0800), length 74: 192.168.1.16 > 192.168.1.74: ICMP echo reply, id 1, seq 1317, length 40 

До who-hasэхо-запроса ICMP не было, как мы изложили это вручную ... но ПК 2 четко отвечает эхо-ответом 1c:3e:84:c8:0c:08после успешного запроса ARP - хорошая вещь - но ПК 1 утверждает, что никогда не получал его.

Кроме того, после пинга ПК 2 имеет адрес ПК 1 в своей таблице ARP (я удалил его раньше):

$ arp -n Address HWtype HWaddress Flags Mask Iface ... 192.168.1.74 ether 1c:3e:84:c8:0c:08 C wlp3s0 ... 

Повторение пинга с Wireshark на ПК 1 и tcpdumpна ПК 2 показывает следующее (дампы см. Ниже):

• Трафик с ПК 1 → ПК 2 выглядит нормально
  • MAC-адрес источника отсутствует
• Трафик с ПК 2 → ПК 1 принимается только в случае широковещательной рассылки (например, запрос ARP)
  • Там является MAC munging источника

ПК 1

$ tcpdump -enr pc1_dump4.cap reading from file pc1_dump4.cap, link-type EN10MB (Ethernet) 12:17:59.525610 1c:3e:84:c8:0c:08 > 02:0f:b5:f4:e0:66, ethertype IPv4 (0x0800), length 74: 192.168.1.74 > 192.168.1.16: ICMP echo request, id 1, seq 1330, length 40 12:17:59.641049 02:0f:b5:f4:e0:66 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.1.74 tell 192.168.1.16, length 28 12:17:59.641080 1c:3e:84:c8:0c:08 > 02:0f:b5:f4:e0:66, ethertype ARP (0x0806), length 42: Reply 192.168.1.74 is-at 1c:3e:84:c8:0c:08, length 28 12:18:04.345340 1c:3e:84:c8:0c:08 > 02:0f:b5:f4:e0:66, ethertype IPv4 (0x0800), length 74: 192.168.1.74 > 192.168.1.16: ICMP echo request, id 1, seq 1331, length 40 12:18:09.346886 1c:3e:84:c8:0c:08 > 02:0f:b5:f4:e0:66, ethertype IPv4 (0x0800), length 74: 192.168.1.74 > 192.168.1.16: ICMP echo request, id 1, seq 1332, length 40 12:18:14.347539 1c:3e:84:c8:0c:08 > 02:0f:b5:f4:e0:66, ethertype IPv4 (0x0800), length 74: 192.168.1.74 > 192.168.1.16: ICMP echo request, id 1, seq 1333, length 40 

ПК 2

$ tcpdump -enr pc2_dump4.cap reading from file dump4.cap, link-type EN10MB (Ethernet) 12:18:02.206931 1c:3e:84:c8:0c:08 > 88:b1:11:f4:e0:66, ethertype IPv4 (0x0800), length 74: 192.168.1.74 > 192.168.1.16: ICMP echo request, id 1, seq 1330, length 40 12:18:02.206995 88:b1:11:f4:e0:66 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.1.74 tell 192.168.1.16, length 28 12:18:02.289242 1c:3e:84:c8:0c:08 > 88:b1:11:f4:e0:66, ethertype ARP (0x0806), length 42: Reply 192.168.1.74 is-at 1c:3e:84:c8:0c:08, length 28 12:18:02.289254 88:b1:11:f4:e0:66 > 1c:3e:84:c8:0c:08, ethertype IPv4 (0x0800), length 74: 192.168.1.16 > 192.168.1.74: ICMP echo reply, id 1, seq 1330, length 40 12:18:07.122444 1c:3e:84:c8:0c:08 > 88:b1:11:f4:e0:66, ethertype IPv4 (0x0800), length 74: 192.168.1.74 > 192.168.1.16: ICMP echo request, id 1, seq 1331, length 40 12:18:07.122484 88:b1:11:f4:e0:66 > 1c:3e:84:c8:0c:08, ethertype IPv4 (0x0800), length 74: 192.168.1.16 > 192.168.1.74: ICMP echo reply, id 1, seq 1331, length 40 12:18:12.037691 1c:3e:84:c8:0c:08 > 88:b1:11:f4:e0:66, ethertype IPv4 (0x0800), length 74: 192.168.1.74 > 192.168.1.16: ICMP echo request, id 1, seq 1332, length 40 12:18:12.037729 88:b1:11:f4:e0:66 > 1c:3e:84:c8:0c:08, ethertype IPv4 (0x0800), length 74: 192.168.1.16 > 192.168.1.74: ICMP echo reply, id 1, seq 1332, length 40 12:18:17.170982 1c:3e:84:c8:0c:08 > 88:b1:11:f4:e0:66, ethertype IPv4 (0x0800), length 74: 192.168.1.74 > 192.168.1.16: ICMP echo request, id 1, seq 1333, length 40 12:18:17.171025 88:b1:11:f4:e0:66 > 1c:3e:84:c8:0c:08, ethertype IPv4 (0x0800), length 74: 192.168.1.16 > 192.168.1.74: ICMP echo reply, id 1, seq 1333, length 40 

Если я изменяю направление (ПК 2 отправляет эхо-запросы на ПК 1), то ПК 1 никогда не видит запрос.

Отключение брандмауэра Windows не помогает.

В крайнем случае, подключение ПК 1 к маршрутизатору через Ethernet решает проблему ... однако в настоящее время это не является приемлемым решением.

Кто-нибудь может помочь?