Problem: Fehler (file read error) bei DynDNS Registrierung

Forum zu aktuellen Geräten der LANCOM Router/Gateway Serie

Moderator: Lancom-Systems Moderatoren

dksoft
Beiträge: 7
Registriert: 07 Mär 2017, 09:39

Problem: Fehler (file read error) bei DynDNS Registrierung

Beitrag von dksoft »

Hallo liebe LANCOM-Freunde,

würde mir bitte jemand ein Tipp geben, wie ich den Fehler "file read error" bei der DynDNS-Registrierung verhindern kann?
Für mich sieht es so aus, dass die URL nach dem Aufbau zu früh aufgerufen wird und der IP-Stack noch nicht bereit ist.

Meine URL sieht so aus: "http://foo.bar.de:XXX@dyn.dns.he.net/ni ... de&myip=%a"
Diese funktioniert auch einwandfrei, wenn ich Sie per curl oder im Browser aufrufe.

Bei LCOS erhalte ich jedoch die Meldung "file read error" in der Aktions-Tabelle.
Rufe ich die URL erneut auf, indem ich ein "repeat:15" Eintrag einführe, so funktioniert das auch. Hier ist aber das Problem, dass dann alle 15 Sekunden ein Update erfolgt.


Vielen Dank,
dksoft
LANCOM 1783VA (over ISDN), A 2016-11-09 MOD A3, 9.24.0212, Telekom VDSL 100
dksoft
Beiträge: 7
Registriert: 07 Mär 2017, 09:39

DynDNS mit dns.he.net

Beitrag von dksoft »

Hallo,

hier die Lösung für DynDNS bei dns.he.net für IPv4 als auch IPv6:
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
LANCOM 1783VA (over ISDN), A 2016-11-09 MOD A3, 9.24.0212, Telekom VDSL 100
失败是成功之母
Beiträge: 73
Registriert: 03 Aug 2020, 14:18

Re: Problem: Fehler (file read error) bei DynDNS Registrierung

Beitrag von 失败是成功之母 »

Dickes Danke! Selbe Symptom auch noch unter LCOS 10.3x. Repeat und Skipiftrue=1 waren der Trick.
Hattest Du das damals bei Lancom gemeldet; weißt Du zufällig noch Deine Ticket-Nummer?

Anfangs wurde bei mir das Repeat als Erstes ausgeführt. Deswegen griff das das Skip nicht. Das sah man schön unter Status → WAN → Aktionen → Aktions-Tabelle. Und das, obwohl der Index vom Repeat größer war. Hin und her geändert, auf einmal (!?) wurde das Repeat als zweites ausgeführt. Seitdem greift auch das Skip. In der Ecke sind irgendwie noch mehr Software-Bugs unterwegs. Egal, dickes Danke!
Benutzeravatar
Jirka
Beiträge: 5225
Registriert: 03 Jan 2005, 13:39
Wohnort: Ex-OPAL-Gebiet
Kontaktdaten:

Re: Problem: Fehler (file read error) bei DynDNS Registrierung

Beitrag von Jirka »

失败是成功之母 hat geschrieben: 04 Aug 2020, 10:31Anfangs wurde bei mir das Repeat als Erstes ausgeführt. Deswegen griff das das Skip nicht. Das sah man schön unter Status → WAN → Aktionen → Aktions-Tabelle.
Da griff vermutlich noch eine Sperrzeit aus einem vorherigen Script. Die Aktions-Tabelle ist in dieser Hinsicht etwas schwer zu verstehen für Einsteiger.
失败是成功之母 hat geschrieben: 04 Aug 2020, 10:31Selbe Symptom auch noch unter LCOS 10.3x. Repeat und Skipiftrue=1 waren der Trick.
Möglicherweise aber auch ein Verbindungs(neu)aufbau (Script startet neu) oder ein Kaltstart (Sperrzeiten werden zurückgesetzt).
失败是成功之母 hat geschrieben: 04 Aug 2020, 10:31In der Ecke sind irgendwie noch mehr Software-Bugs unterwegs.
Definitiv nicht. Es mag sein, dass es ein gewisses Problem gibt, z. B. verursacht durch den Benutzernamen mit den Punkten drin, was in der Folge wie eine URL aussieht (und dadurch dann den Fehler "file read error" auslöst), aber das wäre auch noch nachzuweisen. Mit dieser oberflächlichen Betrachtung hier ist das auf alle Fälle nicht gemacht worden.

