Pi Zero´s (Gen.1 & 2) nach untersch. Zeiten nicht mehr erreichbar

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

    du nutzt auch Windows 10. Das kann von Haus aus ssh. Einfach in einer CMD-Konsole oder powershell-Konsole ssh eingeben.

    Wenn da eine Hilfeseite kommt, dann mal ssh pi@IP-ADRESSE eingeben.

    Was ich aber noch nicht versteh. Kannst du grundsätzlich den Raspberry nicht erreichen ? Oder anders, wie versuchst du nodered zu erreichen?

    73 de Bernd

    Ich habe KEINE Ahnung und davon GANZ VIEL!!
    Bei einer Lösung freue ich mich über ein ":thumbup:"
    Vielleicht trifft man sich in der RPi-Plauderecke.
    Linux ist zum Lernen da, je mehr man lernt um so besser versteht man es.

  • Pi Zero´s (Gen.1 & 2) nach untersch. Zeiten nicht mehr erreichbar? Schau mal ob du hier fündig wirst!

  • Der Pi hat durch den LAN Adapter ja nun zwei IP-Adressen. Wenn ich PowerOff mache, so wie gestern Abend, dann ist Node-Red über <IP>:1880 erreichbar.

    Und irgendwann dann nicht erreichbar, weder per ssh, noch per Seitenaufruf.

    Werde das über Windows 10 auch mal probieren. Aber wenn SSH per Putty nicht nutzbar, wieso dann per CMD ?

    Gruß Thorsten

    Einmal editiert, zuletzt von Thor_Sten (15. Januar 2022 um 07:36)

  • Der Pi hat durch den LAN Adapter ja nun zwei IP-Adressen. Wenn ich PowerOff mache, so wie gestern Abend, dann ist Node-Red über <IP>:1880 erreichbar.

    Und irgendwann dann nicht erreichbar, weder per ssh, noch per Seitenaufruf.

    Wenn der PI per ssh nicht erreichbar ist, funktioniert dann noch das:

    Code
    nc -zv <IP-Adresse> 22

    ? Und das mit beiden IP-Adressen (von wlan0 und von eth0).

    BTW: Wie machst Du PowerOff? Denn nach einem poweroff sollte dein PI nicht mehr erreichbar 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

  • so, es ist wieder passiert. Gestern Abend PowerOff gemacht, alles gut, jetzt kann ich mich nicht mehr verbinden.

    Putty -> Network error: Connection timed out

    Powershell -> connect to host: connection timed out

    Node-Red per Browser -> Die Website ist nicht erreichbar

    ping -> Zielhost nicht erreichbar

    nc -zv <IP> 22 -> connect failed: No route to host

    nc -zv <IP> 1880 -> connect failed: No route to host

    sudo nmap -sS <IP> -p22 -> Host seems down. If it´s really up, but blocking out our ping probes, try -Pn

    sudo nmap -Pn <IP> -> 0 hosts up

    Im Router geschaut -> keine aktive Verbindung

    Router Systemmeldungen -> WLAN-Gerät wird abgemeldet: WLAN-Gerät antwortet nicht

    Also log angeschaut und festgestellt, dass 9min vorm Absturz von Node-Red der tägliche Updateservice gestartet wurde

    -> Starting Daily apt upgrade and clean activities...

    Node-Red konnte sich zwar automatisch rebooten, aber 6min später kam wieder "nodered.service: Main process exited, code=killed, status=11/SEGV"

  • Wenn der PI per ssh nicht erreichbar ist, funktioniert dann noch das:

    Code
    nc -zv <IP-Adresse> 22

    ? Und das mit beiden IP-Adressen (von wlan0 und von eth0).

    BTW: Wie machst Du PowerOff? Denn nach einem poweroff sollte dein PI nicht mehr erreichbar sein.

    PowerOff ist in diesem Fall Stecker ziehen .. anders kriege ich ihn nicht neu gestartet

    Gruß Thorsten

  • PowerOff ist in diesem Fall Stecker ziehen .. anders kriege ich ihn nicht neu gestartet

    OK, wenn er komplett abgestürzt ist, ist das mit dem Steckerziehen ja auch nicht schlimm.

    Aber da Du das ja nicht weißt, solltest Du Folgendes machen: Wenn möglich nur den Hardwarewatchdog aktivieren.

    Wie sind die Ausgaben von:

    Code
    ls -la /dev/watchdog*
    cat /boot/config.txt | grep -i watchdog

    ... und was viel wichtiger ist, ein Script, dass alle 5 Minuten (per cronjob oder gleichwertig) prüft ob dein PI sein gateway (Router) noch per arping erreichen kann und wenn das nicht der Fall sein sollte, wird der PI ordnungsgemäß runtergefahren (mit shutdown oder gleichwertig), so dass Du dann durch Stromkabel ziehen und einstecken den PI wieder starten kannst. Ob das funktioniert, kannst Du dann testen bzw. reproduzieren in dem Du das Netzkabel ziehst oder das Wlan am Router deaktivierst (je nach dem über welches Interface (eth0 oder wlan0) der arping geht). Besser wäre schon via eth0, denn es ist einfacher das Netzkabel nur am besagten PI zu ziehen, als das Wlan am Router zu deaktivieren (da davon ja auch andere Geräte betroffen sein können).

    EDIT:

    BTW: Wenn der PI per icmp und tcp nicht mehr erreichbar ist, hast Du schon versucht den PI per arp (z. B. mit arping oder mit arp-scan) zu erreichen?

    EDIT 2:

    Setze mal auf deinem PI einen cronjob, der alle 2 Minuten einen nicht angeforderten arp-reply ins W/LAN (Subnetz vom Router), als broadcast sendet.

    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

    Einmal editiert, zuletzt von rpi444 (15. Januar 2022 um 09:46)

  • Es geht um arping bzw. arp-scan:

    Code
    apt-cache policy iputils-arping arp-scan

    Beispiele:

    Spoiler anzeigen
    Code
    */3 *    * * *    root    /usr/bin/arping -q -c 2 -w 2 -b -f -I eth0 -s 192.168.178.13 192.168.178.1 > /dev/null 2>&1
    */9 *    * * *    root    /usr/bin/arping -q -c 1 -b -A -I eth0 192.168.178.13 > /dev/null 2>&1
    Code
    # cat /usr/local/bin/maybe_shutdown
    #!/bin/sh -e
    #
    if /usr/bin/arping -c 5 -I eth0 -f -q -w 5 -s 192.168.178.13 192.168.178.1; then
        exit 0
    else
        /sbin/shutdown -P +1
    #    
    fi
    exit 0
    Code
    # cat /usr/local/bin/restart_sshd
    #!/bin/bash -e
    #
    if /bin/ps -fC sshd > /dev/null 2>&1; then
        exit 0
    else
        /bin/systemctl restart ssh
        exit 0
    fi
    exit 0
    Code
    */15 *    * * *    root    /usr/local/bin/maybe_shutdown > /dev/null 2>&1
    36 5    * * *    root    /usr/local/bin/restart_sshd > /dev/null 2>&1

    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

  • Ok, habe das mal annähernd so übernommen. Statt dem shutdown -P habe ich aber -r genommen, da ich lieber einen Reboot haben möchte.

    arp-ping und arp-scan sind installiert.

    Warten wir mal den nächsten Fehler ab.

    Gruß Thorsten

  • Statt dem shutdown -P habe ich aber -r genommen, da ich lieber einen Reboot haben möchte.

    BTW: Wenn Du nicht zuhause bist und dein Router (warum auch immer) ausfällt/abstürzt, wird dein PI ständig rebooten. M. E. keine gute Idee.

    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

  • BTW: Wenn Du nicht zuhause bist und dein Router (warum auch immer) ausfällt/abstürzt, wird dein PI ständig rebooten. M. E. keine gute Idee.

    Da hast Du Recht, aber das wäre nur der Fall, wenn er wirklich abstürzt.

    Wäre ein Restart des Netzwerkservice o.ä. nicht auch möglich? Weil die Frage ist doch weiterhin, stürzt der Pi wirklich ab oder ist er nur nicht erreichbar.

    Gruß Thorsten

  • Da hast Du Recht, aber das wäre nur der Fall, wenn er wirklich abstürzt.

    Wäre ein Restart des Netzwerkservice o.ä. nicht auch möglich? Weil die Frage ist doch weiterhin, stürzt der Pi wirklich ab oder ist er nur nicht erreichbar.

    Du kannst das Script auch so modifizieren, dass der PI maximal z. B. 3mal rebootet (evtl. im cronjob den Zeitintervall auf z. B. 15 Minuten ändern) und wenn dann der Router noch immer nicht erreichbar ist, beim 4x runter fährt.

    Den Netzwerkservice kannst Du auch restarten: Z. B. wenn Du dem PI statische IP-Adressen von außerhalb des DHCP-Pools, mit systemd-networkd zuweist und mit einem Script/cronjob prüfst, ob dem Interface noch eine IP-Adresse zugewiesen ist und wenn nicht, dann systemd-networkd restarten. Aber ich denke, da wird ein restart von systemd-networkd nicht bzw. nie erforderlich sein. Und systemd-networkd dann restarten, wenn das gateway per arp nicht erreichbar ist, wird m. E. nichts bringen.

    BTW: Wenn der PI "richtig" abgestürzt ist, wird auch kein cronjob und kein Script mehr funktionieren. Dann kann evtl. nur noch der Hardwarewatchdog "helfen".

    EDIT:

    Wenn die Dienste die auf deinem PI irgendwann nicht mehr erreichbar sind, mit einer service-unit gestartet werden, kannst Du mit z. B.:

    Code
    systemctl show <service-unit>

    schauen, welcher Ressourcenverbrauch diesen Diensten ermöglicht wird bzw. gestattet ist. Evtl. kannst Du dbzgl. noch etwas optimieren.

    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

    Einmal editiert, zuletzt von rpi444 (15. Januar 2022 um 11:06)

  • Moin Thor_Sten,

    dein Fehler ist hier aufgetreten.

    Danach gibt es Versuche einige Dienste zu starten, aber die gehen alle in die Hose.

    Da auch der ssh-agent weg ist, kann ja auch nix mehr gehen.

    Code
    Jan 15 03:50:17 PiZero kernel: [34392.539700] w1_master_driver w1_bus_master1: Family 0 for 00.294000000000.24 is not registered.
    Jan 15 03:51:08 PiZero kernel: [34443.274276] w1_master_driver w1_bus_master1: Attaching one wire slave 00.a94000000000 crc a8
    Jan 15 03:51:08 PiZero kernel: [34443.296447] w1_master_driver w1_bus_master1: Family 0 for 00.a94000000000.a8 is not registered.

    Frage, was sind das eigentlich für Meldungen? Sieht so aus das was mit den DS18B20 nicht stimmt.

    73 de Bernd

    Ich habe KEINE Ahnung und davon GANZ VIEL!!
    Bei einer Lösung freue ich mich über ein ":thumbup:"
    Vielleicht trifft man sich in der RPi-Plauderecke.
    Linux ist zum Lernen da, je mehr man lernt um so besser versteht man es.

  • Da auch der ssh-agent weg ist, kann ja auch nix mehr gehen.

    Das verstehe ich jetzt nicht, es geht um den sshd-server. Was soll der (auf dem Server) mit dem ssh-agent zu tun haben. Auf keinem meiner Server ist ein ssh-agent aktiv, aber sehr wohl auf den Desktops.

    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

  • Ich habe gestern mal die Karte komplett neu aufgesetzt, anschließend Node-Red installiert und Cronjob und Skripts eingerichtet.

    Die Meldung bzgl. 1-Wire standen drin, weil 1-wire enabled war. Ist jetzt aber disabled, da ich es vorerst nicht benötige.

    Warten wir also mal ab, ob er wieder Probleme macht.

    Gruß Thorsten

  • Ich habe gestern mal die Karte komplett neu aufgesetzt, anschließend Node-Red installiert und Cronjob und Skripts eingerichtet.

    Hast Du die lite-Version installiert oder brauchst Du die Voll-Version?

    Ersichtlich sind auch pulseaudio bzw. bluetoothd, etc. auf deinem PI. Brauchst Du all diese (aktiven) Dienste?

    EDIT:

    BTW: Sniffe mal auf einem anderen Gerät in deinem (W)LAN, ob sich der betroffene PI, mit dem nicht angeforderten arp-reply regelmäßig (via cronjob) bemerkbar macht bzw. zu erkennen gibt:

    Code
    sudo tcpdump -c 100 -vvveni <Interface> arp[7] = 2 and src host <IP-Adresse-PI>

    (Interface bzw. IP-Adresse-PI anpassen und ohne spitze Klammern).

    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

    Einmal editiert, zuletzt von rpi444 (16. Januar 2022 um 10:33)

  • Hallo zusammen.

    Wollte mal kurz ein Feedback geben.

    Die Karte neu aufgesetzt zu haben scheint die Lösung gewesen zu sein, zumindest kam es seit 2 Wochen zu keinem Fehler mehr.

    Die Logdateien beinhalten auch keine Fehlermeldungen mehr und der Pi Zero ist permanent per WiFi erreichbar.

    Danke nochmals für die Hilfe und Geduld.

    Gruß Thorsten

    Gruß Thorsten

  • Ich hab das auch schon mit einigen Pis durch und trotz dass die Deaktivierung des Wiffi SaveMode funktionierte, irgendwann waren die Pis nicht mehr erreichbar.

    Inzwischen versuche ich - wo möglich - alles per Netzwerkkabel zu verbinden.

    ;) Gruß Outi :D
    Pis: 2x Pi B (Rente) / 1x Pi B+ (Rente) / 1x Pi 2 B (Rente) / 2x Pi 3 B (RaspberryMatic / Repetier Server) / 2x Pi Zero 1.2 (B. Lite) / 2x Pi Zero 1.3 (B. Lite) / 2x Pi Zero W 1.1 (B. Lite) / 1x Pi Zero 2 (mal so, mal so) / 1x Pi 3 B+ (Tests) / 1x Pi 4 B 4GB (BW Lite (Webserver)) / Pi 400 (BW) / 1x Pi 5 (BW) / 2x Pi Pico / 2x Pi Pico W
    Platinen: Sense HAT / HM-MOD-RPI-PCB / RPI-RF-MOD / PiFi DAC+ V2.0 / TV HAT / Pi 5 Kühler HAT
    Kameras: orig. Raspberry Pi Camera Module V1 & V3 / PS3 Eye

  • ps915 29. Januar 2024 um 19:14

    Hat das Label Zero 2 W hinzugefügt.

Jetzt mitmachen!

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