Warum funktioniert DYNDNS machmal nicht?

[AndreasMarx]

Hallo nochmal,

WAN-Action-Skripte verhalten sich manchmal merkwürdig. Habe 2 Effekte beobachtet (1821 Annex B, 4.02.0003):

1. Locks (Sperre in Kommunikation/Allgemein/Aktionstabelle) merkt sich LCOS pro Zeile der Aktionstabelle. Die Locks bleiben auch bei Änderung der Tabelle aktiv und ich habe keine Möglichkeit gefunden sie zu löschen. Das ist insbesondere schade, wenn man ein DYNDNS per Assistent eingerichtet hat (legt eine Sperre von 25 Tagen auf die erste Zeile der Aktionstabelle) und dann anfängt das Skript zu verfeinern.

2. Skripte mit repeat werden zwar recht zuverlässig beendet, wenn die WAN-Verbindung beendet wird, aber nur etwa jedes zweite mal auch wieder gestartet, wenn die Vebindung per sofortigem Reconnect wieder aufgebaut wird. Der Effekt ist in /status/WAN-statistics/action-statistics gut zu beobachten. Wenn die Verbindung über den LAN-Monitor beendet wird scheint es etwas häufiger zu funktionieren. Wenn die Verbindung per Cron-Job beendet wird fast nie.

Viele Grüße,

A.M.

[LoUiS]

1. Locks (Sperre in Kommunikation/Allgemein/Aktionstabelle) merkt sich LCOS pro Zeile der Aktionstabelle. Die Locks bleiben auch bei Änderung der Tabelle aktiv und ich habe keine Möglichkeit gefunden sie zu löschen. Das ist insbesondere schade, wenn man ein DYNDNS per Assistent eingerichtet hat (legt eine Sperre von 25 Tagen auf die erste Zeile der Aktionstabelle) und dann anfängt das Skript zu verfeinern.

Die kann man nicht loeschen, ausser wenn man den Router kalt startet oder aus und einschaltet, das Verhalten ist auch so gewollt.

2. Skripte mit repeat werden zwar recht zuverlässig beendet, wenn die WAN-Verbindung beendet wird, aber nur etwa jedes zweite mal auch wieder gestartet, wenn die Vebindung per sofortigem Reconnect wieder aufgebaut wird. Der Effekt ist in /status/WAN-statistics/action-statistics gut zu beobachten. Wenn die Verbindung über den LAN-Monitor beendet wird scheint es etwas häufiger zu funktionieren. Wenn die Verbindung per Cron-Job beendet wird fast nie.

Das kann ich hier nicht nachvollziehen, ich habe ca. 20 DynDNS Provider im LANCOM eingerichtet und alle werden jede Nacht um 04:59 Uhr upgedated.
Wenn Du von "verfeinern" sprichst machst Du was genau?


Ciao
LoUiS

[AndreasMarx]

Hallo LoUiS,

bevor ich wußte, daß man dem Teil unter /status/WAN-statistics/action-statistics auf die Finger schauen kann hab ich mir durch das Einfügen von mailto: Befehlen beholfen. Das war natürlich fatal, weil beim nächsten Versuch die Locks des vorherigen Versuchs noch da waren und auf einmal für ganz andere Befehle galten. Ich fänd's gut, wenns da eine Action Reset-Lock-Table gäbe,

Das mit dem Start der Action-Skripte beobachte ich noch. Hab noch keine Idee wie ich dem auf die Schliche komme. Zur Zeit kann ich nur nach jedem Disconnect die Action-Statistics auslesen und mich wundern, daß es manchmal halt nicht tut (nach Disconnect/Reconnect stundenlang kein einziger Eintrag in Action-Statistics, obwohl Einträge in Action-Table noch da).

Hast Du da einen Tipp?

Andreas

[AndreasMarx]

Heute nach wieder pünktlich um 04:30 disonnect, diesmal lief das Action-Skript weiter, hat aber offensichtlich %a noch in die alte IP aufgelöst. Es hat nämlich brav alle 5 Minuten per dnscheck nachgeschaut, ist dann aber direkt zu der repeat-Zeile gehüpft.

Ich hab daraufhin heute morgen erst mal einen Disconnect über den LAN-Monitor gemacht (Reconnect über Haltezeit 9999 sec) --- mit dem Erfolg, daß dann erst mal kein Skript mehr lief.

