reconnect einer anderen Fritzbox im Netzwerk auslösen

[billygeen]

Hallo zusammen,

Aufbau:

zwei Fritzboxen per WDS verbunden,
7170 (original FW, nur Telnet aktiviert, kein Freetz) Ist als DSL Modem aktiv inkl Dyndns, freigegbener Ports und auch die WDS-Basisstation

7270v3 (freetz) ist der WDS repeater mit ein paar angeschlossenen Geräten

Ziel:
möglichst hohe verfügbarkeit der 7270 vom Internet aus zu gewährleisten


Beobachtete Probleme:

1. WDS-Verbindung 7270: hier kommt es in unregelmäßigen Zeitabständen zum mehrmaligen an/abmelden an der Basisstation (7170)--> dieses Problem hab per CronJob gelöst. Ping an die 7170, wenn nicht erreichbar reboot auslösen!

2. dyndns verbindung 7170: hier kommt es sporadisch zu einem Fehler beim anmelden am account. Nach der Zwangstrennung vom Internet funktioniert die registrierung bei dyndns nicht, und somit ist auch meine 7270 nicht mehr vom Internet erreichbar. Einen manuellen reconnect ausgeführt und schon geht wieder alles! Dieses Problem möchte ich per Script beheben. Wäre an sich ganz einfach wenn auf der 7170 freetz laufen würde, aber da das script auf der 7270 laufen soll hab ich keinen Plan wie ich übers Netzwerk bei meiner 7170 einen reconnect auslösen kann.

 

[RalfFriedl]

Du brauchst keinen Reconnect, Du brauchst nur einen DynDNS Update. Diesen kann die 7270 durchführen.

Ein Problem dabei ist, daß DynDNS schon die Überprüfung des DNS-Eintrags als Missbrauch betrachtet. Ich weiß nicht, ob und wie DynDNS das prüft.

 

[billygeen]

Danke, klappt 1a. Ich denke mal das die Häufigkeit der Anfragen überprüft wird, alle paar sekunden wird wohl ein Problem werden. Ich mach das nur einmal am Tag, wenn die Box mal registriert ist dann passt eh alles, nur nach der Zwangstrennung gibts da manchmal Probleme, eine Stunde später läuft mein script ab und gut is!

 

[hermann72pb]

Ping an die 7170, wenn nicht erreichbar reboot auslösen!

Ist ziemlich brutal, finde ich. Ansonsten, wie Ralf schon sagte, kann auch die 7270 dein DynDNS überwachen, obwohl ich persönlich da eher skeptisch bin. Denn besser ist es, wenn dyndns-Anmeldung über die Box gestaltet ist, die direkt an DSL "hängt". Rein theoretisch ist es in diesem Fall einfacher die Verbindung zu beobachten und ein Update bei DynDNS einleiten/erzwingen.
Auf der anderen Seite hat Ralf wiederum Recht: DynDNS wurden vor 3-4 Jahren einer hacker-Attacke ausgesetzt. Seitdem verstärken sie ihre Kontrollen gegenüber aller möglichen Angreifer. Dazu gehört, dass sie die Anfragen jeglicher Art reduzieren und teilweise ablehnen, wenn sie zu oft kommen. Sprich: Wenn deine Box keine stabile DSL-Verbindung hat und 3-4 Mal in 2 Minuten braucht, bis die Verbindung wieder steht und wenn dein DynDNS-Klient alle diese Versuche bei DynDNS meldet, dann kann es unter Umständen dazu kommen, dass die letzten Anmeldeversuche gesperrt werden. Allerdings darf sowas eigentlich nicht passieren, denn ich habe in AVM-Konfigurationsparametern zu einzelnen ddns-Anbietern so einen Parameter gesehen, wie "Zeit zwischen zwei nacheinander folgenden Anmeldungen". Und diese Zeit ist meines Erachtens bei DynDNS mit 4 Minuten angegeben. D.h. billygeen, irgendwas stimmt bei dir nicht und nicht bei DynDNS. Sonst hätten wir hier deutlich mehr an negativen Meldungen dieser Art.
Ich würde dir empfehlen deine 7170 auf den neuen Stand der Firmware zu bringen. Wenn du dabei Labor nutzt, kann es auch eine mögliche Fehlerquelle sein. Die freigegebene 80-ger Version für 7170 funktioniert auf jeden Fall stabil, was DSL und DynDNS angeht.
Ferner wäre es möglich, auch eine 7170 zu FREETZen. Zwar musst du einige Sachen aus deiner 7170 herauspatchen, damit FREETZ da rein überhaupt passt. Es ist aber grundsätzlich möglich. Außerdem gibt es External und man kann einige der Paketen auf einen USB-Stick auslagern. Wenn du FREETZ auf deiner 7170 hast, kannst du evtl. auf onlinechanged-Paket zurückgreifen. Damit hast du auf jeden Fall etwas mehr Möglichkeiten, um dein Problem zu analysieren bzw. sogar zu beheben.

