Kurze Ausfälle der Netzwerk-Verbindung

[kalamazoo]

Nicht tragisch, aber doch nervig:
seit mittlerweile längerer Zeit (seit der Bookworm-Installation?) kommt es in unregelmäßigen Abtänden zu kurzen Netzwerk-Aussetzern mit den Meldungen

Network Management
Connection 'Wired Connection 1' deactivated

und gleich darauf wieder:

Connection 'Wired Connection 1' activated

oft so kurz, dass sie gar nicht auffallen.

Die Aussetzer stehen offenbar in zeitlichem Zusammenhang mit den in journalctl und dmesg gleichlautenden Einträgen:

Code: Alles auswählen

Feb 29 12:21:42 hpZ4G4 kernel: igb 0000:01:00.0: exceed max 2 second
Feb 29 12:21:46 hpZ4G4 kernel: igb 0000:01:00.0: exceed max 2 second
Feb 29 12:21:53 hpZ4G4 kernel: igb 0000:01:00.0: exceed max 2 second
Feb 29 14:11:23 hpZ4G4 kernel: igb 0000:01:00.0: exceed max 2 second
Feb 29 14:11:27 hpZ4G4 kernel: igb 0000:01:00.0: exceed max 2 second

Im NetworkManager gibt es noch die Warnung

Code: Alles auswählen

Feb 29 14:11:30 hpZ4G4 NetworkManager[903]: <warn>  [1709212290.0667] dispatcher: (19) /etc/NetworkManager/dispatcher.d/ntpsec failed (failed): Script '/etc/NetworkManager/dispatcher.d/ntpsec' exited with status 5.

Was tun?

[Livingston]

Ist der NetworkManager alleine verantwortlich für Verbindungen, oder ist noch was anderes beteiligt wie systemd oder ifup/ifdown? Wenn ja, würde ich diese mal probehalber deaktivieren.

[kalamazoo]

Ist der NetworkManager alleine verantwortlich für Verbindungen, oder ist noch was anderes beteiligt wie systemd oder ifup/ifdown? Wenn ja, würde ich diese mal probehalber deaktivieren.

Code: Alles auswählen

# systemctl list-units | grep -i netw
   sys-devices-pci0000:00-0000:00:1c.0-0000:01:00.0-net-eno2.device                          loaded active plugged   I210 Gigabit Network Connection
   sys-subsystem-net-devices-eno2.device                                                     loaded active plugged   I210 Gigabit Network Connection
   networking.service                                                                        loaded active exited    Raise network interfaces
   NetworkManager-wait-online.service                                                        loaded active exited    Network Manager Wait Online
   NetworkManager.service                                                                    loaded active running   Network Manager
   systemd-timesyncd.service                                                                 loaded active running   Network Time Synchronization
   network-online.target                                                                     loaded active active    Network is Online
   network.target                                                                            loaded active active    Network

Habe jetzt mittels

Code: Alles auswählen

ifdown -a --exclude lo

ifupdown deaktiviert. Mal sehen, ob es dann besser funktioniert.

Mir ist auch das Zusammenspiel von networking.service und NetworkManagerservice nicht ganz klar und ob ifupdown überhaupt noch nötig ist.

[Livingston]

Mir ist auch das Zusammenspiel von networking.service und NetworkManagerservice nicht ganz klar und ob ifupdown überhaupt noch nötig ist.

Grundsätzlich sollte networking.service die alte ifup-Methode vollständig ersetzen können.
Was den Networkmanager angeht: Der soll nur die Geräte verwalten, die nicht konfiguriert sind. Meistens macht man das so, das networking.service oder ifup/ifdown die Festverdrahtung über Ethernet erledigt, und der NetworkManager WLAN und Spezialitäten wie z.B. VPN klarmacht. Vor allem in Verbindung mit einer GUI ist diese Aufteilung meist die bequemste. Das ist aber kein Muss. Man kann networking.service oder dem Manager sogar alles zuschieben und das jeweils andere Teil komplett ausschalten.

Wichtig ist vor allem: Wenn man nicht aufpasst, konkurrieren die Dienste. Um das eindeutig zu klären, muss man sich auf jeden Fall die konkreten Konfigurationen ansehen.

NACHSCHLAG:
So, und jetzt noch mal zur Abrundung: Die reine systemd-Methode heißt systemd-networkd.service. Hinter networking.service steckt der alte Kram mit ifup/ifdown, nur dass der nicht mehr über die alten init/rc-Scripte gestartet wird, sondern von systemd adoptiert ist.
Das heißt, bei Dir sind nur zwei Komponenten beteiligt: NetworkManager und ifup/ifdown.

