Kein Ethernet Reconnect nach Update

Heute ist Stammtischzeit:
Jeden Donnerstag 20:30 Uhr hier im Chat.
Wer Lust hat, kann sich gerne beteiligen. ;)
  • Hallo zusammen

    ich hab heut festgestellt, dass man nach dem Update auf dem Pi (revision 000e) kein Reconnect mehr hat.

    Was ich getan habe:

    Heute frische SD Karte mit dem letzten Image (Raspberry Pi OS Lite) geflasht :

    Version ist Linux raspberrypi 5.4.83+ #1379 Mon Dec 14 13:06:05 GMT 2020 armv6l GNU/Linux

    Neustarten der Fritzbox oder Ethernetkabel ziehen und wieder einstecken funktioniert, danach reconnected sich der Pi wieder.

    Nach einem apt update & upgrade auf

    Linux raspberrypi 5.10.17+ #1403 Mon Feb 22 11:26:13 GMT 2021 armv6l GNU/Linux

    taucht der Pi <edit>nachdem man den Router rebootet hat </edit> nicht mehr im Netzwerk auf.

    Mit einem Pi4 (auf 64bit) geht das nach wie vor.

    Wollte nur zum einen warnen und zum andern fragen, ob jemand dasselbe Problem hat

    Gruss Alex

  • Nach einem apt update & upgrade auf

    Linux raspberrypi 5.10.17+ #1403 Mon Feb 22 11:26:13 GMT 2021 armv6l GNU/Linux

    taucht der Pi <edit>nachdem man den Router rebootet hat </edit> nicht mehr im Netzwerk auf.

    Wie sind auf deinem PI, _vor und nach_ dem Reboot des Routers, die Ausgaben von:

    Code
    ip a
    route -n
    arp -av
    ip n s

    ?

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

    Meine PIs

    PI4B/8GB (border device) OpenBSD 7.4 (64bit): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server

    PI3B+ FreeBSD 14.0-R-p3 (arm64): SSH-Serv., WireGuard-Serv., ircd-hybrid-Serv., stunnel-Proxy, Mumble-Serv., ddclient

    PI4B/4GB Bullseye-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server, botamusique, ample

  • Sorry kann ich nicht mehr prüfen, da ich wieder auf die Version von Dezember zurückgegangen bin.

    War nur neugierig, ob das jemand anderm auch passiert ist.

    Aber vielen Dank für Deine Unterstützung!

  • ..., da ich wieder auf die Version von Dezember zurückgegangen bin.

    Gut, ... aber das kann ja keine Dauerlösung sein, oder? Evtl. eine neue SD-Karte kaufen, das aktuelle image flashen, updaten/upgraden, testen und den Fehler finden.

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

    Meine PIs

    PI4B/8GB (border device) OpenBSD 7.4 (64bit): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server

    PI3B+ FreeBSD 14.0-R-p3 (arm64): SSH-Serv., WireGuard-Serv., ircd-hybrid-Serv., stunnel-Proxy, Mumble-Serv., ddclient

    PI4B/4GB Bullseye-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server, botamusique, ample

  • hmmm Du hast natürlich recht.

    Ich hatte gehofft, dass sich das Problem in nem halben Jahr geklärt hat oder sich besser googeln lässt.

    Hier mal der Output nach einem normalen Boot:

    und hier nachdem ich das Kabel nochmal eingesteckt hatte:

    Mir war aufgefallen, dass ich das Kabel schon länger ausgesteckt haben muss ... circa 3-5 Minuten. Wenns nach kurzer Zeit (30sec) eingesteckt wird findet er wieder das Netzwerk.

    Würde für mich darauf hindeuten, dass ein Timer ausläuft....

  • und hier nachdem ich das Kabel nochmal eingesteckt hatte:

    Mir war aufgefallen, dass ich das Kabel schon länger ausgesteckt haben muss ... circa 3-5 Minuten. Wenns nach kurzer Zeit (30sec) eingesteckt wird findet er wieder das Netzwerk.

    Würde für mich darauf hindeuten, dass ein Timer ausläuft....

    Benutzt Du auf deinen PIs den dhcpcd?

    Code
    systemctl status dhcpcd

    ?

    Frage am Rande: Wenn ja, warum werden per dhcp, IP-Adressen =/> .200 zugewiesen? Ist das Absicht bzw. wie hast Du die dhcp-Range deiner FritzBox konfiguriert?

    Wie ist mit ausgestecktem Kabel und ca. 5 Sekunden nach dem ausstecken des Kabels, die Ausgabe von:

    Code
    ifconfig eth0

    ? Es geht darum, ob das eth0-Interface zu diesem Zeitpunkt noch eine IP-Adresse hat?

    Für den dhcpcd gibt es diesen (default) timeout von 30 Sekunden. Lt. der manpage:

    Zitat
    Code
    -t, --timeout seconds             Timeout after seconds, instead of the default 30.  A setting of 0 seconds causes             dhcpcd to wait forever to get a lease.  If dhcpcd is working on a single interface             then dhcpcd will exit when a timeout occurs, otherwise dhcpcd will fork into the             background.

    Das kann man ändern, mit den Dateien:

    Code
    timeout.conf
    dhcpcd_restart.conf

    im richtigen "*.service.d"-Verzeichnis und dem richtigen Eintrag in diesen Dateien:

    Code
    [Service]
    ExecStart=
    ExecStart=/usr/bin/dhcpcd -w -q -t 0
    Code
    [Service]
    Restart=always

    Aber nur dann machen bzw. ändern/ergänzen, wenn man auch weiß was man tut bzw. wie man es macht.

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

    Meine PIs

    PI4B/8GB (border device) OpenBSD 7.4 (64bit): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server

    PI3B+ FreeBSD 14.0-R-p3 (arm64): SSH-Serv., WireGuard-Serv., ircd-hybrid-Serv., stunnel-Proxy, Mumble-Serv., ddclient

    PI4B/4GB Bullseye-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server, botamusique, ample

  • Also ich hab jetzt doch mal nen halben Tag dran rumgespielt:

    Mit dem "alten" Image funktioniert alles soweit einwandfrei ohne jegliche Änderungen.

    Nach dem Update gibts folgende Probleme:

    - Wenn das Kabel beim Booten nicht eingesteckt ist bezieht er keine IP mehr

    - Wenn das Kabel länger als 10 Sekunden rausgezogen wird (oder der Router so lange keinen Strom hat/rebootet) bezieht er keine IP mehr

    - DHCPCD läuft die ganze Zeit im htop

    - Timeout und DHCPrestart.conf haben nichts geändert

    - w durch -b ersetzen oder nur eines der beiden oder beide bringen auch nichts

    Mir ist aber auch aufgefallen, dass sobald das Netz weg ist ethtool folgendes rauswirft:

    Code
    Settings for eth0:
    Cannot get device settings: No such device
    Cannot get wake-on-lan settings: No such device
    Cannot get message level: No such device
    Cannot get link status: No such device
    No data available

    während vor dem Udate bei abgestecktem Kabel eben alle Details da stehen mit der Ausnahme Link detected:no.

    Weiss nicht ob das einem was sagt, aber ich finds merkwürdig - sieht ja fast so aus als wär der Anschluss komplett weg.

    Gruss Alex

  • Mir ist aber auch aufgefallen, dass sobald das Netz weg ist ethtool folgendes rauswirft:

    Code
    Settings for eth0:
    Cannot get device settings: No such device

    Naja, dann schon etwas genauer: Was meinst Du mit "das Netz weg ist"?

    Und wie ist zusätzlich zur Ausgabe von ethtool, die Ausgabe von:

    Code
    ip a

    ?

    EDIT:

    Wenn der dhcpcd keinen DHCP-Server erreichen kann, sollte per Autoconfiguration, das Interface eth0 eine LL-IP-Adresse bekommen. Ist das der Fall?

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

    Meine PIs

    PI4B/8GB (border device) OpenBSD 7.4 (64bit): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server

    PI3B+ FreeBSD 14.0-R-p3 (arm64): SSH-Serv., WireGuard-Serv., ircd-hybrid-Serv., stunnel-Proxy, Mumble-Serv., ddclient

    PI4B/4GB Bullseye-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server, botamusique, ample

  • Sorry bin schon etwas durch:

    Mit "Netz weg" meinte ich wenn ich das Kabel für mehr als 10 Sekunden rausgezogen hatte und wieder eingesteckt habe und er danach "keine IP mehr bezieht", aber physikalisch das Kabel eingesteckt (und natürlich mit dem Router verbunden) ist.

    ip a mit funktionierendem Netz:

    (nicht wundern beim rumspielen irgendwann wurde aus eth0 dann enxb827ebac1c1a)

    und ip a nachdem das kabel raus und wieder reingesteckt wurde:

    Code
    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: enxb827ebac1c1a: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000
        link/ether b8:27:eb:ac:1c:1a brd ff:ff:ff:ff:ff:ff
  • Achso noch ein Nachtrag: Dasselbe Phänomen hatte ich auch mit Dietpi, den ich zwischendurch mal ausprobiert hatte. Aber da der glaub ich auch ein Debian Abkömmling ist ist das nicht sonderlich überraschend

  • (nicht wundern beim rumspielen irgendwann wurde aus eth0 dann enxb827ebac1c1a)

    ... und als aus eth0 enxb827ebac1c1a geworden ist, hast Du mit ethtool noch immer nach eth0 geschaut und das o. g. Ergebnis gepostet ...

    So kommen wir nicht weiter.

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

    Meine PIs

    PI4B/8GB (border device) OpenBSD 7.4 (64bit): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server

    PI3B+ FreeBSD 14.0-R-p3 (arm64): SSH-Serv., WireGuard-Serv., ircd-hybrid-Serv., stunnel-Proxy, Mumble-Serv., ddclient

    PI4B/4GB Bullseye-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server, botamusique, ample

  • Stimmt, gut aufgepasst. aber dasselbe wirft er auch für die kryptische Schnittstelle enxb827ebac1c1a raus.

    Aber Du hast recht. So komm ich nciht weiter ... das Update hat irgendwas versaut. Ich roll zurück und lass es noch ein halbes Jahr laufen. Wenn ein schneller Test dann nicht funktioniert werd ich mir wohl neue Hardware gönnen.

    Jedenfalls lohnts sich nicht noch mehr Zeit darein zu investieren

    Trotzdem Dir vielen dank für Deine Hilfsbereitschaft

  • ... das Update hat irgendwas versaut. Ich roll zurück und lass es noch ein halbes Jahr laufen.

    Am Update allein kann es m. E. nicht liegen, denn Du bist ja nicht der Einzige der das Update gemacht hat.

    Evtl. hast Du eine "spezielle Konfiguration", die im Zusammenhang mit dem Update, dieses Problem verursacht.

    Auf Updates zu verzichten, kann nicht die Lösung sein.

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

    Meine PIs

    PI4B/8GB (border device) OpenBSD 7.4 (64bit): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server

    PI3B+ FreeBSD 14.0-R-p3 (arm64): SSH-Serv., WireGuard-Serv., ircd-hybrid-Serv., stunnel-Proxy, Mumble-Serv., ddclient

    PI4B/4GB Bullseye-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server, botamusique, ample

  • Hallo an Alle,

    habe das gleiche Problem, nach dem letzten Update sind weder LAN noch WLAN aktiv.

    Extrem lästig!

    Hardware kann ich ausschließen, mit neuem RaspiIo auf neuer SD-Karte klappen die beiden Verbindungen.

    Frage: Gibt es ein Script oder so, womit man die Netzverbindung neu einrichten kann, so wie es beim ersten Einrichten funktioniert?

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!