Dann ein Disconnect über setup/wan/manual/disconnect --- kein Erfolg, immer noch kein Eintrag in Action-Statistics.

Ein weiterer Disconnect über die Telnet-Konsole hats dann gebracht: Skript lief wieder und hat auch gleich DNYDNS aktualisiert. 5 Minuten später hat er dann ganz korrekt festgestellt, daß die IP aktuell ist und geht seither alle 5 Minuten das Skript durch.

Andreas

[AndreasMarx]

Tut mir leid, ich hab' da echt ein Problem...

Ich habe jetzt mal ca 1 Stunde lang jede Minute per cron einen disconnect gemacht. Die Action-Table hat keine repeat-Zeile mehr, d.h. das Skript ist jeweils nach einem Befehl beendet. Es gibt keine Locks mehr (Cold-Boot).

Das Action-Skript wird in mehr als 50% der Fälle nicht gestartet.

Aus den Fällen, in denen es funktioniert hat schließe ich, daß mein LANCOM 1821 4.02.003 nur ca. alle 60 Sekunden prüft, ob ein Action-Skript anlaufen muß. Wenn in diesen 60 Sekunden die Verbindung wieder da ist, dann merkt der Router anscheinend nicht, daß was zu tun ist (ist natürlich erst mal nur eine Vermutung).

Ein Endlos-Skript mit einem repeat als letzter Zeile (wie es etwa der Wizard einrichtet) müßte in einem solchen Fall ja eigentlich helfen --- es würde einfach weiterlaufen. Leider scheitert auch das manchmal, d.h. das laufende Skript wird beendet und beim Reconnect kein neues gestartet.

In mindestens einem Fall habe ich auch beobachtet, daß ein weiterlaufendes Skript %a noch in die IP der alten Verbindung aufgelöst hat.

Jetzt will ich dazu übergehen jede Nacht
1. den Reconnect per set /set/wan/dsl/dsl-out-t-online 0 abzuschalten
2. die Default-Route zu deaktivieren
3. die Verbindung mit do /set/wan/man/disconnect dsl-out-t-online abzubauen
4. Nach 5 Minuten den Reconnect wieder einzuschalten
5. Die Default-Route wieder zu aktivieren

Wenn das nicht hilft, dann bleibt nur noch ein nächtlicher Cold-Boot. Das will ich aber eigentlich nicht.

Ich kann mir eigentlich gar nicht vorstellen, daß nur ich dieses Problem habe???

Viele Grüße,
Andreas

[AndreasMarx]

OK, hier ist nun der Bug: Manchmal schleicht sich offensichtlich ein zusätzliches Zeichen in den Event-Namen ein. In diesem Fall ein "Ã".

Code: Alles auswählen

root@gw-marx:/Status/WAN-statistics/Action-Statistics/Action-Table
> do /o/man/disconnect dsl-out-t-online
OK: Action Disconnect started

root@gw-marx:/Status/WAN-statistics/Action-Statistics/Action-Table
>
[CONNACT] 2005/02/16 23:43:16,280
ConnAct: Got trigger for event DSL-OUT-T-ONLINE/*/BROKEN


[CONNACT] 2005/02/16 23:43:18,900
ConnAct: Got trigger for event DSL-OUT-T-ONLINEÃ/*/ESTABLISH

Kann ich selbst einen Bug aufmachen oder übernehmen das die Moderatoren?

Für eine Tipp bez. Workaround (z.B. "tritt nur bei Connection-Name länger 8 Zeichen auf") wäre ich dankbar.

Viele Grüße,

Andreas

[alf29]

Moin,

Da ist in der Tat ein Fehler, den ich (hoffentlich) gerade
'erschossen' habe. Er tritt nur bei Verbindungsnamen
mit exakt 16 Zeichen Länge (Maximallänge) auf - so weit
brauchst Du als Workaround also nicht zu kürzen

Gruß Alfred

[AndreasMarx]

Hallo Alfred,

hab' den Verbindungsnamen mal gekürzt und das eine Weile beobachtet: Funktioniert seitdem einwandfrei

Vielen Dank für den Tipp und ein schönes Wo-Ende,

Andreas