[Problem] dyndns fackelt immer wieder ab

[RalfFriedl]

In Freetz gibt es schon fast 50 fertige DynDNS Clients

 

[franzl]

In Freetz gibt es schon Lösungen für update und e-Mail ohne Cron-Job, d. h. mit Hilfe des onlinechanged-Ereignisses.

Alles richtig, ich nutze trotzdem bewußt nicht das Ereignis "onlinechanged", weil es den unterschiedlichen möglichen Problemen nicht ausreichend Rechnung trägt.
Gerade in letzter Zeit passierte es ab und an, das der beliebte dyndns.org-Service generell für Stunden nicht funktionierte. Da nützt es mir gar nichts, wenn ich nach "onlinechanged" 3 x prüfe, 3x neustarte und dann doch keine DNS-Eintrag für den ganzen Tag zur Verfügung habe. Hier braucht es schon etwas mehr Logik. Im Übrigen gebe ich zu, dass ich die Sache für mich der Bequemlichkeit halber mit monit löse. Geht aber genauso mit einem kleinen Shellscript und Cron. Ich überprüfe also alle Accounts separat und registriere nur diejenigen, welche nicht funktionieren neu und erkenne vor allen Dingen auch automatisch, ob es sich z.B. um den Ausfall eines ganzen DynDns-Dienstleisters handelt und es sich deshalb lohnt in einem nun größeren Zeitabstand, neue Registrierungsversuche zu unternehmen.

 

[hermann72pb]

@franzl: Dann poste doch deine Lösung, oder noch besser mach daraus ein FREETZ-Paket. Dann wirst nicht nur du persönlich was davon haben, sondern die ganze Community.

Ich persönlich würde es nicht per cron realisieren, sondern es doch vom "onlinechanged" oder von was auch immer abhängig machen, wo man eine zuverlässige Information darüber hat, ob es erfolgreich oder erfolglos aktualisiert wurde. Im erfolglosen Fall startet man dann lieber anstatt cron einen sleep für z.B. eine Stunde und macht seine weiteren Versuche erst dann. Die E-Mail mit der IP kann man aber trotzdem vor der ersten Wartephase absetzen.

Außerdem ist doch der Klient von AVM sowas von hartnäckig, sodass ich gar nicht verstehe, warum er sich in der von dir beschriebenen Situation nicht "durchboxt"? Wenn dyndns.org für 2-3 Stunden nicht da ist, wird AVM-Klient doch solange "kämpfen", bis eine erfolgreiche Rückmeldung da ist. Das hatte ich schon mal in den AVM-Logs öfter beobachtet. Zugegeben, ich nutze seit 4-5 Monaten keinen dyndns.org mehr, weil ich mir meinen eigenen DDNS-Server auf meinem Strato-Root-Server zurecht gebastelt hatte. Ich habe aber noch nie einen anderen Klient, als den von AVM genutzt, weil ich es nicht nötig hatte.

Kann es sein, dass eure Probleme damit zusammen hängen, dass ihr vom AVM-Klient weg wollt bzw. der AVM-Klient vom Thread-Ersteller aus unerklärlicher Gründen ins Stocken gerät?

MfG

 

[sf3978]

Alles richtig, ich nutze trotzdem bewußt nicht das Ereignis "onlinechanged", weil es den unterschiedlichen möglichen Problemen nicht ausreichend Rechnung trägt.
Gerade in letzter Zeit passierte es ab und an, das der beliebte dyndns.org-Service generell für Stunden nicht funktionierte. Da nützt es mir gar nichts, wenn ich nach "onlinechanged" 3 x prüfe, 3x neustarte und dann doch keine DNS-Eintrag für den ganzen Tag zur Verfügung habe. Hier braucht es schon etwas mehr Logik. Im Übrigen gebe ich zu, dass ich die Sache für mich der Bequemlichkeit halber mit monit löse.
...

OK, aber nicht jeder hat diese Probleme mit dem dyndns-Provider. Und wenn es auch so wäre, dass es sporadisch Probleme mit einem dyndns-Provider gibt, kann man mit den Clients aus Freetz (und dem onlinechanged-Ereignis) für Redundanz sorgen. D. h. nicht nur 1 dyndns-Provider, sondern 2 oder 3 und nicht nur 1 Client, sondern 2.

 

[franzl]

Berechtigte Anmerkungen, klar kann man den ganzen Vorgang auch mit "onlinechanged" anstossen und Wartephasen durch sleep einfügen.

