WiFi Range Extender und fehlgeschlagene ARP-Anforderungen

Ich arbeite an einem Netzwerk, wie unten beschrieben - einem BT HomeHub 5 und einem Netgear EX6150 WiFi-Extender. Es gibt andere Punkte im Netzwerk, obwohl ich sie der Kürze halber ausgelassen habe, und alle rosa gestrichelten Linien sind WLAN.

Das Problem, das ich sehe, ist, dass PC 1 nicht mit PC 2 kommunizieren kann ( kann ), mein Telefon jedoch . Natürlich hat mein Telefon die Möglichkeit, direkt mit dem Extender zu springen, und ich kann das momentan nicht als eine Rolle hier ausschließen.

Die gleiche Situation steht für PC 1, der versucht, mit anderen Hosts auf dem WiFi-Extender zu kommunizieren.

Alle Hosts haben Zugang zum Internet.

Ich habe entdeckt, dass der Extender MAC-Adressen " munge " wird, aber ich kann nicht recht herausfinden, warum . Die MAC-Adresse von PC 2 lautet beispielsweise 88:b1:11:f4:e0:66, aber die Schnittstelle des Routers (und die mit dem Router verbundenen Hosts) werden als Kommunikationsverbindung angezeigt 02:0f:b5:f4:e0:66. Es gibt einen schrecklich geschriebenen Abschnitt im Handbuch auf Seite 33, und es scheint keine Möglichkeit zu geben, ihn auszuschalten. Ich sehe keinen technischen Grund dafür, und ich setze meine Wette darauf, dass dies ein wesentlicher Teil des Problems ist.

Zeit für technische Bits.

• 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 scannt fröhlich das Netzwerk (mit Fing ), ermittelt den Host und pingt es an ... Wie bereits erwähnt, wird PC 1 dies nicht tun.

Ich habe versucht, die Adressinformationen von PC 2 manuell in die ARP-Tabelle von PC 1 einzufü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> 

Es handelt sich also eindeutig nicht nur um ein ARP-Problem.

Wenn ich das aus der Sicht von PC 2 betrachte, habe ich tcpdumpwährend eines Pings einen gemacht:

$ 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-hasVor der ICMP-Echoanforderung gibt es keine, da wir das von Hand ausgelegt haben ... aber PC 2 antwortet eindeutig mit einer Echoantwort auf 1c:3e:84:c8:0c:08eine erfolgreiche ARP-Abfrage - gutes Zeug -, aber PC 1 behauptet, sie niemals zu erhalten.

Außerdem hat PC 2 nach dem Ping die Adresse von PC 1 in seiner ARP-Tabelle (ich habe 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 (siehe unten für die Dumps):

• 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 Sendung handelt (z. B. die ARP-Anforderung).
  • Es gibt ein MAC-Munging der Quelle

PC 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 

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 Echoanfragen an PC 1), sieht PC 1 die Anfrage nie.

Das Deaktivieren der Windows-Firewall hilft nicht.

Wenn Sie den PC 1 über Ethernet mit dem Router verbinden, wird das Problem gelöst. Dies ist jedoch derzeit keine akzeptable Lösung.

Kann jemand helfen?