Netzwerkgerät(e) überwachen und Server wecken

Moins

Unter Umständen gehts auch komplett ohne freetz.
...ist aber hilfreich um z.B. die /var/flash/debug.cfg wieder zum Laufen zu kriegen.

So oder so, dann kommts auch noch auf deine Box an, die kenn ich nicht.
...würde der letzte Satz meiner Signatur dir die Welt der Homeautomation öffnen.

Wenn du gewillt bist für Pseudoskripte etwas PHP zu Lernen.

Simples Beispiel
Mein Smartfon loggt sich im WLAN ein und 2 IP-Tischtelefone schalten auf DND*.
...hehe, so ungefähr das Gegenteil was du machen möchtest.
Wenn sich das Smartfon ausloggt, gehen auch Beide wieder auf Empfangsbereitschafft.

Dafür braucht es in SensorAndSwitch:

1. Ein Pseudoskript als Sensor für das Smartfon
2. Zwei Pseudoskripte als Schalter für die IP-Telefone
3. Vier einzelne Kettenstartglieder**, die auf ein/ausloggen des Smartfons schalten.

* DoNotDisturb
** Oder zwei Kettenstartglieder und zwei Kettenfolgeglieder, jeweils zum Erfassen und Schalten eines IP-Telefons.

Unabhängig davon finde ich das Skript etwas "komisch" ... das hat in den möglichen Permutationen mit den 3 überwachten Geräten ja vollkommen unterschiedliche Reaktionen/Verzögerungen.

Server => A
TV => B
mede4er (was auch immer das sein mag) => C

1. Fall:
A, B, C alle aus

Dann wird ein Ping an A abgesetzt, das nach 10 Sekunden Timeout liefert. Anschließend wird B per Ping getestet, hier erfolgt ebenfalls nach 10 Sekunden ein Timeout ... dasselbe noch einmal für C. Wird jetzt unmittelbar nach dem Timeout für B das TV-Gerät eingeschaltet, dauert es 10 Sekunden für C + 10 Sekunden für A, bis der nächste Test für B überhaupt ausgeführt wird.
EDIT: Quatsch, es ist sogar noch "schlimmer" ... das Ping setzt ein einzelnes Paket ab. Wenn jetzt unmittelbar nach diesem Paket B doch noch eingeschaltet wird (bzw. das Netzwerk von B "bereit" ist), dann kommt auch noch die gesamte Timeout-Spanne für B dazu, das sind dann 30 Sekunden - denn daß da vorher mal ein Echo-Request war, weiß B ja nicht und daher bleibt die Antwort auch dann aus, wenn B in den 10 Sekunden für das Timeout nachträglich verfügbar wird.

2. Fall:
A ein, B+C wieder aus (keine Ahnung, wie und wie schnell nach dem Ausschalten der anderen Geräte der Server auch wieder runterfährt oder ob das extern ausgelöst wird, aber das kriegt das Skript ja auch frühestens nach knapp 16 Minuten mit, selbst wenn der Server schon 5 Minuten nach dem letzten erfolgreichen Ping wieder "weg" ist)

Das Ping für A ist erfolgreich, damit geht das Skript für 950 Sekunden "schlafen". Schaltet man jetzt innerhalb dieser Zeit B und/oder C wieder ein und A ist trotzdem inzwischen nicht mehr verfügbar (weil aus), dauert es wiederum den Rest der 950 Sekunden + die Timeouts aus 1. (je nachdem, welches Gerät jetzt eingeschaltet wurde), bis der Server wieder hochgefahren wird.

Diese Fälle lassen sich jetzt fortführen, das geht soweit, daß bei eingeschaltetem A, B und C alle 955 Sekunden zwei "magic packets" hintereinander beim Server eintreffen, obwohl der eigentlich schon läuft. Das mag nicht mal unbedingt schaden, aber die Kombination dieser verschiedenen Zeiten und möglichen Verzögerungen durch das Ergebnis von "ping" (< 1 Sekunde bei Erfolg, 10 Sekunden bei Mißerfolg) ergibt - zumindest in meinen Augen - ja nun absolut kein vorhersagbares Verhalten des gesamten Systems. Das läßt sich wesentlich besser (vorhersagbarer und - je nach akzeptabler Netzwerk-/Routerbelastung - mit kürzerer Reaktionszeit) lösen.

