[Problem] dyndns fackelt immer wieder ab

[kkkap]

@sf3978
warum ich auf den AVM Klient nicht verzichten möchte. Ganz einfach. Ich bin kein Vollprofi wie ihr es seid. Ich bin ein mittelmäßiger Anfänger. Ich kann meine Freetz selbst kompilieren, dies entpacken und hier meinen eingenen Skript einfügen wieder packen und verwenden. Da ich in der Stable Version kein openDD oder NOIP habe, habe ich keine Auswahl, weil ich nicht weiß wie ich hier OpenDD und NOIP einfügen kann.
Vielleicht kannst du mir das erklären eventuel als E-Mail, wenn dies nicht hierher gehören sollte, dann probiere ich das gerne aus. Aber solange das nicht geht möchte ich das v. Franzl verwenden. Solange ich nicht 2 Dyndns Provider verwende, bräuchte ich das nicht. Aber es macht wirklich Sinn 2 zu verwenden. Und dann ist es sehr wohl sinnvoll auf OpenDD bzw. NOIP einzusteigen. Ich muß zu dem script v. Franzl auch noch sagen, das es sich hier um ein sehr kleines script handelt und sehr schnell abarbeitet. Im vergleich habe ich einen ping auf meine dyndns abgesetzt (in meinem 0815 script) und dort mußt man auf das ping Antwort warten.

 

[hermann72pb]

@franzl und kkkap: Wir freuen uns alle auf eure Erfolge in Skript-Programmierung. Der Punkt ist aber: Dies alles wird mehr oder weniger per AVM, per FREETZ (onlinechanged-cgi, etc.) bereits gelöst. Das, was ihr treibt ist mehr oder weniger das Rad neu erfinden. Und genau dies macht wenig Sinn, weil dafür bereits fertige Lösungen existieren. Ich will damit euer Neugier am Programmieren lieber in die anderen Ecken von FREETZ lenken. Glaubt mir, wir haben sehr viele offenen Baustellen und brauchen auch an einer oder anderen Ecke kreative Ideen. Die Idee, wget zu verwenden oder diverse Pings auszuführen ist allerdings an sich nicht neu und daher nicht kreativ. Somit ist es zwar gut für euch, weil ihr davon persönlich viel lernt, es bringt aber uns alle und FREETZ nicht besonders weiter.

MfG

 

[sf3978]

... Da ich in der Stable Version kein ...

OK, verstehe ich das richtig, dass Du auch bei der stable version bleiben willst?
Du kannst alle 4 verwenden, Script, avm-Client, opendd und noip.

 

[franzl]

@hermann72pb
Nein, keine Neugier am Programmieren bei mir, sonst könnte ich das auch besser. Bin eher etwas das man Pragmatiker nennt. Das Problem musste gelöst werden und das habe ich. Bei der nächsten Firmware, die ich mit den tollen Programmierarbeiten (und das sind Echte) des Freetzteams erstelle, werde ich natürlich eure Anregungen (opendd, onlinechanged u.a.) berücksichtigen. Und dennoch muss es bis dahin zuverlässig funktionieren.

 

[sf3978]

...
Da ich in der Stable Version kein openDD oder NOIP habe, habe ich keine Auswahl, weil ich nicht weiß wie ich hier OpenDD und NOIP einfügen kann.
Vielleicht kannst du mir das erklären ...

Im Anhang ein Patch für noip, angepasst an die Stable Version:

:~/myfreetz/freetz114/[COLOR="red"]freetz-stable-1.1[/COLOR]> [COLOR="darkorchid"]patch -p0 < noip_stable.patch.txt[/COLOR]
patching file make/noip/Config.in
patching file make/noip/files/root/etc/init.d/rc.noip
patching file make/noip/files/root/etc/onlinechanged/start_noip
patching file make/noip/Makefile.in
patching file make/noip/noip.mk
patching file make/noip/patches/100_Makefile.patch
patching file make/noip/patches/110_noip2_c.patch
patching file make/Config.in

