Ich arbeite an einem Netzwerk, wie unten beschrieben – einem BT HomeHub 5 und einem Netgear EX6150 WiFi Extender. Es gibt noch weitere Punkte im Netzwerk, die ich der Kürze halber jedoch weggelassen habe, und alle rosa gestrichelten Linien sind WiFi.
Das Problem, das ich sehe, ist, dass PC 1kann nicht(wird nicht) mit PC 2 kommunizieren, aber mein TelefonWille. Natürlich kann mein Telefon rüberspringen und eine direkte Verbindung zum Extender herstellen, und ich kann derzeit nicht ausschließen, dass das hier eine Rolle spielt.
Die gleiche Situation besteht, wenn PC 1 versucht, mit anderen Hosts über den WLAN-Extender zu kommunizieren.
Alle Gastgeber haben Zugang zum Internet.
Ich habe festgestellt, dass der Extender "mung" MAC-Adressen, aber ich bin nicht ganz in der Lage, herauszufindenWarum. Beispielsweise lautet die MAC-Adresse von PC 2 88:b1:11:f4:e0:66, aber die Schnittstelle des Routers (und die mit dem Router verbundenen Hosts) erkennen die Kommunikation als 02:0f:b5:f4:e0:66. Es gibt einen schrecklich geschriebenen Abschnitt in derHandbuchAnSeite 33, und es scheint keine Möglichkeit zu geben, es auszuschalten. Ich kann dafür keinen technischen Grund erkennen und gehe derzeit davon aus, dass dies ein wesentlicher Teil des Problems ist.
Zeit für technische Details.
- PC 1 ist
192.168.1.74/1c:3e:84:c8:0c:08(wie vom Betriebssystem gemeldet) - PC 2 ist
192.168.1.16/88:b1:11:f4:e0:66(wie vom Betriebssystem gemeldet)
Mein Telefon wird munter das Netzwerk durchsuchen (mitFing), ermitteln Sie den Host und pingen Sie ihn an. Wie bereits erwähnt, wird PC 1 dies nicht tun.
Ich habe versucht, die Adressinformationen von PC 2 manuell zur ARP-Tabelle von PC 1 hinzuzufügen:
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>
Das ist also eindeutig nichtNurein ARP-Problem.
Aus der Perspektive von PC 2 betrachtet, habe ich tcpdumpwährend eines Pings Folgendes aufgenommen:
$ 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
Es gibt kein who-has„vor“ der ICMP-Echoanforderung, da wir das manuell festgelegt haben … aber PC 2 antwortet eindeutig mit einer Echoantwort auf 1c:3e:84:c8:0c:08eine erfolgreiche ARP-Abfrage – gute Sache – aber PC 1 behauptet, es nie zu erhalten.
Darüber hinaus hat PC 2 nach dem Ping die Adresse von PC 1 in seiner ARP-Tabelle (ich hatte sie zuvor entfernt):
$ arp -n
Address HWtype HWaddress Flags Mask Iface
...
192.168.1.74 ether 1c:3e:84:c8:0c:08 C wlp3s0
...
Das Wiederholen eines Pings mit Wireshark auf PC 1 und tcpdumpauf PC 2 zeigt Folgendes (die Dumps finden Sie unten):
- Der Verkehr von PC 1 → PC 2 scheint in Ordnung zu sein
- Es gibt kein MAC-Munging der Quelle
- Datenverkehr von PC 2 → PC 1 wird nur empfangen, wenn es sich um eine Übertragung handelt (z. B. die ARP-Anfrage).
- DortIstMAC-Munging der Quelle
PC-1-Geräte
$ 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
PC 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
Wenn ich die Richtung umkehre (PC 2 sendet Echoanforderungen an PC 1), sieht PC 1 die Anforderung nie.
Das Deaktivieren der Windows-Firewall hilft nicht.
Als letzten Ausweg kann das Verbinden von PC 1 mit dem Router über Ethernet das Problem beheben. Dies ist derzeit jedoch keine akzeptable Lösung.
Kann jemand helfen?