Außerdem ist doch der Klient von AVM sowas von hartnäckig, sodass ich gar nicht verstehe, warum er sich in der von dir beschriebenen Situation nicht "durchboxt"? Wenn dyndns.org für 2-3 Stunden nicht da ist, wird AVM-Klient doch solange "kämpfen", bis eine erfolgreiche Rückmeldung da ist.

Das kann ich allerdings überhaupt nicht bestätigen. Mein AVM-Klient "kämpft" genau null und zeigt auch weiter Fehler, wenn an ihm vorbei die Adressen bereits wieder korrekt registriert sind. Habe warscheinlich ein sehr faules AVM-Klient-Exemplar erwischt ;-). Ein fleißiger welcher kann hierbei aber auch das Gegenteil von Erfolg haben - siehe hier.

 

[hermann72pb]

@franzl: In diesem Artikel ist genau das beschrieben, was ich behaupte und was ich da oben angedeutet hatte: AVM-Klient boxt sich durch. Das Verhalten aus dem Artikel bezieht sich konkret auf den Zeitraum Ende Januar. Aktuell steht in dem Artikel sogar, dass der Fehler längst erkannt und behoben ist. Da ich meinen eigenen DDNS-Server betreibe, weiß ich auch in etwa, wovon da die Rede ist. Solche fatalen Ereignisse passieren bei DynDNS ziemlich selten, obwohl auch diese Seltenheiten euch als "Kunden" sicherlich stören. Du versuchst jedoch aus diesem konkreten Beispiel heraus eine pauschalisierte Aussage zu ziehen. Und das ist definitiv falsch. Würde DynDNS generell und immer nicht funktionieren, würden wir hier nur darüber reden. Du gehörst allerdings zu einer seltenen Gruppe derjenigen, die Probleme damit haben. Als Folge kann man eine These aufstellen, dass dieses Problem eher hausgemacht ist und seine Würzel irgendwo bei dir zu suchen sind. Denn im Normallfall reichen drei Versuche, um zuverlässig eine DynDNS-Adresse zu updaten. Du beschreibst jedoch am Anfang sogar eine umgekehrte Problematik: Die Adresse wird gar nicht aktualisiert. Und da glaube ich es einfach nicht daran.

MfG

 

[franzl]

Der von mir angeführte Problemfall bei DynDNS ist leider kein Einzelfall.
Unabhängig davon ist, wenn ich 5 Adressen vom AVM-Client registrieren lasse ca. jeden 2. Tag mindestens 1 davon nicht registriert. Wir können darüber noch lange sinieren. Fakt ist, mit einem simplen Script in der Shell z.B.

#! /bin/sh

PATH=/bin:/sbin:/usr/bin:/usr/sbin
LOGIN=$1
PASS=$2
DOMAIN=$3
BOXIP=`get_ip`
DNSIP=`nslookup ${DOMAIN} | egrep [^\.]127 -v | egrep [^\.]192 -v | egrep -o -e [0-9]+\.[0-9]+\.[0-9]+\.[0-9]+`

if [ "${DNSIP}" != "${BOXIP}" ] ;
then
    wget -q http://${LOGIN}:${PASS}@members.dyndns.org/nic/update?hostname=${DOMAIN} -O /dev/null > /dev/null
fi

exit

aufgerufen durch z.B. cron ala

/var/tmp/verify_dns.sh LOGIN PASSWORD DOMAIN

Löst das Problem nachhaltig.

 

[sf3978]

... Fakt ist, mit einem simplen Script in der Shell z.B.
...
Löst das Problem nachhaltig.

Wenn sich dein Script nicht "durchboxt" und z. B., 20x täglich aufgerufen werden kann ( ... mit/an einem Internetzugang, dessen externe IP-Adresse sich NIE ändert, wenn die FritzBox nur rebootet/neustartet!!), ohne, dass dein dyndns-Provider dir den DynDNS-Account sperrt, dann ist es OK.

 

[hermann72pb]

/dev/null hat übrigens ein Doppel-L am Ende.
Und ich sag immer noch: Das ist keine Lösung, das ist ein Workarround. Und wenn du der Einzige bis jetzt bist, der daran so stark leidet, dann scheint irgendwas bei dir anders zu sein, als bei 99% der restlichen Boxen. Sonst wäre das Geschreie hier in IPPF deutlich lauter.

Hast du denn mit anderen DDNS-Klients ausprobiert, wie es dir oben empfohlen wurde? Ich glaube zwar nicht daran, dass AVM-Klient schuld ist, dennoch wäre es wenigstens ein weterer Versuch das Problem einzugrenzen. Hast du denn genau Logs analysiert an den Tagen, wo es mit dem Update schief lief? Hat der Klient überhaupt versucht sich zu verbinden? Hast du beobachtet, wie lange so ein reconnect dauert? Man kann doch bestimmt mit onlinechanged-cgi da Einiges Richtung logging zu Recht basteln, um zu sehen, was da genau vor sich geht. Bist du dir sicher, dass auch onlinechanged gar nicht aufgerufen wird?

