Я работаю в сети, как описано ниже - 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
Перед эхо-запросом ICMP никто не who-has , поскольку мы изложили это вручную ... но ПК 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 решает проблему ... однако в настоящее время это не является приемлемым решением.
Кто-нибудь может помочь?