[Problem] TR-064 Problem(e) mit 6.98 Inhouse/Labor

[PeterPawn]

AVM hält sich nicht zwangsläufig an die eigene Dokumentation.

Wobei man die Vorwürfe - zumindest bei dem Teil, um den es Dir hier im Thread offensichtlich geht - dann schon differenziert betrachten muß ... ich habe, nachdem ich nun verstanden habe, worum es Dir eigentlich geht, noch einmal sehr genau die "First Steps" nachgelesen (man macht das nur selten so bewußt, daß einem auch die nicht selbstgenutzten Teile 100% in Erinnerung sind).

Und ich kann da beim besten Willen keinen Hinweis darauf finden, daß AVM die Kommunikation über HTTP ohne TLS irgendwie dokumentiert hätte ... in Abbildung 1 ist sehr dezidiert festgehalten, daß genau Discovery unverschlüsselt über den Port 49000 funktionieren soll und der Aufruf von "GetSecurityPort()" - für alle anderen Funktionen finde ich da gar keine Aussage, daß sie ebenfalls über unverschlüsseltes HTTP auf Port 49000 angeboten werden.

Hingegen steht in der "Technical Note" zum TR-064 (halbwegs) dezidiert folgendes:

Sicherheit
TR-064 nutzt aus Sicherheitsgründen eine Anmeldung und Verschlüsselung, um eine ungewollte Konfiguration
zu verhindern.
[...]
Es wird immer empfohlen eine TLS-verschlüsselte Verbindung über https aufzubauen. Erst jetzt können Einstellungen der FRITZ!Box mittels TR-064 ausgelesen oder verändert werden.
[...]

Auch wenn hier nur "empfohlen" wird (was sicherlich mit SHOULD in der Sprache von RFCs gleichzusetzen wäre), steht auch dort nirgendwo eine "Zusicherung", daß der TR-064-Zugriff über eine unverschlüsselte Verbindung funktionieren würde.

Ganz im Gegenteil ... es wird auf die TR-064-Spezifikation des Broadband-Forums verwiesen und dort findet sich u.a. (seit 2011) die Spezifikation für den Service "DeviceProtection" (warum AVM den nicht in voller Schönheit implementiert und stattdessen einen eigenen Sonderweg eingeschlagen hat, wird man auch schwerlich herausbekommen können - aber man darf/kann ja die dort festgelegten Spezifikationen wenigstens analog auf die AVM-Interfaces übertragen), in der dann ausdrücklich festgelegt wird:

DeviceProtection is designed to allow a device to expose some parts of its services to legacy and unauthenticated Control Points and restrict other parts to only authenticated and authorized Control Points. A Device can also simultaneously support both types of Control Points. UPnP actions that require authenticated access MUST be accessible ONLY via HTTPS URLs. Publicly-available actions MUST be accessible over both HTTPS and legacy HTTP URLs. For DeviceProtection:1, TLS version 1.0 [RFC 2246] MUST be supported. A Control Point and Device are also permitted to negotiate and use a more recent version of TLS, if both sides support it.

Das legt dann die Entscheidung, ob nun unverschlüsselt oder verschlüsselt kommuniziert wird, nicht mehr in die Hand des Kunden/Besitzers des Gerätes (hatten wir weiter oben ja auch als einen Punkt) und wenn sich AVM hier (obwohl sie das Interface "DeviceProtection" nicht implementieren) analog verhält, finde ich das auch wieder sehr nachvollziehbar (und löblich).

Die vorliegenden Dokumentationen von AVM würden zumindest Deinen weiter vorne geäußerten Vorwurf, daß AVM da alle Nase lang etwas ändert (obwohl auch das ausdrücklich in Punkt6 von "First Steps" steht, daß dieses passieren könnte), deutlich weniger verständlich machen ... am Ende könnte man sogar auf die Idee kommen zu konstatieren, daß die bisher auch über Port 49000 mögliche, unverschlüsselte TR-064-Kommunikation ein Fehler war, der jetzt behoben wurde (wenn es tatsächlich bis 06.93 funktionierte - was ich nie ernsthaft selbst getestet habe - und nun nicht mehr zur Verfügung steht). Seit wann das bei AVM genau so spezifiziert ist, müßte ich erst in alten Backups suchen ... da bist Du selbst ggf. über die "Wayback Machine" vielleicht schneller, wenn Du die Änderungen "katalogisieren" willst.