Dazu startet man für jedes Gerät eine Subshell (die kann dann sogar mit unterschiedlichen Prüfintervallen pro Gerät umgehen, wenn man unbedingt den Zustand per Polling abfragen muß/will), in der der Status des überwachten Gerätes verwaltet wird. Ändert der sich, wird das "verbindende Element" in Gestalt des "Eltern-Skripts" über diesen Umstand informiert und kann dann aus den aktuellen Zuständen aller Clients den gewünschten Zustand des Gesamtsystems herleiten und die Kommandos absetzen, um diesen herzustellen. Dabei ist man bei den Subshells auch nicht unbedingt auf ein Ping angewiesen, wenn man will, überwacht man einfach die DHCP-Requests eines neu eingeschalteten Gerätes (wenn das sein Netzwerk mit DHCP initialisiert) und kann dann von Polling mit "ping" auf Trigger-Steuerung umstellen.

Ich sehe jedenfalls nicht, warum ein Einsatz von Freetz bei so einem Anliegen irgendwelche Verbesserungen bringen sollte, solange die FRITZ!Box beim Start eigene Skripte ausführen kann. Daß man das gezeigte Skript (wie jedes andere länger laufende auch) nicht synchron im Rahmen der Ausführung einer "debug.cfg" verwenden sollte, versteht sich von selbst ...

Woolfgar schrieb:

das echte Problem ist das sich die Box (7320) irgendwie "verrödelt" ich komme zwar auf die Box rauf aber dann ist Schluß keine Verbidnung zum restlichen Netz und das in unregelmäßigen Abständen.

Zum Vergrößern anklicken....

Das haben wir (denke ich) ja verstanden.

Solange Du das aber nicht mit Protokollen unterfütterst, können wir über die Ursache ja auch nur spekulieren. Als "restliches Netz" hast Du in #1 noch die WAN-Seite der 7320 angegeben (das klingt in #4 nicht mehr so deutlich, aber man sollte ja auch bei #1 anfangen mit dem Lesen), aber auch da wird ja irgendetwas (oder auch nichts, selbst das ist eine relevante Information) im AVM-Eventlog stehen bzw. in diesem Falle sind sogar die Support-Daten keine so schlechte Idee, da dort die möglichen Diagnosekommandos zusammen ausgeführt werden, z.B. showdslsstat für die Anzeige, was der für die Bedienung der WAN-Seite der Box zuständige Daemon von der aktuellen Situation hält.

Ich bin mir auch nicht so richtig darüber im Klaren, ob die 7320 "hinter der Kabelbox" nun als IP-Client im Netz der ersten arbeitet und wie überhaupt die Verbindung zwischen diesen Boxen hergestellt wird. Falls die 7320 für die WAN-Anbindung (oder eben die komplette Netzanbindung, wenn sie IP-Client ist) auch eine WLAN-Verbindung akzeptiert (das schaue ich jetzt nicht selbst nach, auch wenn man es unabhängig von Deiner Frage ermitteln könnte), wäre da ja auch ein Betrieb ohne LAN-Kabel zwischen den Boxen denkbar - im Extremfall sogar die Konfiguration der 7320 als WLAN-Repeater für die erste Box, wenn diese Konfiguration von beiden unterstützt wird.

Das nur mal zur Klarstellung, warum vermutlich bisher niemand so richtig eine Vorstellung/Idee entwickeln kann, was bei Dir am Ende klemmen könnte und aus Deiner Fragestellung

Woolfgar schrieb:

]Deshalb möchte ich auf freetz umsteigen in der Hoffnung das es damit besser wird.
Wie kann ich das mit Freetz realisieren.
Am wichtigsten ist mir tatsächlich diese Netzwerküberwachung

Zum Vergrößern anklicken....

kann man auch nicht die Intention ablesen, das eigentliche Problem zu suchen. Die geht in die Richtung, ob das dargestellte Skript mit Freetz besser laufen würde und genau das habe ich versucht zu beantworten, wenn ich schreibe

PeterPawn schrieb:

Ich sehe jedenfalls nicht, warum ein Einsatz von Freetz bei so einem Anliegen irgendwelche Verbesserungen bringen sollte, solange die FRITZ!Box beim Start eigene Skripte ausführen kann. Daß man das gezeigte Skript (wie jedes andere länger laufende auch) nicht synchron im Rahmen der Ausführung einer "debug.cfg" verwenden sollte, versteht sich von selbst ...

Zum Vergrößern anklicken....

Da "versteckt" sich erstens meine Meinung, daß es keinen Unterschied machen sollte, ob Du dieses Skript nun unter Freetz oder unter normaler AVM-Firmware laufen läßt (die Schwächen der Lösung sind unter beiden Systemen identisch) und - wenn man richtig liest - zumindest noch der Hinweis, daß Du vielleicht mal die Art und Weise, wie Du dieses Skript startest, überprüfen solltest (die "hohe Schule" wäre es dann, uns diese Information auch noch zu geben).