Edit: Hast du denn in der 7170 die Option angeklickt "Zwangstrennung verbeugen und die Box um XY Uhr neu verbinden"? Vermutlich wird dann die echte Zwangstrennung umgangen und es klappt mit DynDNS-Update besser?

MfG

 

[billygeen]

Hast du denn in der 7170 die Option angeklickt "Zwangstrennung verbeugen und die Box um XY Uhr neu verbinden"? Vermutlich wird dann die echte Zwangstrennung umgangen und es klappt mit DynDNS-Update besser?

Hab ich!

Wenn deine Box keine stabile DSL-Verbindung hat und 3-4 Mal in 2 Minuten braucht, bis die Verbindung wieder steht und wenn dein DynDNS-Klient alle diese Versuche bei DynDNS meldet, dann kann es unter Umständen dazu kommen, dass die letzten Anmeldeversuche gesperrt werden.

Kein Problem mit meiner Verbindung, wie gesagt wenn nicht richtig registriert wird dann nur einmal nach der Zwangstrennung

Hab Script und Cronjob bereits fertig und alles aktiviert, bei nem kurzen test sah nun alles gut aus (will nicht zu oft testen). 7270 fragt nun einmal täglich dyndns registrierung ab und registriert gegebenfalls neu! dürfte soweit alles passen

 

[SaschaBr]

... hier kommt es sporadisch zu einem Fehler beim anmelden am account. Nach der Zwangstrennung vom Internet funktioniert die registrierung bei dyndns nicht, und somit ist auch meine 7270 nicht mehr vom Internet erreichbar. Einen manuellen reconnect ausgeführt und schon geht wieder alles! ...

Gibt es hier eventuell etwa auch das gleiche Problem wie bei mir, das "onlinechanged" nicht ausgeführt wird??

 

[hermann72pb]

@billygeen: Deine Lösung ist nicht 100% und ziemlich eigentartig, dafür aber selten. Man sollte dem Problem auf Grund gehen anstatt Workarrounds zu schaffen. Du hast genau so eine brutale Lösung erschaffen, wie mit einem Reboot einer Box.
@SaschaBr: Er hat bei seiner 7170 kein FREETZ, fölglich auch kein onlinechanged. Trotzdem könnte es natürlich sein, dass die Problemwürzeln die gleichen sind.

Was mich an der Sache eigentlich stört: Wenn an der Stelle wirklich ein methodisches Problem gewesen wäre, hätte AVM schon längst eine Lösung dafür gehabt. Denn die Wut der Kunden wäre unerträglich gewesen. Da zu dem Thema allerdings nur vereinzelte Meldungen hier gibts, gehe ich davon aus, dass dieses Problem noch weitere sehr spezifische Randbedingungen erfordert. Z.B. einen bestimmten Provider, eine bestimmte DSL-Verbindung und deren Qualität, eine bestimmte BOX-Konfiguration (wie z.B. hier der WDS-Master-Repeater-Betrieb). All diese Faktoren tragen dazu bei, WIE ein DSL-Reconnect abläuft. Eine richtige Herangehensweise wäre so eine Zwangstrennung zu beobachten und zu analysieren, was dabei schief läuft. Ohne FREETZ auf der 7170 würden solche Beobachtungen sich allerdings nur schwierig gestalten.