Das soll AVM nicht in Gänze "verteidigen" (es gibt genug Stellen, wo die Dokumentation wirklich nicht stimmt und das Protokollieren von vorgenommenen Änderungen scheint auch eine Tugend zu sein, die bei AVM so peu à peu in Vergessenheit gerät) ... aber man muß auch aufpassen, daß die Kritikpunkte tatsächlich zutreffen, ansonsten schadet man anderen Punkten, wenn das alles in einen Topf geworfen wird und dabei auch Vorwürfe inkludiert werden, die nicht ohne weiteres nachvollziehbar sind.

 

[fipsy]

Und ich kann da beim besten Willen keinen Hinweis darauf finden, daß AVM die Kommunikation über HTTP ohne TLS irgendwie dokumentiert hätte ...

AVM äußert sich zu HTTP oder HTTPS eigentlich gar nicht. Auch die Kommunikation mit TLS ist ja nicht dokumentiert. Wenn man mal von der Empfehlung absieht, dass die Kommunikation vorzugsweise gesichert stattfinden sollte. Wie auch immer, bisher hat es jedenfalls bei allen Fritzboxen stets mit HTTP funktioniert.

Ich habe nun zahlreiche Tests auf TCP-Ebene gemacht. Das Problem ist, dass schon allein ein gesicherter TCP-Connect auf Port 49443 von der Fritzbox zurückgewiesen wird. Die Verbindung wird einfach abgebrochen. Die Fritzbox liefert dabei nichtmal ihr Zertifikat. Ein ungesicherter Connect auf Port 49443 wird hingegen akzeptiert. Wenn ich alternativ den selben Connect z.B. mit "web.de" auf Port 443 durchführe (statt mit "fritz.box" auf Port 49443) liefert der Server von web.de brav sein Zertifikat und die sichere Verbindung steht danach. Wohlgemerkt, es handelt sich nur um ein TCP-Connect ohne jedweden Datentransfer. Nichtmal das kriege ich mit der Fritzbox gebacken. Auch wenn ich über meine WAN IP-Adresse auf Port 443 der Fritzbox zugreifen will, wird die Verbindung zurückgewiesen. Auch der HttpRequester kriegt es ja nicht gebacken. Keine Ahnung, wieso es mit System.Net.WebClient funktioniert und was da beim TCP Connect anders ist. Ich werde noch etwas testen, aber wenn ich das nicht zeitnah hinkriege, ist das Projekt erstmal gestorben.

am Ende könnte man sogar auf die Idee kommen zu konstatieren, daß die bisher auch über Port 49000 mögliche, unverschlüsselte TR-064-Kommunikation ein Fehler war, der jetzt behoben wurde (wenn es tatsächlich bis 06.93 funktionierte - was ich nie ernsthaft selbst getestet habe - und nun nicht mehr zur Verfügung steht).

Wenn es nicht bei allen Fritzboxen bisher problemlos funktioniert hätte (sogar bei kompatiblen Modellen von 1&1 u.ä.), hätte ich nicht rund 1000 Nutzer, die das Programm seit fast 2 Jahren ohne Probleme laufen haben.

 

[PeterPawn]

Das hört sich aber eher nach einem Problem mit einer Firewall an, als nach einem "echten" TCP-Problem. Da das erste Paket ja nicht mehr als ein SYN-Flag enthält (zusammen mit ein paar weiteren Vorschlägen für einige TCP-Parameter), kann die FRITZ!Box das noch gar nicht wirklich ablehnen ... erst nach der Antwort der Box mit ihrem eigenen SYN-Paket samt ACK-Flag und einem weiteren ACK-Paket vom Sender, steht die Verbindung überhaupt soweit, daß der TLS-Handshake stattfinden kann.

Den Request kann man ja auch mal zu "fritz.box" auf dem TLS-Port des GUI probieren (anstatt zu "web.de") - dabei gilt aber auch aus dem internen Netz derselbe Port, wie er im GUI für den TLS-Zugriff eingestellt ist und das ist bei aktuellerer Firmware eher ein zufällig gewählter Port oberhalb von 1024 und nicht der "offizielle" HTTPS-Port, solange man es nicht selbst entsprechend angepaßt hat.

