WLAV-Verbindung bricht ständig ab

[mat6937]

FB aus OpenWRT an: Problem trat wieder auf.

Warum hast Du dann nicht, die o. g. Ausgaben gepostet? Was für ein Problem? Mit der Namensauflösung?

[Hount]

Kommen noch. Weil ich die ganzen Ausgaben insgesamt in einem Fred poste

[mat6937]

Weil ich die ganzen Ausgaben insgesamt in einem Fred poste

Warum das? Evtl. brauchst Du für die WLAN-Verbindung zum OpenWRT, eine andere "Optimierung" als für die Verbindung zur FritzBox.

[Hount]

Ich capture jetzt mit OpenWRT.

Beides, also einmal mit FB und einemal mit OpenWRT poste ich hier.

Oder habe ich Dich kervehrt verstanden?

[Hount]

So jetzt die Ausgaben....

Mit OpenWRT ohne FB (17:45) als wieder kein Seitenaufruf möglich war.

Code: Alles auswählen

ping -c 3 -W 2 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_seq=1 ttl=55 time=23.5 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=55 time=22.9 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=55 time=23.1 ms

--- 8.8.8.8 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 22.987/23.221/23.572/0.307 ms


cat /etc/resolv.conf
search lan
nameserver fe80::56e6:fcff:fea7:c0de%wlp1s0


host -t A heise.de
;; connection timed out; no servers could be reached

host -t A heise.de 8.8.8.8
Using domain server:
Name: 8.8.8.8
Address: 8.8.8.8#53
Aliases: 

heise.de has address 193.99.144.80

Ohne den DNS Server 8.8.8.8 war also keine Namensauflösung möglich.

Habe dann im OpenWRT nachgeforscht und gesehen, dass bei den DHCP Settings komischerweise ein DNS forwarding (127.0.0.0) eingetragen war. Das kann natürlich nicht funktionieren.

Jetzt funktioniert auch die Namensauflösung auf heise.de.
host -t A heise.de

Code: Alles auswählen

heise.de has address 193.99.144.80

tcpdump

Code: Alles auswählen

Mit FB

tcpdump: listening on wlp1s0, link-type EN10MB (Ethernet), capture size 262144 bytes
15:35:52.235088 bc:05:43:c1:e7:9a > e4:a7:a0:f1:0c:93, ethertype EAPOL (0x888e), length 161: EAPOL key (3) v2, len 143
15:35:52.235455 e4:a7:a0:f1:0c:93 > bc:05:43:c1:e7:9a, ethertype EAPOL (0x888e), length 113: EAPOL key (3) v1, len 95
15:45:52.201970 bc:05:43:c1:e7:9a > e4:a7:a0:f1:0c:93, ethertype EAPOL (0x888e), length 161: EAPOL key (3) v2, len 143
15:45:52.202275 e4:a7:a0:f1:0c:93 > bc:05:43:c1:e7:9a, ethertype EAPOL (0x888e), length 113: EAPOL key (3) v1, len 95
15:55:52.168405 bc:05:43:c1:e7:9a > e4:a7:a0:f1:0c:93, ethertype EAPOL (0x888e), length 161: EAPOL key (3) v2, len 143
15:55:52.168723 e4:a7:a0:f1:0c:93 > bc:05:43:c1:e7:9a, ethertype EAPOL (0x888e), length 113: EAPOL key (3) v1, len 95
16:05:52.237349 bc:05:43:c1:e7:9a > e4:a7:a0:f1:0c:93, ethertype EAPOL (0x888e), length 161: EAPOL key (3) v2, len 143
16:05:52.238594 e4:a7:a0:f1:0c:93 > bc:05:43:c1:e7:9a, ethertype EAPOL (0x888e), length 113: EAPOL key (3) v1, len 95
16:15:52.206704 bc:05:43:c1:e7:9a > e4:a7:a0:f1:0c:93, ethertype EAPOL (0x888e), length 161: EAPOL key (3) v2, len 143
16:15:52.207090 e4:a7:a0:f1:0c:93 > bc:05:43:c1:e7:9a, ethertype EAPOL (0x888e), length 113: EAPOL key (3) v1, len 95
16:25:52.170977 bc:05:43:c1:e7:9a > e4:a7:a0:f1:0c:93, ethertype EAPOL (0x888e), length 161: EAPOL key (3) v2, len 143
16:25:52.171365 e4:a7:a0:f1:0c:93 > bc:05:43:c1:e7:9a, ethertype EAPOL (0x888e), length 113: EAPOL key (3) v1, len 95
16:35:52.239516 bc:05:43:c1:e7:9a > e4:a7:a0:f1:0c:93, ethertype EAPOL (0x888e), length 161: EAPOL key (3) v2, len 143
16:35:52.239882 e4:a7:a0:f1:0c:93 > bc:05:43:c1:e7:9a, ethertype EAPOL (0x888e), length 113: EAPOL key (3) v1, len 95
16:45:52.204850 bc:05:43:c1:e7:9a > e4:a7:a0:f1:0c:93, ethertype EAPOL (0x888e), length 161: EAPOL key (3) v2, len 143
16:45:52.205158 e4:a7:a0:f1:0c:93 > bc:05:43:c1:e7:9a, ethertype EAPOL (0x888e), length 113: EAPOL key (3) v1, len 95
16:55:52.279617 bc:05:43:c1:e7:9a > e4:a7:a0:f1:0c:93, ethertype EAPOL (0x888e), length 161: EAPOL key (3) v2, len 143
16:55:52.280255 e4:a7:a0:f1:0c:93 > bc:05:43:c1:e7:9a, ethertype EAPOL (0x888e), length 113: EAPOL key (3) v1, len 95
17:05:52.240602 bc:05:43:c1:e7:9a > e4:a7:a0:f1:0c:93, ethertype EAPOL (0x888e), length 161: EAPOL key (3) v2, len 143
17:05:52.240891 e4:a7:a0:f1:0c:93 > bc:05:43:c1:e7:9a, ethertype EAPOL (0x888e), length 113: EAPOL key (3) v1, len 95
tcpdump: pcap_loop: The interface went down
20 packets captured
20 packets received by filter
0 packets dropped by kernel