MfG

 

[RalfFriedl]

Ich mit Freetz werden sich solche Beobachtungen schwierig gestalten, weil das Ganze im AVM Teil abläuft.

Im Wesentlichen gibt es zwei Möglichkeiten:
- Die Box versucht erst gar nicht, die Adresse bei DynDNS zu aktualisieren.
- Die Box versucht es, aber DynDNS aktualisiert trotzdem nicht.
Mir ist auch von anderen Routern von Herstellern bekannt, daß es gelegentlich Probleme gibt. Vielleicht liegt es also an DynDNS, vielleicht machen mehrere Hersteller das nicht perfekt.

Generell bin ich auch eher dafür, die Ursache eines Problems zu beheben, als an dem Problem vorbei zu arbeiten. Hier liegt aber die Ursache entweder bei AVM oder bei DynDNS. Auf beide haben wir wenig Einfluß. Von daher ist eine pragmatische Lösung manchmal besser.

 

[hermann72pb]

So ganz schwarz sehe ich es nicht Ralf. Der ddns-Klient von AVM ist an sich nicht schlecht, leider nur schlecht bzw. kaum dokumentiert. Ich weiß nicht, ob du dich daran erinnerst, es gab aber vor einigen Monaten hier eine Diskussion, wie man die ar7.cfg ändern kann, damit man den ddns-Klient von AVM dazu überredet, mehrere Konten und mehrere ddns-Anbieter zu bedienen. Wir haben es sogar geschafft, für IP-Telefonie eine eigene Adresse/Konto zu hinterlegen als für Hauptverbindung. Solche Sachen schaffst du nämlich nur mit dem AVM-Teil und mit keiner Box, die dahinter hängt.
Ich bin damals sogar weiter gegangen und hatte auf meinem eigenen Strato-Root-Server bind-basierend einen eigenen DDNS-Service aufgesetzt. Das läuft seit Ende November ganz gut und ich benutze es für mindestens 3 Boxen, alle von denen je zwei Accounts haben (1.PVC und IP-Telefonie über 2.PVC). Darüber mache ich meine Direktanrufe zwischen diesen 3 Boxen an dem 1und1-VOIP-Server vorbei. Ohne AVM-ddns-Klient wäre dies nur mit sehr viel Aufwand schaffbar.
Als ich mit der Sache rumgespielt hatte, hatte ich festgestellt, dass AVM-ddns-Klient an sich gar nicht schlecht ist, sondern auch diverse Antworten vom DDNS-Server bearbeitet und in einer Datei ablegt. Es gibt da (wenn ich mich richtig besinne) 5 Antoworttypen, an denen man eindeutig erkennen kann, ob ddns-Update erfogreich war, WANN es ausgeführt wurde, wann letztes Update vorlag. Man kann auch einige Ablehngründe fürs Update ablesen (z.B. zu viele Anmeldungen in kurze Zeit, etc.). Diese Informationen sind leider kaum dokumentiert und werden auch im AVM-WebIF nicht weitergegeben, weil AVM wahrscheinlich von einem blöden Kunden ausgeht. Man kann aber wenigstens diese Datei analysieren und daraus Einiges erkennen.
Wenn ihr nach ddns und 2.PVC sucht, werdet ihr bestimmt unsere damalige Diskussion finden. Dort in dem Thread sind auch einige Informationen zu finden, die wir damals herausgefunden hatten.

MfG

 

[RalfFriedl]

Ich habe auch nichts gegen die AVM Client. Es kann genauso gut sein, daß DynDNS selbst das Problem ist. Wenn Router mehrere Hersteller Probleme damit haben, macht das diese Erklärung sogar wahrscheinlicher.

Es ändert aber nichts daran, daß aus unbekannten Gründen ein Update manchmal nicht funktioniert und ein manuelles Update dann hilft.

Das macht es nicht falsch, dem ursprünglichen Problem auf den Grund zu gehen. Wenn diese Datei mit dem Update-Status brauchbare Informationen liefert, dann umso besser.

 

[hermann72pb]