Viele Grüße,
Jirka
失败是成功之母
Beiträge: 73
Registriert: 03 Aug 2020, 14:18

Re: Problem: Fehler (file read error) bei DynDNS Registrierung

Beitrag von 失败是成功之母 »

Verstehe ich leider alles nicht. Wenn Du mir helfen willst, dass zu Debuggen, dann schreibe bitte, was Du brauchst.

Wenn ich die Action (belanglos) ändere, erhalte ich direkt "file read error". Das hat also nichts mit einem Skript davor, Kaltstart oder IP-Stack zu tun. Auch habe ich mittels Port-Mirroring den HTTP-Datenverkehr angeschaut (nutze ein Modem vor dem Lancom) und sehe nichts Auffälliges. Alle Variablen gesetzt. Auch habe ich drei Stunden gebraucht, das Skipiftrue zum Laufen zu bekommen. Anfangs wurde bei mir immer die repeat- vor der http-Aktion ausgeführt. Auf einmal und seitdem ist der repeat nach der http-Aktion (wie es sich gehört). Diesen Bug, und das war ein Bug, kann ich leider nicht mehr analysieren, weil ich diesen Zustand nicht mehr hinbekomme. Ich erwähnte das nur für all jene, die hier vorbeikommen, und sich die Zähne ausbeißen, warum es immer noch nicht geht.
Benutzeravatar
Jirka
Beiträge: 5225
Registriert: 03 Jan 2005, 13:39
Wohnort: Ex-OPAL-Gebiet
Kontaktdaten:

Re: Problem: Fehler (file read error) bei DynDNS Registrierung

Beitrag von Jirka »