[kalamazoo]

Grundsätzlich sollte networking.service die alte ifup-Methode vollständig ersetzen können.
...
Wichtig ist vor allem: Wenn man nicht aufpasst, konkurrieren die Dienste. Um das eindeutig zu klären, muss man sich auf jeden Fall die konkreten Konfigurationen ansehen.

Danke, ifupdown gänzlich deinstallieren, weil nicht benötigt oder ist es in Zusammenhang mit dem NetworkManager noch nötig?
systemd-networkd.service ist deaktiviert (Voreinstellung: aktiviert).

[Livingston]

systemd-networkd.service aktivieren und dann ifupdown runterschmeißen.
Danach solltest Du noch mal checken:

Code: Alles auswählen

# systemctl status systemd-networkd

Wenn alles läuft, war's das. Wenn nicht, dann nochmal

Code: Alles auswählen

# systemctl enable systemd-networkd
# systemctl start systemd-networkd

hinterher.

[kalamazoo]

systemd-networkd.service aktivieren und dann ifupdown runterschmeißen.

Hmm, das versteh ich nicht ganz: systemd-networkd aktivieren um ifupdown zu deinstallieren?

[mat6937]

Hmm, das versteh ich nicht ganz: systemd-networkd aktivieren um ifupdown zu deinstallieren?

Für systemd-networkd musst Du vorher die config-Dateien (*.network, evtl. auch *.netdev, *.link, evtl. symlinks) erstellen.

Code: Alles auswählen

ls -la /etc/systemd/network

[kalamazoo]

Für systemd-networkd musst Du vorher die config-Dateien (*.network, evtl. auch *.netdev, *.link, evtl. symlinks) erstellen.

Code: Alles auswählen

ls -la /etc/systemd/network

Ich bin diesbezüglich -- bzw. generell was Netzwerk und dessen Administration betrifft -- noch beim Nachlernen ...

Desktop unverändert, kurzer Ausfall der Netzwerkverbindung, diese wird aber sogleich wieder hergestellt. Was aber eigenartig ist: beim Laptop, mit dem ich jetzt ein wenig herumgespielt habe, fällt die Verbindung ebenfalls von Zeit zu Zeit aus, es wird da aber kein "Connection deactivated" angezeigt und es erfolgt auch keine automatische Verbindungswiederherstellung. systemctl restart NetworkManager hilft -- aber auch nicht immer. Ein in der Konsole durchgeführter Download bleibt hängen und lässt sich auch mittels <Strg>+<C> nicht abbrechen ...

Es kann dann dazu führen, dass letztlich alles hängt:

Code: Alles auswählen

# systemctl restart NetworkManager
^C
*** Exit Status 130 ***

# systemctl status NetworkManager
^C
*** Exit Status 130 ***

# systemctl daemon-reload
Reload daemon failed: Transport endpoint is not connected
*** Exit Status 1 ***

# umount -f /mnt/NAS
umount.nfs4: /mnt/TS-873/VOL-1: device is busy
*** Exit Status 16 ***

Was tun?

[kalamazoo]

Für wen immer es interesiert:
nachdem ich networking.service deaktiviert habe, ist die Verbindung stabil; seit mittlerweile fast zwei Wochen funktioniert alles tadellos!

Nachsatz -- oder eigentlich: Nachfrage:
ich habe auf GitHub ein Shell Script entdeckt, das die Internetverbindung überprüft und alle Ausfälle in einer Logdatei dokumentiert; ich würde dieses gerne ausprobieren, durchblicke aber ohne IT-Hintergrund den Code nicht ganz; ist dieser sicher und kann ich das am PC ohne weiteres laufen lassen?
Hier der Link: https://github.com/TristanBrotherton/netcheck

[chrbr]

ich habe auf GitHub ein Shell Script entdeckt, das die Internetverbindung überprüft und alle Ausfälle in einer Logdatei dokumentiert;

Für mich sieht das Skript so aus, als könnte man es getrost einsetzen. Der Kern ist die Funktion NETCHECK() ab Zeile 213. Per Default wird mit wget die google Seite abgerufen. Wenn das funktioniert, dann ist die Internetverbindung vorhanden. Das passiert in einer Endlosschleife. Das sleep in Zeile 251 bestimmt den Abstand zwischen den Tests. Das scheinen 5 Sekunden zu sein.

