[Problem] dyndns fackelt immer wieder ab

[sf3978]

...
Die Registrierung einer unveränderten IP vermeidet das kleine Script schlicht durch vorherigen Vergleich und ...

if [ "${DNSIP}" != "${BOXIP}" ] ;

Für meine ferne Box am DSL-Anschluss wäre dieser Vergleich ausreichend. Aber nicht für meine Box am Kabelanschluss. Nach einem Neustart hat meine Box am Kabelanschluss erstmal gar keine IP-Adresse, dann bekommt diese die IP-Adresse 192.168.100.2 (die im Internet nichts verloren hat) und dann erst (... nach dem Neustart des Kabelmodems!) bekommt die Box, eine externe (öffentliche) IP-Adresse, die evtl. (... eher nicht da keine Änderung) registriert werden muss:

Sat Jan  1 01:01:54 CET 2000
Sat Jan  1 01:03:57 CET 2000
192.168.100.2
Sat Jan  1 01:04:20 CET 2000
##.##.2#3.##

Damit haben die Clients noip und opendd, kein Problem.

 

[franzl]

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?

Einfach eingetragen - und ja, ich halte auch für möglich und sogar warscheinlich, dass die gleichzeitige Registrierung mehrerer Accounts bei einem Provider eine Rolle spielt.

 

[sf3978]

... - und ja, ich halte auch für möglich und sogar warscheinlich, dass die gleichzeitige Registrierung mehrerer Accounts bei einem Provider eine Rolle spielt.

Also ich habe damit keine Probleme:

Jan  1 01:04:27 fritz user.notice ONLINECHANGED[4367]: [online] executing /etc/onlinechanged/start_opendd
Jan  1 01:04:27 fritz user.notice info: start OPENDD after IP-change
Jan  1 01:04:28 fritz daemon.info opendd[4689]: -- running OpenDD 0.7.9 in normal mode
Jan  1 01:04:28 fritz daemon.info opendd[4689]: dyndns() : established external or dummy ip address : ##.##.2#3.##
Jan  1 01:04:28 fritz daemon.info opendd[4689]: main() : getting my ip address : ##.##.2#3.##
Jan  1 01:04:28 fritz daemon.info opendd[4689]: getdyndnshostnames() : no need to update ####.ath.cx with ##.##.2#3.##
Jan  1 01:04:29 fritz daemon.info opendd[4689]: getdyndnshostnames() : no need to update ####.###.nu with ##.##.2#3.##
Jan  1 01:04:29 fritz daemon.info opendd[4689]: getdyndnshostnames() : no need to update ####.###.cx with ##.##.2#3.##
Jan  1 01:04:29 fritz daemon.info opendd[4689]: getdyndnshostnames() : no need to update ####.###.nu with ##.##.2#3.##
Jan  1 01:04:29 fritz daemon.info opendd[4689]: getdyndnshostnames() : no need to update #####.###.nu with ##.##.2#3.##
Jan  1 01:04:29 fritz daemon.err opendd[4689]: main() : No hostname(s) to update

 

[hermann72pb]

@sf3978: Bist du bei DynDNS? Wenn nicht, dann ist es gut möglich. DynDNS hatten gerade wegen solcher Attacken vor drei Jahren Probleme gehabt. Wenn ich an deren Stelle wäre, würde ich auch ähnliche Schutzmechanismen einbauen.
Eine andere Annahme. Du benutzt opendd. Vermutlich ist das Ding besser multiaccount-fähig als der Klient von AVM. Und den Klient von AVM kenne ich zu gut: Der benutzt eine Datei für sein Status: /tmp/ddnsstat.txt. In meinem Fall hat sie folgenden Inhalt:

5 1039847 meindomain1.domain.tld
5 1039809 meindomain2.domain.tld

Die zweite Eintragung benutze ich für 2.PVC. Nach meiner Beobachtung, liegen aber wenigstens einige Sekunden zwischen dem Update von 1.PVC und 2.PVC. Daher gibt es keine Probleme bei mir. In deinem Fall kann jedoch sein, dass AVM-Klient zweifach/mehrfach aufgerufen wird und versucht die gleiche Datei zu beschreiben. Sowas geht generell schief.

@franzl:
Haben wir nun die Ursache gefunden?

Blöd ist nur, dass du damit nicht an AVM treten kannst. Über WebIF lässt sich sowieso nur ein Provider eintragen. Von daher fragen sie dich verwundert, wie du es geschafft hast da mehrere einzutragen...