Über solche Kleinigkeiten wie die von der 7320 verwendete Firmware und Typ/Firmware-Version der "Kabelbox" brauchen wir nicht zu reden, denn Deine Frage zielte ja nicht in Richtung der Fehlersuche für die 7320 ... ansonsten gehört das natürlich automatisch (zusammen mit den o.a. Informationen zur "Verbindung" der beiden) zu einer "ordentlichen" Problembeschreibung dazu. Bisher wissen wir von dem gesamten Problem nur, daß eine 7320 daran beteiligt ist ... das ist ein wenig schmal, wenn die Frage eher in Richtung der Beseitigung dieses Problems zielen sollte.

Vorschlag zur Umkonfiguration (ob das Dein Zuverlässigkeitsproblem löst, weiß ich nicht - es ist ja unklar, was da nach einiger Zeit ausfällt):

Anhang anzeigen 82335

Die Einstellungen "Kabelanschluß" und "externer Router" unterscheiden sich nur in Kleinigkeiten - wenn Du genau wissen willst, was da jeweils anders ist (auch im Vergleich zu "Vorhandener Zugang über LAN", wofür ich gerade keinen Screenshot an der Hand habe und daher nicht weiß, was da noch einstellbar ist), dann probiere diese Einstellungen durch und exportiere die Einstellungen. Wenn man dann diese Dateien vergleicht (alle Werte, die mit $$$$ beginnen, sind - ohne daß das hier relevant wäre - immer unterschiedlich), sieht man auch, welche Einstellungen sich hinter den Punkten im GUI jeweils verbergen.

Meine (versteckte) Frage, wie Du das Skript startest, hast Du überlesen? Wenn das direkt in der "debug.cfg" (die ist bei der 06.03 ja noch aktiviert) ausgeführt wird, kommt die Initialisierung des Systems nie bis zum Ende ... daher startet man so etwas asynchron, wofür es mehrere Wege gibt, deren "Gangbarkeit" sich aber auch im Laufe der Zeit änderte. Das ist also nicht nur reine Neugierde, das ist eine Idee, warum das nach einiger Zeit Probleme machen könnte.

Das mit der "debug.cfg" war ja eigentlich schon klar ... die Frage ist tatsächlich, wie das gestartet wird und nicht wo.

Der fundamentale Unterschied zwischen DSL-Betrieb (mit internem Modem) und dem jetztigen Zustand ist es, daß der dsld (der ist für die externe Anbindung zuständig, wie ich Dir bereits schrieb) dabei vollkommen anders arbeiten muß (es gibt z.B. keine "Zwangstrennung" mehr, das ist aber mehr ein "sichtbarer" Unterschied, unter der Haube ist da noch viel mehr anders, z.B. DHCP vs. LCP) und deshalb ist der "Vergleich" dieser beiden Betriebsarten zwar möglich, aber der Schluß "bisher ging es ja auch immer" nicht wirklich zwingend ... besonders dann, wenn wie in Deinem Falle ja die externe Verbindung Probleme bereitet.

Der Beitrag #7 bestand auch aus zwei Teilen ... erstens einem Vorschlag für eine Konfigurationsänderung, bei dem ich zwar nicht weiß, ob er das Problem löst (ich weiß noch nicht einmal sicher, was denn nun das Anliegen ist ... das Problem mit der wegbrechenden WAN-Verbindung in den Griff zu bekommen oder das Shell-Skript ausführen zu wollen), das macht den aber nicht überflüssig, da es keine wirkliche Investition von Zeit erfordert, den umzusetzen und dann zu sehen, was passiert. Nur der zweite Teil bezog sich auf das Skript und vielleicht solltest Du das entweder gleich in zwei Probleme aufteilen oder tatsächlich erst einmal klären, ob der Verlust der WAN-Konnektivität nicht auch auftritt, wenn Dein Skript gar nicht läuft. Unter Umständen wirfst Du hier zwei vollkommen getrennte Fragen in einen Topf.

Meine Bemerkungen zum asynchronen Start bleiben trotzdem gültig ... "haben wir schon immer so gemacht und hat bisher immer funktioniert" heißt auch noch nicht, daß das schon immer richtig war, wie es gemacht wurde - wenn man Probleme hat, sollte man auch hinterfragen, ob das, was bisher "nur funktionierte", nicht vielleicht doch wegen geänderter Randbedingungen eine Ursache dieser Probleme sein könnte.