Ich leite die Fritz!Box DynDNS Updates über ein Proxy.
Das gibt mir die Möglichkeit die Antwortszeiten zu messen.
(es gab mir auch die Möglichkeit festzustellen, daß jede dritte Update von der Box fehlerhaft ist)
Die ipv6.ipv64.net Updates werden häufig nach 10 Sekunden ausgetimed.
Häufig liegen die über 1 Sekunde, manchmal 2 & 3 Sekunden, was problematisch sein kann, denn die Fritz!Box scheint ein Timeout von ca, 3 Sekunden zu verwenden.
Bei andere DynDNS Dienste liegen die Antwortzeiten bei wenige 100 Millisekunden.
Gezielt unter IPv4 habe ich keine Messungen.
Aber am problematischten sind die Timeouts, die häufiger vorkommen als erfolgreiche Updates.
Mhh, das guck ich mir mal an.
Sooo, du hattest mich da auf eine Idee gebracht. Ich hab jetzt mal eine kleine Innovation eingebaut. Messe doch bitte mal die Performance in den nächsten Stunden / Tagen und gebe mir gerne hier ein Feedback. Ich bin sehr gespannt.
Will do…
Ich habe ein DynDNS Proxy hier entwickelt:
mit eine custom Update URI kann ich sehr einfach zwischen Dienstleister wechseln.
Dabei auch zwischen ipv6.ipv64.net & ipv4.ipv64.net.
ipv6.ipv64.net scheint etwas langsamer zu sein. Soeben lag die bei 1,6 Sek.
ipv4.ipv64.net liegt bei ca. 1 Sek.
duckdns dagegen bei ca. 400 ms.
P.S. diese Woche sind die Timeouts bisher ausgeblieben.
Miss mal erneut. Dürfte jetzt nicht mehr so sein.
Ich muss das jetzt mal wirklich in Frage stellen. Wenn ich eine Update URL aufrufe (ohne cache), ist die innerhalb von paar ms bei mir fertig ausgeliefert.
Egal was ich tu, über 1 Sekunde ist bei mir weit entfernt. Was tut bitte dein Proxy?
Dennis,
du könntest mir (uns alle) ein gefallen tun…
…eine Auswertung von Update Aufträge von Fritz!Boxen.
(erkennbar z.B. durch dem Header User-agent=Fritz!Box DDNS/1.0.3)
Schau mal wie häufig &IP (bzw. &IP4) und &IP6 leer sind im Update URI.
Bei mir sind das ca. 30% alle Updates.
Beispiel URI Update Query:
?domain=mee.ipv64.de**&ipv6=**&ip4=99.111.77.222…
Kann ich gerne mit dir teilen: ist lediglich ein Java 21 Klasse.
Außer JDK 21, verwendet die SLF4J für Logging.
Die läuft auf unsere Synology NAS, die im gleichen Subnetz wie Fritz! sitzt.
Ich messe die Zeit zwischen GET Ankunft von der Box bis der Antwort von ipv64 zurück an der Box fertig gemeldet ist.
(es gibt auch eine Eierlegenwollmilchsau Fassung die deutlich detailierte misst.
da habe ich festgestellt, der Löwenanteil der Antwortzeit ist in der ipv64.net Aufruf)
Die Eierlegenwollmilchsau Fassung hat auch ein „ping“ Funktion.
Die ping läuft in ca. 20 ms durch. Da kann ich kein Flaschenhals erkennen.
Soeben lag die Antwortzeit bei knapp 2 Sek.
Standard Java HttpClient.
https
(da soll natürlich " micros rc=" in dem Screenshot stehen)
Ich halte mich zurück zu sagen " JAVA "…
Kann ich leider nicht nachvollziehen. Egal wie und wo ich messe, ich lande bei 300ms.
Wobei heut-zu-tage (laut z.B. Heise) Java liefert Performance vergleichbar mit C++.
Und eine Suche zum Thema Performance für die „neue“ Java 11 HttpClient liefert keine Treffer.
Das war übrigens ernst gemeint:
ich habe aktuell diesbezüglich eine Ticket offen bei AVM.
Da scheint es eine Fehler in der DynDNS Dienst zu geben.
Wenn du Möglichkeit hättest, eine Auswertung zu machen.
Es ging um folgendes:
mein Fritz!Box liefert in ca. 30% der Fälle falsche Update URI’s.
Mal ist der &ip (bzw. &ipv4, &ip4 o. &myip) Key vorhanden, aber ohne Wert.
Mal ist es der &ip6 (bzw. &ipv6, &myip6 o. &myipv6) Key ohne Wert.
Und manchmal ist &ip6lanprefix (bzw. &ipv6prefix) mit ein falsche Wert belegt.
Im extrem Fall, sieht die URI Query so aus:
?domain=myipv64domain&ip=&ip6=&ip6lanprefix=2a02:b98:8a29:3a00::/64&key=XXXX
(obwohl zwei fehlende Werte habe ich noch nicht beobachtet)
Ich denke mein Box ist nicht der einzige der betroffen ist.
Aber, wie üblich, AVM versteckt sein Kopf im Sand.
Deshalb, wäre ein Auswertung, welche Anteil der von Fritz!Box stammende (User-agent=Fritz!Box DDNS/1.0.3) URI’s Keys ohne Werte ausweisen sehr hilfreich.
Hallo Miteinander,
ich habe das ganze mit einer 7590 8.03 DS-Lite Wisotel (nur öffentliche IPV6 und NAT IPV4) am laufen. Das ganze funktioniert.
IPV4 ist deaktiviert (Ignor IPV4 / A Records)
Mir ist jedoch folgendes aufgefallen:
Jetzt gerade steht mein DynDNS Update Limit schon auf 19 (8:15) ???
Und meine Fritzbox meldet:
Aber in den Ereignissen steht folgendes drin und diese Meldung kommt öfters.
Kann es sein, dass da doch ein Timeout vorliegt und dann die Fritzbox öfters versucht das zu korrigieren und deshalb das Update jetzt schon um 8de auf 19* steht?
Zur Info für Euch
Bis dann
(Ach und wenn das nicht hier hergehört dann kanns der Admin bestimmt verschieben)
Die Fritz!Box scheint eine Timeout von 3 Sekunden zu haben.
Besonders während der DDOS Angriff neulich, könnte mann beobachten, nach ca. 3 Sekunden verschickte die !Box noch eine Update, obwohl die Vorrige von ipv64 noch nicht fertig verarbeitet wurde.
Nachtrag.:
heute Nacht, nach ein Timeout von ipv64,
erfolgte der Fritz!Box Retry nach ziemlich genau 1 Minute.
Du kannst mal testweise den Teil der Update URL entfernen, der die IPv4-Adresse aktualisieren will. Brauchst du ja wegen DS-Lite sowieso nicht. Also statt:
Update URL: https://ipv64.net/nic/update?key=1234567890abcdefgh&domain=DOMAINNAME.ipv64.net&ip=<ipaddr>&ip6=<ip6addr>
teste mal:
Update URL: https://ipv64.net/nic/update?key=1234567890abcdefgh&domain=DOMAINNAME.ipv64.net&ip6=<ip6addr>
oder
Update URL: https://ipv64.net/nic/update?key=1234567890abcdefgh&domain=DOMAINNAME.ipv64.net&ip6=<ip6addr>&ip6lanprefix=<ip6lanprefix>
wenn du auch den IPv6-Prefix aktualisierst.
Nachtrag und Hintergrund:
Ich habe an einem entfernten Standort eine 7490 aber Dual-Stack. Unterschiede sind also das
- OS (die 7490 hat 7.60) und
- ich habe dort Dual-Stack. Somit kann und wird auch die IPv4-Adresse aktualisiert genau wie der IPv6-Prefix
Dennoch habe ich dort keinerlei Probleme mit einem Timeout. DynDNS-Updates klappen immer. Grund kann also das unterschiedliche OS sein, oder aber dass dir Fritte bei DS-Lite auch die IPv4-Adresse aktualisieren will, aber wegen Ignor IPV4 / A Records keine Antwort darauf bekommt.
Auch wenn ich nur die IPV6 aktualisiere kommt es weiterhin zu häufigen Updates der Fritzbox und die Fehlermeldungen das der angegebene Domainname nicht aufgelöst werden konnte.
Jetzt ist mir noch aufgefallen das ein PING auf meine Domain tatsächlich zu keinem Ergebniss führt. Weder der Ping auf die IPV4 noch auf die IPV6 vom CDN. Das geht auch nicht mit den angebotenen Tools von ipv64.
Jedoch findet ein nslookup oder eine direkte Eingabe der Domain in den Browser sein Ziel und landet auf der CDN-Seite.
Wenn jetzt die Fritzbox über einen PING versucht den Domainname anzupingen bekommt die nix. Und versucht es dann immer wieder. Da mir unbekannt ist was und wie die „Auflösung“ bei der Fritzbox gemacht wird, wäre zu klären warum ein PING generell nicht geht.
Ist das evt. im CDN abgeschalten, dass die auf keinen PING reagiert oder evt. aus Sicherheitsgründen nicht mehr reagiert?