-----------------------------------------------------------------------------

Mit OpenWRT
17:19:17.637702 54:e6:fc:a7:c0:de > e4:a7:a0:f1:0c:93, ethertype EAPOL (0x888e), length 145: EAPOL key (3) v2, len 127
17:19:17.637990 e4:a7:a0:f1:0c:93 > 54:e6:fc:a7:c0:de, ethertype EAPOL (0x888e), length 113: EAPOL key (3) v1, len 95
17:29:17.600378 54:e6:fc:a7:c0:de > e4:a7:a0:f1:0c:93, ethertype EAPOL (0x888e), length 145: EAPOL key (3) v2, len 127
17:29:17.601605 e4:a7:a0:f1:0c:93 > 54:e6:fc:a7:c0:de, ethertype EAPOL (0x888e), length 113: EAPOL key (3) v1, len 95
17:39:17.696772 54:e6:fc:a7:c0:de > e4:a7:a0:f1:0c:93, ethertype EAPOL (0x888e), length 145: EAPOL key (3) v2, len 127
17:39:17.699655 e4:a7:a0:f1:0c:93 > 54:e6:fc:a7:c0:de, ethertype EAPOL (0x888e), length 113: EAPOL key (3) v1, len 95
17:49:17.669425 54:e6:fc:a7:c0:de > e4:a7:a0:f1:0c:93, ethertype EAPOL (0x888e), length 145: EAPOL key (3) v2, len 127
17:49:17.672357 e4:a7:a0:f1:0c:93 > 54:e6:fc:a7:c0:de, ethertype EAPOL (0x888e), length 113: EAPOL key (3) v1, len 95
17:59:17.848353 54:e6:fc:a7:c0:de > e4:a7:a0:f1:0c:93, ethertype EAPOL (0x888e), length 145: EAPOL key (3) v2, len 127
17:59:17.849363 e4:a7:a0:f1:0c:93 > 54:e6:fc:a7:c0:de, ethertype EAPOL (0x888e), length 113: EAPOL key (3) v1, len 95
18:09:17.713727 54:e6:fc:a7:c0:de > e4:a7:a0:f1:0c:93, ethertype EAPOL (0x888e), length 145: EAPOL key (3) v2, len 127
18:09:17.716643 e4:a7:a0:f1:0c:93 > 54:e6:fc:a7:c0:de, ethertype EAPOL (0x888e), length 113: EAPOL key (3) v1, len 95
18:19:17.660201 54:e6:fc:a7:c0:de > e4:a7:a0:f1:0c:93, ethertype EAPOL (0x888e), length 145: EAPOL key (3) v2, len 127
18:19:17.660520 e4:a7:a0:f1:0c:93 > 54:e6:fc:a7:c0:de, ethertype EAPOL (0x888e), length 113: EAPOL key (3) v1, len 95
18:29:17.711059 54:e6:fc:a7:c0:de > e4:a7:a0:f1:0c:93, ethertype EAPOL (0x888e), length 145: EAPOL key (3) v2, len 127
18:29:17.711359 e4:a7:a0:f1:0c:93 > 54:e6:fc:a7:c0:de, ethertype EAPOL (0x888e), length 113: EAPOL key (3) v1, len 95
18:39:17.667849 54:e6:fc:a7:c0:de > e4:a7:a0:f1:0c:93, ethertype EAPOL (0x888e), length 145: EAPOL key (3) v2, len 127
18:39:17.668458 e4:a7:a0:f1:0c:93 > 54:e6:fc:a7:c0:de, ethertype EAPOL (0x888e), length 113: EAPOL key (3) v1, len 95
^C
18 packets captured
18 packets received by filter
0 packets dropped by kernel