Nochmal zur Information für diejenigen, die es interessiert...
Die angesprochene Diskussion hat hier statt gefunden. Ralf, du warst da übrigens auch an der Diskussion aktiv beteiligt. Deswegen fragte ich dich, ob du dich erinnerst.
Die Datei, von der ich gesprochen hatte:

root@fritz:/var/mod/root# cat /tmp/ddnsstat.txt
5 330 domain1.dnsserver.tld
5 331 domain2.dnsserver.tld

5 heißt, wenn ich weiß, dass alles OK ist. 330 und 331 geben in irgendeiner Form die Auskunft darüber, wann die letzte Aktualisierung statt gefunden hat. Entweder in Minuten, Sekunden oder was auch immer. Typischerweise ist diese Zahl etwas höher. Ich hatte aber meine Box vor etwa einer Stunde reconnected, weil ich sie upgedatet hatte. Die Zwangstrennung lag irgendwann mal in der Nacht oder in den frühen Morgenstunden.
Der Unterschied zwischen beiden ist dadurch zu erklären, dass 1.PVC und 2.PVC typischerweise einen geringen Zeitversatz im Verbindungsaufbau haben.

Zu dieser Zahl 5 kann man sich auf DynDNS informieren. Irgendwo gibt es da eine kurze Doku zu, wo sie ihre Requests definieren. Wenn ich mich richtig erinnere, sind diese Zeilen in der Log-Datei mehr oder weniger das, was von dem ddns-Server kommt. Ich glaube, AVM filtert da nicht so viel.

MfG

 

[RalfFriedl]

Ich erinnere mich dunkel, aber da ging es mehr um das Ändern von Parametern und die 2. PVC und weniger darum, herauszufinden, warum ein Update nicht funktioniert.

Aber es wäre sicher interessant, die Status-Meldungen nach einem nicht funktionierenden Update zu prüfen.

 

[hermann72pb]

Irgendwo hatte ich mich damit auseinander gesetzt, was all diese Codes heißen. Und ich meine sogar es damals halbwegs verstanden zu haben. Allerdings finde ich es nicht mehr, WO ich darüber in IPPF diskutiert hatte. Wobei ich auch nicht weiß, ob ich es denn nicht doch nur für mich behalten hatte.
Die Infos über die Antworten von DynDNS findet man z.B. hier. Allerdings fand ich dort jetzt keine direkte Zuordnung zu 0 bis 5, die AVM im Log als Status speichert.
Konkret zu 5: Es kann durchaus sein, dass 5 keine vom DDNS-Klient erkannte Antwort bedeutet. Ich nutze nämlich "custom update", weil ich meinen eigenen DDNS-Server benutze, der eine etwas andere Syntax hat, als DynDNS. Ich hatte diesbezüglich schon einige Unterschiede im AVM-WebIF zum "echten" DynDNS gesehen. Bei "custom"-Einstellung scheint AVM die Rückgabewerte nicht besonders auszuwerten. Das Updaten an sich funktioniert bei mir trotzdem. Daher stört es mich nicht besonders.

MfG

 

[billygeen]

Hab die Logfiles nochmal durchgesehen, der Fehler tritt nur auf wenn die Box nach dem Reconnect wieder die gleiche IP bekommt. Dann schlägt die Registrierung bei dyndns fehl, ein weiterer Reconnect beschafft dann eine andere IP und die registrierung ist erfolgreich!

 

[sf3978]

..., der Fehler tritt nur auf wenn die Box nach dem Reconnect wieder die gleiche IP bekommt. Dann schlägt die Registrierung bei dyndns fehl, ...

Warum ist bei dir eine Registrierung bei dyndns erforderlich, wenn sich die öffentliche (externe) IP-Adresse nicht geändert hat?

 

[hermann72pb]

Genau das frage ich mich auch. Und selbst, wenn die Registrierung bei DynDNS fehl schlägt, bleibt doch bei dem DynDNS-Namenserver die alte Zuweisung noch aktiv? Der DNS-Eintrag wird sich durch diese Fehlanmeldung erstmal nicht ändern! Sprich, du kannst deine Box ohne Probleme von Außen erreichen!