Das Verzeichnis für die Konfigurationsdatei "no-ip2.conf", habe ich gemäß der Empfehlung von Oliver, in "/tmp/flash/noip" geändert.
Als HOWTO für das Einfügen von noip in die Stable Version, das Testen, Kompilieren und Konfigurieren von noip, empfehle ich dir diesen Thread (besonders Beitrag #28). Ein Gratis-Account bei NOIP wird benötigt.
Die Konfigurationsdatei für noip wird auf der Box, mit "noip2 -C" erstellt und muss im Verzeichnis "/tmp/flash/noip", persistent gespeichert werden.

root@fritz:/var/mod/root# noip2 -h

USAGE: noip2 [ -C [ -F][ -Y][ -U #min]
        [ -u username][ -p password][ -x progname]]
        [ -c file][ -d][ -D pid][ -i addr][ -S][ -M][ -h]

Version Linux-2.1.9
Options: [COLOR="red"][B]-C               create configuration data[/B][/COLOR]
         -F               force NAT off
         -Y               select all hosts/groups
         -U minutes       set update interval
         -u username      use supplied username
         -p password      use supplied password
         -x executable    use supplied executable
         -c config_file   use alternate data path
         -d               increase debug verbosity
         -D processID     toggle debug flag for PID
         -i IPaddress     use supplied address
         -I interface     use supplied interface
         [COLOR="purple"]-S               show configuration data[/COLOR]
         -M               permit multiple instances
         -K processID     terminate instance PID
         -z               activate shm dump code
         -h               help (this text)

Wenn noip funktioniert, werden wir am kommenden WE, opendd für die Stable Version anpassen und installieren.

 

[hermann72pb]

Ich habe einige Grundsatzfragen zu diesem onlinechanged und zu den derzeit existierenden Clients:
1. So wie ich es verstanden habe, existiert eine Reihe von Clients, die alle erstmal nur für sich arbeiten und keine gemeinsame Ablagestelle für Accountdaten haben (sprich ar7.cfg). Ist es richtig?
2. Alle diese Clients müssen per Kommandozeile konfiguriert und teilweise auch noch bedient werden. Es existieren keine CGIs dazu. Ist diese Behauptng auch richtig?
3. Hinzu kommt noch, dass die Daten meist in den speziellen Config-Dateien abgelegt werden und kaum in FREETZ-cfg, die man per rc-Skripte abfragen kann. Ist dies auch richtig? Dies erschwert natürlich jede CGI-sierung enorm.
4. Kaum ein Client außer AVM ist in der Lage 2.PVC upzudaten. Stimmt diese Behauptung auch?
5. Onlinechanged kann per spezial-Skripte die entsprechenden Clients ansteuern. Voraussetzung: Clients stellen solche Skripte bereit. Sonst muss man händisch die benutzerdefinierte onlinechanged-Datei bedienen. Ist diese Behauptung ebenfalls richtig?

MfG

 

[sf3978]

1. So wie ich es verstanden habe, existiert eine Reihe von Clients, die alle erstmal nur für sich arbeiten und keine gemeinsame Ablagestelle für Accountdaten haben (sprich ar7.cfg). Ist es richtig?

Ja, richtig

2. Alle diese Clients müssen per Kommandozeile konfiguriert und teilweise auch noch bedient werden. Es existieren keine CGIs dazu. Ist diese Behauptng auch richtig?

Teilweise richtig. Bedienung ist nicht erforderlich. CGI gibt es für opendd.

3. Hinzu kommt noch, dass die Daten meist in den speziellen Config-Dateien abgelegt werden und kaum in FREETZ-cfg, die man per rc-Skripte abfragen kann. Ist dies auch richtig? Dies erschwert natürlich jede CGI-sierung enorm.

Ja und nein.;-)

4. Kaum ein Client außer AVM ist in der Lage 2.PVC upzudaten. Stimmt diese Behauptung auch?

Ja, wird so stimmen.

5. Onlinechanged kann per spezial-Skripte die entsprechenden Clients ansteuern. Voraussetzung: Clients stellen solche Skripte bereit. Sonst muss man händisch die benutzerdefinierte onlinechanged-Datei bedienen. Ist diese Behauptung ebenfalls richtig?

Für die Clients habe ich diese Scripte erstellt.

 

[hermann72pb]

Zu Frage 3: "Ja", wenn man es vernünftig macht. Und "Nein", wenn man die komplette Config als Eingabemaske darstellt und dem Benutzer die freie Wahl stellt: "mach mal". Ist zwar auch eine Lösung, die auch mächtig ist, aus Sicht von FREETZ aber nicht die schönste.
Zu Frage 4: Aber irgendwie machen die AVMs das doch? Wie gesagt, nach meiner Beobachtung wird die selbe Statusdatei dafür bedient. Daten kommen auch aus der selben ar7.cfg. Es wäre logisch, dass onlinechanged da auch bedient wird. Ich würde gerne in der Hinsicht meine Nachforschung treiben, wenn es vom allgemeinen Interesse wäre. Denn ich habe zwei Accounts die über AVM upgedatet werden und einer davon ist für die 2.PVC. Was muss ich in onlinechanged-Skripte eintragen, um dies etwas zu loggen und zu beobachten, ob onlinechanged auch beim Update vom zweiten PVC bedient wird?
Als Nächstes würde ich echt die Möglichkeit checken, wenigstens die Zugangsdaten in ar7.cfg zentral abzuspeichern. Und selbst, wenn jeder der Klients dafür einen Extra-Schalter bekommen soll.

MfG

 

[RalfFriedl]

Das wesentliche Problem beim Update der 2. IP-Adresse ist, die 2. Adresse bzw. eine Änderung dieser Adresse mit zu bekommen. Warum sollte AVM damit Probleme haben, wenn sie Zugriff auf das Programm haben, das die 2. Verbindung aufbaut?

Welchen Vorteil hat es, alle Daten in der ar7.cfg abzulegen? Es wird ja wohl niemand mehrere Clients für den selben Account verwenden, da man dann im Normalfall mehrere Updates für den gleichen Account mit der gleichen Adresse hätte.

 

[hermann72pb]

Zunächst mal vermelde ich auch, dass alle gestrigen Beiträge von cuma irgendwie weg sind. Und zwar nicht nur hier, sondern in mehreren Threads:

onlinechanged führt Skripte aus wenn der Onlinestatus such ändert, der Parameter ist dann "online" oder "offline". Da kannst du eintragen was dir in den Sinn kommt

cuma hat um eine gefährliche Zeit herum seine Postings verfasst, nämlich so um 01:30. Ich hatte früher auch damit Probleme gehabt, dass meine Beiträge nachher weg waren. Anscheinend wird die Forum-Datenbank zu dieser Zeit upgedatet.
@cuma: Ich habs verstanden, ich werde es mal probieren.
@Ralf: Ich sage nicht, dass AVM damit Probleme haben. Ganz im Gegenteil: Dort klappt es mit dem AVM-Klient bei mir. Mir war allerdings nicht klar, ob AVM es im Fale von 2.PVC auch über "onlinechanged" machen und ob wir davon was in FREETZ mitkriegen. Es scheint aber keiner hier zuverlässig zu wissen. Ergo: Ich baue es einfach dorthin, wo cuma empfehlt, schaue es mir an und melde mich dazu.
Zur zentralen Ablagestelle in ar7.cfg. Meine Idee zielte schon dorthin, dass man sich für nur einen Klienten entscheidet und die ar7.cfg einfach als zentrale Ablage nutzt. Dann wird es leichter sein, den anderen Klienten mal ausprobieren. Aber wahrscheinlich hast du Recht und es wird schwierig sein, den AVM-Klienten an der Stelle "tot zu legen", damit er sich nicht aus den Daten "bespeist". Diese zentrale Ablagestelle hatte ich aber eher als eine zusätzliche Option gedacht. Ein der möglicher Ziele wäre hier auch, den AVM-Klienten mit einem alternativen zu ersetzen.


EDIT: onlinechanged bezieht sich auf jeden Fall nur auf die 1.PVC. Von der Änderung der 2.PVC kriegt man darüber leider nichts mit. Ich hatte gehofft, dass "/bin/dhcpcipchanged" vielleicht als "Ersatz" für die onlinechanged in Sachen 2.PVC und voipd steht. Dem ist es aber leider nicht so. Hat jemand weitere Ideen, wo ich solche onlinechanged-ähnliche Vorgänge für 2.PVC "abzapfen" kann?

Desweiteren wird es notwendig sein unsere get_ip etwas zu erweitern. Ich würde für den Parameter -d noch zusätzliche Option vorschlagen:

get_ip -d 1

Dies sollte heißen, dass -d nicht nur für Device 0 (1.PVC) ausgewführt wird, wie jetzt, sondern auch für weitere Devices (z.B. für 2.PVC). Denn im Unterschied zum "normalen" reconnect, muss man bei der 2.PVC die IP-Adresse explizit übertragen, weil sie ja nicht der Adresse gleicht, von der man sein Update durchführt.
Der AVM-Klient meistert dies alles ziemlich gut. Für andere ddns-Klients bräuchte man aber erstmal die IP vom 2.PVC.

Wenn dies und onlinechanged für 2.PVC als derzeitige Probleme gelöst sind, dann würde nichts dazu im Wege stehen, die 2.PVC mit anderen Klients upzudaten.

Und wenn wir dies können, dann sind wir erstmal mit unseren Klients nicht schlechter als AVM. Das wäre eine entscheidende Voraussetzung dafür, dass man AVM-Klient komplett mit einem alternativen Klient ersetzt.


MfG

 

[sf3978]

... Es wird ja wohl niemand mehrere Clients für den selben Account verwenden, da man dann im Normalfall mehrere Updates für den gleichen Account mit der gleichen Adresse hätte.

Doch, ich habe ein Account bei noip mit 5 Hostnamen. Davon werden 4 Hostnamen von opendd updatet und 1 Hostname vom noip-Client. Motiv: Redundanz.

 

[RalfFriedl]

Dann sind das aber trotz gleichem Account verschiedene Namen innerhalb eines Accounts. Auch in diesem Fall würde es nichts bringen, die Daten zentral zu hinterlegen.

Insbesondere kann man nicht die Daten in der AVM Konfiguration unterbringen und dem AVM-Client beibringen, dass er diese Daten nicht nutzen soll.

 

[hermann72pb]

Hallo Ralf,

wo du dich gerade hier meldest, habe ich eine spezielle Frage an dich, als Experte: Was kann man tun, um die doppelten Schreibzugriffe vom AVM-Klient an die Datei /var/tmp/ddnsstat.txt "abzufangen"? Besser wäre natürlich den Klienten zu patchen, dafür haben wir aber keine Quellen. Ich weiß nicht mal, in welcher Binary der Klient von AVM sitzt und wodurch er "angestoßen" wird. Sonst könnte man evtl. noch diese Anstöße "abfangen".
Meine Vermutung zu den Problemen vom AVM-Klient: Er versucht gleichzeitig mehrere Accounts upzudaten. Wenn die Antworten ziemlich gleich ankommen, führt es zu Problemen, die Status-Datei gleichzeitig zu beschreiben. Hätten wir dort vielleicht gewisse Wartezeiten einführen können, hätten wir das Problem vermutlich entschärft. Es wäre natürlich keine saubere Lösung, dennoch wären wir zumindest etwas weiter.
Zum zentralen Speicherort war nur eine Idee. Du hast mich überzeugt: Ich arbeite erstmal nicht in der Richtung.

MfG

 

[RalfFriedl]

Hallo Hermann

Sowohl bei der 7270 Version .88 als auch 7390 Version .90 kommt diese Ergebnis.

$ fgrep -r ddnsstat * 2> /dev/null
Übereinstimmungen in Binärdatei lib/libboxlib.so.0.
Übereinstimmungen in Binärdatei lib/libboxlib.so.
Übereinstimmungen in Binärdatei lib/libboxlib.so.0.0.0.
Übereinstimmungen in Binärdatei sbin/multid.
Übereinstimmungen in Binärdatei usr/bin/ctlmgr.

Wenn es daran liegt, wäre es as Beste und Einfachste, wenn AVM das in Ordnung bringt. Ansonsten könnte man die genannten Binaries anschauen und versuchen, über eine Preload-Library die entsprechenden Funktionen abzufangen.

Was genau ist das Problem, das mit dem AVM-Klient auftritt, und was bringt Dich zu der Vermutung, dass es am gleichzeitigen Zugriff auf diese Datei liegt? Ich verwende kein DynDNS und habe das nicht so genau verfolgt.

 

[olistudent]

Vielleicht der gleiche Grund wie hier? Im Besonderen #30 dürfte interessant sein.

Gruß
Oliver

 

[RalfFriedl]

Dort wird aber onlinechanged erst gar nicht aufgerufen. Ich sehe da keinen Zusammenhang zum gleichzeitigen Schreiben auf die Datei, was nur dann passieren sollte, wenn mehrere Accounts tatsächlich aktualisiert werden.
Wofür wird überhaupt diese ddnsstat Datei verwendet? Steht dort nur der Status, damit man ihn manuell auslesen kann, oder wird der Inhalt auch im normalen Betrieb von einer AVM-Komponente genutzt?

 

[olistudent]

Wir wissen ja nicht wie und wann der multid den dyndns-Account aktualisiert. Es könnte doch sein, dass der onlinechanged Aufruf in der gleichen Funktion wie der dyndns update trigger ist. Und daher beide nicht ausgeführt werden...

 

[RalfFriedl]

Es ist sogar sehr wahrscheinlich, dass sowohl onlincechanged als auch ddns Update auf die gleiche Funktion zurückgehen.
Ich sehe nur nicht den Zusammenhang zum gleichzeitigen Überschrieben der Status Datei von zwei verschiedenen Update-Instanzen. Selbst wenn das der Auslöser für ein Problem ist, hat das vermutlich einen anderen Grund als wenn onlinechanged und ddns Update gar nicht aufgerufen werden.

 

[hermann72pb]

@Ralf: Gründe für meine Vermutung hatte ich schon oben dargestellt:
a) Alle Ergebnisse vom Update-Status stehen in EINER Datei drin.
b) Bei mir gibt es auch zwei Accounts unter dem AVM-Klient konfiguriert und ich hatte noch nie Probleme damit beobachtet. Bei mir sind es allerdings 1.PVC und 2.PVC und sie werden nachweislich mit einem Versatz von mehreren Sekunden upgedatet.
c) Ich greife ab und zu auf mehrere Boxen, die irgendwo im Feld verteilt sind. Die meisten davon nutzen dyndns, allerdings nur mit einem Account. Ich hatte noch nie solche gravierenden Probleme gesehen, von denen hier berichtet wurde.