Es scheint also an diesem DNS forwarding gelegen zu sein.

Aber wieso funktioniert es erst eine gewisse Zeit und nach ein paar Minuten später nicht mehr?
Müsste bei einer verkehrten DNS Einstellung nicht immer ein Seitenaufruf fehlschlagen?

Gruß

[mat6937]

Code: Alles auswählen

cat /etc/resolv.conf
search lan
nameserver fe80::56e6:fcff:fea7:c0de%wlp1s0

Es scheint also an diesem DNS forwarding gelegen zu sein.

Aber wieso funktioniert es erst eine gewisse Zeit und nach ein paar Minuten später nicht mehr?
Müsste bei einer verkehrten DNS Einstellung nicht immer ein Seitenaufruf fehlschlagen?

Das Problem sind nicht deine (WLAN-)Router, sondern deine Konfiguration des Laptops.

Da wird evtl. etwas sein, dass den Eintrag (d. h. die IPv4-nameserver) in der /etc/resolv.conf verändert/überschreibt.

Poste mal die Ausgabe von:

Code: Alles auswählen

host -t A heise.de fe80::56e6:fcff:fea7:c0de%wlp1s0

... denn eigentlich sollte auch ein IPv6-nameserver in der resolv.conf, eine Namensauflösung für einen einen A-record machen können.

EDIT:

Z. B.:

Code: Alles auswählen

:~ $ host -t A heise.de fe80::c225:6ff:fe2b:52de%wlan0
Using domain server:
Name: fe80::c225:6ff:fe2b:52de%wlan0
Address: fe80::c225:6ff:fe2b:52de%3#53
Aliases: 

heise.de has address 193.99.144.80

[Hount]

Oha.... Hier die Ausgabe:

Code: Alles auswählen

Using domain server:
Name: fe80::56e6:fcff:fea7:c0de%wlp1s0
Address: fe80::56e6:fcff:fea7:c0de%3#53
Aliases: 

heise.de has address 193.99.144.80

[Hount]

Das Problem sind nicht deine (WLAN-)Router, sondern deine Konfiguration des Laptops.
Da wird evtl. etwas sein, dass den Eintrag (d. h. die IPv4-nameserver) in der /etc/resolv.conf verändert/überschreibt

Was kann denn meine resolve.conf überschreiben?

[mat6937]

Oha.... Hier die Ausgabe:

OK, ... evtl. kann bzw. will auch nicht jeder IPv4-Dienst, zwecks IPv4-Namensauflösung, auf die IPv6-Adresse eines DNS-Servers zugreifen. Deshalb musst Du deinen Laptop so konfigurieren, dass in der resolv.conf immer ein brauchbarer/gültiger IPv4-DNS-Server (eigener Router oder externer) eingetragen ist.

[Hount]

Danke.... Aber der DNS-Server wird doch per DHCP-Server festgelegt oder habe ich da ein Verständnisproblem?

[mat6937]

Was kann denn meine resolve.conf überschreiben?

Z. B.: resolvconf, openresolv, systemd-network, networking, etc, ...., evtl. diverse restarts

[mat6937]

.... Aber der DNS-Server wird doch per DHCP-Server festgelegt ...

Nicht immer. Es gibt auch andere Möglichkeiten/Konfigurationen. Aber auch wenn das so ist, heißt das nicht, dass durch eine "Fehlkonfiguration" die resolv-conf nicht regelmäßig oder sporadisch überschrieben werden kann.

[Hount]

Ah ok...

Die Datei schaut jetzt so aus:

Code: Alles auswählen

domain localdomain
search localdomain
nameserver 192.168.2.1

Passt das so?

[mat6937]

Code: Alles auswählen

domain localdomain
search localdomain
nameserver 192.168.2.1

Passt das so?

Das kannst Du testen mit z. B.:

Code: Alles auswählen

host -t A loc.gov

Hast Du die resolv.conf jetzt manuell editiert?
Aber auch wenn die Namensauflösung damit funktioniert, stellt sich die Frage, wie sieht diese Datei nach 1 Stunde aus bzw. nach einem reboot aus?

[Hount]

Supi Danke.

Noch eine Frage: Was hast Du mit diesem tcpdump Befehl überprüft?

[mat6937]

Noch eine Frage: Was hast Du mit diesem tcpdump Befehl überprüft?

Mit tcpdump und dem Filter sieht man, dass die beiden WLAN-Router, alle 10 Minuten regelmäßig ein rekeying gemacht haben und es in diesem Zeitraum keine Unterbrechung/Wiederverbindung gegeben hat, denn dann hätte tcpdump mit diesem Filter, auch ein 4-way-hand-shake anzeigen müssen (was aber nicht der Fall war).

[Hount]

Supi. Wieder was gelernt.
Vielen Dank.
Tolles Forum bzw. User hier.