Wie gesagt, deutlich schöner wäre es dein Problem an den Würzeln zu packen. Wenn du es allerdings nicht willst, dann kannst du mit deinem Workarround leben, solange es bei dir funktioniert. Da es nur dein lokales Problem ist, sehe ich da keine Gefahren für die Allgemeinheit.

MfG

 

[SaschaBr]

... Sonst wäre das Geschreie hier in IPPF deutlich lauter. ...

Ich schreie zwar nicht, jedoch habe ich auch zeitweise Probleme mit der Dyndns-Aktualisierung (siehe hier). Bei mir ist es jedoch "onlinechanged", welches sich gelegentlich selber "ausknockt": Geschieht die "vorgezogene Zwangstrennung" durch die Box zu schnell, wird "onlinechanged online" laut syslog "rejected" (da "onlinechanged offline" noch läuft). Momentan habe ich als Würgaround "onlinechanged online" ins crontab eingetragen, um das rejected "online" nachzuholen.

Eventuell liegt das Problem hier ja auch an einem fehlgeschlagenem "onlinechanged online"??

 

[hermann72pb]

@SaschaBr: Du schmeißt wieder unterschiedliche Dinge durcheinander. In deinem Thread ging es doch darum, dass deine selbst eingetragenen Sachen in "onlinechanged.cgi" nicht immer ausgeführt wurden. Oliver und cuma waren sich sogar einig, woher das kommt. Es gab zwar keine Lösung zu, sie wussten jedoch in etwa, was man tun sollte, um dieses seltene Fehlverhalten zu beheben.
Im hier dieskutierten Falle geht es aber nicht um onlinechanged.cgi, sondern um rudimentäre AVM-Funktion, wenn ich es richtig verstanden hatte. Es sei denn, uns wurde nicht alles verraten. Ich würde mir hier übrigens auch eine ähnliche Untersuchung wünschen, wie du es in deinem Thread getrieben hast. Zusätzich würde ich evtl. per cron oder wie auch immer die AVM-Statusdatei zum ddns-Ereignis ins Log übernehmen. Dann würde man schon alleine daran evtl. erkennen, was da beim ddns-Update schief läuft.
Allerdings weiß ich nicht, ob unsere onlinechanged-Sachen das allgemeine Verhalten vom AVM-Update beeinflüssen. Vielleicht "funken" unsere Sachen da dazwischen und es reicht bereits onlinechanged im Image zu haben, selbst wenn seine Aktionen "leer" sind und eigentlich keine Wirkung zu erwarten wäre. Dazu müssen wir erstmal wissen, ob franzl onlinechanged im Image hat, ob es irgendwie gefüllt ist. dann bräuchten wir die Auskunft von unseren Experten, wo onlinechanged überhaupt in AVM-Sachen eingebunden ist und ob es AVM-Skripte in irgendeiner Form stören kann.
Es wäre vielleicht auch sinnvoll ein Image ohne onlinechanged zu bauen und langfristig damit testen.

MfG

 

[SaschaBr]

Was heißt hier wieder?? Würde ich niemals nicht tun.

Das onlinechanged-cgi habe ich aber auch nicht in der Firmware, und dem entsprechend dort auch nichts selber eingetragen. "vsftpd" und "opendd" nutzen nur das onlinechanged, welches ja (so wie ich es hier mal irgendwo gelesen habe) sowieso mit drinne ist.

Ich dachte halt nur "dyndns fackelt immer wieder ab" könnte auch was mit "onlinechanged" (also mit meinem Problem) zu tun haben.

 

[hermann72pb]

Ok, ein guter Hinweis "immer drinne". An sowas hatte ich nämlich schon gedacht. D.h. onlinechanged gehört fest zu FREETZ und nestet sich somit immer fest ein? Was sagen unsere Experten dazu? Kann man wenigstens für Testzwecke onlinechanged "wegpatchen"?

MfG

 

[sf3978]

So wie ich das verstehe, benutzt franzl weder das onlinechanged von AVM (... oder ist es doch auch aus Freetz?), noch das onlinechanged-cgi aus Freetz. Ich denke, er startet sein Script (für das dyndns-update) mit cron, nach der Zwangstrennung:

aufgerufen durch z.B. cron ala