Bevor du jetzt zu opendd wechselst oder Ähnliches, wäre es sehr nett, wenn du bei dir die besagte Datei beobachtest. Wir werden sicherlich da was erkennen können, wennn wir sie haben. Modifiziere doch deinen Wunderskript, dass vor dem Update Inhalt von /tmp/ddnsstat.txt irgendwo abgesichert wird. Dann können wir meine Theorie entweder bestätigen oder widerlegen. Als Nächstes müssen wir dann an den Klient von AVM ran.

MfG

 

[sf3978]

@sf3978: Bist du bei DynDNS? Wenn nicht, dann ist es gut möglich. DynDNS hatten gerade wegen solcher Attacken vor drei Jahren Probleme gehabt. Wenn ich an deren Stelle wäre, würde ich auch ähnliche Schutzmechanismen einbauen.
Eine andere Annahme. Du benutzt opendd. Vermutlich ist das Ding besser multiaccount-fähig als der Klient von AVM. ...

Meine dyndns-Provider sind DynDNS und noip. Ja, ich benutze neben noip2 (aus Gründen der Redundanz) auch opendd. opendd ist nicht nur multiaccount-fähig, sondern auch multiprovider-fähig. Ich benutze opendd mit 2 Konfigurationsdateien für die 2 dyndns-Provider. DynDNS mit 5 Accounts und noip mit 4 Accounts. Der 5. Account von noip, wird mit dem Client noip2 registriert (d. h. updatet). Übrigens, DynDNS hat mit einem multiaccount-fähigem Client, keine Probleme.

 

[Osz]

[Edit frank_m24: Vollzitat gelöscht, siehe Forumregeln.]

Hi,

vielen Dank für das Script! Hier kommt es 1 bis 2 mal im Monat vor, das dyndns die IP nicht richtig aktualisiert.
Ich habe es nun erstmal temporär eingebaut und starte das Script täglich 6 Uhr ... wobei zwischen 2 - 3 Uhr die Provider "Relogin" stattfindet.

Könnte man das ganze nicht in die Web - Oberfläche von freetz einbauen? Also ein Check einmalig pro Tag nach 2 Stunden Provider "Relogin", ob dyndns richtig funktioniert hat ...!?

 

[sf3978]

...
Könnte man das ganze nicht in die Web - Oberfläche von freetz einbauen? Also ein Check einmalig pro Tag nach 2 Stunden Provider "Relogin", ob dyndns richtig funktioniert hat ...!?

Dafür gibt es schon was (opendd, noip, ip_archiv) für bzw. in Freetz:
opendd

Apr 29 05:42:12 fritz daemon.info opendd[1127]: -- running OpenDD 0.7.9 in normal mode
Apr 29 05:42:12 fritz daemon.info opendd[1127]: dyndns() : established external or dummy ip address : xx.1x4.xxx.xxx
Apr 29 05:42:12 fritz daemon.info opendd[1127]: main() : getting my ip address : xx.1x4.xxx.xxx
Apr 29 05:42:16 fritz daemon.info opendd[1127]: dyndns() : Setting SSL trust certificate store to /var/tmp/flash/opendd/opendd.pem
Apr 29 05:42:17 fritz daemon.err opendd[1127]: Warning : certificate cannot be verified with trust store : unable to get issuer certificate locally
Apr 29 05:42:17 fritz daemon.info opendd[1127]: dyndns() : connected to members.dyndns.org:443
Apr 29 05:42:17 fritz daemon.info opendd[1127]: dyndns() : GET /nic/update?system=dyndns&hostname=yyy.yyy.cx,yyyy.xxx.net,xxx.yyy.org,yyy.xxx.nu,yyy.xxxxx.net&offline=NO&myip=xx.1x4.xxx.xxx HTTP/1.0
Apr 29 05:42:17 fritz daemon.info opendd[1127]: listen_response() : HTTP/1.1 200 OK
Apr 29 05:42:17 fritz daemon.info opendd[1127]: listen_response() : Date: Fri, 29 Apr 2011 03:42:17 GMT
Apr 29 05:42:17 fritz daemon.info opendd[1127]: listen_response() : Server: Apache
Apr 29 05:42:17 fritz daemon.info opendd[1127]: listen_response() : Content-Type: text/plain
Apr 29 05:42:17 fritz daemon.info opendd[1127]: listen_response() : Connection: close
Apr 29 05:42:17 fritz daemon.info opendd[1127]: listen_response() : good xx.1x4.xxx.xxx
Apr 29 05:42:17 fritz daemon.info opendd[1127]: listen_response() : The update was successful, and the hostname is now updated.
Apr 29 05:42:17 fritz daemon.info opendd[1127]: listen_response() : good xx.1x4.xxx.xxx
Apr 29 05:42:17 fritz daemon.info opendd[1127]: listen_response() : The update was successful, and the hostname is now updated.
Apr 29 05:42:17 fritz daemon.info opendd[1127]: listen_response() : good xx.1x4.xxx.xxx
Apr 29 05:42:17 fritz daemon.info opendd[1127]: listen_response() : The update was successful, and the hostname is now updated.
Apr 29 05:42:17 fritz daemon.info opendd[1127]: listen_response() : good xx.1x4.xxx.xxx
Apr 29 05:42:17 fritz daemon.info opendd[1127]: listen_response() : The update was successful, and the hostname is now updated.
Apr 29 05:42:17 fritz daemon.info opendd[1127]: listen_response() : good xx.1x4.xxx.xxx
Apr 29 05:42:17 fritz daemon.info opendd[1127]: listen_response() : The update was successful, and the hostname is now updated.
Apr 29 05:42:18 fritz daemon.info opendd[1127]: listen_response() : mail report sent !
Apr 29 05:42:18 fritz daemon.info opendd[1127]: dyndns() : connection closed
Apr 29 05:42:18 fritz daemon.info opendd[1127]: main() : dyndns() exit normally

