DynDNS.org Update Scripte ohne DNS-Check von LoUiS

[Jirka]

EDIT
Dieser Thread ist mittlerweile etwas unübersichtlich geworden, wer die Quintessenz sucht, findet sie hier (Link zum Eintrag im FAQ-Bereich des LANCOM-Forums).
EDIT

Hallo an alle,

im FAQ-Bereich findet sich ein DynDNS.org Update Script ohne DNS-Check von LoUiS. Ich kann das irgendwie nicht so recht nachvollziehen oder bin der Meinung, dass da ein Fehler drin ist. Die Frage geht also insbesondere an LoUiS

Irgendwie führen alle Auswertungen auf die "Fehlgeschlagen-Zeile" - das soll bei Zeile 1 (enspricht Excel-Zeile 3) bestimmt nicht so sein. Man kann sich das auf beiliegender Excel-Tabelle mal übersichtlich anschauen.

Viele Grüße,
Jirka

Nachfolgender Download nur zum nachvollziehen/zur Dokumentation.

[LoUiS]

Hi,

ja da ist die Sprungmarke um eins zu hoch, dort muss 10 stehen und nicht 11. Habe ich mich vermutlich vertippt. Das kann man aber aus dem Selfhost Script ableiten, da ist es richtig, hat nur weniger Bedingungen.

P.S.: Das kann man durch simples zaehlen auch ohne Exel Viren Schleudern sehen.


Ciao
LoUiS

[Jirka]

Hi LoUiS,

vielen Dank erst mal für die Info.

> Das kann man aber aus dem Selfhost Script ableiten

Kann sein, das habe ich mir aber nicht angeschaut. Vielleicht ist Selfhost sogar besser als DynDNS.org, aber ich kannte es nicht und die Downloadhäufigkeit Deiner Scripte war bei DynDNS auch höher. Nun habe ich mal reingeschaut, da findet man ja schon nach 3 Klicks Dein Script Aber ich will doch erst mal bei DynDNS.org bleiben.

> Das kann man durch simples zaehlen auch ohne Exel Viren Schleudern sehen.

Also ich bin neulich nacht daran verzweifelt. Man muss ja erst mal wissen, was da ablaufen soll und dann ständig diese überlangen Zeilen (mein Bildschirm hat leider nur 1024x768 [ok - mein Problem]) und dazu dann noch Leerzeilen und dann keine Striche zwischen den Zeilen, das war irgendwie grausam. Und da hab ich halt kurzerhand Excel zur Hilfe genommen, da brauchte ich dann nicht mehr Zeilen zählen. Na ja - und wenn weißt Du doch von wem der Virus kommt

So, zurück zum Thema. In Zeile 8 Deines Scripts steht abuse %a. Ich weiß nicht, ob das %a da tatsächlich hingehört, hiernach http://www.dyndns.com/developers/specs/return.html wohl eher nicht.

Um die Übersichtlichkeit zu erhöhen könntest Du auch noch in der Zeile der Spaltenköpfe vor dem Wort Gegenstelle ein Leerzeichen streichen.

Und wenn jetzt Zeile 1 als Rückgabewert 1 hat und damit die Repeat-Zeile angesprungen wird, und da dann wieder 4 (warum 4?) Zeilen weiter gesprungen wird, und von da an geht die Schleife da im Kreis, dann verstehe ich das irgendwie immer noch nicht.
Und wenn meine Verbindung innerhalb von 300 Sekunden zusammenbricht und daraufhin neu aufgebaut wird, dann wird Zeile 2 nicht ausgeführt, weil in der Sperrzeit, dann ist StillAlive trotzdem auf 1 und dann geht es nicht weiter.

Oder was liefert lastresult? Und in welche Zeile wird von der Repeat-Zeile aus gesprungen? Also ich vermute ja Denkfehler bei mir, und dadurch kann ich das nicht nachvollziehen.

Vielen Dank und viele Grüße,
Jirka

[LoUiS]

Hi,

