Raspberry Pi 3 - Dauerping bei Neustart einrichten, wegen einschlafen LAN Verbindung

  • Hallo,

    ich verwende einen Raspberry Pi 3 (Raspbian GNU/Linux 8) mit installiertem Fhem Server zur Steuerung meiner Hausautomatisation. Mit diesen greife ich über einen RPC Server auf eine CCU2 Zentrale (Homematic) zu, um die Verbindung zu den Homematic Sensoren und Aktoren über Fhem zu bekommen.
    Nun habe ich folgendes Problem, ich beobachte ein "einschlafen" der Kommunikation (LAN) vom Raspi zur CCU2 Zentrale, nach einer Laufzeit von mehr als ca. 6 Stunden inaktivität (Nachts), diese betragen teilweise mehr als 2 Minuten. Ich habe mir schon den Kopf zerbrochen und tagelang in Foren gestöbert aber ich selbst habe nur Vermutungen und kein anderer User hat das gleiche Problem.

    Richte ich aber einen Dauerping vom Raspi zur CCU2 ein, tritt das beschriebene "einschlafen" nicht mehr auf und ich habe Antwortzeiten von weniger als 11 Sekunden. Damit könnte ich prima leben.

    Nun brauche ich eure Hilfe bei der korrekten Einrichtung des Dauerpings auf dem Raspi, welches auch einen Neustart übersteht. Bisher habe ich nach Studium von div. Foren folgende Möglichkeiten versucht.

    Eintrag in etc/rc.local:

    Dieser Eintrag wird jedoch nicht beachtet, ich kann jedenfalls nach einem Neustart keinen gestarteten Ping über "ps ax" erkennen. :(

    Nun habe ich es über etc/crontab wie folgt versucht:

    Nach einem Neustart gibt es keine Fehler, aber wie kann ich erkennen ob der Ping ausgeführt wird?
    Ich denke die Angabe des User pi war hier korrekt oder?

    Noch lieber würde ich das einschlafen der Kommunikation lösen, aber da habe ich die Hoffnung ehrlich gesagt schon aufgegeben.

    Es wäre nett wenn ihr mir mit eurem Wissen hier weitrhelfen könntet.

    Gruß Reinhard

  • Raspberry Pi 3 - Dauerping bei Neustart einrichten, wegen einschlafen LAN Verbindung? Schau mal ob du hier fündig wirst!


  • Nach einem Neustart gibt es keine Fehler, aber wie kann ich erkennen ob der Ping ausgeführt wird?

    Mit Z. B.:

    Code
    sudo apt-get install tcpdump iputils-arping net-tools wireless-tools
    sudo tcpdump -c 50 -vvveni eth0 icmp and host 192.168.1.32


    auf deinem PI, über einen Zeitraum von ca. 10 Minuten.



    Noch lieber würde ich das einschlafen der Kommunikation lösen, ...

    Wie stellst Du das Einschlafen der Kommunikation fest? Poste mal mit und ohne eingeschlafener Kommunikation, die Ausgabe von:

    Code
    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

  • Hallo rpi444,

    danke für die schnelle Antwort. :thumbs1:

    So wie ich es interpretiere wird der Ping einmal pro Minute vom Rpi an die CCU2 gesendet:

    Code
    tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
    21:03:01.098010 b8:27:eb:9f:e7:36 > 00:1a:22:08:40:11, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 164, offset 0, flags [DF], proto ICMP (1), length 84)
       192.168.1.33 > 192.168.1.32: ICMP echo request, id 2015, seq 1, length 64
    21:03:01.098617 00:1a:22:08:40:11 > b8:27:eb:9f:e7:36, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 11669, offset 0, flags [none], proto ICMP (1), length 84)
    .....

    Somit sollte die Variante mit etc/crontab problemlos funktionieren.

    Zu meinem Problem mit der einschlafenden Kommunikation habe ich schon alle mir bekannten Register gezogen und Wochen damit verbracht das Problem mit Logik zu lösen, hier die wichtigsten in Stichpunkten:
    1. Alle Geräte Raspi und CCU2 komplett platt gemacht, Software neu aufgespielt und Test mit Minimalkonfiguration.
    2. Betrieb (nur Raspi und CCU2 alleine) mit statischen IP-Adressen über einen uralten NETGEAR Ethernet Switch (üblich Fritzbox 7390).
    3. CCU2 zum Herstellermit Fehlerbeschreibung eingesandt.

    Alle diese Maßnahmen brachten keinerlei Verbesserung.

    Führe ich aber vom Raspi zur CCU2 einen Dauerping aus, treten die Verzögerungen nicht auf. Lösche ich den Dauerping wieder werden die Antwortzeiten im Laufe der Zeit immer wieder länger, besonders nach einer Nacht (bei wenig Kommunikation zwischen Raspi und CCU2) sind diese am Morgen besonders lang.


    Anbei der Output bei "ip n s", bei Antwortzeiten von unter 10 Sekunden:

    Code
    192.168.1.27 dev eth0 lladdr 08:fd:0e:d9:05:89 STALE                     #Desktop PC 2
    192.168.1.30 dev eth0 lladdr 00:30:de:05:5a:d9 STALE                              #WAGO Steuerung (SPS)
    192.168.1.25 dev eth0 lladdr 00:11:e2:09:cf:1b REACHABLE                      #Desktop PC
    192.168.1.32 dev eth0 lladdr 00:1a:22:08:40:11 STALE                              #CCU2
    192.168.1.13 dev eth0 lladdr 9c:c7:a6:85:44:b3 REACHABLE                      #Fritz Box 7390 (Router)
    fe80::9ec7:a6ff:fe85:44b3 dev eth0 lladdr 9c:c7:a6:85:44:b3 router STALE
    fd00::9ec7:a6ff:fe85:44b3 dev eth0 lladdr 9c:c7:a6:85:44:b3 router STALE


    Den Output bei Antwortzeiten > 1 Minute liefere ich ggf. in den nächstn Tagen nach.

    Vorerst vielen Dank für deine Mühe, bei mir keimt wieder Hoffnung auf das Problem eventuell doch noch zu lösen.
    Gruß Reinhard


  • Anbei der Output bei "ip n s", bei Antwortzeiten von unter 10 Sekunden:

    Code
    192.168.1.32 dev eth0 lladdr 00:1a:22:08:40:11 STALE                              #CCU2
    192.168.1.13 dev eth0 lladdr 9c:c7:a6:85:44:b3 REACHABLE                      #Fritz Box 7390 (Router)

    Konfiguriere deinen PI so, dass dieser sofort nach dem booten, einen statischen arp-cache-Eintrag für diese Geräte hat.

    BTW: Wenn Du IPv6 nicht brauchst, dann evtl. (schon beim booten) deaktivieren.

    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 rpi444,

    IPV6 sollte mir gelungen sein zu deaktivieren, guck bitte mal ob es so passt (nach Neustart):

    Code
    root@raspberrypi:~# ip addr show
    1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
       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
    2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
       link/ether b8:27:eb:9f:e7:36 brd ff:ff:ff:ff:ff:ff
       inet 192.168.1.33/24 brd 192.168.1.255 scope global eth0
          valid_lft forever preferred_lft forever

    Mit "ip n s":

    Code
    root@raspberrypi:~# ip n s
    192.168.1.13 dev eth0 lladdr 9c:c7:a6:85:44:b3 REACHABLE
    192.168.1.32 dev eth0 lladdr 00:1a:22:08:40:11 REACHABLE
    192.168.1.30 dev eth0 lladdr 00:30:de:05:5a:d9 REACHABLE
    192.168.1.25 dev eth0 lladdr 00:11:e2:09:cf:1b REACHABLE

    Der obige Auszug ist nur eine Momentaufname, führe ich "ip n s" mehrmals hintereinander aus, wechseln die Zustände zwischen DELAY, STALE, REACHABLE bei allen Teilnehmern!

    WLAN und Bluetooth habe ich auch noch abgeschaltet, da ich es derzeit definitiv nicht benötige.
    Bezüglich der Konfiguration mit dem statischen arp-cache-Eintrag bin ich als Linux Neuling noch am suchen, eventuell benötige ich da noch Hilfe.

    Tausend Dank, Gruß Reinhard
    Automatisch zusammengefügt:
    Hallo rpi444,

    habe mich mal mit dem statischen arp-cache-Eintrag wie folgt versucht:


    Ich habe die Datei als root User neu erstellt:

    Code
    /etc/network/if-up.d/add-my-static-arp
    
    
    #!/bin/sh
    arp -i eth0 -s 192.168.1.13 9c:c7:a6:85:44:b3
    arp -i eth0 -s 192.168.1.32 00:1a:22:08:40:11
    
    
    chmod +x /etc/network/if-up.d/add-my-static-arp

    War es korrekt, dass ich für den Router (Fritz-Box) und für meine CCU2 eine statische arp Zuweisung anlege?
    Müsste ich nicht auch für meine WAGO Steuerung (192.168.1.30) eine statische arp Zuweisung anlegen, da ich alle 60 Sekunden vom Raspi von dieser SPS über MODBUS ca. 30 Variablen abhole?


    Ich hoffe es war korrekt so, Fehler kommen nach dem Reboot keine und die Kommunikation steht.

    Code
    192.168.1.32 dev eth0 lladdr 00:1a:22:08:40:11 PERMANENT
    192.168.1.25 dev eth0 lladdr 00:11:e2:09:cf:1b REACHABLE
    192.168.1.13 dev eth0 lladdr 9c:c7:a6:85:44:b3 PERMANENT
    192.168.1.30 dev eth0 lladdr 00:30:de:05:5a:d9 REACHABLE

    Ich habe mal den Dauerping wieder entfernt, damit ich die Übermittlungsverzögerungen korrekt messen kann. Somit kann ich sehen ob sich durch diese Maßnahmen etwas verbessert hat.


    Gruß Reinhard

    Einmal editiert, zuletzt von Rewe2000 (27. Februar 2017 um 20:46)


  • War es korrekt, dass ich für den Router (Fritz-Box) und für meine CCU2 eine statische arp Zuweisung anlege?
    Müsste ich nicht auch für meine WAGO Steuerung (192.168.1.30) eine statische arp Zuweisung anlegen, da ich alle 60 Sekunden vom Raspi von dieser SPS über MODBUS ca. 30 Variablen abhole?

    Du kannst für alle Geräte zu denen dein PI eine permanente Verbindung haben soll/muss, eine statischen arp-cache-Eintrag anlegen/konfigurieren.

    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 rpi444,

    die Umstellung auf statischen arp-cache hat leider nicht den gewünschten Erfolg gebracht.
    Ich vermute fast, es muss an der Hardware der CCU2 oder am Raspi liegen, da mir kein anderer User bekannt ist, welcher ähnliche Probleme hat und diese Verbindung (Raspi, CCU2, FHEM) nutzen viele.
    Aber so recht kann ich mir auch nicht vorstellen, dass es an elektronischen Bauteilen liegen könnte.

    Ich denke ich werde mir nochmals einen Raspi und eine CCU2 zulegen, damit ich eine vernünftige Ausschlußdiagnostik betreiben kann, auch wenn es finanziell ziemlich schmerzt.

    Die Laufzeiten messe ich wie folgt:

    1. Die Zeiten werden über einen NTP Zeitserver auf der Fritz Box beim Raspi und der CCU2 syncronisiert.
    2. Ein ankommendes Signal eines Bewegungsmelders in der CCU2, schreibt die Systemzeit der CCU2 in eine Systemvariable.
    3. Diese Systemvariable mit der CCU2 Zeit wird zum Raspi übertragen.
    4. Wenn das Signal des Bewegungsmelders im FHEM Server ankommt werden die Zeiten in eine Log-Datei geschrieben.

    Somit kann ich sehr genau die Verzögerungszeit messen.

    Anbei mal 2 Gegenüberstellungen der Zeiten:

    Verzögerungen mit Dauerping (1 Sekunde) und arp-cache dynamisch.Verzögerung mit ständigen Anpingen.pdf

    Verzögerungen mit Dauerping (1 Minute) und arp-cache dynamisch.Verzögerung mit dyn. arp-cache Eintrag.pdf

    Verzögerungen ohne Dauerping und arp-cache statisch .Verzögerung mit stat. arp-cache-Eintrag.pdf


    Hast du noch eine Idee was ich noch machen könnte?

    Gruß Reinhard


  • ..., da mir kein anderer User bekannt ist, welcher ähnliche Probleme hat ...

    Siehe z. B. auch: RPi 3 WLAN schläft ein


    Hast du noch eine Idee was ich noch machen könnte?

    ... leider nein.

    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 rpi444,

    eben habe ich noch einen Raspberry PI 3 und eine CCU2 (als Bausatz) bestellt, somit kann ich zumindestens ausschließen, dass Hardware defekt ist. Ganz umsonst ist die Investition ja auch nicht, denn somit habe ich immer Ersatz wenn ein Gerät zukünftig ausfallen sollte ;) .

    Bei dir möchte ich mich für die Hilfe vielmals bedanken, auch wenn wir mein Problem nicht lösen konnten. :thumbs1:
    Sollte ich neue Erkenntnisse gewinnen, so hänge ich diese an diesen Thread an.

    Gruß Reinhard

    P.s. Wie würden wir nur unsere freie Zeit verbringen, wenn es keine Computer geben würde?

  • Hallo Reinhard,

    herzlich Willkommen in unserem Forum!

    2013 hatte ich auch mal so ein Problem, dass gelegentlich bis jede Stunde mal die LAN-Verbindung verlorenging. Damals habe ich das Programm [font="Courier New"]HostRepair[/font] geschrieben. Das macht einen zeitlich einstellbaren Dauerping auf Netzwerk-Teilnehmer und den Router. Wenn eine dieser IP-Adressen nicht erreichbar ist, wird geschaut, ob dies an bestimmten Dateien des Betriebsystemes liegt. Wenn ja, werden diese Daten repariert.

    Den Quellcode kannst Du im Forum herunterladen.


    So, wie Du geschrieben hast, brauchst Du diesen Reparaturteil nicht?
    Dann kannst Du die beiden Reparatur-Funktionen weglassen.

    Ursache bei mir war damals ein schwaches Netzteil. Nach dem Austausch kam der Fehler extrem selten vor. Da [font="Courier New"]HostRepair[/font] per Autostart aufgerufen wird, bekomme ich davon auch nicht viel mit, außer dass es vielleicht 3 mal im Monat mal eine Verbindung herstellen konnte. Verbindungsausfälle bemerke ich als Nutzer überhaupt nicht mehr - aber [font="Courier New"]HostRepair[/font] zählt weiter.

    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 (28. Februar 2017 um 19:54)

  • Hallo Andreas,

    danke für die Info und das Angebot. Ich werde mir dein Programm mal ansehen und dieses ggf. testen.

    Bei mir hillft definitiv ein Dauerping, solange dieser läuft, habe ich Antwortzeiten um max. 10-11 Sekunden und damit kann ich prima leben. Ich denke ein Ping alle Sekunden muss es nicht sein, es sollten auch 10 Sekunden ausreichen, eine Minute ist jedenfalls zu lange.

    Da ich blutiger Linux Anfänger (im fortgeschrittenen Alter) bin, bräuchte ich noch etwas Hilfe bei der automatischen Einrichtung eines Dauerpings, welcher auch ein reboot übersteht.

    Mit crontab geht ja unter 1 Minute nichts und als Eintrag in etc/rc.local klappt das auch nicht (siehe oben im thread). Ich habe schon so ziemlich alles abgesucht was es in dieser Richtung gibt, aber leider nichts passendes gefunden.

    Hättest du oder ein anderer User noch einen Tipp zur Einrichtung des dauerhaften Dauerping für mich.

    Danke und Gruß Reinhard

  • Hallo Reinhard,

    lade erst mal den Quellcode von HostRepair herunter.

    Dann musst Du die verwendete Programmiersprache installieren (suche nach: Icon Tutorial Teil 1).

    Dann den Quellcode durchjagen.

    Dann einen Autostart einrichten mit

    Code
    iconx hostrepair

    bzw.

    Code
    /home/bin/icon9_51/bin/iconx /home/bin/icon9_51/bin/hostrepair

    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.


  • Ich denke ein Ping alle Sekunden muss es nicht sein, es sollten auch 10 Sekunden ausreichen, ...

    Es gibt tools mit denen Du das machen kannst, z. B. nping ("-c" die Anzahl der pings und "--delay" der Intervall):

    Code
    sudo nping -c 1000000000 --icmp --icmp-type time --delay 10s 192.168.178.1
    Spoiler anzeigen


    pi@raspberrypi:~ $ sudo nping -c 1000000000 --icmp --icmp-type time --delay 10s <IP-Adresse-Router>

    Starting Nping 0.7.01 ( https://nmap.org/nping ) at 2017-02-28 20:34 CET
    SENT (0.1116s) ICMP [192.168.178.43 > 192.168.178.1 Timestamp request (type=13/code=0) id=24301 seq=1 orig=0 recv=0 trans=0] IP [ttl=64 id=18854 iplen=40 ]
    RCVD (0.2784s) ICMP [192.168.178.1 > 192.168.178.43 Timestamp reply (type=14/code=0) id=24301 seq=1 orig=0 recv=70473051 trans=70473051] IP [ttl=64 id=23097 iplen=40 ]
    SENT (10.1207s) ICMP [192.168.178.43 > 192.168.178.1 Timestamp request (type=13/code=0) id=24301 seq=2 orig=0 recv=0 trans=0] IP [ttl=64 id=18854 iplen=40 ]
    RCVD (10.1484s) ICMP [192.168.178.1 > 192.168.178.43 Timestamp reply (type=14/code=0) id=24301 seq=2 orig=0 recv=70483057 trans=70483057] IP [ttl=64 id=23098 iplen=40 ]
    SENT (20.1219s) ICMP [192.168.178.43 > 192.168.178.1 Timestamp request (type=13/code=0) id=24301 seq=3 orig=0 recv=0 trans=0] IP [ttl=64 id=18854 iplen=40 ]
    RCVD (20.2284s) ICMP [192.168.178.1 > 192.168.178.43 Timestamp reply (type=14/code=0) id=24301 seq=3 orig=0 recv=70493058 trans=70493058] IP [ttl=64 id=23099 iplen=40 ]
    SENT (30.1283s) ICMP [192.168.178.43 > 192.168.178.1 Timestamp request (type=13/code=0) id=24301 seq=4 orig=0 recv=0 trans=0] IP [ttl=64 id=18854 iplen=40 ]
    RCVD (30.3084s) ICMP [192.168.178.1 > 192.168.178.43 Timestamp reply (type=14/code=0) id=24301 seq=4 orig=0 recv=70503064 trans=70503064] IP [ttl=64 id=23100 iplen=40 ]
    SENT (40.1395s) ICMP [192.168.178.43 > 192.168.178.1 Timestamp request (type=13/code=0) id=24301 seq=5 orig=0 recv=0 trans=0] IP [ttl=64 id=18854 iplen=40 ]
    RCVD (40.1884s) ICMP [192.168.178.1 > 192.168.178.43 Timestamp reply (type=14/code=0) id=24301 seq=5 orig=0 recv=70513076 trans=70513076] IP [ttl=64 id=23101 iplen=40 ]
    SENT (50.1483s) ICMP [192.168.178.43 > 192.168.178.1 Timestamp request (type=13/code=0) id=24301 seq=6 orig=0 recv=0 trans=0] IP [ttl=64 id=18854 iplen=40 ]
    RCVD (50.3184s) ICMP [192.168.178.1 > 192.168.178.43 Timestamp reply (type=14/code=0) id=24301 seq=6 orig=0 recv=70523085 trans=70523085] IP [ttl=64 id=23102 iplen=40 ]
    SENT (60.1595s) ICMP [192.168.178.43 > 192.168.178.1 Timestamp request (type=13/code=0) id=24301 seq=7 orig=0 recv=0 trans=0] IP [ttl=64 id=18854 iplen=40 ]
    RCVD (60.1884s) ICMP [192.168.178.1 > 192.168.178.43 Timestamp reply (type=14/code=0) id=24301 seq=7 orig=0 recv=70533096 trans=70533096] IP [ttl=64 id=23103 iplen=40 ]
    SENT (70.1706s) ICMP [192.168.178.43 > 192.168.178.1 Timestamp request (type=13/code=0) id=24301 seq=8 orig=0 recv=0 trans=0] IP [ttl=64 id=18854 iplen=40 ]
    RCVD (70.2684s) ICMP [192.168.178.1 > 192.168.178.43 Timestamp reply (type=14/code=0) id=24301 seq=8 orig=0 recv=70543107 trans=70543107] IP [ttl=64 id=23104 iplen=40 ]
    SENT (80.1815s) ICMP [192.168.178.43 > 192.168.178.1 Timestamp request (type=13/code=0) id=24301 seq=9 orig=0 recv=0 trans=0] IP [ttl=64 id=18854 iplen=40 ]
    RCVD (80.3484s) ICMP [192.168.178.1 > 192.168.178.43 Timestamp reply (type=14/code=0) id=24301 seq=9 orig=0 recv=70553118 trans=70553118] IP [ttl=64 id=23105 iplen=40 ]
    SENT (90.1925s) ICMP [192.168.178.43 > 192.168.178.1 Timestamp request (type=13/code=0) id=24301 seq=10 orig=0 recv=0 trans=0] IP [ttl=64 id=18854 iplen=40 ]
    RCVD (90.2284s) ICMP [192.168.178.1 > 192.168.178.43 Timestamp reply (type=14/code=0) id=24301 seq=10 orig=0 recv=70563130 trans=70563130] IP [ttl=64 id=23106 iplen=40 ]
    SENT (100.2036s) ICMP [192.168.178.43 > 192.168.178.1 Timestamp request (type=13/code=0) id=24301 seq=11 orig=0 recv=0 trans=0] IP [ttl=64 id=18854 iplen=40 ]
    RCVD (100.3084s) ICMP [192.168.178.1 > 192.168.178.43 Timestamp reply (type=14/code=0) id=24301 seq=11 orig=0 recv=70573140 trans=70573140] IP [ttl=64 id=23107 iplen=40 ]
    SENT (110.2108s) ICMP [192.168.178.43 > 192.168.178.1 Timestamp request (type=13/code=0) id=24301 seq=12 orig=0 recv=0 trans=0] IP [ttl=64 id=18854 iplen=40 ]
    RCVD (110.3984s) ICMP [192.168.178.1 > 192.168.178.43 Timestamp reply (type=14/code=0) id=24301 seq=12 orig=0 recv=70583147 trans=70583147] IP [ttl=64 id=23108 iplen=40 ]
    ^C
    Max rtt: 187.383ms | Min rtt: 27.394ms | Avg rtt: 109.961ms
    Raw packets sent: 12 (480B) | Rcvd: 12 (480B) | Lost: 0 (0.00%)
    Nping done: 1 IP address pinged in 112.96 seconds

    Mit einem cronjob könntest Du Prozess "nping" überwachen und falls erforderlich, neu starten:

    Code
    pi@raspberrypi:~ $ ps -fC nping > /dev/null 2>&1; echo $?
    0

    https://nmap.org/nping/

    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 (28. Februar 2017 um 20:51)

  • Hallo Andreas,

    ich wollte mir dein vorgeschlagenes Programm hostrepair mal ansehen, aber ich habe festgestellt so einfach ist das (für mich) nicht.

    Zitat

    Den Quellcode kannst Du im Forum herunterladen.


    Wo kann ich das Programm hier im Forum downloaden? :s

    Kannst du mir mal einen Tipp geben, wo sich der Downloadbereich befindet, irgendwie zweifle ich schon an mir selbst!
    Auch Tante Google findet nur eine Firma in USA oder irgend welche Logos zum Thema.

    Gruß Reinhard

  • Hallo Reinhard,

    mal einfach die Suchfunktion dieses Forums aufrufen und

    Code
    hostrepair

    eingeben?

    Bei mir kommt dann jedenfalls eine lange Liste von Threads, in denen Hostrepair erwähnt wurde. Da ich geschrieben habe, dass ich da mal was programmiert habe, ist die Wahrscheinlichkeit recht groß, dass ich auch der Thread-Ersteller bin. Das reduziert die lange Liste auf einen Eintrag. Und der steht auch noch recht weit oben.


    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.

Jetzt mitmachen!

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