noip

Apr 29 05:42:14 fritz daemon.info noip2[1158]: v2.1.9 daemon started with NAT enabled
Apr 29 05:42:15 fritz daemon.info noip2[1158]: xxxxxx.yyyyyy.net set to xx.1x4.xxx.xxx
Apr 29 05:42:29 fritz daemon.info noip2[1158]: v2.1.9 daemon ended.

ip_archiv

Apr 29 05:42:13 fritz user.notice info: [ip_archiv] Fri Apr 29 05:42:13 CEST 2011 xx.1x4.xxx.xxx

 

[Osz]

Dafür gibt es schon was (opendd, noip, ip_archiv) für bzw. in Freetz:
opendd
...
noip
...
ip_archiv
...

Ahh, wunderbar, Danke für die Info! Also muss ich wohl doch nen neues Image bauen ...

 

[kkkap]

Also,

ich bin zwar Anfänger aber ich finde die Lösung v. Franzl gut. Ich muß dazu sagen, daß bei seiner Lösung kein opendd oder andere Programme nicht zum Freetz genommen werden muß.

@Franzl
wenn ich ein Teil dirket auf der Fritz Konsole eingebe bekomme ich folgendes.

/var/mod/root # wget -q http://myaccount:[email protected]/nic/update?hostname=mydm.dyndns.info
wget: can't open 'update?hostname=mydm.dyndns.info': File exists

was hat das zu bedeuten? Prost

 

[sf3978]

... Ich muß dazu sagen, daß bei seiner Lösung kein opendd oder andere Programme nicht zum Freetz genommen werden muß.
...