So, zurück zum Thema. In Zeile 8 Deines Scripts steht abuse %a. Ich weiß nicht, ob das %a da tatsächlich hingehört, hiernach http://www.dyndns.com/developers/specs/return.html wohl eher nicht.

zu der Zeit als ich die Scripte mal gemacht hatte, meine ich das DynDNS unter "Abuse" auch die WAN-IP-Adresse des Absenders angegeben hat, deshalb das %a. Wenn dies sich bei DynDNS geaendert hat, kann man das "%a" natuerlich weglassen und generell bei einem "Abuse" das Script abbrechen lassen.

Und wenn jetzt Zeile 1 als Rückgabewert 1 hat und damit die Repeat-Zeile angesprungen wird, und da dann wieder 4 (warum 4?) Zeilen weiter gesprungen wird, und von da an geht die Schleife da im Kreis, dann verstehe ich das irgendwie immer noch nicht.

Das "repeat:300" zieht einen Timer von 300 Sekunden auf, der dann nach eben den 300 Sekunden das Script neu startet. Der Sprung 4 Zeilen weiter springt dann aus dem Script heraus und beendet die aktuelle Abarbeitung somit. Die aber ja dann 300 Sekunden spaeter wieder durch den Timer neu gestartet wird.

Und wenn meine Verbindung innerhalb von 300 Sekunden zusammenbricht und daraufhin neu aufgebaut wird, dann wird Zeile 2 nicht ausgeführt, weil in der Sperrzeit, dann ist StillAlive trotzdem auf 1 und dann geht es nicht weiter.

Nein, die Variable "Stillalive" ist nach trennen der Verbindung "0", da im Script die letzte Zeile vorhanden ist, die bei Abbruch oder Trennung der Verbindung die Variable auf "0" setzt.

Ja name.dyndns.org T-Online 0 Abbau exec:unsetenv StillAlive

Natuerlich wird dann in der Sperrzeit nicht aktualisiert, aber dies habe ich bewusst so gemacht, damit das Script nicht beim Provider "hammern" kann, wenn die Verbindung oefters schnell hintereinander abbricht und wieder aufgebaut wird. Dann stimmt eh etwas Anderes nicht und man muss nach dem LANCOM schauen weil man mit der Verbindung nicht arbeiten kann.

Oder was liefert lastresult? Und in welche Zeile wird von der Repeat-Zeile aus gesprungen? Also ich vermute ja Denkfehler bei mir, und dadurch kann ich das nicht nachvollziehen.

"lastresult" liefert das Ergebnis des letzten Updatevorgang, oder genauer der letzten Aktion, die das LANCOM in diesem Script durchgefuehrt hat. Dies kann man im "trace # connact" auch nachvollziehen, oder halt im Status unter "/Status/WAN/Actions/Action-Table" nachschauen.


Ciao
LoUiS

[Jirka]

Hi LoUiS,

vielen Dank für die lange Antwort.

> kann man das "%a" natuerlich weglassen und generell bei einem "Abuse" das Script abbrechen lassen.

Ich denke damit fährt man besser.

> "repeat:300" ... Der Sprung 4 Zeilen weiter springt dann aus dem Script heraus und beendet die aktuelle Abarbeitung somit.

Aha. Dann würde ein skipiftrue=3 also gleiches bewirken. Weil ich schon überlegt hatte, ob er dann vom Anfang des Scripts auch noch ein paar Zeilen überspringt ... Wahrscheinlich würde auch skipiftrue=2 funktionieren, denn die Abbau-Zeile sollte ja in dem Moment nicht ausgeführt werden. Schön.

Aber noch mal: Wenn jetzt Zeile 1 des Scriptes 1 liefert, dann entsteht doch eine Schleife, die nichts aber auch gar nichts sinnvolles mehr macht. Es wird immer nur von Zeile 1 in Zeile 12 gesprungen, dann wird der Timer gestartet, der 300 Sekunden später wieder Zeile 1 aufruft usw. Mir ist irgendwie unklar, wofür das gut sein soll.

