Fredo
Anmeldungsdatum: 27. Juni 2005
Beiträge: 5244
Wohnort: Bochum
|
Hallo! Bei meinem Laptop (Dell XPS 13) habe ich das Problem, dass der Internetzugriff über das WLAN nach einiger Zeit abbricht. So ca. eine halbe Stunde lang funktioniert es gut, dann lädt nichts mehr. Das WLAN-Symbol in der Statusleiste zeigt dann ein Fragezeichen an. Wenn ich das WLAN wechsele oder es einmal deaktivieren und wieder anschalte, geht es wieder. Hat jemand eine Idee, woran das liegen könnte? Liebe Grüße Fredo $ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: wlp58s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether 9c:b6:d0:ec:a0:77 brd ff:ff:ff:ff:ff:ff
inet6 2a02:908:e841:4240:bcbb:33f:5c22:e3c4/64 scope global temporary dynamic
valid_lft 157760sec preferred_lft 71360sec
inet6 2a02:908:e841:4240:8aaf:5146:5dbc:3f9e/64 scope global dynamic mngtmpaddr noprefixroute
valid_lft 157760sec preferred_lft 71360sec
inet6 fe80::e3dc:6f43:6df8:351e/64 scope link noprefixroute
valid_lft forever preferred_lft forever
3: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default
link/ether 02:42:58:4d:89:cd brd ff:ff:ff:ff:ff:ff
inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0
valid_lft forever preferred_lft forever
4: br-56288a8d4d90: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default
link/ether 02:42:80:0b:cc:35 brd ff:ff:ff:ff:ff:ff
inet 172.19.0.1/16 brd 172.19.255.255 scope global br-56288a8d4d90
valid_lft forever preferred_lft forever $ ip r
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown
172.19.0.0/16 dev br-56288a8d4d90 proto kernel scope link src 172.19.0.1 linkdown $ ip n s
fe80::5667:51ff:fe71:1f54 dev wlp58s0 lladdr 54:67:51:71:1f:54 router REACHABLE $ lspci -nnk | grep -i net -A2
3a:00.0 Network controller [0280]: Qualcomm Atheros QCA6174 802.11ac Wireless Network Adapter [168c:003e] (rev 32)
Subsystem: Bigfoot Networks, Inc. QCA6174 802.11ac Wireless Network Adapter [1a56:1535]
Kernel driver in use: ath10k_pci
Kernel modules: ath10k_pci
|
von.wert
Anmeldungsdatum: 23. Dezember 2020
Beiträge: 9642
|
Powermanagement des WLAN-NICs deaktivieren, natürlich linux-firmware aus Impish installieren.
|
DJKUhpisse
Supporter, Wikiteam
Anmeldungsdatum: 18. Oktober 2016
Beiträge: 17660
Wohnort: in deinem Browser, hier auf dem Bildschirm
|
Betrifft das nur IPv4 oder auch IPv6?
Du hast nämlich keine IPv4-Adresse auf dem WLAN-NIC.
Evtl. läuft da der Lease ab und der macht keinen Request mehr.
|
Fredo
(Themenstarter)
Anmeldungsdatum: 27. Juni 2005
Beiträge: 5244
Wohnort: Bochum
|
DJKUhpisse schrieb: Betrifft das nur IPv4 oder auch IPv6?
Du hast nämlich keine IPv4-Adresse auf dem WLAN-NIC.
Evtl. läuft da der Lease ab und der macht keinen Request mehr.
Puh, keine Ahnung, wie finde ich das denn raus? Ich bin über einen Fritz Repeater im WLAN, vielleicht vergibt der für das interne Netz nur noch eine IPv6-Adresse? Bin leider in Netzwerkdingen ziemlich unbewandert.
|
DJKUhpisse
Supporter, Wikiteam
Anmeldungsdatum: 18. Oktober 2016
Beiträge: 17660
Wohnort: in deinem Browser, hier auf dem Bildschirm
|
Ich bin über einen Fritz Repeater im WLAN, vielleicht vergibt der für das interne Netz nur noch eine IPv6-Adresse?
Der vergibt gar nichts, der ist so wie ein Switch. Zeige ip a
wenn das Problem auftritt und wenn es normal läuft.
|
Fredo
(Themenstarter)
Anmeldungsdatum: 27. Juni 2005
Beiträge: 5244
Wohnort: Bochum
|
Ha, interessant! Meine vorherige Ausgabe war aus der Fehlersituation, wenn ich es jetzt mache, wo es gerade läuft, habe ich tatsächlich auch IPv4: $ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: wlp58s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether 9c:b6:d0:ec:a0:77 brd ff:ff:ff:ff:ff:ff
inet 192.168.0.101/24 brd 192.168.0.255 scope global dynamic noprefixroute wlp58s0
valid_lft 3050sec preferred_lft 3050sec
inet6 2a02:908:e841:4240:ac8a:b5fe:7207:8224/64 scope global temporary dynamic
valid_lft 170803sec preferred_lft 84403sec
inet6 2a02:908:e841:4240:8aaf:5146:5dbc:3f9e/64 scope global dynamic mngtmpaddr noprefixroute
valid_lft 170803sec preferred_lft 84403sec
inet6 fe80::e3dc:6f43:6df8:351e/64 scope link noprefixroute
valid_lft forever preferred_lft forever
3: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default
link/ether 02:42:8e:a2:c5:b6 brd ff:ff:ff:ff:ff:ff
inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0
valid_lft forever preferred_lft forever
4: br-56288a8d4d90: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default
link/ether 02:42:4f:c7:7b:42 brd ff:ff:ff:ff:ff:ff
inet 172.19.0.1/16 brd 172.19.255.255 scope global br-56288a8d4d90
valid_lft forever preferred_lft forever Wie kann ich denn verhindern, dass der "Lease abläuft"?
|
DJKUhpisse
Supporter, Wikiteam
Anmeldungsdatum: 18. Oktober 2016
Beiträge: 17660
Wohnort: in deinem Browser, hier auf dem Bildschirm
|
Wie kann ich denn verhindern, dass der "Lease abläuft"?
Gar nicht, ist bei DHCP so.
Vor Ablauf muss der Lease muss der einen neuen Request stellen.
Nimm den Wireshark und schaue, wie das abläuft und ob das passiert.
|
von.wert
Anmeldungsdatum: 23. Dezember 2020
Beiträge: 9642
|
Sofern der Lease die Ursache sein sollte, könnte man ja ganz einfach statische IPs verwenden.
|
lubux
Anmeldungsdatum: 21. November 2012
Beiträge: 13938
|
DJKUhpisse schrieb: Betrifft das nur IPv4 oder auch IPv6?
Wenn es nur IPv4 betrifft, dann sollte das:
Das WLAN-Symbol in der Statusleiste zeigt dann ein Fragezeichen an
nicht angezeigt werden, oder? @TE: Wie sind die Ausgaben von:
ip n s
arp -av
Wenn das Fragezeichen angezeigt wird? Mach mal dann auch einem ping6 auf die interne IPv6-Adresse vom Router (gateway). EDIT: BTW: man kann eine IPv4-Adresse auch mit unendlicher (infinite) lease-time, per dhcp "zuweisen" lassen.
|
kB
Supporter, Wikiteam
Anmeldungsdatum: 4. Oktober 2007
Beiträge: 8628
Wohnort: Münster
|
lubux schrieb: […] Wenn es nur IPv4 betrifft, dann sollte das:
Das WLAN-Symbol in der Statusleiste zeigt dann ein Fragezeichen an
nicht angezeigt werden, oder?
Doch, das passt schon gut ins Fehlerbild. Das Fragezeichen wird immer angezeigt, wenn der Connectivitäts-Test ins Internet fehl schlägt und möglicherweise noch in weiteren Situationen. Der Connectivitäts-Test schlägt sicher fehl, wenn man wegen fehlender IPv4-Adresse keinen DNS-Server per IPv4 erreichen kann. (Es sei denn, man hat, was aber ungewöhnlich wäre, nur IPv6-Adressen als Namensserver definiert.)
|
lubux
Anmeldungsdatum: 21. November 2012
Beiträge: 13938
|
kB schrieb: Der Connectivitäts-Test schlägt sicher fehl, wenn man wegen fehlender IPv4-Adresse keinen DNS-Server per IPv4 erreichen kann. (Es sei denn, man hat, was aber ungewöhnlich wäre, nur IPv6-Adressen als Namensserver definiert.)
Nein, man hat beides konfiguriert: v6-DNS-Server und v4-DNS-Server. Der TE hat ja neben der IPv4-Adresse auch eine IPv6-Adresse und wenn die IPv4-Adresse (warum auch immer) "verschwindet", sollte die IPv6-Adresse weiter für Internet-Zugang, W/LAN-Zugang und Namensauflösung (DNS) benutzt werden können. Es gibt keinen Grund die WLAN-Verbindung zu unterbrechen oder als unterbrochen anzuzeigen, wenn eine funktionierende IPv6-Verbindung noch da ist. Der TE hast das aber noch nicht vollständig geprüft.
|
Fredo
(Themenstarter)
Anmeldungsdatum: 27. Juni 2005
Beiträge: 5244
Wohnort: Bochum
|
lubux schrieb: Wie sind die Ausgaben von:
ip n s
arp -av
Wenn das Fragezeichen angezeigt wird?
$ ip n s
fe80::5667:51ff:fe71:1f54 dev wlp58s0 lladdr 54:67:51:71:1f:54 router REACHABLE $ arp -av
Einträge: 0 Ignoriert: 0 Gefunden: 0 Im Gegensatz dazu wenn die Verbindung funktioniert: $ arp -av
compalhub.home (192.168.0.1) auf 54:67:51:71:1f:54 [ether] auf wlp58s0
? (192.168.0.17) auf <unvollständig> auf wlp58s0
Einträge: 2 Ignoriert: 0 Gefunden: 2
Mach mal dann auch einem ping6 auf die interne IPv6-Adresse vom Router (gateway).
Das habe ich nicht hingekriegt. Ich dachte, ich würde die IPv6 vom router über ip -f inet6 r rauskriegen, aber wenn ich darauf einen ping6 mache, kommt immer nur "ping6: sendmsg: Das Argument ist ungültig". Das mit der Lease time scheint aber ein guter Hinweis zu sein! Ich kann das Problem provozieren, wenn ich die lease time in den Rounter-Einstellungen runtersetze. Jetzt versuche ich mal, die länger zu machen, in der Hoffnung, dass sich das Problem damit begrenzen lässt. (Natürlich wäre es trotzdem interessant, warum es überhaupt auftritt und hier nicht der offenbar erforderliche neue request erfolgt.) Auf jeden Fall schon mal vielen Dank an alle Helfenden!
|
DJKUhpisse
Supporter, Wikiteam
Anmeldungsdatum: 18. Oktober 2016
Beiträge: 17660
Wohnort: in deinem Browser, hier auf dem Bildschirm
|
|
lubux
Anmeldungsdatum: 21. November 2012
Beiträge: 13938
|
Fredo schrieb: $ ip n s
fe80::5667:51ff:fe71:1f54 dev wlp58s0 lladdr 54:67:51:71:1f:54 router REACHABLE Das habe ich nicht hingekriegt. Ich dachte, ich würde die IPv6 vom router über ip -f inet6 r rauskriegen, aber wenn ich darauf einen ping6 mache, kommt immer nur "ping6: sendmsg: Das Argument ist ungültig".
Die IPv6-Adresse vom Router hast Du doch schon in der Ausgabe von "ip n s" gehabt (siehe oben).
Welche IPv6-Adresse hast Du mit:
ip -f inet6 r
rausgekriegt?
Es gibt verschiedene Möglichkeiten einen Ping auf eine IPv6-Adresse zu machen. Siehe auf deinem Gerät die manpage für ping und/oder ping6. EDIT: Versuch mal mit:
ping6 -c 3 -I wlp58s0 fe80::5667:51ff:fe71:1f54%wlp58s0
|
Fredo
(Themenstarter)
Anmeldungsdatum: 27. Juni 2005
Beiträge: 5244
Wohnort: Bochum
|
lubux schrieb: Versuch mal mit:
ping6 -c 3 -I wlp58s0 fe80::5667:51ff:fe71:1f54%wlp58s0
Ah, danke, das funktioniert! Wusste nicht, dass man bei IPv6 das Interface gesondert angeben muss. (Es scheint übrigens eine der beiden Angaben zu reichen, also entweder via -I oder via % .)
|