Also, kann man darauf schließen, dass es Probleme nur dann auftreten, wenn mehrere Accounts gleichzeitig (in der gleichen PVC) aktualisiert werden. Dann ist es wahrscheinlich, dass ziemlich gleichzeitig versucht wird, die Accounts upzudaten. Diese Funktionalität (mehrere Accounts, Multi-PVC) ist von AVM weder offiziell freigegeben, noch irgendwo dokumentiert. Meine Vermutung ist: Es wurde irgendwann mal seitens AVM in der Richtung was unternommen, allerdings noch nicht zu Ende geführt. Aus diesem Grund können wir dies zwar, es klappt aber nicht immer.
Die Status-Datei wird meiner Meinung nach für mehrere Zwecke benutzt. Zum einen steht dort in Form einer Zahl, ob das letzte Update erfolgreich war oder nicht. Zum anderen scheint dort an der ersten Stelle sowas wie Zeitstempel zu stehen. Die Datei könnte z.B. vom AVM-WebIF dafür genutzt werden, um anzuzeigen "DDNS Update erfogreich am XXX um YYY". Also, das ist schon mal eine Anwendung. Darüberhinaus kann man in den Tiefen von ar7.cfg für jeden DDNS-Account eine Delay-Zeit programmieren. Bei DynDNS steht sie meiner Beobachtung nach bei 4 oder 5 Minuten. D.h. DDNS-Klient würde die Datei zuerst auslesen und checken, wann letztes Update durchgeführt wurde. Dann wird ggf. gewartet.
Wenn die AVMs (oder wer auch immer) etwas schlampig programmiert haben, würden sie nach dem Auslösen vom Update die Status-Datei zum Schreiben eröffnen. Danach wird die Antwort abgewartet, Ergebnisse in die Datei geschrieben und die Datei geschlossen. Im Falle von mehreren Accounts wäre es wenigstens theoretisch denkbar, dass AVM dieses wartende Prozess (Unterprozess) irgendwie in Hintergrund schicken, um den Durchlauf der Hauptschleife zu beschleunigen. In diesem Falle kann es durchaus passieren, dass für den nächsten Eintrag in ar7.cfg bei der gleichen PVC zum zweiten Mal das gleiche versucht wird duchzuführen. In diesem Falle wäre aber die Statusdatei schon vom anderen Prozess schreibend eröffnet und somit gesperrt. Eine vernünftige Reaktion darauf wäre eine endliche Warteschleife einzuführen. Aber wer programmiert schon vernünftig. Entweder checken sie gar nicht den Status oder lassen ihre Schleife weiter laufen.

Wenn meine Vermutung richtig ist, dann wäre die Position vom Account in ar7.cfg von Bedeutung. Denn die Aussage war doch, dass einige von mehreren Accounts nicht upgedatet werden.

Ich weiß Ralf, meine Anmutungen sind ziemlich an den Haaren vorbeigezogen. Möglich wären sie aber.

Und ich denke allerdings auch, dass das hier beschriebene Problem mit dem anderen erstmal nicht zu tun hat, Oliver.

MfG

 

[RalfFriedl]

Das Sperren einer Datei müsste explizit veranlasst werden. Wenn man das nicht tut, wird die Datei nicht gesperrt.
Natürlich kann es trotzdem sein, dass die Datei gesperrt wird und der Fall nicht richtig gehandhabt wird.