> Nein, die Variable "Stillalive" ist nach trennen der Verbindung "0", da im Script die letzte Zeile vorhanden ist, die bei Abbruch oder Trennung der Verbindung die Variable auf "0" setzt.

Gut. Und dann wird die Verbindung neu aufgebaut. Zeile 1 erstellt die Variable, es geht in Zeile 2 weiter. Zeile 2 wird nicht ausgeführt, weil in der Sperrzeit. Zeile 3, ja da ist jetzt die Frage was liefert lastresult: entweder nichts aus Zeile 1 oder gesperrt-Info aus Zeile 2, auf alle Fälle wohl nichts mit nochg %a, somit geht es in Zeile 4 weiter. Das geht jetzt so weiter bis Zeile 11, dort wird StillAlive auf 1 gesetzt. Dann geht's in Zeile 12 zur Repeat-Schleife und vorläufigen Abbruch. Nach 300 Sekunden landen wir in Zeile 1 von wo aus in Zeile 12 gesprungen wird, weil StillAlive ja jetzt auf 1 ist. So geht das dann weiter, aber es erfolgt keine Aktualisierung, oder siehst Du das anders?

Ciao und herzlichen Dank,
Jirka

[LoUiS]

Aha. Dann würde ein skipiftrue=3 also gleiches bewirken. Weil ich schon überlegt hatte, ob er dann vom Anfang des Scripts auch noch ein paar Zeilen überspringt ... Wahrscheinlich würde auch skipiftrue=2 funktionieren, denn die Abbau-Zeile sollte ja in dem Moment nicht ausgeführt werden. Schön.

Ob dies so funktioniert kann ich nicht beantworten, da ich es nicht getestet habe. Es muss zumindest HINTER das eigentliche Script gesprungen werden, also mindestens skipiftrue=3 im Beispiel.

Aber noch mal: Wenn jetzt Zeile 1 des Scriptes 1 liefert, dann entsteht doch eine Schleife, die nichts aber auch gar nichts sinnvolles mehr macht. Es wird immer nur von Zeile 1 in Zeile 12 gesprungen, dann wird der Timer gestartet, der 300 Sekunden später wieder Zeile 1 aufruft usw. Mir ist irgendwie unklar, wofür das gut sein soll.

Es sollt urspruenglich das Script immer wieder durchlaufen werden (wie beim default DynDNS Script mit dem DNS Check auch), um zu schauen ob die WAN IP sich geaendert hat und ein Update gemacht werden muss. Bei naeherer Betrachtung hast Du aber recht, es muss hier keine Schleife sein, da das Update durch den erneuten Verbindungsaufbau eh getriggert wird.

Gut. Und dann wird die Verbindung neu aufgebaut. Zeile 1 erstellt die Variable, es geht in Zeile 2 weiter. Zeile 2 wird nicht ausgeführt, weil in der Sperrzeit. Zeile 3, ja da ist jetzt die Frage was liefert lastresult: entweder nichts aus Zeile 1 oder gesperrt-Info aus Zeile 2, auf alle Fälle wohl nichts mit nochg %a, somit geht es in Zeile 4 weiter. Das geht jetzt so weiter bis Zeile 11, dort wird StillAlive auf 1 gesetzt. Dann geht's in Zeile 12 zur Repeat-Schleife und vorläufigen Abbruch. Nach 300 Sekunden landen wir in Zeile 1 von wo aus in Zeile 12 gesprungen wird, weil StillAlive ja jetzt auf 1 ist. So geht das dann weiter, aber es erfolgt keine Aktualisierung, oder siehst Du das anders?

Ja, auch hier gebe ich Dir Recht, dass dies passiert wenn die Sperrzeit greift. Dieser Fall sollte nicht eintreten, da die Sperrzeit und der Repeat beide 300 Sekunden sind und somit gleichzeitig ablaufen. Die IP wird dann wirklich nicht aktualisiert, wenn innerhalb der 5 Minuten mehrfach Updates gemacht werden.