EDIT:
Aha, es gibt ein AVM onlinechanged (... so verstehe ich den Beitrag #35 von Oliver).

 

[olistudent]

Kann man wenigstens für Testzwecke onlinechanged "wegpatchen"?

Nein, kann man nicht. In Freetz wird die Funktionalität das AVM onlinechanged erweitert. Nenne mir einen Grund warum man es rauspatchen sollte?

Gruß
Oliver

 

[franzl]

Um nicht mißverstanden zu werden. Keine Kritik von mir an onlinechanged und ich gebe auch zu, dass mein script einen ganz bösen Fehler hatte - es muss natürlich /dev/null heißen.
Ändert alles nichts an der Tatsache seit meinem unprofessionellen Eingriff funktioniert's.

Wenn sich dein Script nicht "durchboxt" und z. B., 20x täglich aufgerufen werden kann ( ... mit/an einem Internetzugang, dessen externe IP-Adresse sich NIE ändert, wenn die FritzBox nur rebootet/neustartet!!), ohne, dass dein dyndns-Provider dir den DynDNS-Account sperrt, dann ist es OK.

Genau das unterscheidet meine Lösung vom integrierten DNS-Klienten.

 

[sf3978]

...
Genau das unterscheidet meine Lösung vom integrierten DNS-Klienten.

Vom integrierten Original-AVM-DNS-Klienten oder vom noip- bzw. opendd-Klienten aus Freetz?
Könnte ich dein Script auf meiner Box benutzen, ohne dass mein dyndns-Account gesperrt wird?

 

[hermann72pb]

Nenne mir einen Grund warum man es rauspatchen sollte?

Im oben von SaschaBr angesprochenen Thread hast du doch mit cuma über irgendein & (Hintergrundprozess) innerhalb von onlinechanged gesprochen. Das Verhalten war dem sehr ähnlich, was auch hier diskutiert wird. Daher liegt der Verdacht nah, es könnte was mit onlinechanged an sich zu tun haben.
Ohne jetzt mich da in die Sache tief einzusteigen, wollte ich vorschlagen, dass man wenigstens die von FREETZ reingebrachten Änderungen deaktiviert. Eine radikale Lösung wäre natürlich komplett auf FREETZ zu verzichten und damit testen. Damit wird es aber vermutlich gehen und wir haben auf der anderen Seite sogut wie keine Debug-Werkzeuge, wenn wir es ohne FREETZ testen wollen. Daher dachte ich an "herauspatchen", wobei dies nur von uns reingebrachten Änderungen betrifft.
Ich muss allerdings dazu sagen, dass ich mich mit dem onlinechanged noch nie auseinander gesetzt hatte. Darum solche radikalen Vorschläge von mir...

Andersrum will man hier doch irgendweie weiter kommen. Und momentan sieht es für mich eher nach einer Sackgasse aus. Abgesehen von einem Workarround, der das eigentliche Problem nicht löst.

MfG

 

[franzl]

Für die Erstregistrierung verwende ich den Original-AVM-Klienten erweitert in der ar7.cfg um einige Accounts. Bei den Accountsperren scheint es so zu sein, dass Registrierungen mit unveränderter IP und Registrierungen mit zu kurzen oder regelmäßigen Zeitabständen zur Sperre führen. Exakte Angaben bleibt DynDNS schuldig. Vieleicht hat dazu jemand genaue Angaben?
Die Registrierung einer unveränderten IP vermeidet das kleine Script schlicht durch vorherigen Vergleich und einen unregelmäßigen und ausreichend großen Zeitabstand gewährleistet man mit dem Aufruf aus crond, monit oder was auch immer.

 

[hermann72pb]

... erweitert in der ar7.cfg um einige Accounts....

Vielleicht ist das dein Problem? Denn wir wissen immer noch nicht genau, wie diese Registrierung funktioniert. Wie hast du denn die zusätzlichen Accounts in ar7.cfg reingebracht? Durch die neue Methode mit ctlmgr oder einfach eingetragen?
Bei mir sieht es z.B. so aus:

       .....
ddns {
        accounts {
                enabled = yes;
                domain = "$$$$geheim";
                iface = 0;
                username = "$$$$geheim";
                passwd = "$$$$geheim";
                ddnsprovider = "Benutzerdefiniert";
        } {
                enabled = yes;
                domain = "$$$$geheim";
                iface = 1;
                username = "$$$$geheim";
                passwd = "$$$$geheim";
                ddnsprovider = "Benutzerdefiniert";
        }
        types {
        ...

Wobei iface =1 für 2.PVC steht. Hast du schon mit nur einem Provider in ar7.cfg ausprobiert? Wenn es mehrere Accounts sind, sind sie denn alle bei dyndns.org? Vielleicht deutet DynDNS sowas als pishing?

MfG