Das man ab und zu die gleiche IP wieder bekommt, das habe ich schon öfter erlebt. In bestimmten IP-Segmenten von Telefonica (auf die mein 1und1-Provider und viele anderen Provider auch setzen) passiert das ziemlich oft. Das führt aber doch nicht dazu, dass man von Außen nicht erreichbar ist.

MfG

 

[sf3978]

... Und selbst, wenn die Registrierung bei DynDNS fehl schlägt, bleibt doch bei dem DynDNS-Namenserver die alte Zuweisung noch aktiv? Der DNS-Eintrag wird sich durch diese Fehlanmeldung erstmal nicht ändern! Sprich, du kannst deine Box ohne Probleme von Außen erreichen!
...

Je nach dem ob der dyndns-Provider von der (forcierten) "Fehlregistrierung" was mitbekommen/gemerkt hat. Manche dyndns-Provider blocken sofort oder später den Account.

 

[hermann72pb]

Wenn er bei DynDNS.org ist (was ist stark annehme), dann ist das typische Verhalten so, wie ich es annehme. Damit es zu einer Accountblockade kommt, muss schon viel passieren. Ein oder zwei Fehlanmeldeversuche führen mit Sicherheit nicht dazu. Vor allem, es sind auch keine Fehlversuche mit einem falschen Passwort oder Ähnlichem, sondern lediglich Versuche die gleiche IP kund zu geben. Wenn DynDNS darauf so empfindlich reagieren würde, wie du annimmst, sf3978, würden sie alle ihre Kunden verscheuchen. Denn es würde dafür ausreichen, dass du 2-3 Update-Klients in deinem privaten Subnetz hast, die die gleiche externe IP versuchen werden in unregelmäßigen Abständen upzudaten. So ein Missuse kann ich mir in der Zeit der heutigen Verbreitung von DynDNS-Klients ganz gut vorstellen. Vor allem, nicht alle Endkunden wissen, dass man nur einen Klient nutzen sollte.

Übrigens, kann es sein billygeen, dass bei dir in deinem privaten Netzwerk noch ein DynDNS-Klient irgendwo lauscht und dir in die Suppe reinspuckt? Z.B. zweite Box, einer der vielen Rechner, irgendeine Multimediabox, NAS oder Ähnliches? Geh mal bitte auf deine Account-Seite bei DynDNS. Dort steht wenigstens WANN dein Klient sich zum letzten Mal bei DynDNS upgedatet hat. Vergleiche bitte diese Zeit akribisch mit deinen Logs auf der Fritz!Box. Wenn du da diverse Unterschiede erkennst, lauscht da noch jemand bzw. etwas an deinem Account.

MfG

 

[sf3978]

Wenn er bei DynDNS.org ist (was ist stark annehme), dann ist das typische Verhalten so, wie ich es annehme. Damit es zu einer Accountblockade kommt, muss schon viel passieren. Ein oder zwei Fehlanmeldeversuche führen mit Sicherheit nicht dazu. Vor allem, es sind auch keine Fehlversuche mit einem falschen Passwort oder Ähnlichem, sondern lediglich Versuche die gleiche IP kund zu geben. Wenn DynDNS darauf so empfindlich reagieren würde, wie du annimmst, sf3978, würden sie alle ihre Kunden verscheuchen.

Ich habe nichts angenommen. Ich habe nur gefragt und neutral/allgemein geantwortet. Ich sehe die Sache positiv und nicht negativ. Mein Account bei dyndns wurde schon mal blockiert, und das nicht wegen falschem Passwort, sondern weil die gleiche IP-Adresse (ich habe Kabelanschluss) versucht (... mit Sicherheit mehr als 2x) worden ist zu updaten. Ich bin aber immer noch bei DynDNS, aber mit einem anderen update-Client.

Denn es würde dafür ausreichen, dass du 2-3 Update-Klients in deinem privaten Subnetz hast, die die gleiche externe IP versuchen werden in unregelmäßigen Abständen upzudaten. So ein Missuse kann ich mir in der Zeit der heutigen Verbreitung von DynDNS-Klients ganz gut vorstellen. Vor allem, nicht alle Endkunden wissen, dass man nur einen Klient nutzen sollte.