Ich hab mir diese Punkte noch mal durch den Kopf gehen lassen und das Script in Deinem Exel entsprechend geaendert. Nun ist keine Schleife mehr drin, die Sperrzeit ist raus.
Als Enviroment-Variable wir die WAN IP verwendet, die beim Start des Script mit der aktuellen WAN IP verglichen wird. Sind die beiden Adressen gleich, wird eine Fehler Mail geschickt und das Script beendet (Zeile 15). Sind die IPs unterschiedlich, wird ein Update durchgefuehrt (Zeile 4) und die verschiedenen Fehlermoeglichkeiten werden mit "lastresult" geprueft (Zeile 4 - 12). Im Fehlerfall wieder eine Email gesendet (Zeile 14) und das Script beenden. War alles OK und kein Fehler, wird die aktuelle WAN IP in der Enviroment-Variable gespeichert (Zeile 13) und das Script beendet. Sollte nun die Verbindung abgebaut und wieder aufgebaut werden, gehts wieder von Vorne los und die letzte gespeicherte IP mit der aktuellen verglichen ...


Ciao
LoUiS

[Jirka]

Hallo LoUiS,

erst mal besten Dank für Deine Überarbeitung. Gestern bin ich leider nicht dazu gekommen mir das anzuschauen.

> Nun ist keine Schleife mehr drin, die Sperrzeit ist raus.

Irgendwo in meinen Augen echt sinnvoll.

> Als Enviroment-Variable wird die WAN IP verwendet

Genialer Gedanke. Das hatte ich bei meiner letzten Unterhaltung mit Backslash auch schon als sinnvoll erachtet.

> Sind die beiden Adressen gleich, wird eine Fehler Mail geschickt und das Script beendet (Zeile 15).

Super, die Fehler-E-Mail zu senden ist sicher vom jeweiligen Anwendungsfall abhänging. Wenn man bedenkt, dass es eben auch Situationen gibt, wo nach Verbindungsaufbau wieder die gleiche IP zugewiesen wird, dann wäre das ja genau der Fall, den wir damit ja nicht mit einem "Fehler" enden lassen wollen.

Der Rest gefällt mir sehr gut. Neben mir liegt noch ein Zettel mit einem Gedankengang von mir, den werde ich noch mal zu Ende führen und dann melde ich mich an dieser Stelle wieder.

Viele Grüße,
Jirka

[LoUiS]

> Als Enviroment-Variable wird die WAN IP verwendet

Genialer Gedanke. Das hatte ich bei meiner letzten Unterhaltung mit Backslash auch schon als sinnvoll erachtet.

Jo, haette ich aber auch schon vorher dran denken koennen, dies habe ich im Skript fuer "dynacces.de" schon so verwendet. Es ist nur schon was laenger her, das ich dieses Script erstellt hatte.

Super, die Fehler-E-Mail zu senden ist sicher vom jeweiligen Anwendungsfall abhänging. Wenn man bedenkt, dass es eben auch Situationen gibt, wo nach Verbindungsaufbau wieder die gleiche IP zugewiesen wird, dann wäre das ja genau der Fall, den wir damit ja nicht mit einem "Fehler" enden lassen wollen.

Ja das kann man ja jetzt noch individuell, ggf. fuer jeden Fehler separat, anpassen.

Der Rest gefällt mir sehr gut. Neben mir liegt noch ein Zettel mit einem Gedankengang von mir, den werde ich noch mal zu Ende führen und dann melde ich mich an dieser Stelle wieder.

Immer her damit, evtl. ersetzen wird dann mit diesem fertigen Script das aktuelle Script aus dem LANconfig Assistenten.


Ciao
LoUiS

[Jirka]

Hi LoUiS,

noch mal eine Frage, kriege ich den Wert von lastresult: oder den Wert einer Variablen (wie z. B. StillAlive) in eine E-Mail? Wäre ja sicher schön auch in der E-Mail zu erfahren, was für ein Fehler da tatsächlich aufgetreten ist. Aber ich glaube das geht nicht, oder? Bleibt dann nur der Blick in die Aktions-Tabelle.

Viele Grüße,
Jirka

[Jirka]