失败是成功之母 hat geschrieben: 04 Aug 2020, 15:42Verstehe ich leider alles nicht.
Ok, schade. Ich weiß nicht, wie genau Du vorgegangen bist und was Du alles gemacht hast, ich weiß nur, was 90 % der User typischerweise in so einem Szenario falsch machen und vermute, dass es hier ähnlich gelaufen ist. Da wird z. B. zuerst mal der DynDNS-Assistent benutzt, der standardmäßig mit Sperrzeiten arbeitet. Ist das Script erst einmal irgendwie ausgeführt, sind die Sperrzeiten aktiv und bleiben da auch, bis die Sperrzeit abgelaufen ist, selbst wenn Du den Eintrag dreimal änderst. Einsehen kann man die aktiven Sperrzeiten unter /Status/WAN/Actions/Lock-Table im LCOS-Menübaum (also auch im Webinterface unter der dann entsprechenden deutschen Bezeichnung Aktionen/Sperrtabelle).
Oder hast Du alles per Hand in die Aktions-Tabelle eingetragen?
失败是成功之母 hat geschrieben: 04 Aug 2020, 15:42Wenn Du mir helfen willst, dass zu Debuggen, dann schreibe bitte, was Du brauchst.
Na im Augenblick weiß ich nicht ganz genau, wo das Problem ist. Kommt das "file read error" vom DynDNS-Provider oder vom LANCOM-Router? Wenn es vom LANCOM-Router kommt, wieso geht es dann 20 Sekunden später problemlos?
Zum echte Debuggen wäre es sicherlich hilfreich, wenn Du mir die echte Zeile/den Account und damit das Passwort zur Verfügung stellen könntest, das Passwort kann ja später wieder geändert werden. Das würde sicherlich auf beiden Seiten Zeit sparen.
Ansonsten wäre fürs erste ein 'ls /Status/WAN/Actions/Action-Table' hilfreich - gerne auch anonymisiert hier im Forum oder auch per PN. Oder die entsprechende Tabelle aus dem Webinterface kopiert.
失败是成功之母 hat geschrieben: 04 Aug 2020, 15:42Wenn ich die Action (belanglos) ändere, erhalte ich direkt "file read error". Das hat also nichts mit einem Skript davor, Kaltstart oder IP-Stack zu tun.
Und im späteren Verlauf geht es dann?
失败是成功之母 hat geschrieben: 04 Aug 2020, 15:42Auch habe ich mittels Port-Mirroring den HTTP-Datenverkehr angeschaut (nutze ein Modem vor dem Lancom) und sehe nichts Auffälliges. Alle Variablen gesetzt.
Und in diesem Trace siehst Du dann auch das "file read error"? Oder was kommt als Antwort vom Provider?
失败是成功之母 hat geschrieben: 04 Aug 2020, 15:42Auch habe ich drei Stunden gebraucht, das Skipiftrue zum Laufen zu bekommen. Anfangs wurde bei mir immer die repeat- vor der http-Aktion ausgeführt.
Also bei einem Script, was nur aus zwei Zeilen besteht und die letzte davon das repeat ist, ist es im Status natürlich schwer auszumachen, was jetzt zuerst ausgeführt wird. Typischerweise ist die Repeat-Zeit mit 20 Sekunden (15 Sekunden gibt es nicht, wird auf 20 hochgerechnet) so lange, dass man die Zeile halt als letztes in der Status-Tabelle sieht.
失败是成功之母 hat geschrieben: 04 Aug 2020, 15:42Auf einmal und seitdem ist der repeat nach der http-Aktion (wie es sich gehört). Diesen Bug, und das war ein Bug, kann ich leider nicht mehr analysieren, weil ich diesen Zustand nicht mehr hinbekomme.
Hmm. Wenn es nicht nachstellbar ist, ist es natürlich immer so eine Sache. Aber wie hast Du denn angefangen? Normal müsste das nachstellbar sein. Vielleicht doch Sperrzeiten aktiv gewesen? Das sieht man dann aber auch im Status. Oder der Scriptname vorne nicht gleich, so dass die zweite Zeile als eigenständiges Script interpretiert wird. Die Fehlerquellen sind hier echt unendlich, aber einen Bug vermute ich an dieser Stelle definitv nicht. Mit dem file read error ist es was anderes, da habe ich keinen Bug ausgeschlossen.
失败是成功之母 hat geschrieben: 04 Aug 2020, 15:42Ich erwähnte das nur für all jene, die hier vorbeikommen, und sich die Zähne ausbeißen, warum es immer noch nicht geht.
Die positive Absicht nehme ich Dir ab. Das Script ist aber derart weit von einem Optimum entfernt, dass ich hier eher nur warnen kann, das so zu übernehmen, wenn es auch unter normalen Umständen vielleicht funktioniert. Funktioniert es aber irgendwie warum auch immer nicht, dann gibt es hier weder eine E-Mail noch eine Einstellung der 20-sekündigen Update-Versuche. Viele DynDNS-Provider reagieren darauf sehr allergisch.

Viele Grüße,
Jirka
失败是成功之母
Beiträge: 73
Registriert: 03 Aug 2020, 14:18

Re: Problem: Fehler (file read error) bei DynDNS Registrierung

Beitrag von 失败是成功之母 »

Jirka hat geschrieben: 06 Aug 2020, 11:06 Oder hast Du alles per Hand in die Aktions-Tabelle eingetragen?
Ja, alles per Hand. Wobei ich nur eine Aktion angelegt hatte. Muss man noch mehr machen? Zur Sicherheit schaue ich gerne mal nach dieser Lock-Tabelle. Finde die nur nicht. Hast Du zufällig die SNMP-ID parat?
Jirka hat geschrieben: 06 Aug 2020, 11:06 "file read error" vom DynDNS-Provider oder vom LANCOM-Router? Wenn es vom LANCOM-Router kommt, wieso geht es dann 20 Sekunden später problemlos?
Dies erscheint im (WEBconfig-) Status der Aktions-Tabelle als Ergebnis, also auf der Ebene des Routers:

Code: Alles auswählen

Zeit                    Aktion          Ergebnis
06.08.2020 08:59:26	https://…	good
06.08.2020 08:59:22	repeat:10	timer started
06.08.2020 08:59:22	https://…	file read error
In Wireshark sehe ich nichts, aber auch gar nichts, was mir das erklären könnte. Und warum es dann (bei mir keine fünf Sekunden) später klappt … kein Schimmer. Ich befürchte es hat etwas mit HTTPs oder IPv6 zu tun, was mein DynDNS-Provider unterstützt. In der HTTPs-Aktion nutze ich nur %a.
Jirka hat geschrieben: 06 Aug 2020, 11:06 Und im späteren Verlauf geht es dann?
Ja, keine fünf Sekunden später. Die Aktion ist bereits beim nächsten Mal erfolgreich. Das Skipiftrue=1 beendet dann alles.
Jirka hat geschrieben: 06 Aug 2020, 11:06 … oder auch per PN.
Kommt … ich schalte Dir gleich eine eigene Sub-Domain bzw. privaten Zugang (und teste das vorher noch).
Jirka hat geschrieben: 06 Aug 2020, 11:06 bei einem Script, was nur aus zwei Zeilen besteht und die letzte davon das repeat ist, ist es im Status natürlich schwer auszumachen, was jetzt zuerst ausgeführt wird. Typischerweise ist die Repeat-Zeit mit 20 Sekunden (15 Sekunden gibt es nicht, wird auf 20 hochgerechnet) so lange, dass man die Zeile halt als letztes in der Status-Tabelle sieht.
Mhm. Also bei mir ist die kleinste Einheit nicht 20 sondern 10 Sekunden. Werden diese Aktionen asynchron ausgeführt? Ich dachte, dass die Repeat-Aktion auf Index 2 das Ergebnis der HTTPs-Aktion auf Index 1 abwartet.
Jirka hat geschrieben: 06 Aug 2020, 11:06 einen Bug vermute ich an dieser Stelle definitv nicht
Also ich bin doof aber so doof auch wieder nicht. Ich hatte das Problem, dass das Skipifx=y überhaupt nicht griff. Die beiden Aktionen liefen endlos und ich konnte nicht drüber springen. Witzig war, dass ich den Inhalt der beiden Aktionen getauscht hatte und immer noch nix ging. Zurückgetauscht, und es ging. Unsichtbare Zeichen können die Ursache auch nicht gewesen sein, weil ich mit Skipiffalse gegentestete. Die Aktionen selbst habe ich dabei nicht gelöscht … weiß ich nicht mehr sicher. Das einzige was ich als Unterschied dann sah, als es endlich lief: Repeat wurde laut Status nicht mehr vor HTTPs ausgeführt – sondern wie erwartet danach.
Jirka hat geschrieben: 06 Aug 2020, 11:06 Script ist aber derart weit von einem Optimum entfernt
Mhm? Du meinst mit Sperrzeit eine Art von Fail2ban? Meinem DynDNS-Provider ist die Menge der Anfragen egal und ich habe jetzt auch genau nur zwei Anfragen. Optimaler wäre ein Aufruf, ja.
Benutzeravatar
alf29
Moderator
Moderator
Beiträge: 6205
Registriert: 07 Nov 2004, 19:33
Wohnort: Aachen
Kontaktdaten:

Re: Problem: Fehler (file read error) bei DynDNS Registrierung

Beitrag von alf29 »

Moin,

die Meldung "file read error" kommt vom HTTP(S)-Client im LCOS, wenn die Kommunikation mit dem Server beim Lesen des HTTP-Headers abgebrochen ist.

Viele Grüße

Alfred
“There is no death, there is just a change of our cosmic address."
-- Edgar Froese, 1944 - 2015
失败是成功之母
Beiträge: 73
Registriert: 03 Aug 2020, 14:18

