Verbindung nach "draußen" sicherstellen. Watchdog?

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

    Unser Pi soll als kleiner Messcomputer in einem Heizungskeller eingesetzt werden.
    Dort sammelt er Daten, welcher er in der internen Datenbank abspeichert.
    Alle drei Stunden soll er die letzten 100 Messwerte an eine externe Datenbank senden.
    Dafür und für den Fernzugriff (über Weaved) ist er über W-Lan im Heimnetz des Hauses eingebunden.

    Leider hat es in den letzten Tagen der Testphase immer wieder Probleme mit dem Halten der Verbindung gegeben.
    Am Morgen war plötzlich kein Pi mehr im Netzwerk zu sehen.
    Nach einem Neustart, also kurz den Stecker raus und wieder rein, war wieder alles OK.

    Eigentlich dachte ich mir, den Pi einfach immer um 1 Uhr nachts neu starten zu lassen (Cron).
    Aber dann würde er ja von dem Zeitpunkt des Verbindungsabbruchs bis um 1 keine Werte mehr übertragen.

    Nach ein bisschen googlen bin ich auf den Watchdog gestoßen und auf auf die Kritik hier im Forum:
    Watchdog-Problem für den Raspberry

    Ob jetzt Watchdog oder nicht, es muss ja ein Test gemacht werden, der bestanden werden kann,
    dann passier nichts, oder durch den der Pi durchfällt und dann einen Gegenmaßnahme eingeleitet wird.
    Der Reboot hat bisher immer funktioniert, daher wäre das eine einfache und verlässliche Maßnahme.

    Nur wann soll diese eingeleitet werden?
    bsp: Der Pi pingt alle x Minuten einen externen Server an
    und wenn das nicht mehr klappt, startet er neu.
    Wenn aber, warum auch immer, das WLAN im Haus ausfällt,
    kommt der Pi nicht mehr zum Messen sondern startet immer wieder neu...

    Habt ihr ne Idee wie ich das realisieren könnte?

    Danke und Gruß Kolja

    auto → de
    udn

  • Verbindung nach "draußen" sicherstellen. Watchdog?? Schau mal ob du hier fündig wirst!

  • Es ist generell sinnvoller ein Problem zu ergründen und zu beheben, als es zu ignorieren und zu umschiffen... Du solltest also lieber dein "Am Morgen war plötzlich kein Pi mehr im Netzwerk zu sehen"-Problem beheben.


    Ein Watchdog ist generell erst mal nur ein Programm/Script was regelmäßig etwas überwacht. Für dein Anliegen würde ich Abstand vom BCM_Watchdog nehmen da dieser das Dateisystem beschädigen kann - der macht nämlich stumpf ein Hard-Reset, trennt also die Stromzufuhr aber fährt nicht das System ordnungsgemäß herunter. Das wäre also gerade für deine Datenbank äußert gefährlich!

    Also wenn, dann schreibt man sich just die 4 Zeilen Code selbst. Je nachdem wie dein Script zur Übertragung der Datenbanksätze aussieht, wäre es aber das beste diesen Vorgang dort direkt mit zu integrieren... Allerdings ahne ich Böses, wenn ich mir deine anderen Beiträge zu dem Projekt in Erinnerung hohle, war das fast alles sinnfrei über PHP und imho etwas Chaos, wofür aber auch nicht du sondern jemand anderes für Verantwortlich ist :-/

    Aber wie gesagt wäre es sinnvoller herauszufinden wieso der Pi eines Tages nicht mehr im WLAN ist - normal ist das jedenfalls nicht.

  • Hallo Kolja,

    folgende Deiner Aktionen stellen in einem Linux-Umfeld insbesondere Raspberry Pi keine Lösung dar:
    - Neustart durch Steckerziehen, um eine verlorengegangene Netzwerkverbindung herzustellen
    - pausenlosen Reboot mit dem gleichen Ziel

    Du musst der Ursache für die ständigen Netzwerkverluste auf den Grund gehen. Hier im Forum gibt es unzählige Threads zu diesem Thema (Mysterium).
    Ursache ist in der Regel eine unzureichende Spannungsversorgung, die nicht ausreicht, um USB-Peripherie, LAN/WLAN etc. sicher zu versorgen.

    Möglicherweise wird eine ausgefallene Netzwerk-Verbindung auch nur vorgetäuscht. Nicht immer ist ein Netzwerk ausgefallen, wenn ein Ping mal nicht funktioniert. Auch 20 gescheiterte Pings in Folge sind noch kein Kriterium dafür.
    Ich lasse - sofern möglich - immer in beiden Richtungen pingen. Dann ist ein harmloser Netzwerk-Aussetzer schnell beseitigt.

    Zur Analyse solcher Netzwerk-Probleme habe ich mal eine Anwendung Host-Repair geschrieben. Danach kannst Du suchen, herunterladen und an Dein Netz anpassen. Dadurch erfährst Du mehr über die Ursachen - und die Netzwerk-Probleme werden beseitigt, bevor Deine Software etwas davon bemerkt.
    Diese Anwendung kennt mehrere Stufen der "Eskalation"
    - Ping scheitert => Wiederholen, ggf. Pingen aus anderer Richtung "weckt" den Schläfer wieder auf (wirkt bei Netzwerk-Aussetzern ohne Verlust der IP-Adresse / IP des Gateways)
    - IP-Adresse des Clients verloren => Schreiben fehlender Informationen in Dateien
    - IP-Adresses des Gateway verloren => Starten entsprechender Linux-Kommandos

    Seit bei mir Host-Repair im Hintergrund läuft, habe ich kein einziges Mal den Raspberry Pi neustarten müssen, um wieder Netzwerk-Verbindung zu erhalten.

    Vom Watchdog halte ich übrigens auch nichts, weil der meist zu giftig agiert und einen Reboot veranlasst, zu dem kein Grund besteht.

    Beste Grüße

    Andreas

    Ich bin wirklich nicht darauf aus, Microsoft zu zerstören. Das wird nur ein völlig unbeabsichtigter Nebeneffekt sein.
    Linus Torvalds - "Vater" von Linux

    Linux is like a wigwam, no windows, no gates, but with an apache inside dancing samba, very hungry eating a yacc, a gnu and a bison.

    Einmal editiert, zuletzt von Andreas (14. Oktober 2017 um 19:53)

  • Hallo Kolja,


    Gibt es das mittlerweile auch in python?

    myLOC(Python) = 0

    Beste Grüße

    Andreas

    Ich bin wirklich nicht darauf aus, Microsoft zu zerstören. Das wird nur ein völlig unbeabsichtigter Nebeneffekt sein.
    Linus Torvalds - "Vater" von Linux

    Linux is like a wigwam, no windows, no gates, but with an apache inside dancing samba, very hungry eating a yacc, a gnu and a bison.

  • Hallo Kolja,

    LOC ist ein Kürzel und steht für Lines of Code.

    [font="Courier New"]myLOC(Python) = 0[/font] bedeutet dann soviel wie Meine Zeilen Code in Python sind genau Null.

    Beste Grüße

    Andreas

    Ich bin wirklich nicht darauf aus, Microsoft zu zerstören. Das wird nur ein völlig unbeabsichtigter Nebeneffekt sein.
    Linus Torvalds - "Vater" von Linux

    Linux is like a wigwam, no windows, no gates, but with an apache inside dancing samba, very hungry eating a yacc, a gnu and a bison.

  • Ah, ok.
    Meine auch... Zumindest die selbst geschriebenen.

    Ich würde aber ungerne auf ein weiteres System (Icon) setzen, welches ich nicht verstehe und welches fehleranfällig sein kann.
    So langsam überlege ich ja, den Pi durch einen kleinen AVR zu ersetzen, da bräuchte ich nur eine Datei und zwei drei Bibliotheken.

    Ich versuche mir mal ein kleines Skript zu schreiben, dass:

    -unseren Server anpingt
    wenn das klappt, ist ja alles OK

    -wenn nicht, pingt es den Router an
    wenn das nicht klappt, ist auch ok, denn da kann der Pi ja dran ändern
    wenn das klappt, muss was getan werden, zur not ein neustart

    Das Skript rufe ich dann über Cron alle 5 Minuten auf.

  • Hallo Kolja,

    wie gesagt, in Beitrag #2 und #3 haben Meigrafd und ich Dir nahe gelegt, dass ein Neustarten / Rebooten keine Methode der Wahl ist.

    Mit dem vorgeschlagenen Programm [font="Courier New"]Host-Repair[/font] wäre Dein Problem gelöst - wenn auch nicht die Ursache (z.B. unzureichende Spannungsversorgung etc.) beseitigt.

    Die Programmiersprache Icon kann wohl neben C / C++ als eine der stabilsten Entwicklungsumgebungen bezeichnet werden. Auch während der übelsten Entwicklungsphasen hatte ich nie einen Programmabsturz hinbekommen. Die üblichen Instrumente, wie man das in anderen Programmiersprachen insbesondere als Anfänger hinbekommst, gibt es in Icon nicht. Es gab sogar mal Entwicklungsprojekte, das ist mir während der gesamten Entwicklung kein einziger Compilierfehler begegnet. Als das Programm dann fehlerfrei lief, habe ich extra einen Fehler eingebaut, um mich davon zu überzeugen, dass wirklich alles in Ordnung ist, und der Fehler auch identifiziert wird. Das tat er dann auch.


    Ich weiß jetzt nicht, wie viele Anwender [font="Courier New"]Host-Repair[/font] einsetzen - aber die es nutzen, sind wohl begeistert. Und einige haben Icon auch nur diesem Zweck installiert. Manche sind dann auf den Geschmack gekommen. ;)


    Wenn Du ein eigenes Script schreibst, dass über Cron alle 5 Minuten aufgerufen wird, dann hast Du im statistischen Mittel einen Netzwerkausfall von 2,5 Minuten - bevor das System wahrscheinlich irrsinnigerweise rebootet wird.

    Mit [font="Courier New"]Host-Repair[/font] hast Du selbst bei 5-sekündigem Aktiv-Werden keinerlei merkbare CPU-Auslastung. Dies entspricht im statistischen Mittel einem Netzwerkausfall von 2,5 Sekunden, die Du garantiert nicht bemerken würdest!


    Letztlich bleibt es Dir überlassen, was Du machst. Ich persönlich lege großen Wert auf ein stabiles System, das störungsfrei läuft, das aber überschaubar bleibt - mir aber auch mitteilt, wenn irgendwas nicht rund läuft.

    Wenn Du Icon suspekt findest, kannst Du ja auch [font="Courier New"]Host-Repair[/font] an Dein Netzwerk anpassen, ein ausführbares Programm erzeugen, beim Systemstarten im Hintergrund laufen lassen - und Icon dann wieder löschen. Ein Icon-Executable braucht normalerweise keinen Zugriff mehr auf das Entwicklungssystem - es gibt keine Dateien, auf die während der Laufzeit zugegriffen werden muss.

    Dann ist Dein System auf dem Stand vor der Icon-Installation - aber mit einem wirkungsvollen Tool mehr.

    Beste Grüße

    Andreas

    Ich bin wirklich nicht darauf aus, Microsoft zu zerstören. Das wird nur ein völlig unbeabsichtigter Nebeneffekt sein.
    Linus Torvalds - "Vater" von Linux

    Linux is like a wigwam, no windows, no gates, but with an apache inside dancing samba, very hungry eating a yacc, a gnu and a bison.

    2 Mal editiert, zuletzt von Andreas (28. Oktober 2017 um 22:11)

  • Jaja, ich lass ja schon die Finger von dem reboot...

    Interessant ist vor allem dein letzter Absatz.

    Es reicht also eine (angepasste) ausführbare Datei auf den Pi zu legen?

    Und könntest du mir diese erzeugen *jetzt soll hier so ein Smilie hin, der mit den Augen rollt*

    Gruß Kolja
    Automatisch zusammengefügt:
    edit: ich sehe gerade, es wird die Router IP benötigt.
    Die habe ich leider nicht von dem Router, wo der Pi nachher stehen wird...

    Einmal editiert, zuletzt von kolja (9. November 2015 um 19:16)


  • Leider hat es in den letzten Tagen der Testphase immer wieder Probleme mit dem Halten der Verbindung gegeben.
    Am Morgen war plötzlich kein Pi mehr im Netzwerk zu sehen.

    Beobachte mal auf deinem PI wenn dieser sich im WLAN befindet, über einen Zeitraum von ca. 2 bis 3 Stunden, die Ausgabe von:

    Code
    sudo tcpdump -vvven ether src or dst <MAC-Adresse-WLAN-Interface_PI> and 'ether proto 0x888e or ether proto 0x0806'

    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

  • @ rpi444
    Musste tcpdump erst installieren, aber jetzt läuft es.

    Was mache ich jetzt ?

    Pi@home:~# sudo tcpdump -vvven ether src or dst c4:6e:1f:26:c2:2a and 'ether proto 0x888e or ether proto 0x0806'
    tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes


  • Ergebnis bei alle 4 Pis:
    0 packets captured
    Dabei wurden Daten an eine externe Datenbank übertragen.

    OK, aber mit der eth0-Schnittstelle kann man die WLAN-Verbindung auch nicht testen (d. h. keine EAPOL-Pakete (rekeying) captured) ... und wenn auch mit der eth0-Schnittstelle in diesem Zeitraum keine arp-requests und keine arp-replys empfangen/ausgetauscht worden sind, dann wundert es mich nicht, dass Du mit deinen PIs, gelegentlich Verbindungsprobleme in den (W)LANs hast.

    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 (9. November 2015 um 22:22)

  • Wenn du sicher bist, dass der PI läuft, und nur die WLAN-Verbindung verloren gegangen ist, könntest du auch regelmäßig, so z.B. vor dem Übertragend er Daten, sehen, ob der PI netz hat udn z.B. den Router erreicht. Wenn nicht, wird das WLAN, vom PI aus, testweise neu gestartet.

    Erst dann wäre ein kompletter Neustart des PI möglich.

    (Beim Ping kann man auch die Größer des 'Ping-Paketes' angeben, so dass nicht nur ein einsamen ICMP-Paket über die Leitung geht.
    Beim Linux kann man, bei den neueren "pings" auch einen Port angeben, auf den gepingt werden soll.
    Auch das würde sicherstellen, dass z.B. das Netz wirklich noch vorhanden ist und nicht einfach nur ICMP-Medungen durchgehen.)

    Computer ..... grrrrrr


  • Beim Linux kann man, bei den neueren "pings" auch einen Port angeben, auf den gepingt werden soll.
    Auch das würde sicherstellen, dass z.B. das Netz wirklich noch vorhanden ist ...

    Auch wenn ein Port im Internet per ping nicht erreichbar ist, bedeutet das nicht immer, dass das Netz (d. h. die WLAN-Verbindung zum WLAN-Router) nicht vorhanden ist. Es gibt auch Fälle in denen lediglich die "default route" fehlt. D. h. man sollte auf Verbindung zum WLAN-Router prüfen (am schnellsten/einfachsten mit dem arp-Protokoll) und prüfen ob die "default route" vorhanden ist. Wenn beides OK, dann kann man auch den Ping ins Internet machen.

    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 (10. November 2015 um 09:44)

  • Wie in jedem Problemfall wäre es doch erst einmal interessant, zu erfahren, welcher WLAN Stick eingesetzt wird. Aber leider ist es eine in sehr vielen Foren übliche Unsitte, solche und andere essentiellen Informationen überhaupt nicht oder nur nach mehrmaligem Nachfragen herauszurücken. So bleibt nur ein herumstochern im Nebel.

    Es gibt genügend WLAN Sticks, deren Stromsparfunktionen unter Linux zwingend abgeschaltet werden müssen, damit die Verbindung dauerhaft besteht, Paradebeispiel der beliebte Edimax.

  • Der eigene Router sollte immer vorhanden sein, wenn das System normal am Netz ist und nur nicht mehr erreichbar ist. Auch sollte der eigene Router, in seinen Standardeigenschaften, immer pingbar sein.
    Eine Adresse im Internet anzupingen kann eine falsche Reaktion hervorrufen, wenn die Verbindung zum Internet mal ausfallen sollte.

    Eine Default-Gateway benötigt das System nur, wenn es aus dem eigenen Netz heraus soll. Für das Netz an dem aktiven Interface wird keine Route benötigt.
    (Wobei ein Default-Gateway aber bei der normalen Konfiguration immer gesetzt wird. Was dann wieder zu Problemen führen kann, wenn das System an zwei unterschiedlichen Netzen hängt und das Netz, das die wirkliche Route hat, zu früh geladen wird. Denn dann wird oft der DG überschrieben.)

    Computer ..... grrrrrr


  • Auch sollte der eigene Router, in seinen Standardeigenschaften, immer pingbar sein.

    Wenn die die WLAN-Verbindung unterbrochen ist, dann ist der eigene Router aber nicht mehr pingbar.
    BTW: Auch wenn die Ausgabe von "ps -fC wpa_supplicant; echo $?" 0 ist, kann die WLAN-Verbindung zum Router unterbrochen sein (bzw. der Router nicht pingbar sein). Dann muss man den wpa_supplicant killen und anschließend neu starten.

    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

  • Der Witz ist ja grade, festzustellen, wenn die Netzverbindung nicht mehr da ist udn dann die passenden Maßnahmen zu ergreifen.
    Wenn man also etwas anpingt, dass garantiert immer da ist, und, wenn es nicht mehr da ist, reagiert, und zwar von dem Gerät aus, von dem man eine Reaktion erreichen kann, muss man dieses Gerät nicht (hart) neu starten.
    (Netz runter fahren, warten, Reste killen und Netz neu starte, zum Bleistift)

    Computer ..... grrrrrr

Jetzt mitmachen!

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