Aus solchen Skripts kann man gut lernen, zum Beispiel in dem man auf der Befehlszeile eines Terminals nur das wget ausprobiert, auch mit nicht existierenden Adressen. Das wäre dann schon der Funktionskern. Dann kann man sich selber eine Schleife drum bauen und so weiter. Das eigene "Machwerk" muss man ja nicht zwingend nutzen . Aber zum Lernen ist das gut.

Dann könnte man auch überlegen, ob es nicht reicht, mit nmap oder ping eine Seite zu kontaktieren, anstatt mit wget den Inhalt zu holen.

[kalamazoo]

Für mich sieht das Skript so aus, als könnte man es getrost einsetzen. Der Kern ist die Funktion NETCHECK() ab Zeile 213. Per Default wird mit wget die google Seite abgerufen. Wenn das funktioniert, dann ist die Internetverbindung vorhanden. Das passiert in einer Endlosschleife. Das sleep in Zeile 251 bestimmt den Abstand zwischen den Tests. Das scheinen 5 Sekunden zu sein.
...
Dann könnte man auch überlegen, ob es nicht reicht, mit nmap oder ping eine Seite zu kontaktieren, anstatt mit wget den Inhalt zu holen.

werde es somit ausprobieren + mittels nmap "aufpeppen"

[mat6937]

werde es somit ausprobieren ...

24/7 hinter dem eigenen Router und in einer Dauerschleife? Wofür soll das gut sein?
Gute Ergebnisse bekommt man, wenn man z. B. den eigenen Internetanschluss von extern (d.h. aus dem Internet), per "downdetector" (als Dienst 24/7) bzw. einem account bei einem externen Provider (der solche Dienste anbietet), überwachen lässt.

[kalamazoo]

24/7 hinter dem eigenen Router und in einer Dauerschleife? Wofür soll das gut sein?

24/7 ja, aber nicht 24/7/365 -- ich werde das mal einige Tage laufen lassen, um festzustellen, ob die Internetverbindung noch abbricht; teilweise waren die Ausfälle ja so kurz, dass mir das gar nicht aufgefallen ist und es mich daher auch kaum gestört hat (es hat halt ein wenig geruckelt, bis es weitergegangen ist, Downloads wurden auch nicht abgebrochen); das Script misst übrigens auch die Downloadgeschwindigkeit (was dann eher wieder für die Verwendung von wget spricht)

Gute Ergebnisse bekommt man, wenn man z. B. den eigenen Internetanschluss von extern (d.h. aus dem Internet), per "downdetector" (als Dienst 24/7) bzw. einem account bei einem externen Provider (der solche Dienste anbietet), überwachen lässt.

So professionell muss es gar nicht sein, mir reicht, dass jetzt wieder alles ohne Probleme funzt.
ifupdown, networking.service sowie NetworkManager.service harmonieren interessanterweise auf anderen Geräten mit [fast] idenitschen Konfigurationen; weshalb nicht auch hier, ist mir immer noch unklar.

[mat6937]

... das Script misst übrigens auch die Downloadgeschwindigkeit ...

Ja, aber nicht mit wget, sondern mit dem python-Script "speedtest-cli" (... das ich nicht empfehlen kann):

Code: Alles auswählen

echo "Installing this library will allow tests of network connection speed."
  echo "https://github.com/sivel/speedtest-cli"
  echo "Installation is a single python file, saved in:"

(siehe Zeilen 68 bis 70).

[kalamazoo]

Ja, aber nicht mit wget, sondern mit dem python-Script "speedtest-cli" (... das ich nicht empfehlen kann):

Okay, das macht natürlich mehr Sinn!
speedtest-cli habe ich erst gestern zufällig kennengelernt und ausprobiert: muss mal die Bahnfahrtergebnisse mit meinem Heimnetz vergleichen
Und Danke auch für den Code, ich werde die Zeilen ersetzen.

[mat6937]

Und Danke auch für den Code, ich werde die Zeilen ersetzen.

Das war nur zur Info und ist aus dem Script. D. h. es muss nichts ersetzt werden.

EDIT:

Evtl. mit DL nach /dev/null vergleichen:

Code: Alles auswählen

wget -4 -c -O /dev/null http://download.thinkbroadband.com/1GB.zip

(oder gleichwertig).

[kalamazoo]

python-Script "speedtest-cli" (... das ich nicht empfehlen kann)

Weshalb keine Empfehlung für speedtest-cli?