Re: Problem: Fehler (file read error) bei DynDNS Registrierung

Beitrag von 失败是成功之母 »

Das bedeutet für mich … wir müssen es so akzeptieren oder ich sollte es an LANCOM melden?
Zuletzt geändert von 失败是成功之母 am 07 Aug 2020, 14:49, insgesamt 1-mal geändert.
Benutzeravatar
Jirka
Beiträge: 5225
Registriert: 03 Jan 2005, 13:39
Wohnort: Ex-OPAL-Gebiet
Kontaktdaten:

Re: Problem: Fehler (file read error) bei DynDNS Registrierung

Beitrag von Jirka »

失败是成功之母 hat geschrieben: 06 Aug 2020, 16:09Ja, alles per Hand. Wobei ich nur eine Aktion angelegt hatte. Muss man noch mehr machen?
Für ein gutes und stabil laufendes Script ganz klar ja.
失败是成功之母 hat geschrieben: 06 Aug 2020, 16:09Zur Sicherheit schaue ich gerne mal nach dieser Lock-Tabelle. Finde die nur nicht. Hast Du zufällig die SNMP-ID parat?
Wenn Du keine Lock-Werte hattest, dann gibt es auch keine Einträge in der Lock-Tabelle. Von daher brauchst Du dann also nicht nachschauen. Ich hatte es nur vermutet, offensichtlich war es aber nicht so.
Die Lock-Tabelle befindet sich hier:
/Status/WAN/Actions/Lock-Table
Das ist die SNMP-ID 1.3.6.1.4.1.2356.11.1.4.20.2
失败是成功之母 hat geschrieben: 06 Aug 2020, 16:09

Code: Alles auswählen