Hallo an alle, hallo LoUiS,

vor einem Monat hatte ich mal angefangen mir über das DynDNS.org-Update Script im LANCOM Gedanken zu machen (siehe http://www.lancom-forum.de/ptopic,26909.html#26909). So recht schön fand ich das nicht, in Kombination mit ADSL-Verbindungsabbrüchen kam der Wunsch nach einem besseren Script auf. Dann hatte ich mir das Script von LoUiS angeschaut, was einen anderen, besseren Ansatz hat, da haben wir dann noch etwas drüber diskutiert (siehe dieser Thread), LoUiS hat es überarbeitet und ich fand es dann schon sehr schön, aber noch verbesserbar. Und genau das habe ich jetzt versucht, also auf der Grundlage des Scriptes von LoUiS ein verbessertes Script zu schreiben. Und das will ich Euch jetzt hier endlich präsentieren.

In gewisser Weise sind einem in der Aktions-Tabelle natürlich die Hände gebunden. Aus diesem Grund ist das Script hier natürlich auch nicht _das_ Optimum. Aber es ist das Optimum mit den derzeit zur Verfügung stehenden Mitteln (jedenfalls meiner Meinung nach).
Grundproblem ist, dass die bei DynDNS.org aktualisierte IP nirgendswo Kaltstart-resistent abgelegt werden kann, der LANCOM also nach einem Kaltstart nicht mehr weiß, welche IP als letztes erfolgreich an DynDNS.org übermittelt wurde. Das gleiche trifft für den Zeitpunkt der letzten erfolgreichen Aktualisierung zu.

Nun zu den Vorteilen dieses Scriptes gegenüber dem Standard-Script:
schnellere Aktualisierung bei kurzen Verbindungszeiten (z. B. bei ISDN-Wählverbindungen oder ADSL-Verbindungsproblemen)
höhere Zuverlässigkeit, keine doppelten Updates
bessere Benutzerinteraktion, Info-E-Mail bei Problemen
Abbruch des Scriptes bei einem Fehler in der Konfiguration, dadurch keine Sperrung (abuse) bei DynDNS.org
kein unnötiges Durchlaufen des Scriptes nach erfolgreicher Aktualisierung
insgesamt DynDNS.org-regelkonformer

Vorteile gegenüber dem letzten Script von LoUiS:
nochg (erfolgreiche Aktualisierung, aber IP hat sich nicht geändert) liefert keine Fehler-E-Mail mehr und führt beim nächsten Verbindungsaufbau nicht wieder zu einem doppelten Update
tritt ein anderer Fehler auf als die aufgeführten, dann erfolgt ein erneuter Update-Versuch
besseres Verhalten nach Kaltstart, keine doppelten Updates
insgesamt durch erneute Versuche bei Problemen zuverlässiger

Nachteile:
vielleicht ein paar Zeilen mehr in der Aktions-Tabelle ... (dafür aber weniger im Status)
bei dauerhaft gleicher IP erfolgt keine Aktualisierung mehr, d. h. DynDNS.org löst den Namen nach 35 Tagen ohne Aktualisierung (gilt nur für dyndns-Dienst, nicht statdns) nicht mehr auf, da kann man wenig gegen machen, das Script hat einfach keine Möglichkeit herauszufinden, wann das letzte Update durchgeführt wurde. Aber es gibt einen Workaround:

• Variante 1: Verbindung wird mind. alle 4 Tage neu aufgebaut, aber meist bekommt man die alte IP (die 4 Tage ergeben sich aus oben angegebenen 35 Tagen abzüglich der max. 31 Tage im Monat), dann trägt man in die Cron-Tabelle folgenden Eintrag ein:
  Aktiv, Echtzeit, Minuten 0, Stunden 0, Monatstage 1, Befehl: setenv IPnamedyndnsorg updaten (wichtig: Variablenname hier nur Beispiel!)
  Dann wird das Script beim ersten Verbindungsaufbau im Monat ein Update durchführen.
  
  Variante 2: Verbindung bleibt mitunter tagelang ohne Neuaufbau bestehen
  dann trägt man in die Cron-Tabelle den gleichen Eintrag wie bei Variante 1 ein:
  Aktiv, Echtzeit, Minuten 0, Stunden 0, Monatstage 1, Befehl: setenv IPnamedyndnsorg updaten
  Und ändert im Script folgende Zeilen wie folgt:
  Zeile 15: skipiftrue=6 in 7 ändern
  Zeile 16: skipiftrue=5 in 6 ändern
  Zeile 18: skipiftrue=3 in 4 ändern
  Zeile 20: skipiftrue=1 in 2 ändern
  Zeile 22 neu ergänzen: Ja name.dyndns.org T-Online 0 Aufbau repeat:86400
  Dann wird jeden Tag geschaut, ob wieder Monatsanfang ist und ggf. ein Update ausgeführt.

Alle diejenigen, die sich hier im Forum immer als Beta-Tester anbieten, können jetzt dieses Script testen!

Und ja, es gibt wieder eine Excel-Tabelle. Und nein, es ist kein Virus drin, auch keine VBA-Programmierung (obwohl ich es gerne gemacht hätte, aber Euch zu Liebe ...). Dafür werdet Ihr aber auch belohnt und bekommt nach wenigen Eintragungen ein fertiges Update-Script!!! Ich habe mir also größte Mühe gegeben! Wer wirklich kein Excel hat, schreib mir eine PN.

So, alle diejenigen, die denken das ist hier viel zu lesen ... im Script gibt es noch einige Dinge mehr zu lesen. Alle wichtigen Befehle und Ereignisse sind ausdokumentiert/-kommentiert. Damit sollten sich die meisten Fragen von selbst beantworten.

So und nun könnt Ihr Euch auf die Excel-Tabelle stürzen! Viel Spaß und Fragen oder Hinweise nehme ich natürlich gerne entgegen ...

Viele Grüße,
Jirka

EDIT: Hier steht eine aktualisierte Version der Excel-Tabelle bereit.

[SIN]

Hallo Jirka,

vielen Dank für dieses wirklich nette Script! War zwar am Anfang vom Umfang erschlagen, habe mich aber dennoch für die Nutzung entschieden.
Zwei Anmerkungen habe ich trotzdem:

• 1. Beim Benutzernamen und Passwort für dynDNS wird der erste Buchstabe bei Eingabe im Sheet immer gross geschrieben. Wenns einem nicht auffällt - wie mir zuerst - kommt es zu einem Fehler der

• 2. bei der Prüfung aller Eventualitäten nicht abgefangen wird. Ist wegen o.g. Fehler kein Logon bei DynDNS möglich, gibt es einen HTTP Fehler, der die Abfrage ins Leere laufen läßt.

• 3. Scheinbar ist der Member.Dynalias.org häufig nicht erreichbar/auflösbar. Dies führt zu einem action result "TCP connect error". Ergebnis: wie unter 2.

Ich denke, wenn dies noch raus ist, dann ists sehr gut!

Es wäre schön wenn LCS den Assistenten mal in diese Richtung anpassen/erweitern könnten.

Nochmals bedankt!

[COMCARGRU]

Tach,

wann haste das mit DynDNS getestet? Weil: http://www.heise.de/newsticker/meldung/86550

Gruß
COMCARGRU

[SIN]

Hallo,

seit Sonntag Nacht hats Probleme und auch bis heute gibt es Probleme über die Router Funtion DynDNS zu parametrieren (Action result: "TCP connect error". Die Aktualisierung über das Web-Frontend geht hingegen einwandfrei.

[froeschi62]

Guten Morgen,

bei mir läuft es seit gestern über den Router wieder tadellos. Ich hatte nur Samstag und Sonntag Probleme.

Gruß
Dietmar

[Jirka]

Hallo SIN,

vielen Dank erst mal für das Feedback.

1. Beim Benutzernamen und Passwort für dynDNS wird der erste Buchstabe bei Eingabe im Sheet immer gross geschrieben.

Das kann ich hier nicht nachvollziehen. Was für eine Excel-Version verwendest Du?
Ich benutze hier Excel 2003 und 2002 (XP), mit beiden Programmen tritt das bei mir nicht auf. Ich vermute, dass bei Dir (soweit ich weiß gilt das immer Office-weit) die AutoKorrektur-Optionen nicht dem entsprechen, wie Du es gerne hättest. Du findest die Einstellungen dafür unter Extras -> AutoKorrektur-Optionen. Wenn ich zum Beispiel als Benutzername montag und als Passwort dienstag eingebe, macht er daraus tatsächlich Montag und Dienstag, dies aber deswegen, weil unter besagten Optionen Wochentage immer großschreiben angehakt ist.
Passiert das bei Dir auch, wenn Du eine x-beliebige Zeichenfolge da eingibst?

2. bei der Prüfung aller Eventualitäten nicht abgefangen wird. Ist wegen o.g. Fehler kein Logon bei DynDNS möglich, gibt es einen HTTP Fehler, der die Abfrage ins Leere laufen läßt.

Das kann ich im Augenblick nicht prüfen, bei DynDNS.org scheint es tatsächlich erhebliche Probleme zu geben.
Beim Benutzernamen ist es vermutlich egal, ob da einzelne Buchstaben groß oder klein geschrieben werden. Beim Passwort wird das nicht so sein. Das Ergebnis dürfte dann ein falsches Passwort sein und somit im Fehlercode badauth enden, was dann zum verschicken einer Mail in Zeile 16 des Scripts führen sollte.

3. Scheinbar ist der Member.Dynalias.org häufig nicht erreichbar/auflösbar. Dies führt zu einem action result "TCP connect error". Ergebnis: wie unter 2.

Wie aufgrund der Heise-Meldung (Danke an COMCARGRU) zu sehen, scheint es tatsächlich Probleme mit members.dyndns.org zu geben, da dieser Server (über den die Updates laufen) wohl DDoS-Attacken ausgesetzt ist. Gerade aktuell liefert ein ConnAct-Trace bei mir als Rückgabewert für den Updateversuch: ConnAct: Action result is "TCP connect error". Das führt dann aber im Script in Zeile 15 zu einer Wiederholung in 600 Sekunden. Man könnte an dieser Stelle sicher auch die Möglichkeit des E-Mail-Versands vorsehen (mit entsprechenden Sperrzeiten), so dass man wenigstens per E-Mail über die externe WAN-IP informiert wird, aber ich fand das bisher nicht so wichtig, da Fehler dieser Art häufig nicht so lange anhalten. Ins Leere läuft das Script somit jedoch nicht, es startet regelmäßig aufs neue einen Updateversuch.

Die Aktualisierung über das Web-Frontend geht hingegen einwandfrei.

As of March 10th, 17:00 UTC, steps were taken to isolate our main website, www.dyndns.com, out of the line of fire of the attack. We're continuing to analyze and evaluate the situation, ...Quelle: http://www.dyndns.com/news/status/

Gegen solche Ausfälle von dyndns.org ist man sicher nie geschützt, da hilft nur, gleichzeitig einen zweiten DynDNS-Anbieter laufen zu haben, um dann im Extremfall noch eine zweite Karte zu haben. Aus diesem Grund wird es in einigen Tagen auch für Selfhost.de ein Update-Script von mir geben. Dies ist auch schon fertig, soll aber noch von Selfhost abgesegnet werden und dazu bin ich bisher noch nicht gekommen. In diesem Zusammenhang wird es für DynDNS.org ebenfalls eine neue Excel-Tabelle geben, am eigentlichen Script gab es jedoch nur unwesentliche Korrekturen, da ändert sich inhaltlich nichts. Die Excel-Tabelle wird dann überlange E-Mail-Adressen abfangen und ein paar bisher relative Bezüge werden auf absolute umgestellt sein, damit eine eventuelle Bearbeitung/Anpassung/Änderung des Scripts leichter möglich ist.

Viele Grüße,
Jirka