Zumindest seit einer Woche hat mein Ubuntu 18.04 manchmal keinen Internetzugang. Trotzdem wird in der GUI das WLAN-Symbol wie gewohnt angezeigt.
Interessanterweise dig @8.8.8.8 google.comfunktioniert es, ping google.comtut es aber nicht. Websites im Browser werden auch nicht geladen.
(Ich beabsichtige, diese Frage mit detaillierteren Beschreibungen dessen zu aktualisieren, was „funktioniert nicht“ bedeutet, wenn ich das nächste Mal die Fehlermeldungen sehe.)
Wenn dies geschieht, dhclient -r wlp0s20f3wird das Problem normalerweise nicht durch behoben, sondern sudo dhclient wlp0s20f3nur vorübergehend.
Manchmal wird das ausgegeben RTNETLINK answers: File existsund in diesem Fall scheint es (manchmal?) so, als müsste ich die GUI verwenden, um das WLAN aus- und wieder einzuschalten. Es scheint, als würde das Gleiche mit ifdown/ ifupoder sudo ifconfig wlp0s20f3 down/ uppassierennichtfunktioniert dafür zuverlässig, die Verwendung der GUI jedoch schon.
Wie kann ich dies beheben, ohne diesen Zustand manuell beenden zu müssen?
Die folgenden Versuche listen auf, was ich versucht habe, und einige zusätzliche, möglicherweise nützliche Informationen. Ich glaube, Beobachtung 7 ist bisher die aufschlussreichste, also scrollen Sie bitte nach unten :)
Versuch 1
ich fandirgendwoder Änderungsvorschlag /etc/network/interfacessieht so aus:
# interfaces(5) file used by ifup(8) and ifdown(8)
auto lo
iface lo inet loopback
# adding this in th ehopes that it will help me avoiding
# that issue where i have to run
# `sudo dhclient wlp...` every time.
auto wlp0s20f3
iface wlp0s20f3 inet dhcp
auto enp0s31f6
iface enp0s31f6 inet dhcp
Das hat aber nicht geholfen und ich habe die Änderungen nach einem Neustart wieder entfernt.
Versuch 2
Dieses Problem scheint häufig zu sein1,2,3aber all die Antworten scheinen nicht viel zu erklären.Diese Antwortlässt vermuten, dass es damit zusammenhängen könnte /etc/resolv.confunddiese Antwortspricht über die Überprüfung, ob eine Standardroute vorhanden ist.
Tatsächlich hatte ich (einmal) keine Standardroute, bevor ich das WLAN neu gestartet habe. Einmal hat Folgendes funktioniert:
# down interface and delete dhcp leases, then up it again
sudo ifdown wlp0s20f3 ; sudo ifconfig wlp0s20f3 down ; sudo rm /var/lib/dhcp/dhclient.* ; sudo ifup wlp0s20f3 ;
# view routes
ip route
# still broken
# try this:
sudo ifconfig wlp0s20f3 down
sudo ifconfig wlp0s20f3 up
ip route
# now it works???
aber beim nächsten Mal war es nicht so:
generic@motorbrot:~$ echo "bad:" && ip route
bad:
169.254.0.0/16 dev virbr0 scope link metric 1000 linkdown
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown
192.168.122.0/24 dev virbr0 proto kernel scope link src 192.168.122.1 linkdown
generic@motorbrot:~$ echo "bad:" && ip route
bad:
169.254.0.0/16 dev virbr0 scope link metric 1000 linkdown
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown
192.168.122.0/24 dev virbr0 proto kernel scope link src 192.168.122.1 linkdown
generic@motorbrot:~$ ping 1.1.1.1 -
ping: -: Name or service not known
generic@motorbrot:~$ ping 1.1.1.1
connect: Network is unreachable
generic@motorbrot:~$ dig @8.8.8.8 google.com
^Cgeneric@motorbrot:~echo "after down:" && ip route
after down:
169.254.0.0/16 dev virbr0 scope link metric 1000 linkdown
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown
192.168.122.0/24 dev virbr0 proto kernel scope link src 192.168.122.1 linkdown
generic@motorbrot:~$ echo "after up:" && ip route
after up:
169.254.0.0/16 dev virbr0 scope link metric 1000 linkdown
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown
192.168.0.0/24 dev wlp0s20f3 proto kernel scope link src 192.168.0.37
192.168.122.0/24 dev virbr0 proto kernel scope link src 192.168.122.1 linkdown
generic@motorbrot:~$ echo "after down-rm-up:" && ip route
after down-rm-up:
169.254.0.0/16 dev virbr0 scope link metric 1000 linkdown
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown
192.168.0.0/24 dev wlp0s20f3 proto kernel scope link src 192.168.0.37
192.168.122.0/24 dev virbr0 proto kernel scope link src 192.168.122.1 linkdown
generic@motorbrot:~$ echo "after gui turnoff turnon:" && ip route
after gui turnoff turnon:
default via 192.168.0.1 dev wlp0s20f3 proto dhcp metric 600
169.254.0.0/16 dev virbr0 scope link metric 1000 linkdown
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown
192.168.0.0/24 dev wlp0s20f3 proto kernel scope link src 192.168.0.37 metric 600
192.168.122.0/24 dev virbr0 proto kernel scope link src 192.168.122.1 linkdown
Beachten Sie, dass die endgültige, funktionierende Version ip routedie Route anzeigt, die ursprünglich nicht vorhanden war. Irgendwie hat sich also etwas geändert.
Ansatz 3
Bei mir /etc/resolv.confsieht es auch ab und zu düster aus:
# this was the state of the /etc/resolv.conf
# file at the time when my network was currently working after a
# wifi-off-wifi-on action in the gui, but generally had issues
# after some time when I reconnected to a wifi...
domain v.cablecom.net
search v.cablecom.net
nameserver 62.2.17.61
nameserver 62.2.24.158
Aber ich habe meinen eigenen DNS-Resolver, der dnscrypt-proxyauf localhost läuft. Also sollte es eigentlich eher so etwas sein wie
nameserver 127.0.0.1
options edns0
Meinen Notizen zufolge ist dies ein Problem, das ich irgendwann schon einmal hatte.Diese Antwortdns=noneschlägt vor , hinzuzufügen /etc/NetworkManager/NetworkManager.conf, aber das hat damals überhaupt nicht funktioniert, bis nach dem Kommentar vonChris Mooreauch laufen sudo service network-manager restart.
Im Moment dns=noneist jedoch bei mir Folgendes eingestellt NetworkManager.conf:
[main]
plugins=ifupdown,keyfile
# Added 30.07.2020 by LucidBrot to avoid /etc/resolv.conf being overwritten and hence breaking the DNS resolving.
dns=none
[ifupdown]
managed=false
[device]
wifi.scan-rand-mac-address=no
Ich kann versuchen, es noch einmal durchzuführen sudo service network-manager restart, aber es würde mich überraschen, wenn es tatsächlich helfen würde.
Es ist auch erwähnenswert, dass mein /etc/resolv.confein Symlink ist. Lautroter HutDies würde auch dazu führen, dass NetworkManager diese Datei nicht ändert. Aber offensichtlich hat er es getan, denn ich habe nachverfolgt, was ich für den Inhalt dieser Datei festgelegt hatte.
Ich weiß nicht, was ich als Nächstes versuchen soll, und ich würde gerne verstehen, was passiert ist und warum, und außerdem wissen, wie ich das Problem beheben kann.
generic@motorbrot:/etc$ ls -la | grep resolv
drwxr-xr-x 3 root root 3 Mai 7 2020 resolvconf
lrwxrwxrwx 1 root root 25 Mär 31 10:21 resolv.conf -> /etc/resolv.conf.localdns
-rw-r--r-- 1 root root 737 Jul 29 2020 resolv.conf.backup
-rw-r--r-- 1 root root 74 Jul 30 2020 resolv.conf.backup2
-rw-r--r-- 1 root root 364 Mär 31 10:17 resolv.conf.backup3
-rw-r--r-- 1 root root 89 Apr 5 00:06 resolv.conf.localdns
Beobachtung 3
Es passierte erneut, also schaltete ich das WLAN aus und wieder ein. Es funktionierte immer noch nicht. An diesem Punkt führte ich die folgenden Befehle aus:
generic@motorbrot:~$ ip route
default via 192.168.43.68 dev wlp0s20f3 proto dhcp metric 600
169.254.0.0/16 dev virbr0 scope link metric 1000 linkdown
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown
192.168.43.0/24 dev wlp0s20f3 proto kernel scope link src 192.168.43.143 metric 600
192.168.122.0/24 dev virbr0 proto kernel scope link src 192.168.122.1 linkdown
generic@motorbrot:~$ sudo dhclient wlp0s20f3
[sudo] password for generic:
generic@motorbrot:~$ ip route
default via 192.168.43.68 dev wlp0s20f3
169.254.0.0/16 dev virbr0 scope link metric 1000 linkdown
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown
192.168.43.0/24 dev wlp0s20f3 proto kernel scope link src 192.168.43.143
192.168.43.0/24 dev wlp0s20f3 proto kernel scope link src 192.168.43.143 metric 600
192.168.122.0/24 dev virbr0 proto kernel scope link src 192.168.122.1 linkdown
Wir können sehen, dass sich lediglich das Entfernen von aus der Route sudo dhclient wlp0s20f3geändert hat . Danach funktioniert das Internet.proto dhcp metric 600default
NetworkManager oder systemd-networkd
Ein Kommentar deutet darauf hin, dass es möglicherweise zu Konflikten zwischen verschiedenen Konfigurationsmethoden kommt. Ich glaube, ich verwende NetworkManager, und ich glaube, diese Ausgabe stützt diese Annahme:
generic@motorbrot:~$ systemctl list-unit-files | grep networkd
networkd-dispatcher.service enabled
systemd-networkd-wait-online.service disabled
systemd-networkd.service disabled
systemd-networkd.socket disabled
generic@motorbrot:~$ systemctl list-unit-files | grep NetworkManager
NetworkManager-dispatcher.service enabled
NetworkManager-wait-online.service enabled
NetworkManager.service
Beobachtung 4
Im Moment hatte ich das Problem, dass die GUI dachte, ich sei verbunden, aber trotzdem dig @8.8.8.8 google.comnicht funktionierte. Ich vermute also, dass ich mehrere Probleme gleichzeitig habe.
Zu diesem Zeitpunkt gab es keine Standardroute. Ich habe die GUI verwendet, um WLAN aus- und wieder einzuschalten, und jetzt funktionierte die Verbindung wieder, und es war eine Standardroute vorhanden:
# before restarting wifi:
generic@motorbrot:~$ ip route
169.254.0.0/16 dev virbr0 scope link metric 1000 linkdown
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown
192.168.122.0/24 dev virbr0 proto kernel scope link src 192.168.122.1 linkdown
# after restarting wifi:
generic@motorbrot:~$ ip route
default via 192.168.0.1 dev wlp0s20f3 proto dhcp metric 600
169.254.0.0/16 dev virbr0 scope link metric 1000 linkdown
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown
192.168.0.0/24 dev wlp0s20f3 proto kernel scope link src 192.168.0.37 metric 600
192.168.122.0/24 dev virbr0 proto kernel scope link src 192.168.122.1 linkdown
Ich habe einige Antworten gefunden [5,6] erwähnt /etc/NetworkManager/NetworkManager.confbei der erneuten Suche das Problem einer fehlenden Standardroute. Auf meinem Laptop enthält es managed=false. Es scheint, als ob stattdessen dies sein sollte true, also habe ich es vorerst geändert. Diese Antworten scheinen jedoch selbst unsicher zu sein, ob dies sein sollte managed=trueoder managed=false...
[main]
plugins=ifupdown,keyfile
# Added 30.07.2020 by LucidBrot to avoid /etc/resolv.conf being overwritten and hence breaking the DNS resolving.
dns=none
[ifupdown]
managed=true
[device]
wifi.scan-rand-mac-address=no
Die Antworten besagen, dass dies ein erfordert service network-manager restart, was ich jetzt mache. Ich habe ein gemacht systemctl restart NetworkManagerund faszinierenderweise ist meine Standardroute jetzt weg, aber die Internetverbindung funktioniert immer noch. Eine leere Zeile in meinen Routen ist verschwunden.
generic@motorbrot:~$ systemctl status NetworkManager
● NetworkManager.service - Network Manager
Loaded: loaded (/lib/systemd/system/NetworkManager.service; enabled; vendor p
Active: active (running) since Tue 2022-04-05 00:12:28 CEST; 1 weeks 0 days a
Docs: man:NetworkManager(8)
Main PID: 16747 (NetworkManager)
Tasks: 4 (limit: 4915)
CGroup: /system.slice/NetworkManager.service
├─16747 /usr/sbin/NetworkManager --no-daemon
└─32449 /sbin/dhclient -d -q -sf /usr/lib/NetworkManager/nm-dhcp-help
generic@motorbrot:~$ ip route
default via 192.168.0.1 dev wlp0s20f3 proto dhcp metric 600
169.254.0.0/16 dev virbr0 scope link metric 1000 linkdown
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown
192.168.0.0/24 dev wlp0s20f3 proto kernel scope link src 192.168.0.37 metric 600
192.168.122.0/24 dev virbr0 proto kernel scope link src 192.168.122.1 linkdown
generic@motorbrot:~$ systemctl restart NetworkManager
generic@motorbrot:~$ ip route
169.254.0.0/16 dev virbr0 scope link metric 1000 linkdown
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown
192.168.122.0/24 dev virbr0 proto kernel scope link src 192.168.122.1 linkdown
~~Ich werde berichten, ob und wie sich das auf das Verhalten ausgewirkt hat.~~ Das Problem mit der fehlenden Standardroute konnte dadurch jedoch nicht behoben werden. Dieses Problem lässt sich vorübergehend beheben, indem Sie das WLAN in der GUI aus- und wieder einschalten, aber nicht durch sudo dhclient wlp0s20f3.
Da es keinen erkennbaren Effekt zu haben schien, habe ich es bald wieder in geändert managed=false.
Beobachtung 5
Ich glaube, mein Verdacht hat sich bestätigt. Nach dieser Änderung hatte ich jetzt eine Standardroute auf meinem Hotspot, aber immer noch einige Probleme.
- Websites werden nicht geladen, Domänen werden nicht mit Ping aufgelöst
- Telegram hat funktioniert
dig @8.8.8.8 google.comrichtig auflösendig google.comnicht auflösend
Es müsste also entweder ein Problem mit meinem lokalen DNS-Resolver oder ein anderes Netzwerkproblem sein.
Die Routen sahen folgendermaßen aus:
generic@motorbrot:~$ ip route
default via 192.168.43.143 dev wlp0s20f3 proto dhcp metric 600
169.254.0.0/16 dev virbr0 scope link metric 1000 linkdown
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown
192.168.43.0/24 dev wlp0s20f3 proto kernel scope link src 192.168.43.144 metric 600
192.168.122.0/24 dev virbr0 proto kernel scope link src 192.168.122.1 linkdown
generic@motorbrot:~$ ping google.com
^C
generic@motorbrot:~$ dig google.com
; <<>> DiG 9.11.3-1ubuntu1.17-Ubuntu <<>> google.com
;; global options: +cmd
;; connection timed out; no servers could be reached
generic@motorbrot:~$ dig @8.8.8.8 google.com
; <<>> DiG 9.11.3-1ubuntu1.17-Ubuntu <<>> @8.8.8.8 google.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17464
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;google.com. IN A
;; ANSWER SECTION:
google.com. 59 IN A 142.250.203.110
;; Query time: 44 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Wed Apr 13 09:01:30 CEST 2022
;; MSG SIZE rcvd: 55
sudo dhclient -r wlp0s20f3Es hat wieder einmal geklappt , mein lokales DoH vorübergehend wieder zum Laufen zu bringen .
Beobachtung 6
systemctl status systemd-resolvedzeigte, dass es geladen, deaktiviert und aktiv (ausgeführt) war.
Es sollte sein disabled, das ist richtig. Weil ich es als lokalen Stub verwende dnscrypt-proxyund es nicht brauche systemd-resolved. Aber es sollte nicht laufen... Ich weiß nicht, warum es lief, aber ich habe es jetzt wieder gestoppt.
Ich habe meine Datei jetzt auch gelöscht /etc/network/interfaces, dadiese Antwortzeigt an, dass ich es nicht möchte. Es würde verwendet werden, ifupdownaber ich verwende den Netzwerkmanager.
Beobachtung 7
Gefolgtdiese Antwort, ich habe eine Überwachung für die Datei eingerichtet, /etc/resolv.confauf die mein symbolischer Link verweist.
sudo apt install auditd
sudo systemctl status auditd
# shows it is running and enabled
# Set up a rule to watch the file
# and use an arbitrary key for later grepping it:
sudo auditctl -w /etc/resolv.conf.localdns -p wa -k lb_dhclient_issue
# list rules
sudo auditctl -l
# to remove the watch, use the same command but with -W instead of -w and match each other field in the rule.
# i.e.
# sudo auditctl -W /etc/resolv.conf.localdns -p wa -k lb_dhclient_issue
Sehr bald darauf sehe ich bereits Aktivität in dieser Datei:
sudo ausearch -f /etc/resolv.conf.localdns --format text
At 13:47:15 25.04.2022 generic, acting as root, successfully renamed /etc/resolv.conf.localdns.dhclient-new.13892 to /etc/resolv.conf.localdns using /bin/mv
At 13:49:39 25.04.2022 generic, acting as root, successfully renamed /etc/resolv.conf.localdns.dhclient-new.15462 to /etc/resolv.conf.localdns using /bin/mv
At 13:53:08 25.04.2022 generic, acting as root, successfully renamed /etc/resolv.conf.localdns.dhclient-new.17715 to /etc/resolv.conf.localdns using /bin/mv
At 13:56:52 25.04.2022 generic, acting as root, successfully renamed /etc/resolv.conf.localdns.dhclient-new.20232 to /etc/resolv.conf.localdns using /bin/mv
At 13:59:51 25.04.2022 generic, acting as root, successfully renamed /etc/resolv.conf.localdns.dhclient-new.22822 to /etc/resolv.conf.localdns using /bin/mv
Ungefähr alle drei Minuten genericfungiert ein Prozess unter meinem Benutzernamen ( ) als Root, um eine Datei nach zu verschieben /etc/resolv.conf.localdns. Und die Quelle ist /etc/resolv.conf.localdns.dhclient-new.22822, was darauf hindeutet, dass dies dhclientder Übeltäter ist.
Ich schätze chattr +i /etc/resolv.conf, ich könnte es nicht mehr editierbar machen, aber das scheint mir ein schmutziger Ansatz zu sein. Im Moment mache ich das und es scheint erfolgreich zu verhindern, dass dhclient die Datei ändert, aber ich würde gerne verstehen, was schief gelaufen ist und wie ich das gleiche Problem in Zukunft vermeiden kann, vielleicht sogar eine sauberere Lösung.
Außerdem verstehe ich nicht ganz, warum dhclientmir das manuelle Ausführen geholfen hat. Ich vermute, das lag an der fehlenden Standardroute, die seit einiger Zeit nicht mehr angezeigt wird.
Antwort1
Nachdem ich die /etc/resolv.confDatei mit unveränderlich gemacht hatte chattr +i /etc/resolv.conf, dhclienthörte ich auf, meine Datei zu ändern, weil es nicht funktionierte, hörte aber nicht auf, es zu versuchen. Das war in den auditdProtokollen sichtbar.
Irgendwann heute habe ich jedoch versucht, einige andere Probleme zu beheben und habe auch
- und
apt upgradedasapt autoremovehat auch einige Kernel-Header hinzugefügt und entfernt - ein Neustart von Windows, bei dem ich Lenovo Vantage verwendet habe, um eine große Anzahl von Treibern und das BIOS zu aktualisieren
Obwohl ein normaler Neustart bisher überhaupt nicht geholfen hat, scheint die Kombination dieser Dinge den dhclientVersuch beendet zu haben. Meine Überwachungsregeln melden jetzt nur noch meine manuellen Versuche, die Datei zu ändern, keine Fehler mehr von dhclient. Der letzte Fehler von dhclientist vor diesen beiden Aufzählungspunkten aufgetreten.
Es scheint also, dass das Problem wahrscheinlich durch ein Kernel-Upgrade verursacht und durch ein anderes behoben wurde.
Edit 02. Mai 2022: Das stimmt nicht mehr. Heute Morgen war das Problem nicht vorhanden. Jetzt ist es wieder passiert, ohne Neustart dazwischen.
Meine anfängliche Problemumgehung, chattrdie Datei unveränderlich zu machen, war nicht mehr vorhanden (vielleicht hatte ich sie wieder entfernt, nachdem die Prüfung gezeigt hatte, dass der dhclient die Versuche eingestellt hatte) und mein symbolischer Link von /etc/resolv.confnach /etc/resolv.conf.localdnswar weg. Die Datei enthielt falsche Werte für das aktuelle Netzwerk (basierend auf dem ISP des Netzwerks, in dem ich vorher war). Das manuelle Korrigieren der Datei und erneute Einstellen der Unveränderlichkeit hat das Problem wieder behoben ... vorerst.
Es scheint, dass Cisco AnyconnectAuchEinmischung in diese Angelegenheit! Nachdem ich die Prüfprotokolle wie in der Frage beschrieben eingerichtet habe, sehe ich jetzt Folgendes, wenn ich damit eine Verbindung herstelle:
At 18:19:09 02.05.2022 system, acting as root, unsuccessfully opened-file /etc/resolv.conf using /opt/cisco/anyconnect/bin/vpnagentd
At 18:19:09 02.05.2022 system, acting as root, unsuccessfully renamed /etc/resolv.conf.vpnbackup using /opt/cisco/anyconnect/bin/vpnagentd
At 18:19:09 02.05.2022 system, acting as root, unsuccessfully changed-file-ownership-of /etc/resolv.conf to root using /opt/cisco/anyconnect/bin/vpnagentd
At 18:19:09 02.05.2022 system, acting as root, unsuccessfully renamed /etc/resolv.conf.vpnbackup using /opt/cisco/anyconnect/bin/vpnagentd
At 18:19:10 02.05.2022 system, acting as root, unsuccessfully changed-file-ownership-of /etc/resolv.conf to root using /opt/cisco/anyconnect/bin/vpnagentd
At 18:19:10 02.05.2022 system, acting as root, unsuccessfully renamed /etc/resolv.conf.vpnbackup using /opt/cisco/anyconnect/bin/vpnagentd
At 18:19:10 02.05.2022 system, acting as root, unsuccessfully changed-file-ownership-of /etc/resolv.conf to root using /opt/cisco/anyconnect/bin/vpnagentd
Es ist also möglich, dass Cisco Anyconnect die resolv.conf manchmal umbenennt /etc/resolv.conf.vpnbackupund sie dann aus irgendeinem Grund nach dem Verbindungsverlust nicht repariert... Mein aktueller "Fix" mit chattrbedeutet, dass ich keine Verbindung zum VPN herstellen kann. Es scheint, dass dies einbekanntes Problem