Zeit                    Aktion          Ergebnis
06.08.2020 08:59:26	https://…	good
06.08.2020 08:59:22	repeat:10	timer started
06.08.2020 08:59:22	https://…	file read error
Hmm, die Uhrzeit zeigt einem, dass der erste HTTPS-Aufruf anscheinend 6 Sekunden gedauert hat, danach kam offensichtlich der Fehler.
失败是成功之母 hat geschrieben: 06 Aug 2020, 16:09Also bei mir ist die kleinste Einheit nicht 20 sondern 10 Sekunden.
Korrekt. Ich ging hier nur von den 15 Sekunden aus, die hier vom Threadstarter angegeben wurden im Screenshot. Und die werden dann zu 20.
失败是成功之母 hat geschrieben: 06 Aug 2020, 16:09Ich dachte, dass die Repeat-Aktion auf Index 2 das Ergebnis der HTTPs-Aktion auf Index 1 abwartet.
Ja, so ist es im Normalfall. Schließlich soll ja das repeat nur ausgeführt werden, wenn es nicht erfolgreich war.
失败是成功之母 hat geschrieben: 06 Aug 2020, 16:09Ich hatte das Problem, dass das Skipifx=y überhaupt nicht griff. Die beiden Aktionen liefen endlos und ich konnte nicht drüber springen. Witzig war, dass ich den Inhalt der beiden Aktionen getauscht hatte und immer noch nix ging. Zurückgetauscht, und es ging. Unsichtbare Zeichen können die Ursache auch nicht gewesen sein, weil ich mit Skipiffalse gegentestete. Die Aktionen selbst habe ich dabei nicht gelöscht … weiß ich nicht mehr sicher. Das einzige was ich als Unterschied dann sah, als es endlich lief: Repeat wurde laut Status nicht mehr vor HTTPs ausgeführt – sondern wie erwartet danach.
Hmm. Ich kann das hier jetzt nicht nachvollziehen, aber das sei dann dahingestellt. Das einzige, was ich bereits schrieb, dass davor und danach sehr schwierig zu unterscheiden ist, weil Du es bei einem repeat von 10 Sekunden schlicht nicht erkennen kannst. Der repeat von 10 Sekunden startet nicht genau 10 Sekunden nachdem das Script zu Ende ist, sondern 10 Sekunden nachdem das Script angefangen hatte. Und wenn der erste Befehl schon 6 oder noch mehr Sekunden braucht, bis der Timeout kommt oder der Fehler, dann sieht es eben so aus, als ob das eine vor dem anderen kommt.
失败是成功之母 hat geschrieben: 06 Aug 2020, 16:09Optimaler wäre ein Aufruf, ja.
Das funktioniert in der Praxis definitiv nicht. Es können ja sonstwas für Fehler auftreten. Das muss man natürlich abfangen und dann halt nochmal probieren. Aber wenn das Passwort falsch ist, dann sagt der Provider badauth oder liefert der LANCOM ein HTTP protocol error 401, dann sollte man eher eine E-Mail verschicken und abbrechen, als weiter versuchen. Da gibt es aber noch zig andere Fälle, das war jetzt nur ein Beispiel. Man muss jetzt ja auch nicht alles neu erfinden, es gibt ja bereits fertige Scripte auch hier im Forum, die das alles machen, die müsste man nur anpassen. Ich würde das auch machen, finde aber gerade meine letzte Original-Vorlage gerade selber nicht mehr (die im Forum hier habe ich gerade geschaut, stellt nicht den letzten Stand dar, den ich hatte, da fehlen noch 2 Jahre Ergänzungen)
Irgendwie wollte ich das alles auch noch mal perfekt machen, aber die Zeit...
alf29 hat geschrieben: 06 Aug 2020, 16:16 die Meldung "file read error" kommt vom HTTP(S)-Client im LCOS, wenn die Kommunikation mit dem Server beim Lesen des HTTP-Headers abgebrochen ist.
Vielen Dank für den Input Alfred. Ich habe meine uralten Aufzeichnungen hierzu gerade nicht zur Hand, wie ich schon schrieb, ich bin mir unsicher, ob ich file read error da schon mit drin hatte, ich bin mir ziemlich sicher eigentlich nicht. Irgendwie ist mir die Fehlermeldung jetzt wie neu. Was ja aber durchaus auch sein kann, weil ich sie noch nie erlebt habe.
So, nun bricht also die Kommunikation mit dem HTTP(S)-Server beim Lesen des HTTP(S)-Headers ab. Ok. Liegt das nun am LANCOM, am HTTP-Server oder am Übertragungsweg? Offensichtlich ist es ja so, dass es beim ersten Versuch fast nie klappt, beim zweiten aber ja? Oder kann der zweite Versuch manchmal auch schief gehen (die Frage geht eher an den "Chinesen")? Und klappt vielleicht manchmal auch schon der erste Versuch?
Führt irgendeine Konstellation dazu, dass es mit diesem HTTP-Server mehr Probleme gibt als mit anderen? Sollte man das sich mal anschauen, was da vor sich geht, also warum nun genau die Kommunikation abbricht? Header mit Fehlern? Offensichtlich ist er ja nun nicht der einzige. Und ich kenne das Problem gar nicht, da muss also doch irgendwas faul sein, oder?

Viele Grüße,
Jirka
Benutzeravatar
alf29
Moderator
Moderator
Beiträge: 6205
Registriert: 07 Nov 2004, 19:33
Wohnort: Aachen
Kontaktdaten:

Re: Problem: Fehler (file read error) bei DynDNS Registrierung

Beitrag von alf29 »