Wobei ein "einfach abgebrochen" bei TCP auch nicht so ganz klar ist ... kommt kein SYN-ACK auf das erste Paket zurück, gibt es ein Timeout - mit entsprechendem Fehlercode. Blockiert irgendetwas die Verbindung und gibt dieses "etwas" darüber noch Auskunft, sieht man ein passendes ICMP-Paket als Antwort (vom Blockierer) - das wäre auch der Fall, wenn man einen Port ohne Listener auf der FRITZ!Box anspricht. Handelt es sich um eine "stille Blockade" (das ist in etwa der Unterschied zwischen "drop" und "reject", daß Letzteres noch Auskunft über die Ursache gibt), muß es wieder ein Timeout geben. Wenn da tatsächlich jemand auf ein SYN-Paket sofort mit einem FIN-Paket antwortet, kann das eigentlich nur irgendetwas "auf dem Weg" sein.

Die FRITZ!Box kann obendrein auch noch selbst einen Paketmitschnitt erzeugen ... da sieht man dann nicht nur das, was beim eigenen Programm ankommt (und ggf. eben auf dem eigenen System oder auf dem Transportweg verändert werden kann - je nach Topologie), sondern genau das, was bei der Box ankommt und von ihr gesendet wird. Erst dann, wenn es da gar keine Diskrepanzen mehr gibt, erfolgt die Kommunikation wirklich "ungefiltert" - daß eine FRITZ!Box so gar nicht reagieren will (der "Security-Port" 49443 für TR-064 ist m.W. auch nicht wirklich konfigurierbar und kann damit eigentlich nicht abweichen), halte ich eher für unwahrscheinlich. Daß die verwendete Portnummer beim Test des Zugriffs aufs GUI hingegen nicht stimmt, kam schon das eine oder andere Mal vor.

 

[fipsy]

Das hört sich aber eher nach einem Problem mit einer Firewall an, als nach einem "echten" TCP-Problem.

Das sollte man meinen! An die Firewall dachte ich auch schon. Aber eine Deaktivierung brachte keine Änderung. Ich bin dann vom Low-Level TCP weg und habe eine andere HTTP/HTTPS Webclient-Library benutzt. Wenn ich den Request unverschlüsselt mit HTTP, jedoch mit "basic auth" (Nutzername/Kennwort) auf Port 49000 durchführe, kommt eine gültige SID zurück. Führe ich exakt den selben Request mit HTTPS und "basic auth" auf Port 49443 durch, kommt "The connection with the server has been reset" zurück. Wie gesagt, keine Firewall aktiv. Die Fritzbox liefert bei "GetSecurityPort()" auch 49443 zurück. Der stimmt also. Offensichtlich kommen einige Libraries nicht mit der Art und Weise zurecht, wie die Fritzbox das SSL handhabt. Es ist zum Auswachsen!

Den Request kann man ja auch mal zu "fritz.box" auf dem TLS-Port des GUI probieren (anstatt zu "web.de")

Habe ich gemacht. Da kommt beim TCP-Connect ebenfalls sofort (und ohne Wartezeit) "Session aborted" zurück. Das Selbe zu web.de ergibt hingegen eine erfolgreiche Verbindung. Ich habe den GUI SSL-Port der Fritzbox übrigens fest auf 443 eingestellt. Wenn ich mit meinem Browser Port 443 kontaktiere, kommt auch die Anmeldeseite der Fritzbox mit Kennwortabfrage.

Die FRITZ!Box kann obendrein auch noch selbst einen Paketmitschnitt erzeugen ...

Das wusste ich noch gar nicht. Damit muss ich mich wohl mal beschäftigen.

 

[PeterPawn]

Nun gibt es ja mehrere Algorithmen, mit denen so eine TLS-Library arbeiten kann - die FRITZ!Box mag (auch wieder richtigerweise) seit einiger Zeit keine alten Verfahren mehr ... zumal die gängigen Browser (das "responsive design" setzt ohnehin neuere Versionen auf der Client-Seite voraus) inzwischen auch alle TLS1.2 verstehen.