Ich benutze seit einiger Zeit 2 Update-Clients auf der Box und habe überhaupt keine Probleme mit den DynDNS-Provider. An manchen WE startet meine Box auch mehr als 10 mal pro Tag, mit der gleichen IP-Adresse. Wer Freetz auf der Box hat, kann evtl. Probleme mit den DynDns-Provider sicher lösen/beheben:

Mar 19 14:00:17 fritz daemon.info opendd[4629]: -- running OpenDD 0.7.9 in normal mode
Mar 19 14:00:17 fritz daemon.info opendd[4629]: dyndns() : established external or dummy ip address : ##.#.2##.##
Mar 19 14:00:17 fritz daemon.info opendd[4629]: main() : getting my ip address : ##.#.2##.##
Mar 19 14:00:17 fritz daemon.info opendd[4629]: getdyndnshostnames() : [COLOR="red"]no need to update[/COLOR] 1-########## with ##.#.2##.##
Mar 19 14:00:17 fritz daemon.info opendd[4629]: getdyndnshostnames() :[COLOR="red"] no need to update[/COLOR] 2-########## with ##.#.2##.##
Mar 19 14:00:18 fritz daemon.info opendd[4629]: getdyndnshostnames() : [COLOR="red"]no need to update[/COLOR] 3-########## with ##.#.2##.##
Mar 19 14:00:18 fritz daemon.info opendd[4629]: getdyndnshostnames() : [COLOR="red"]no need to update [/COLOR]4-########## with ##.#.2##.##
Mar 19 14:00:18 fritz daemon.err opendd[4629]: main() : [COLOR="red"][B]No hostname(s) to update[/B][/COLOR]

 

[hermann72pb]

(... mit Sicherheit mehr als 2x)

Das müssten bei dir deutlich mehr als 2 Versuche gewesen zu sein. Ich hatte auch schon eine Sperre vor ewigen Zeiten erleben dürfen, da gab es aber sehr viele Anmeldungen mit der gleichen IP.

Was ich mittlerweile bei billygeen eher vermute, dass sein DynDNS-Account entweder dadurch temporär blockiert wird (das machen sie -glaube ich- auch), dass irgendein Klient (sei es Windows, oder irgendein Gerätchen im lokalen Netz) STÄNDIG oder wenigstens öfter als nötig versucht sich bei DynDNS anzumelden, oder es wird sogar von irgendwo anders durchgeführt. Letzteres kann schon mal vorkommen, wenn man seine alte Fritz!Box an seine Eltern/Verwandte oder wen auch immer weitergibt und vergisst die Anmeldedaten zu löschen. Anstatt einer Fritz!Box kann es auch was anderes sein.

Das was du beschreibst, sf3978, mit deinen 2 Klients ist völlig legitim. Denn alle deinen Klients laufen nicht amok und melden die IP an DynDNS nur wenn es wirklich nötig ist. Wenn da die Anmeldung 2 oder 3 Mal nacheinander kommt, wird es wahrscheinlich noch von DynDNS toleriert. Und bei 10 Anmeldungen pro Tag liegen auch längere Pausen zwischen den Anmeldungen. Wie ich schon oben gesagt hatte, erinnere ich mich dunkel an so eine Sperrzeit zwischen zwei Anmeldeversuchen von 5 Minuten.
Die Veränderungen seitens DynDNS vor 2-3 Jahren gingen genau in die Richtung, solche brute-force-Attacken zu blocken. Sprich, wenn man innerhalb einer sehr kurzen Zeit sich zu oft anmeldet. Wobei "sehr kurze Zeit" wahrscheinlich bei 2-3 Minuten maximal liegen dürfte und "zu oft" bestimmt erst ab 4-5 Versuchen innerhalb dieser Zeit anfängt.
Die Sperrzeit danach dürfte auch bei 24 Stunden oder ähnlich liegen (wenn man in die erste Falle gerät). Dass sie komplett den Account sperren, glaube ich kaum, kann aber in bestimmt härteren Fällen vielleicht doch vorkommen.

MfG