Moin,
So, nun bricht also die Kommunikation mit dem HTTP(S)-Server beim Lesen des HTTP(S)-Headers ab. Ok. Liegt das nun am LANCOM, am HTTP-Server oder am Übertragungsweg? Offensichtlich ist es ja so, dass es beim ersten Versuch fast nie klappt, beim zweiten aber ja? Oder kann der zweite Versuch manchmal auch schief gehen (die Frage geht eher an den "Chinesen")? Und klappt vielleicht manchmal auch schon der erste Versuch?
Führt irgendeine Konstellation dazu, dass es mit diesem HTTP-Server mehr Probleme gibt als mit anderen? Sollte man das sich mal anschauen, was da vor sich geht, also warum nun genau die Kommunikation abbricht? Header mit Fehlern? Offensichtlich ist er ja nun nicht der einzige. Und ich kenne das Problem gar nicht, da muss also doch irgendwas faul sein, oder?
Das kann ich Dir alles nicht ohne weitergehende informationen beantworten. Ich kann die Meldung in den Sourcen nur bis zu der Stelle zurückverfolgen, wo das EOF beim Lesen des HTTP-Headers kommt. Wieso, weshalb, warum - keine Ahnung. Bringt ein Capture eines solchen abgebrochenen HTTP(S)-Zugriffs, dann sehen wir vielleicht mehr.

Viele Grüße

Alfred
“There is no death, there is just a change of our cosmic address."
-- Edgar Froese, 1944 - 2015
失败是成功之母
Beiträge: 73
Registriert: 03 Aug 2020, 14:18

Re: Problem: Fehler (file read error) bei DynDNS Registrierung

Beitrag von 失败是成功之母 »

Ja, die Sperrtabelle [1.4.20.2] ist bei mir leer. Das Verhalten ist (seitdem es läuft) konstant: 1. Versuch scheitert, 2. Versuch gelingt. Für mich persönlich reicht dies erstmal. Aber wenn das DKSoft noch nicht gemeldet hat, würde ich das melden. Sollte ich dann direkt die Ergebnisse von DynDNS tracen.lcg anhängen oder warten bis ich aufgefordert werde?
Benutzeravatar
Jirka
Beiträge: 5225
Registriert: 03 Jan 2005, 13:39
Wohnort: Ex-OPAL-Gebiet
Kontaktdaten:

Re: Problem: Fehler (file read error) bei DynDNS Registrierung

Beitrag von Jirka »

失败是成功之母 hat geschrieben: 07 Aug 2020, 14:48Ja, die Sperrtabelle [1.4.20.2] ist bei mir leer.
Ok, wie mittlerweile erwartet. Das war ja auch nur ein Erklärungsversuch für andere aufgetretene Probleme.
失败是成功之母 hat geschrieben: 07 Aug 2020, 14:48Das Verhalten ist (seitdem es läuft) konstant: 1. Versuch scheitert, 2. Versuch gelingt.
Ok, dann bräuchte man davon jetzt ein Trace. Entweder wie Du es schon gemacht hast mit dem Monitoring-Port oder - das geht mindestens genauso gut - am LANCOM. Da gibt es die Möglichkeit richtige Wireshark-Dateien zu erstellen (unter Extras -> Paket-Capturing), nach Möglichkeit mit wenig oder gar keinem anderem Traffic, oder man traced direkt auf der LANCOM-Konsole - was hast Du für ein Gerät bzw. für eine Internetverbindung (Modem/Ethernet)?
Alternative wäre, dass ich trace, brauche dann aber DynDNS-Provider-Daten, denn so kann man sich da doch nicht anmelden, soweit ich das gesehen hatte, oder?
失败是成功之母 hat geschrieben: 07 Aug 2020, 14:48Aber wenn das DKSoft noch nicht gemeldet hat
Wir haben jetzt 2020, sein Posting war von 2017. Ich meine gut, wenn der Bug geringe Prio hat ist alles möglich, aber da wird er wohl nichts gemeldet haben.
失败是成功之母 hat geschrieben: 07 Aug 2020, 14:48Sollte ich dann direkt die Ergebnisse von DynDNS tracen.lcg anhängen oder warten bis ich aufgefordert werde?
Also hier ist kein LANCOM-Support. Da musst Du schon liefern, mehr als die bisherigen "Aufforderungen" wird es nicht geben. Alfred würde sich das anschauen, um hier zu helfen, dieses seltene Phänomen aufzuklären. Aber dafür brauch er halt Daten, weil er kann es genauso wenig wie ich nachstellen, weil wir den DynDNS-Provider nicht haben. Wenn es Datenschutz-Bedenken gibt, dann als PN oder meist noch besser, als E-Mail hier über das Forum. Sehe gerade, bei E-Mail kann man keine Anlage ranhängen, da müsste man dann verlinken oder die Rückantwort abwarten... Im Zweifel dann wohl doch einfach eine PN. (Problem ist da nur, dass die PN-Postfächer chronisch voll sind, ansonsten geht das mal für den Augenblick ganz gut.)

