Meine WLAN-Verbindung bricht zwischen einigen Minuten und einer halben Stunde oder länger ab.
Problembeschreibung:
- Neue Seiten werden nicht geöffnet
- Bereits laufende Downloads werden fortgesetzt
- Ping 8.8.8.8 funktioniert nicht
Die „Lösung“ ist einfach (hält für eine zufällige Zeitspanne):
$ sudo arp -d 192.168.1.1
Diese Lösung macht keinen Sinn, da ich sie überprüft habe und es sich nicht um ARP-Poison handelt.
Irgendwelche Ideen, warum das passiert?
$ ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
^C
--- 8.8.8.8 ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 2999ms
$ sudo arp -d 192.168.1.1
$ ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_req=1 ttl=47 time=55.2 ms
64 bytes from 8.8.8.8: icmp_req=2 ttl=47 time=53.5 ms
64 bytes from 8.8.8.8: icmp_req=3 ttl=47 time=55.2 ms
64 bytes from 8.8.8.8: icmp_req=4 ttl=47 time=53.4 ms
^C
--- 8.8.8.8 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 53.425/54.358/55.282/0.923 ms
Drahtloser Router: ZonHub 1.0 (Hitron BVW3653-Board mit angepasstem OpenRG von Jungo, bereitgestellt von meinem ISP)
BEARBEITEN 1. Mai, 17:12 UTC:
$ ip addr show wlan0
3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
link/ether 00:1c:bf:2a:09:b6 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.2/24 brd 192.168.1.255 scope global wlan0
inet6 fe80::21c:bfff:fe2a:9b6/64 scope link
valid_lft forever preferred_lft forever
$ ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
^C
--- 8.8.8.8 ping statistics ---
9 packets transmitted, 0 received, 100% packet loss, time 7999ms
$ sudo arp -an
? (192.168.1.1) at 00:05:ca:69:96:58 [ether] on wlan0
$ sudo arp -d 192.168.1.1
$ ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_req=1 ttl=47 time=53.5 ms
64 bytes from 8.8.8.8: icmp_req=2 ttl=47 time=53.8 ms
64 bytes from 8.8.8.8: icmp_req=3 ttl=47 time=79.8 ms
^C
--- 8.8.8.8 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 53.544/62.396/79.815/12.317 ms
$ ip addr show wlan0
3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
link/ether 00:1c:bf:2a:09:b6 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.2/24 brd 192.168.1.255 scope global wlan0
inet6 fe80::21c:bfff:fe2a:9b6/64 scope link
valid_lft forever preferred_lft forever
$ sudo arp -an
? (192.168.1.1) at 00:05:ca:69:96:58 [ether] on wlan0
Wie gesagt, kein ARP-Gift.
ANMERKUNG 1:Ich kann nur auf meinem Router auf eine Webseite zugreifen, da alles andere vom ISP gesperrt ist.
Antwort1
Diese Antwort beruht ausschließlich auf Vermutungen. Ich habe keine Ahnung, ob dies tatsächlich die Ursache ist, aber …
Wenn Sie den Router aus Ihrer ARP-Tabelle löschen, wird Ihr Computer gezwungen, beim nächsten Mal, wenn er ein Paket an den Router senden möchte, ein ARP-Paket zu senden. Ich kann mir vorstellen, dass dieses ARP-Paket alles behebt, was in der ARP-Tabelle des Routers defekt ist, da in dem von Ihnen geposteten Beispiel die ARP-Tabelle Ihres Computers in Ordnung zu sein scheint (dasselbe vor und nach der „Reparatur“).
Ich vermute, dass die ARP-Tabelle des Routers, wenn Sie sie einsehen könnten, „(unvollständig)“ anstelle der MAC-Adresse Ihres Computers anzeigen würde (versuchen Sie, eine nicht vorhandene LAN-Adresse anzupingen, um ein Beispiel dafür zu erhalten, wie das aussieht). Er würde in diesen Zustand geraten, wenn der ARP-Eintrag darin abgelaufen wäre, er ein ARP-Paket gesendet hätte und dieses gesendete Paket Ihren Computer nie erreicht hätte (oder das Antwortpaket den Router nie erreicht hätte). Ihr ARP-Paket vervollständigt den Eintrag und er kann wieder IPv4-Pakete an Ihren Computer senden.
Warum sollte das nun passieren? Ich kann mir zwei mögliche Ursachen vorstellen. Eine falsch konfigurierte Firewall auf dem Router oder Ihrem Computer (was ich für unwahrscheinlich halte) oder ein Problem mit der Übertragung vom WLAN-Router.
Etwas problematisch sind Broadcast-Pakete nach dem 802.11-Standard. Da sie an alle angeschlossenen Stationen gerichtet sind:
- Sie werden nicht bestätigt, sodass der AP nicht weiß, ob sie empfangen wurden. Das bedeutet, dass ein einziger falsch platzierter statischer Ausbruch ein Broadcast-Paket zerstören kann.
- Sie müssen mit einer Rate gesendet werden, die alle Stationen hören können. Der AP kann nicht die beste Rate verwenden, die seine Ratenkontrollalgorithmen gefunden haben. Dies bedeutet normalerweise eine viel niedrigere Rate als die Basisraten des BSS. Dies verbraucht mehr Sendezeit, hilft aber bei dem vorherigen Problem (niedrigere Raten sind normalerweise etwas robuster).
- Da dasselbe Paket von allen angeschlossenen Stationen dekodiert werden können soll, können sie nicht mit dem individuellen Schlüssel der Station verschlüsselt werden. Stattdessen müssen sie mit einem separaten Gruppenschlüssel verschlüsselt werden, den alle angeschlossenen Stationen kennen. Dieser Gruppenschlüssel wird regelmäßig rotiert (sonst könnten Stationen, die das Netzwerk verlassen haben, immer noch Broadcast-Pakete dekodieren).
Ich persönlich habe mysteriöse Fehler im Zusammenhang mit diesem letzten Punkt gesehen. Ein Access Point, den ich einmal konfiguriert habe, war mit deaktiviertem Gruppenschlüsselintervall ausgestattet. „Das ist dumm“, dachte ich, „warum sollten sie diese Sicherheitsfunktion deaktivieren?“ und stellte es auf eine Stunde ein. Nachdem ich einige Zeit damit verbracht hatte, zeitweise Probleme mit der drahtlosen Verbindung zu beheben, die durch Pingen von der richtigen Seite gelöst werden konnten (ich weiß nicht mehr, ob es von der kabelgebundenen oder der drahtlosen Seite war – ich hatte SSH-Zugriff auf die Firewall und ich erinnere mich, dass es ein ARP-Problem war), hatte ich eine Einsicht und dachte: „Ah, DESHALB war es standardmäßig deaktiviert, es ist wahrscheinlich fehlerhaft in der Firmware dieses Access Points und sie haben es als Last-Minute-Lösung auf Null gesetzt“, setzte es auf die Standardeinstellung zurück und das Problem verschwand.
Ich habe keine Ahnung, ob das Ihr Problem ist; der Hersteller ist ein ganz anderer und Sie haben wahrscheinlich noch nie mit einer so esoterischen Einstellung herumgespielt.
Als Nächstes könnten Sie versuchen, einen Sniffer auszuführen, wenn das Problem auftritt, um zu sehen, welche Pakete ausgetauscht werden. Wenn Sie einen zweiten Computer haben, können Sie ihn an die Ethernet-LAN-Ports des Routers anschließen und gleichzeitig auch dort einen Sniffer ausführen (um zu sehen, ob meine Hypothese einer ARP-Übertragung, die im LAN, aber nicht im WLAN sichtbar ist, zutrifft).
Und ich habe keine Ahnung, wie die Downloads weitergehen würden, wenn meine Hypothese stimmt. Vielleicht wird die MAC-Adresse im TCP-Verbindungsstatus irgendwie zwischengespeichert?