Jedenfalls erwartet die Box m.W. minimal TLS1.0 und wenn solche Libraries schon etwas älter sind (bei VB6 ja nicht so ungewöhnlich), dann kann auch deren Versuch, mit SSLv3 (oder gar SSLv2) zu arbeiten, zu Problemen führen. Wobei das tatsächlich alles erst dann stattfinden würde, wenn eine TCP-Verbindung bereits steht ... der TLS-Handshake erfolgt erst innerhalb dieser Verbindung, kann aber bei "Mißverständnissen" auch umgehend zum FIN-Paket führen.

Wenn hier jedenfalls eine TLS-Library (und ich glaube durchaus verstanden zu haben, daß Du mehrere benutzt/getestet hast) ihre Probleme mit der FRITZ!Box hat, würde ich die Ursache immer noch eher in den Bibliotheken als in der Firmware suchen ... AVM verwendet am Ende hier auch ganz normal die Libraries von OpenSSL und es gibt zwar jede Menge Möglichkeiten für eine unverträgliche Konfiguration zwischen Server und Client, aber da muß sich nun mal der Client nach dem Server richten.

Ein weiterer, möglicher Stolperstein (gerade für irgendwelche Windows-Libraries, die vielleicht noch CAPI (das ist nicht das "Common ISDN API", sondern Microsoft's "Crypto API") verwenden wollen) ist das selbstsignierte Zertifikat der FRITZ!Box ... aber auch das sieht der Client erst im Rahmen des TLS-Handshakes.

Ich würde mal sagen, daß ein erfolgreicher Download der TR-064-Interface-Beschreibung (tr64desc.xml) über die TLS-Verbindung zur FRITZ!Box mit einem Browser (also der Aufruf der URL "https://fritz.box:49443/tr64desc.xml") schon ein ausreichendes Zeichen dafür ist, daß sowohl der Browser als auch die FRITZ!Box hier beide standardkonform arbeiten und das würde ich bei fast jeder möglichen Zusatz-Library für VB6 bis zum Beweis des Gegenteils erst einmal in Zweifel ziehen bzw. (s.o.) auf veraltete Implementierungen tippen.

 

[fipsy]

Ich würde mal sagen, daß ein erfolgreicher Download der TR-064-Interface-Beschreibung (tr64desc.xml) über die TLS-Verbindung zur FRITZ!Box mit einem Browser (also der Aufruf der URL "https://fritz.box:49443/tr64desc.xml") schon ein ausreichendes Zeichen dafür ist, daß sowohl der Browser als auch die FRITZ!Box hier beide standardkonform arbeiten und das würde ich bei fast jeder möglichen Zusatz-Library für VB6 bis zum Beweis des Gegenteils erst einmal in Zweifel ziehen bzw. (s.o.) auf veraltete Implementierungen tippen.

Du hast mich in die richtige Richtung geschubst. Vielen Dank dafür! Und für deine Ausdauer. Ich habe mein Programm statt in der virtuellen Maschine mit der Entwicklungsumgebung jetzt einfach mal auf meinem regulären Arbeitsplatzrechner mit Windows 10 laufen lassen. Und siehe da: Hier funktioniert sowohl der HTTPS-Download der tr64desc.xml über Port 49443, als auch eine Anmeldung mit basic auth über Port 49443 und der Abruf einer gültigen Session-ID. Es muss also irgendwas mit der Maschine zu tun haben, auf der die Entwicklungsumgebung liegt. Ich muss die Umgebung mal auf eine andere VM portieren oder rauskriegen, wo da der Hase im Pfeffer liegt. Auf jeden Fall sind wir jetzt schon einen gewaltigen Schritt weiter. Nochmal vielen Dank für deine Unterstützung und deine Anregungen, die mich motiviert haben, nicht so schnell aufzugeben! Sobald ich neue Ergebnisse habe, sage ich hier natürlich bescheid...

Edit: Mit einem Quick-And-Dirty Workaround konnte ich das Programm jetzt durch eine ganz kleine Änderung einfach auf HTTPS umstellen. Die ersten Tests waren mit meiner 6.93 Firmware erfolgreich. Ich benutze also erstmal weiter CLA, aber über TLS. Ich denke, damit wirst sogar du leben können. Ich habe das Programm jetzt an einen meiner Beta-Tester mit Labor-Firmware geschickt und warte auf die Rückmeldung. Es wird ja gemunkelt, dass die Wählhilfe und der Anrufmonitor bei der 6.98 auch zicken oder sogar nicht mehr funktionieren. Da liegen dann die nächsten Testfelder, wenn der Hauptteil der Software wieder läuft.

 

[fipsy]

Nur mal so als Zwischenbericht: Das Ergebnis des Beta-Testers war positiv. Derzeit arbeite ich nun daran, bei FritzBlock alles sauber auf TLS 1.2 mit CLA umzubauen, damit das Programm zukunftsfähig wird. Wie ich aus anderen Foren herausgelesen habe, funktioniert auch die Wählhilfe für die VoIP-Telefonie nur noch mit TLS und Authentifizierung, weshalb einige andere Utilities wohl auch arge Probleme haben / hatten. Das erscheint besonders logisch, da sonst jede beliebige Malware fröhlich Telefonate nach Timbuktu aufbauen kann. Zum Ausgangsthema dieses Threads ist also abschließend zu sagen, dass TR064 ab Firmware-Version 6.98 nach wie vor vollumfänglich funktioniert, aber eben nur noch mit einer sicheren TLS 1.2 Verbindung.

 

[fipsy]

Huhu!

Ich stehe wieder vor einer Wand. Meine aktuelle Basisversion macht schon wieder Ärger. Ich habe mein Programm nun so aufgebaut, dass es den TLS-Port über GetSecurityPort() zuerst unverschlüsselt über einen HTTP-Request auf Port 49000 holen soll und dann auf diesem sicheren Port mit TLS weiter kommuniziert. Genau das funktioniert aber offenbar bei Firmware 6.98 nicht. Jeder Versuch, mit GetSecurityPort() ohne TLS eine Information zu bekommen, scheitert. Ich beziehe mich dabei auf diese Aussage von dir:

in Abbildung 1 ist sehr dezidiert festgehalten, daß genau Discovery unverschlüsselt über den Port 49000 funktionieren soll und der Aufruf von "GetSecurityPort()" - für alle anderen Funktionen finde ich da gar keine Aussage, daß sie ebenfalls über unverschlüsseltes HTTP auf Port 49000 angeboten werden.

Kannst du nochmal bei der Laborversion testen, ob das bei dir auch nicht - wie von AVM beschrieben - funktioniert?

Ich erzeuge einen HTTP-Request folgender Art, der zurückgewiesen wird:

POST /upnp/control/deviceinfo HTTP/1.1
Connection: keep-alive
SoapAction: urn:dslforum-org:service:DeviceInfo:1#GetSecurityPort
Content-Length: 285
Content-Type: text/xml

<?xml version="1.0" encoding="utf-8"?>
<s:Envelope s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
   <s:Body>
       <u:GetSecurityPort xmlns:u="urn:dslforum-org:service:DeviceInfo:1">
       </u:GetSecurityPort>
   </s:Body>
</s:Envelope>

 

[PeterPawn]

@fipsy:
Bei mir funktioniert der Aufruf (der sieht z.B. so aus, wie der hier: https://www.ip-phone-forum.de/threa...e-firmware-update.286994/page-40#post-2183948) auch mit der folgenden Version noch:

vidar:/tmp # wget -qO- http://192.168.178.3:49000/tr64desc.xml | sed -n -e "\|<systemVersion>|,\|</systemVersion>|p" | xmllint --format -
<?xml version="1.0"?>
<systemVersion>
  <HW>225</HW>
  <Major>153</Major>
  <Minor>6</Minor>
  <Patch>98</Patch>
  <Buildnumber>52128</Buildnumber>
  <Display>153.06.98-52128</Display>
</systemVersion>

.... eine neuere habe ich gerade nicht auf der 7580 installiert.

 

[fipsy]

wget -qO- http://192.168.178.3:49000/tr64desc.xml

Der Abruf von tr64desc.xml funktioniert auch bei mir unverschlüsselt auf Port 49000. Versuche ich aber, GetSecurityPort() auf dem selben Port 49000 unverschlüsselt auszuführen (natürlich ohne Basic Auth), kriege ich die rote Karte. Daher meine Frage.

 

[PeterPawn]

Der Abruf der "tr64desc.xml" diente auch nur der Illustration der installierten Firmware-Version.

Die Abfrage, wie sie im ebenfalls verlinkten PowerShell-Skript zu sehen ist, habe ich noch in diversen anderen Skript-Dateien in Verwendung und eine davon habe ich auf die gezeigte Firmware losgelassen - dabei auch als "NewSecurityPort" die richtigen Angaben erhalten:

[DBG]: PS C:\Users\[...]\PS_FB>> $response.Envelope.Body.GetSecurityPortResponse

u                                     NewSecurityPort
-                                     ---------------
urn:dslforum-org:service:DeviceInfo:1 49443

 

[fipsy]

Okay, das ist ja höchst seltsam. Der XML-Content, wie auch der HTTP-Header sind bei uns beiden in den wesentlichen Punkten identisch. Bleibt mal wieder die Frage, wieso es bei mir nicht funktioniert. *GRUMMEL* Bei meiner Firmware 6.93 funktioniert es nämlich einwandfrei, nur bei dem Beta-Tester mit seiner 7490 und Firmware 6.98 geht es nicht...

 

[PeterPawn]

Dir ist sicherlich auch schon aufgefallen, daß die Angabe "06.98" selbst in Verbindung mit dem Modell 7490 nicht so sehr aussagekräftig ist ... ich habe schon meine Gründe, warum ich selbst immer die komplette Versionsnummer (also inkl. Modell und Build-Nummer) angebe.

Vielleicht probierst Du es ja auch noch einmal mit einem zusätzlichen "Host"-Header im HTTP-Request ... seit 06.98 ist zumindest auch beim TLS eine Auswertung des SNI-Headers dabei, weil nur für die MyFRITZ!-Adresse dann das passende LE-Zertifikat auch von der Box präsentiert wird. Gut möglich, daß das jetzt bei HTTP-Verbindungen auch abgefragt wird und da ein fehlender "Host"-Header im HTTP-Request jetzt am Ende für das CGI zu einem leeren "SERVER_NAME" führt, der final dann zu Deinem Fehler wird (der genaue Fehler ist ja - hier zumindest - auch unbekannt, denn "scheitert" und "wird zurückgewiesen" sind eben auch keine HTTP-Errorcodes oder SOAP-Results).

 

[fipsy]

Dir ist sicherlich auch schon aufgefallen, daß die Angabe "06.98" selbst in Verbindung mit dem Modell 7490 nicht so sehr aussagekräftig ist

Ja, da hast du Recht. Ich hatte mich auch geirrt: Der User hat eine 7590 und keine 7490.

Vielleicht probierst Du es ja auch noch einmal mit einem zusätzlichen "Host"-Header im HTTP-Request

Ja, eine gute Idee! AVM benutzt diesen in seinen Beispielen ebenfalls. Muss hier die IP-Adresse des Hosts angegeben werden, oder reicht auch der Hostname (also z.B. "fritz.box:49000")? Leider war das Logfile, das ich von dem Tester erhalten habe, unvollständig, so dass mir die genaue Firmware-Version und die Fehlernummer derzeit fehlen. Ich hoffe, die Infos bekomme ich noch nachgeliefert. Inzwischen bin ich so genervt, dass ich schon dazu tendiere, mir eine zweite Fritzbox nur für Testzwecke zuzulegen. Auf jeden Fall danke für deine Informationen, so weiß ich zumindest, dass es grundsätzlich funktionieren muss!

 

[fipsy]

Ich habe jetzt mal mit Wireshark den TCP-Transfer meiner beiden Versionen direkt verglichen. Also die, die funktionierte und die, die nicht funktionierte. Du hast wohl mal wieder direkt ins Schwarze getroffen *verneig*! Im unten angehängten Screenshot wird es ab Zeile 14 interessant: Im funktionierenden Beispiel gibt es noch die Header "Accept:" und "Host:". Alles andere ist hingegen völlig identisch. Es muss also wohl genau daran liegen. Vielen Dank wieder einmal für deinen Tipp!

 

[fipsy]

Vielleicht probierst Du es ja auch noch einmal mit einem zusätzlichen "Host"-Header im HTTP-Request ...

Zur Bestätigung: Das war tatsächlich die Ursache! TR-064 benötigt ab Firmware-Version 6.98 zumindest beim Transfer mit HTTP auf Port 49000 einen "Host:"-Header! Sonst wird die Anfrage mit HTTP-Fehler 400 (Bad Request) abgewiesen. Ob der "Accept:"-Header ebenfalls notwendig ist, kann ich noch nicht sagen, aber ich vermute mal eher nicht.

 

[PeterPawn]

@fipsy:
Es sieht inzwischen tatsächlich auch für mich so aus, als ob beim TR-064-Zugriff ohne TLS am Ende nur der "Host"-Header inzwischen unbedingt benötigt wird. Im Rahmen anderer Tests (des FBEditors) hat jedenfalls auch der Zugriff über den Port 49000 mit Digest-Auth (CLA habe ich nicht probiert, weil ich das Vermischen der "Schichten" ohnehin ablehne) bei einer 113.06.98 funktioniert - aber wenn Du es jetzt schon mal auf TLS umgestellt hast, wirst Du ja hoffentlich auch dabei bleiben (wollen).

 

[fipsy]

Huhu!

@PeterPawn: Ja, ich werde bei TLS bleiben. Es ist eh die selbe (neue) Library, die HTTPS ebenso wie HTTP unterstützt. Ich versuche jetzt, ein maximal breites Spektrum an möglichen Betriebssystem / Fritz!OS Kombinationen abzudecken, indem ich zuerst auf Port 49000 die tr64desc.xml hole, danach mit GetSecurityPort den TLS-Port unverschlüsselt hole und dann auf dem SecurityPort verschlüsselt weiter mache. Wenn das fehl schlägt, versuche ich alles nochmal unverschlüsselt auf Port 49000. Für den Fall, dass jemand doch noch ein OS ohne TLS 1.2 verwenden sollte. Was dann aber auch nur mit Fritz!OS kleiner gleich 6.93 funktioniert. Daher möchte ich auch vorerst nicht auf CLA verzichten. Denn bei grundsätzlicher Nutzung von CLA ist es softwaretechnisch völlig wumpe, ob auf höherer Ebene HTTP oder HTTPS benutzt wird, da in beiden Fällen ohne Basic Auth gearbeitet wird.

Seit einigen Wochen läuft die Betaversion von FritzBlock mit TLS 1.2 bei einigen Testusern ohne Probleme, so dass es dann in Kürze den Release geben kann.

Letztens hatte ich bei einem User allerdings einen äußerst kuriosen Fall. Vielleicht kannst du den ja erklären? Der Abruf von tr64desc.xml im Browser mit

http://fritz.box:49000/tr64desc.xml

schlug grundsätzlich fehl und wurde von der Fritz!Box 7490 (Firmware 6.92) mit HTTP Fehler 400 beantwortet. Der Abruf mit

https://fritz.box:49443/tr64desc.xml

funktionierte hingegen. Kann das eigentlich sein, dass der Abruf von TR64DESC.XML ungesichert mit HTTP nicht möglich ist und nur mit HTTPS funktioniert? Kann man die Box irgendwie so einstellen? Gibt es eine Erklärung für dieses Verhalten? Ich hatte das vorher noch nie.

 

[fipsy]

Da wir uns hier schonmal vor 3 Jahren auch zur Action GetPhonebook unterhalten hatten, mach ich dazu mal weiter, zumal es keinen anderen Thread gibt, der sich damit beschäftigt. Einige meiner Nutzer haben mittlerweile das Problem, dass sie Telefonbücher mit mehr als 999 Einträgen haben. Diese können über TR-064 nicht heruntergeladen werden, bzw. nur die ersten 999 Einträge. Es gibt einen Parameter "max" für die URL, mit dem man angeben kann, wieviele Einträge man haben möchte, default ist 999. Also z.B.:

https://192.168.178.1:49443/phonebook.lua?sid=c1eacf7ea8b17aae&pbid=0&max=999

Wenn man mehr als 999 angibt, werden trotzdem nur die ersten 999 Einträge zurückgeliefert. Das macht TR-064 für die Verwaltung größerer Telefonbücher völlig unbrauchbar. Hat jemand eine Lösung für das Problem oder kann irgendwas dazu sagen?

 

[Grisu_]

Eine Fritzbox ist eben keine Telefonanlage und auch die haben Limits. Die muß das nebenbei hermachen damit sie auch noch Router und Modem spielen kann.
Wenn man tatsächl. so viele Einträge braucht wird man nicht umhinkommen eine professionelle Lösung dafür anzuschaffen.