Ja, der Mitschnitt hat funktioniert. Allerdings ist eine HTTPS-Anfrage natürlich verschlüsselt. Kannst Du daher bitte noch einen weiteren Mitschnitt machen, aber mit HTTP als Protokoll in den DynDNS-Einstellungen. Das Verhalten des Speedport wird sich (sehr wahrscheinlich) sonst nicht dadurch ändern.
so hier der neue Mittschnitt:
Das ist der HTTP-Request für das DynDNS-Update vom Speedport:
GET /nic/update/nic/update?hostname=ts-server.home64.de&myip=93.242.210.152 HTTP/1.1
Host: ipv4.ipv64.net
User-Agent: DT - Speedport Pro Plus - 6.73.60.013.0
Accept: */*
HTTP/1.1 301 Moved Permanently
Date: Thu, 28 Mar 2024 17:40:53 GMT
Server: Apache
Location: https://ipv4.ipv64.net/nic/update/nic/update?hostname=ts-server.home64.de&myip=93.242.210.152
Content-Length: 305
Content-Type: text/html; charset=iso-8859-1
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>301 Moved Permanently</title>
</head><body>
<h1>Moved Permanently</h1>
<p>The document has moved <a href="https://ipv4.ipv64.net/nic/update/nic/update?hostname=ts-server.home64.de&myip=93.242.210.152">here</a>.</p>
</body></html>
Die Weiterleitung nach HTTPS ist korrekt.
Bei dem HTTP-Request des Speedport fehlt Benutzername und Passwort, daher auch der DynDNS-Autorisierungs-Fehler in den Speedport-Systemmeldungen. Das Capturing bestätigt dies noch mal.
Jetzt stellt sich also die Frage, warum der Speedport keinen Benutzernamen und Passwort mitsendet.
Der Packet-Capture wird jetzt nicht mehr benötigt, Du kannst wieder den HTTP-Request-Catcher verwenden, was wesentlich einfacher und schneller ist.
Versuche einmal folgendes: Trage als Benutzername etwas einfaches wie „benutzer“ und auch als Passwort etwas einfaches wie z.B. „Passwort123“ ein und lass den Request mal catchen, es kann sein, dass dann Benutzername und Passwort mitgesendet werden. Das würde auf ein Problem des Speedports mit der Passwort-Länge oder dem -Inhalt hinweisen.
Hallo, hier der neue Chatch.
Ich glaube das gleiche wieder, sehe da kein Passwort oder Benutzer.
Ich habe das auch mal mit Angaben von DuckDNS pobiert. Der Record sieht gleich aus. Trotzdem funktioniert es dort. Das soll einer Verstehen.
Ich habe jetzt auch noch mal probiert mit DuckDNS mit einem falschen Key, da lässt er mich nicht rein. Mit richtigen Key geht es wieder. Er sendet den Key also schon mit.
Als Adresse geht da https://www.duckdns.org/ oder auch https://www.duckdns.org/nic/update.
Die Auth-Informationen sollten als HTTP-Header drin stehen, nicht in der URL (und leider lässt der Speedport das wohl auch nicht zu). Kannst Du das für DuckDNS mit HTTP statt HTTPS und ein Packet capture davon machen?
Ergänzung: Du könntest auch noch mal die Einstellungen mit einem anderen Browser / Inkognito-Modus / ohne Add-Ons/Adblocker versuchen. Es sollte zwar auch mit funktionieren, aber manche Web GUIs sind einfach fragil und haben Probleme damit.
Mit anderen Browser ist das Ergebniss das gleiche. Habe die das Capture von DuckDNS mal per PM geschickt.
Der Packet Capture war äußerst aufschlussreich – zu DuckDNS hat der Speedport nämlich zwei HTTP-Anfragen nacheinander gemacht (innerhalb von 0.2 Sekunden oder so):
GET /nic/update/nic/update?hostname=ts-server.duckdns.org&myip=93.242.210.152 HTTP/1.1
Host: www.duckdns.org
User-Agent: DT - Speedport Pro Plus - 6.73.60.013.0
Accept: */*
HTTP/1.1 401 Unauthorized
GET /nic/update/nic/update?hostname=ts-server.duckdns.org&myip=93.242.210.152 HTTP/1.1
Host: www.duckdns.org
Authorization: Basic bm91c2VyOjMzZmIzZTM4LWNlODktNDFkMS05OGJiLWFlM2I5NGE0YTdiYQ==
User-Agent: DT - Speedport Pro Plus - 6.73.60.013.0
Accept: */*
HTTP/1.1 200 OK
Wie Du siehst, enthält der zweite HTTP-Request auch einen HTTP Auth Header (Authorization), und DuckDNS bestätigt die Anfrage positiv.
Ich habe noch eine Diskussion dazu gefunden, mit potentiellen Workarounds:
https://telekomhilft.telekom.de/t5/Festnetz-Internet/deSEC-DDNS-mit-Speedport-Pro-Plus/td-p/5681250
Wenn ich in der Serveradresse was Anhänge wie im Beispiel kommt immer:
D002-6Aktualisierung für Dynamic DNS war nicht erfolgreich. Der Dynamic DNS Anbieter meldet Service is temporarily not available (911)
Nur die Adresse https://ipv4.ipv64.net/ kommt wieder:
D002-1Aktualisierung für Dynamic DNS war nicht erfolgreich. Der Dynamic DNS Anbieter meldet Fehler bei der Authentifizierung (badauth)
Ich glaube ich habe da auch zweimal abgeschickt bei der DuckDNS Anmeldung. Hatte beim ersten mal einen Schriebfehler drin.
Hier ist auch noch ein Beitrag dazu:
Das ist aber alles schon alt die Lösungen. Es gibt mittlerweile eine neue Firmware wo das so auch nicht geht.
Dann sendet der Speedport aber bei der Update-Anfrage an DuckDNS den HTTP Auth Header, und bei der Anfrage an den benutzerdefinierten DynDNS-Provider IPv64.net jedoch nicht.
Ich gehe mal davon aus, dass Du nicht einfach Query-Parameter an die Update-URL ranhängen kannst und der Speedport diese gleich wieder „bereinigt“, korrekt?
Nein bereinigt er nicht. Kann er aber scheinbar nicht interpretieren.
Aber auch nicht immer, manche Kombination geht, da kommt nur ein bath auth. Bei anderen dann kommt er überhaut bis zum Server.
Jetzt gerade geht es wieder nur ganz ohne Anhang. Habe jetzt auch mal vom Strom genommen und neu anmelden lassen.
In letzten Post der „Telekomhilft“ war ja das mal erwähnt worden das der Pro auf eine bestimmte Antwort vom Server besteht.
Bist Du Dir sicher? Der Speedport hat nämlich überhaupt kein HTTP Auth gesendet, obwohl Benutzername- und Passwort-Felder schon gesetzt sind/gesetzt sein müssen.
Kannst Du den Packet capture für DuckDNS wiederholen, aber direkt mit Benutzername- und Passwort-Feldern korrekt ausgefüllt?
Das letzte Capture enthielt leider keine HTTP-Requests (auch keine HTTPS-Requests). 
Ok neuer Versuch 
Der Speedport hat auch hier wieder zwei HTTP-Requests gemacht:
GET /nic/update/nic/update?hostname=ts-server.duckdns.org&myip=87.132.222.35 HTTP/1.1
Host: www.duckdns.org
User-Agent: DT - Speedport Pro Plus - 6.73.60.013.0
Accept: */*
278 6.545947 52.60.135.62 87.132.222.35 HTTP 114 HTTP/1.1 401 Unauthorized
Und ein weiterer, mit HTTP Auth:
GET /nic/update/nic/update?hostname=ts-server.duckdns.org&myip=87.132.222.35 HTTP/1.1
Host: www.duckdns.org
Authorization: Basic bm91c2VyOjMzZmIzZTM4LWNlODktNDFkMS05OGJiLWFlM2I5NGE0YTdiYQ==
User-Agent: DT - Speedport Pro Plus - 6.73.60.013.0
Accept: */*
283 6.688941 52.60.135.62 87.132.222.35 HTTP 114 HTTP/1.1 200 OK
Bei fehlgeschlagenem Auth sendet DuckDNS Login Required als Antwort-Body.
Jetzt ist die Frage, ob der Speedport so einen Antwort-Body benötigt, um mit einem weiteren HTTP-Request mit HTTP Auth Header zu reagieren.
Edit: Ich habe gerade gesehen, dass die erste HTTP-Antwort einen HTTP Auth über einen HTTP Header anfordert: WWW-Authenticate: basic realm="Auth ()"
Ich habe mal einen komplexeren HTTP-Request-Catcher vorbereitet, der bei einer HTTP-Anfrage ohne HTTP Auth jenen explizit anfordert.
Verwende folgende URL als Updater-URL für einen benutzerdefinierten DynDNS-Dienst:
https://speedport.free.beeceptor.com/nic/update
Sollte sich meine Vermutung bestätigen, wird der Speedport erst eine HTTP-Anfrage ohne HTTP Auth senden, und dann eine weitere mit HTTP Auth Header.
Würde sich dieses Verhalten bestätigen, ließe sich mithilfe einer Anpassung in der IPv64.net API bzw. über einen HTTP-„Adapter“ Kompatibilität mit diesem Speedport-Modell herstellen.
WOW - Ich bin begeistert wie Tief ihr selber forscht. Ich habe jetzt mal eine „Anforderung“ hinzugefügt wenn kein Auth Token mit gesendet wird.
Kommt kein Token / Key etc. wird jetzt eine 401 gesendet und das WWW-Authenticate wird gesendet.
Bin gespannt was ihr sagt
1 „Gefällt mir“
Kleine Ergänzung.
Was der v64 Updater aktuell nicht kann ist eine Auth via „DIGEST“. Ließe sich aber natürlich noch hinzufügen. Aber probiert das jetzt erstmal so.