Das hast Du leider nicht richtig erkannt. Bei seiner Lösung (siehe sein Beitrag #27) läuft cron ständig. opendd und noip funktionieren im nodaemon-Modus, d. h. das update mit opendd und /oder noip, wird durch das onlinechanged-Ereignis ausgelöst.

 

[kkkap]

Das ist schon richtig, daß crond läuft und jede Minute oder alle 5 Minuten sein script abgerufen wird. Opendd ist aber kein Bestendteil v. Freetz oder? Weil beim kompilieren konnte ich opendd nicht auswählen.

 

[sf3978]

... Opendd ist aber kein Bestendteil v. Freetz oder? Weil beim kompilieren konnte ich opendd nicht auswählen.

opendd und noip gibt es im Freetz trunk.

 

[sf3978]

Nur zur Info

Ein Beispiel wie nützlich ein multiproviderfähiger dyndns-Client sein kann:
Heute morgen (nach dem onlinechanged) konnte meine ferne Box, warum auch immer, zu dyndns.org keine Verbindung aufbauen. Da die Verbindung zum 2. Provider funktioniert hat, ist meine ferne Box, für diverse Anwendungen (VPN, IM, etc.) auf der nahen Box, über das Internet trotzdem erreichbar.

...
May  1 05:39:38 fritz user.notice info: start OPENDD after IP-change
May  1 05:39:46 fritz daemon.info opendd[2339]: -- running OpenDD 0.7.9 in normal mode
May  1 05:39:46 fritz daemon.info opendd[2339]: dyndns() : established external or dummy ip address : xx.x1x.xxx.xxx
May  1 05:39:46 fritz daemon.info opendd[2339]: main() : getting my ip address : xx.x1x.xxx.xxx
May  1 05:39:50 fritz daemon.info opendd[2339]: dyndns() : Setting SSL trust certificate store to /var/tmp/flash/opendd/opendd.pem
May  1 05:42:59 fritz daemon.err opendd[[COLOR="red"]2339[/COLOR]]: dyndns() : [COLOR="red"]connect() error[/COLOR] on [COLOR="red"]members.dyndns.org[/COLOR] : (null)
May  1 05:42:59 fritz daemon.err opendd[[COLOR="red"]2339[/COLOR]]: main() : dyndns() [COLOR="red"]exit abnormally[/COLOR]
....
May  1 05:43:07 fritz daemon.info opendd[[COLOR="red"][B]2395[/B][/COLOR]]: dyndns() : [COLOR="red"][B]connected to dynupdate.no-ip.com:443[/B][/COLOR]
...
May  1 05:43:09 fritz daemon.info opendd[[COLOR="red"]2395[/COLOR]]: listen_response() : [COLOR="red"]mail report sent ![/COLOR]
May  1 05:43:09 fritz daemon.info opendd[2395]: dyndns() : connection closed
May  1 05:43:09 fritz daemon.info opendd[[COLOR="red"]2395[/COLOR]]: main() : dyndns() [COLOR="red"]exit normally[/COLOR]
...

 

[franzl]

Auch wenn ich natürlich die Nutzung von opendd insbesondere im Vergleich zum integrierten AVM-Klienten sehr viel besser finde, ist die "Systemlast" von crond nun wirklich kein ernstzunehmendes Argument gegen meine kleine Frickellösung.

 

[kkkap]

Ich finde die Frickellösung echt gut. Das mit dem Systemlast finde ich nicht besonders schlimm. Meine Box macht es schon länger und deshalb habe ich keine Probleme. Ich mußte feststellen, daß ich die Dyndns Problem nur mit den Trunk Versionen gehabt habe. Ich habe seit kurzem wieder die stable Version und da kam es nicht mehr vor. Aber das kann auch nur Zufall sein.

Ich finde auch die OpenDD Lösung sehr gut. Vor allem macht es sinn wenn mann 100% erreibar sein möchte und 2 Dyndns Accounts benützt.
Ich habe bedenken, daß der DynDNS Dienst v. AVM und OpenDD sich beißen könnten. OpenDD ist auch im stable 1.1.4 nicht vorhanden.
Aber ich mache mir ernsthaft gedanken dies einzusetzen. Es würde sich sogar rentieren wegen OpenDD wieder Trunk Version zu kompilieren.

Kann ich dann mit dem DynDns Klient v. AVM dyndnsorg eintragen und mit OpenDD einen anderen DynDNS Provider eintragen, für den Fall, das ein Dienst abfackelt?

Welche Kostenlose DynDNS Provider gibt es nun. Kann die jemand aufzählen.

Vielen Dank!

 

[sf3978]

Ich habe bedenken, daß der DynDNS Dienst v. AVM und OpenDD sich beißen könnten. OpenDD ist auch im stable 1.1.4 nicht vorhanden.
Aber ich mache mir ernsthaft gedanken dies einzusetzen. Es würde sich sogar rentieren wegen OpenDD wieder Trunk Version zu kompilieren.!

Der avm-dyndns-Client und opendd sollten problemlos nebeneinander funktionieren. Aber warum kannst bzw. willst Du auf den avm-dyndns-Client nicht verzichten? Du könntest auch noch einen 3. Client, z. B. noip, auf deiner Box installieren und benutzen. opendd und noip könnten auch an Freetz-1.1.4 angepasst werden.

Kann ich dann mit dem DynDns Klient v. AVM dyndnsorg eintragen und mit OpenDD einen anderen DynDNS Provider eintragen, für den Fall, das ein Dienst abfackelt?

Ja, das ist auch möglich.

 

[hermann72pb]

@kkkap: Die Lösung von franzl ist keine echte Lösung, sondern ein Workarround. Alleine der zweite "händische" Aufruf vom wget ist meiner Meinung nach schon etwas daneben. Außerdem muss man die ganzen Zugangsdaten auch im Klartext im Skript eintragen. Ferner, es ist speziell für DynDNS zugeschnitten.
@all: Meiner Meinung nach ergeben sich hier für uns folgende möglichen Handlungsfelder:
1. Einen Super-DDNS-Klient zu bauen, der mehrere DDNS vereinigt bzw. beobachtet, dass sie sich nicht gegenseitig stören. Dieser Klient soll keinen eigentlichen Klient beinhalten, sondern lediglich auf bestehende Lösungen zurückgreifen. Und zu diesen lösungen gehören sowohl der AVM-Klient, als auch alle hier bisher genannten. Als eine der Hauptaufgaben von diesem Super-Klient würde ich eine zentrale Stelle für die Speicherung der Zugangsdaten für ALLE Klients sehen. Idealerweise wäre es ar7.cfg. Vor allem, weil wir seit kurzem wissen, dass man die Sektionen dort auch für multiaccount und multi-PVCs "missbrauchen" kann.
2. Den AVM-eigenen Klient irgendwie dazu ertüchtigen, dass er keine Probleme mit dem Beschreiben der gleichen Status-Datei hat. Evtl. einen Wrapper, der auf die Datei wartet oder was Ähnliches.

Zum Super-DDNS-Klient. Ich hatte eine ähnliche Idee zu allen unseren FTP-Servern. Hatte allerdings bis jetzt noch keine Zeit dazu. Die Grundbausteine für den Super-DDNS-Klient sind schon längst in Form von "onlinechanged" gelegt worden. Die letzten Erkenntnisse mit der Multiaccount-Fähigkeit vom AVM-Klient sind nun auch bekannt. Man muss nur auf dies alles aufbauen und daraus was Vernünftiges und vor allem Benutzerfreundliches erstellen. Und da gebe ich sf3978 schon Recht, dass man eine gewisse Redundanz braucht. Auf der anderen Seite bedürfen sowohl die Lösungen von franzl, als auch alleine schon die Benutzung von diversen alternativen ddns-Klients gewisse Kenntnisse und Erfahrungen vom Endbenutzer. Alleine aus diesem Grund sind sie nicht leicht anzuwenden, nicht leicht zu verstehen und nicht immer leicht zu bedienen.

MfG

 

[hermann72pb]

mal sehen...
Es wäre aber schon sinnvoll für solche Sachen einen "Sammler" bzw. "Superkonfigurator" in Form einer CGI ins Leben zu rufen. Mit dem konnte der Benutzer dann an einer Stelle das grundsätzliche Verhalten beeinflüßen und manuell steuern.
Für HTTP wäre es natürlich auch sinnvoll. Aber dort sollte man zunächst eine vernünftige Benutzerverwaltung einführen. Dann könnte man darüber nachdenken alles auf einem Web-Port laufen zu lassen, als pro Anwendung einen Port zu spendieren.

MfG

 

[franzl]

@kkkap: Die Lösung von franzl ist keine echte Lösung, sondern ein Workarround. Alleine der zweite "händische" Aufruf vom wget ist meiner Meinung nach schon etwas daneben. Außerdem muss man die ganzen Zugangsdaten auch im Klartext im Skript eintragen. Ferner, es ist speziell für DynDNS zugeschnitten.

Workaround - ja.
Keine Lösung - funktioniert super, also ist es eine Lösung.
Zugangsdaten im Script? Bitte noch mal genau anschauen.
Das Script war bewußt als kleines Beispiel deklariert und nicht als Allroundfertiglösung, lässt sich aber mit 2 Handgriffen auf beliebige Provider ausdehnen.

 

[hermann72pb]

...
aufgerufen durch z.B. cron ala

/var/tmp/verify_dns.sh LOGIN PASSWORD DOMAIN

...

Ob es direkt im Skript oder als Aufrufparameter realisiert ist, spielt in diesem Fall keine Rolle. Es ist im Klartext irgendwo abgespeichert.

Und Workarround ist keine Allgemeinlösung. Für dich persönlich schon, für Allgemeinheit allerdings noch nicht. Denn das Hauptproblem in deinem Fall ist die Benutzung der Multi-Account-Funktionalität von AVM. Und dies tut momentan keiner. Dein Workarround wird von den meisten alternativen Klients mit Bravur gemeistert. Und zwar per see. D.h. die eigentliche saubere Lösung wäre an der Stelle einen anderen Klient zu benutzen. Obwohl diese Lösung mir persönlich auch nicht gefällt.

MfG