Viele Grüße,
Jirka
失败是成功之母
Beiträge: 73
Registriert: 03 Aug 2020, 14:18

Re: Problem: Fehler (file read error) bei DynDNS Registrierung

Beitrag von 失败是成功之母 »

Dickes Danke an die Helfenden und für die Hilfsbereitschaft. Wollte erstmal zwei Wochen warten, ob DKSoft sich vielleicht noch meldet. Auch habe ich die Zwischenzeit genutzt, mir einen LANCOM Router zu besorgen, der die neusten Releases, Candidates und Betas erlaubt. Weil ich im Trace wirklich gar nichts Verdächtiges sehe, vermute ich eher eine Abhängigkeit zu einem internen Zustand. Daher habe ich das (zusammen mit einem Test-Account) im Support-Portal unter dem Ticket LCSUP-72339 eingetütet. DKSofts Workaround konnte ich für meine Situation etwas verfeinern, indem ich stattdessen auf isequal=file read error?skipiffalse=1 prüfe.
失败是成功之母
Beiträge: 73
Registriert: 03 Aug 2020, 14:18

Re: Problem: Fehler (file read error) bei DynDNS Registrierung

Beitrag von 失败是成功之母 »

Mit der aktuellen LCOS 10.42 bzw. LCOS 10.50 ist das Problem mit dem HTTPS-Header immer noch da … auch hat der Lancom-Support das mit der Hol-/Bringschuld alles andere als drauf. Das Ticket LCSUP-72339 bekam Ende September den Status „Done“. Wobei „Done“ für den Support bedeutet, dass intern ein Fehler-Report angelegt wurde. Schön. Kann ja sein, dass der Fehler unbedeutend und bis heute noch nicht gelöst ist. Aber das Problem bei jenem Vorgehen ist, dass es annimmt, dass intern alles unfehlbar ist. Wenn der interne Report nicht richtig abgearbeitet wird (vergessen, verloren gegangen, Fehler behoben aber meine Situation nicht abgedeckt), dann erfahre ich das nie. Ich weiß also nicht, ob es jetzt mit LCOS 10.50 eigentlich funktionieren müsste. So kann man Bug-Tracking auch kaputt machen … soll ich in diesem Vorgehensmodell bei jedem Major-Release erneut ein Ticket aufmachen oder soll ich für immer schweigen? Fazit für Euch Passive-Leser da draußen mit der selben Fehlermeldung: Meldet es!
失败是成功之母 hat geschrieben: 04 Aug 2020, 10:31 Anfangs wurde bei mir das Repeat als Erstes ausgeführt. Deswegen griff das das Skip nicht. Das sah man schön unter Status → WAN → Aktionen → Aktions-Tabelle. Und das, obwohl der Index vom Repeat größer war. Hin und her geändert, auf einmal (!?) wurde das Repeat als zweites ausgeführt. Seitdem greift auch das Skip.
Heute mögen mich Software-Bugs irgendwie. Ich kann diesen Bug nun auch nachstellen: Wenn der (Host-) Name der Aktion „repeat“ leer ist, dann greift meine Aktion „skipiffalse=1“ nicht. Ich erhalte eine Dauerschleife. Wenn die Hostnamen unterschiedlich sind, dann startet das „repeat“ die andere Aktion nicht erneut. Ich erhalte laufend nur Repeats. Verstehe ich nicht. Gruppiert oder sortiert ein Hostname irgendwie Aktionen zusätzlich? Wäre sinnvoll, wenn man mehrere Hostnamen hat. Nur kann ich das nicht aus der Dokumentation herauslesen.
Antworten