TR064: Probleme mit der Authorisierung (401 Authorized)

c-f-g

Neuer User
Mitglied seit
22 Jan 2018
Beiträge
8
Punkte für Reaktionen
0
Punkte
1
Ich möchte eigentlich nur einen Probe-Request absetzen und habe mich für die externe IP entschieden.

Mein aktueller Test findet im Postman statt und ich arbeite mit einer SID, die ich meiner Meinung nach auch korrekt über ein Pre-request-Script erhalte:

Javascript:
// Challenge + SID holen
pm.sendRequest({
    url: 'http://192.168.178.1/login_sid.lua',
    method: 'GET'
}, function (err, res) {
    if (err) { console.log(err); return; }
   
    const challengeMatch = res.text().match(/<Challenge>(.*?)<\/Challenge>/);
    const sidMatch = res.text().match(/<SID>(.*?)<\/SID>/);

    if (!challengeMatch) {
        console.log("Challenge nicht gefunden!");
        return;
    }

    if (challengeMatch) pm.collectionVariables.set("challenge", challengeMatch[1]);
    if (sidMatch) pm.collectionVariables.set("sid", sidMatch[1]);
   
    console.log("Challenge:", pm.collectionVariables.get("challenge"));
    console.log("SID:", pm.collectionVariables.get("sid"));

    const hashInput = pm.collectionVariables.get("challenge") + "-" + pm.collectionVariables.get("password");
    const encoder = new TextEncoder("utf-16le");
    const data = encoder.encode(hashInput);

    // CryptoJS MD5 (Postman built-in)
    const CryptoJS = require('crypto-js');
    const hash = CryptoJS.MD5(CryptoJS.enc.Utf16LE.parse(hashInput));
    const response = pm.collectionVariables.get("challenge") + "-" + hash.toString();
   
    console.log("Response:", response);
    pm.environment.set("response", response);

    // 3. Login POST (neue SID holen)
    pm.sendRequest({
        url: `http://192.168.178.1/login_sid.lua`,
        method: 'POST',
        header: {
            'Content-Type': 'application/x-www-form-urlencoded'
        },
        body: {
            mode: 'urlencoded',
            urlencoded: [
                {key: 'response', value: response},
                {key: 'username', value: pm.collectionVariables.get("username")}
            ]
        }
    }, function (err, loginRes) {
        if (err) {
            console.log("Login Fehler:", err);
            return;
        }
       
        // Neue SID extrahieren
        const newSidMatch = loginRes.text().match(/<SID>(.*?)<\/SID>/);
        if (newSidMatch) {
            const newSid = newSidMatch[1];
            pm.environment.set("sid", newSid);
            console.log("✅ NEUE SID:", newSid);
        } else {
            console.log("❌ SID nicht gefunden:", loginRes.text());
        }
    });      
});

Meine Url: http://192.168.178.1:49000/upnp/control/wanipconnection1

Headers:
Content-Type: text/xml; charset=utf-8
SoapAction: urn:dslforum-org:service:WANIPConnection:1#GetExternalIPAddress
Cookie: sid=c82c75176d842922

Body:
XML:
<?xml version="1.0"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" soap:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
  <soap:Body>
    <u:GetExternalIPAddress xmlns:u="urn:dslforum-org:service:WANIPConnection:1"/>
  </soap:Body>
</soap:Envelope>

Response:

HTML:
<HTML>

<HEAD>
    <TITLE>401 Unauthorized (ERR_NONE)</TITLE>
</HEAD>

<BODY>
    <H1>401 Unauthorized</H1><BR>ERR_NONE
    <HR><B>Webserver</B> Sun, 30 Nov 2025 16:52:31 GMT
</BODY>

</HTML>

Was mache ich falsch?

Oder muss ich einen anderen Namespace verwenden?
In meiner http://192.168.178.1:49000/tr64desc.xml finde ich unter serviceId:
urn:WANIPConnection-com:serviceId:WANIPConnection1

Wenn ich das verwende, dann erhalte ich folgende Response:
XML:
<?xml version="1.0"?>
<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/" s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
    <s:Body>
        <s:Fault>
            <faultcode>s:Client</faultcode>
            <faultstring>UPnPError</faultstring>
            <detail>
                <UPnPError xmlns="urn:schemas-upnp-org:control-1-0">
                    <errorCode>401</errorCode>
                    <errorDescription>Invalid Action</errorDescription>
                </UPnPError>
            </detail>
        </s:Fault>
    </s:Body>
</s:Envelope>

Was irgendwie komisch ist, da ich bei einem Authorisierungsproblem immer 401 erwarten würde.
 
habe mich für die externe IP entschieden.
[…]
Meine Url: 192.168.178.1
Das ist schon mal ein Widerspruch
Das gesamte Netz 192.168.178.0/24 ist nach meinem Verständnis intern
 
Meine Url meint die Url die ich aufrufe. Das ist natürlich die interne IP der Fritze.
 
@Novize:
Er meinte sicherlich, er will die externe IP-Adresse per TR-064 ermitteln als "Übung".

@c-f-g:
Wie wäre es denn mal mit vollständigem(!) Code, inkl. aller Log-Ausgaben, die dann auch den tatsächlich gesendeten Request beinhalten? Leider zeigst Du immer nur Teile davon und greifst dann immer wieder auf eigene Prosa zurück.

Wie so ein TR-064-Request korrekt aussehen sollte, ist einerseits bei AVM dokumentiert: https://fritz.com/pages/schnittstellen - aber mal abgesehen davon … wo ist denn beschrieben, man solle/müsse eine (über das GUI ermittelte) Session-ID mit einem "Cookie"-(HTTP-)Header im SOAP-Request übermitteln? Zumindest habe ich das so noch nie gesehen - und kann mich auch nicht erinnern, das irgendwo in einer Spec gelesen zu haben (EDIT: aber ich nehme dafür gerne eine Quellenangabe).

Andererseits findet man hier (mit etwas Suchen) auch genug Beispiele (vielleicht in anderen Sprachen und nicht unbedingt in JS), wie so ein Request aussehen muß und wie man sich dafür authentifiziert - hier: https://github.com/PeterPawn/YourFritz/tree/main/tr-064 gäbe es drei Beispiele in PowerShell. Bei der Suche hilft die boardeigene allerdings nicht wirklich weiter, weil "TR-064" nicht richtig in den Index aufgenommen wird (das wird in "TR" und "064" zerlegt und beides ist zu kurz für den Index). Aber eine (passende) externe Suche ist sinnvoll(er) und funktioniert auch - ich erhalte dabei 328 Treffer zur Zeit.

Und wenn es für einen Request eine Authentifizierung braucht, kann die ganz stinknormal per Benutzername und Kennwort mit "HTTP basic auth" im SOAP-Request erfolgen (entweder nach Fehler und Aufforderung oder gleich vorab), was bei einer TLS-gesicherten Verbindung (die geht dann auch üblicherweise an den Port 49443 anstelle von 49000, siehe GetSecurityPort in dieser Beschreibung: https://fritz.support/resources/TR-064_First_Steps.pdf) auch unproblematisch ist, aber natürlich bei unverschlüsselter HTTP-Verbindung vermieden werden sollte/muß.

Welche Alternativen der Authentifizierung es gäbe, steht auch im zuletzt verlinkten Dokument - aber von einem Cookie-Header mit einem sid-KV-Set, steht da iirc auch nichts. Anstelle von CLA (Punkt 4.2.1 - was noch mit Cookies arbeiten würde) würde ich jedenfalls TLS-Verschlüsselung und "basic auth" empfehlen, zumal niemand garantiert, daß GUI-SIDs auch künftig für TR-064-Requests verwendbar sind … immerhin gibt es eine gesonderte TR-064-Funktion zum Erzeugen von SIDs, da wo man tatsächlich welche benötigt.

Wie AVM sich das vorstellt, ist dort (also bei AVM) jedenfalls haarklein beschrieben, inklusive entsprechender Beispiele im Anhang - wenn das auch dann nicht klappen sollte, bitte die "Hinweise" zum Umfang der Problembeschreibung wieder beachten.
 
@Novize:
Er meinte sicherlich, er will die externe IP-Adresse per TR-064 ermitteln als "Übung".
Genau.
@c-f-g:
Wie wäre es denn mal mit vollständigem(!) Code, inkl. aller Log-Ausgaben, die dann auch den tatsächlich gesendeten Request beinhalten? Leider zeigst Du immer nur Teile davon und greifst dann immer wieder auf eigene Prosa zurück.
Es gibt keinen Code. Ich schrieb doch, dass ich es mit Postman teste.

Was fehlt Dir denn noch? Die SID erhalte ich übers Pre-Request-Script und dann habe ich den eigentlich Call dokumentiert.
Wie so ein TR-064-Request korrekt aussehen sollte, ist einerseits bei AVM dokumentiert: https://fritz.com/pages/schnittstellen - aber mal abgesehen davon … wo ist denn beschrieben, man solle/müsse eine (über das GUI ermittelte) Session-ID mit einem "Cookie"-(HTTP-)Header im SOAP-Request übermitteln? Zumindest habe ich das so noch nie gesehen - und kann mich auch nicht erinnern, das irgendwo in einer Spec gelesen zu haben (EDIT: aber ich nehme dafür gerne eine Quellenangabe).
Quelle: https://blog.soldierer.com/wp-content/AVM_Technical_Note_-_Session_ID.pdf
Hier läuft nichts über eine GUI? Der ganze Prozess läuft rein über die APIs.
Andererseits findet man hier (mit etwas Suchen) auch genug Beispiele (vielleicht in anderen Sprachen und nicht unbedingt in JS), wie so ein Request aussehen muß und wie man sich dafür authentifiziert - hier: https://github.com/PeterPawn/YourFritz/tree/main/tr-064 gäbe es drei Beispiele in PowerShell. Bei der Suche hilft die boardeigene allerdings nicht wirklich weiter, weil "TR-064" nicht richtig in den Index aufgenommen wird (das wird in "TR" und "064" zerlegt und beides ist zu kurz für den Index). Aber eine (passende) externe Suche ist sinnvoll(er) und funktioniert auch - ich erhalte dabei 328 Treffer zur Zeit.

Und wenn es für einen Request eine Authentifizierung braucht, kann die ganz stinknormal per Benutzername und Kennwort mit "HTTP basic auth" im SOAP-Request erfolgen (entweder nach Fehler und Aufforderung oder gleich vorab), was bei einer TLS-gesicherten Verbindung (die geht dann auch üblicherweise an den Port 49443 anstelle von 49000, siehe GetSecurityPort in dieser Beschreibung: https://fritz.support/resources/TR-064_First_Steps.pdf) auch unproblematisch ist, aber natürlich bei unverschlüsselter HTTP-Verbindung vermieden werden sollte/muß.
Das hatte ich vorher, auch im Postman, probiert. Aber auch hier hatte ich einen 401 erhalten.
Auch jetzt, wenn ich den Cookie-Header deaktiviere und Basic Auth mit meinem User aktiviere, erhalte ich 401.
Zum testen verwende ich meinen Admin-User und unter "Heimnetz" -> "Netzwerk" -> "Netzwerkeinstellungen" ist "Zugriff für Anwendungen zulassen" aktiviert.
Welche Alternativen der Authentifizierung es gäbe, steht auch im zuletzt verlinkten Dokument - aber von einem Cookie-Header mit einem sid-KV-Set, steht da iirc auch nichts. Anstelle von CLA (Punkt 4.2.1 - was noch mit Cookies arbeiten würde) würde ich jedenfalls TLS-Verschlüsselung und "basic auth" empfehlen, zumal niemand garantiert, daß GUI-SIDs auch künftig für TR-064-Requests verwendbar sind … immerhin gibt es eine gesonderte TR-064-Funktion zum Erzeugen von SIDs, da wo man tatsächlich welche benötigt.

Wie AVM sich das vorstellt, ist dort (also bei AVM) jedenfalls haarklein beschrieben, inklusive entsprechender Beispiele im Anhang - wenn das auch dann nicht klappen sollte, bitte die "Hinweise" zum Umfang der Problembeschreibung wieder beachten.
 
Quelle: <Link entfernt wegen Unklarheiten hinsichtlich des Urheberrechts>
Hier läuft nichts über eine GUI? Der ganze Prozess läuft rein über die APIs.
Na ja - wenn man sich etwas genauer mit dem Aufbau des FRITZ!OS befaßt, stellt man schnell fest, daß DIESER Prozess der Anmeldung nicht wirklich über ein eigenes API (application programming interface) läuft, sondern stinknormal über den Aufruf einer bestimmten (Lua-basierten) Seite auf dem HTTP-Server (wenn auch mit XML-Syntax), der ebenso für das GUI zuständig ist (deshalb auch meine Zusammenfassung, das würde über das GUI laufen) und mit den dabei erhaltenen Session-IDs kann man dann diverse andere Funktionen (i.d.R. auch über GUI-Aufrufe) nutzen.

Abgesehen davon finde ich es ebenso befremdlich, wenn man Schnittstellenbeschreibungen referenziert, die einerseits waaahnsinnig veraltet sind (2012 ist inzwischen 13 Jahre her und es gab mittlerweile die eine oder andere Änderung im FRITZ!OS)und wo andererseits zumindest unklar bleibt, ob derjenige, der sie bereitstellt, tatsächlich auch die notwendigen Rechte daran hält.

Es gab und gibt keinen Grund, da eine eigene Kopie vorzuhalten (erst recht nicht, sie auch noch zu veröffentlichen), wenn es doch genauso gut ein Link auf die ursprüngliche Quelle tun würde (auch wenn sich das eher an den Blog-Autoren richten sollte, als an Dich). Und ich bezweifle mal ganz stark, daß AVM hier die Genehmigung(en) nach dem UrhG erteilt hat - das wäre (nach meinen Erfahrungen) gänzlich untypisch.

Abgesehen davon werden dann auch entsprechende Aktualisierungen durch den ursprünglichen Autor erkannt - hier: https://fritz.support/resources/HTTP_Session-ID_DE.pdf findet man die AKTUELLE Version dieser Dokumentation (iirc wahlweise auch in Englisch) und darin kann man EBENFALLS wieder sehen, warum ich meinerseits dieses Verfahren der Anmeldung dem GUI (graphical user interface oder graphisches Webinterface) zurechne … AVM macht das nämlich ebenso, wie man im allerersten Abschnitt "FRITZ!Box Schnittstellen" nachlesen kann.

Das hatte ich vorher, auch im Postman, probiert.
Wie geschrieben - die SID ist hier fehl am Platz und AVM hat haarklein dokumentiert (wenn man die originalen(!) Quellen benutzt und tatsächlich sind die auch einigermaßen aktuell gehalten), wie eine gültige Anmeldung für TR-064-Interfaces auszusehen hat … bis hin zum Umgang mit der 2FA bei den Funktionen, die eine solche erfordern.

Schon die Tatsache, daß Du hier den Port 49000 verwendest, paßt nicht zu einem Versuch, das über TR-064 zu machen (auf GetSecurityPort habe ich schon verwiesen) - Du solltest Dich in die AVM-Dokumente einlesen, speziell auch zu Unterschieden und Gemeinsamkeiten von TR-064 und den IGD-Interfaces bei AVM (IGD-Interfaces können auch ohne Authentifizierung genutzt werden). Da steht dann auch, was man über Port 49000 erreicht und was nicht. Die HTML-formatierte Fehlermeldung irgendwo in #1 deutet jedenfalls eher darauf hin, daß Du da den UPnP-Server angesprochen hast und nicht das TR-064-Interface, denn das "spricht" normalerweise SOAP (bzw. XML als Grundlage dafür), wie Du es bei weiteren Versuchen ja auch festgestellt hast, wenn Du SOAP-Fehler erhältst.

Wenn Dir jemand helfen soll und derjenige nicht selbst mit Postman arbeitet (afaik ist Postman auch mehr auf REST-APIs ausgerichtet als auf SOAP), wirst Du schon genau das zeigen müssen, was an das Interface gesendet wird (notfalls aus einem Packet-Dump extrahiert, wobei das bei TLS-Verschlüsselung ja auch keine Option ist … also bleibt wohl nur, das jeweils sehr, sehr ausführlich loggen zu lassen) und ebenso, wie die jeweilige Antwort aussieht … DAS ist es jedenfalls, was mir fehlt und wenn das bei der Benutzung von Postman als Plattform für Deine Tests nicht möglich ist, ist das vielleicht auch nicht die richtige Wahl für diese Aufgabenstellung.

EDIT:
Tatsächlich scheint sich Postman (von mir unbemerkt) weiterentwickelt zu haben - ja, es gibt inzwischen sogar einen Vergleich zwischen meinem früheren Favoriten SoapUI und Postman: https://www.postman.com/platform/postman-vs-soapui/ - natürlich aus der Postman-Perspektive. Wie weit das jetzt alles mit der kostenlosen Version auch zur Verfügung steht, kann ich nicht beurteilen - jedoch ziehe ich meinen Einwand, es wäre eher auf REST-APIs ausgelegt, zurück.

Aber mit diesen Weiterentwicklungen scheint es ja erst recht ziemlich simpel, alle Informationen zu den eigenen Tests auch bereitzustellen. Um das noch einmal klarer zu formulieren - ein vollständiges(!) Protokoll für einen Request umfaßt sowohl die (teils automatisch von Postman erzeugten) Header, den Body des per POST abgeschickten Requests inkl. der Adresse, an die dieser geht und das vollständige Ergebnis dieses Aufrufs ("Save response …“ in Postman), was dann auch die HTTP-Resultcodes einschließt.
 
Zuletzt bearbeitet:
Wie geschrieben - die SID ist hier fehl am Platz und AVM hat haarklein dokumentiert (wenn man die originalen(!) Quellen benutzt und tatsächlich sind die auch einigermaßen aktuell gehalten), wie eine gültige Anmeldung für TR-064-Interfaces auszusehen hat … bis hin zum Umgang mit der 2FA bei den Funktionen, die eine solche erfordern.
Mhh Postman ist doch eigentlich nur eine einfachere Möglichkeit als Curl beliebige Requests abzusetzen.

Und wie geschrieben kommt der Fehler auch ohne sid bei mir. Einfach indem ich, wie auch von Dir vorgeschlagen, Basic Auth einsetze.
Schon die Tatsache, daß Du hier den Port 49000 verwendest, paßt nicht zu einem Versuch, das über TR-064 zu machen (auf GetSecurityPort habe ich schon verwiesen) - Du solltest Dich in die AVM-Dokumente einlesen, speziell auch zu Unterschieden und Gemeinsamkeiten von TR-064 und den IGD-Interfaces bei AVM (IGD-Interfaces können auch ohne Authentifizierung genutzt werden). Da steht dann auch, was man über Port 49000 erreicht und was nicht. Die HTML-formatierte Fehlermeldung irgendwo in #1 deutet jedenfalls eher darauf hin, daß Du da den UPnP-Server angesprochen hast und nicht das TR-064-Interface, denn das "spricht" normalerweise SOAP (bzw. XML als Grundlage dafür), wie Du es bei weiteren Versuchen ja auch festgestellt hast, wenn Du SOAP-Fehler erhältst.

Port 49000 ist doch einfach Http, während Port 49443 Https wäre. In meinem Szenario (internes Netz und sowieso nur ein Test daher irrelevant). Https hatte ich natürlich auch bereits getestet.
Wenn Dir jemand helfen soll und derjenige nicht selbst mit Postman arbeitet (afaik ist Postman auch mehr auf REST-APIs ausgerichtet als auf SOAP), wirst Du schon genau das zeigen müssen, was an das Interface gesendet wird (notfalls aus einem Packet-Dump extrahiert, wobei das bei TLS-Verschlüsselung ja auch keine Option ist … also bleibt wohl nur, das jeweils sehr, sehr ausführlich loggen zu lassen) und ebenso, wie die jeweilige Antwort aussieht … DAS ist es jedenfalls, was mir fehlt und wenn das bei der Benutzung von Postman als Plattform für Deine Tests nicht möglich ist, ist das vielleicht auch nicht die richtige Wahl für diese Aufgabenstellung.

EDIT:
Tatsächlich scheint sich Postman (von mir unbemerkt) weiterentwickelt zu haben - ja, es gibt inzwischen sogar einen Vergleich zwischen meinem früheren Favoriten SoapUI und Postman: https://www.postman.com/platform/postman-vs-soapui/ - natürlich aus der Postman-Perspektive. Wie weit das jetzt alles mit der kostenlosen Version auch zur Verfügung steht, kann ich nicht beurteilen - jedoch ziehe ich meinen Einwand, es wäre eher auf REST-APIs ausgelegt, zurück.

Aber mit diesen Weiterentwicklungen scheint es ja erst recht ziemlich simpel, alle Informationen zu den eigenen Tests auch bereitzustellen. Um das noch einmal klarer zu formulieren - ein vollständiges(!) Protokoll für einen Request umfaßt sowohl die (teils automatisch von Postman erzeugten) Header, den Body des per POST abgeschickten Requests inkl. der Adresse, an die dieser geht und das vollständige Ergebnis dieses Aufrufs ("Save response …“ in Postman), was dann auch die HTTP-Resultcodes einschließt.
In meinem Eingangspost hatte ich genau diese Parameter (url, alle Headers, den Body und die Response) bereits angegeben.
Die Response-Headers sind nicht aussagekräftig:
1764700421042.pngIch wollte es eigentlich jetzt als curl posten, aber das escaping ist stark von der Umgebung Windows/Linux abhängig, daher bringt das nicht viel Sinn.
Ich weiß nicht wie ich sonst ein reproduzierbares Beispiel zur Verfügung stellen kann.
 
Wenn die Response einen Header WWW-Authenticate für "digest auth" enthält, wird wohl irgendetwas mit der "basic auth" beim Request nicht gestimmt haben - was genau, muß man eben raten, solange man den auslösenden Request nicht kennt.



Es ist zwar bei AVM nicht 100%ig klar kommuniziert, daß (oder ob) der Großteil der TR-064-Funktionen nur über TLS (also Port 49443) zur Verfügung steht, aber wir haben hier (jedenfalls nach meiner Erinnerung und auf die Suche nach Beispielen in diesem Board habe ich auch schon zu Beginn verwiesen) auch schon festgestellt, daß eben NICHT alles auch über ungesicherte HTTP-Verbindungen zum Port 49000 funktioniert bzw. daß es schon einen Unterschied macht, ob so ein HTTP-Request einen passenden Host-Header enthält oder nicht (auf Port 49000 gibt es eben mehrere Interfaces als "virtuelle Server") - bei TLS ist das über die SNI quasi automatisch eingeschlossen.
In meinem Szenario (internes Netz und sowieso nur ein Test daher irrelevant).
Jedenfalls steht bei AVM auch (in https://fritz.support/resources/TR-064_Automatische_Konfiguration_FRITZBox.pdf):
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.
Nun ist das halt nicht eindeutig, wenn da von "empfohlen" die Rede ist und gleichzeitig heißt es: "Erst jetzt können …“ - nur habe ich bisher beim Zugriff über TLS-gesicherte Verbindungen (da dann auch mit "basic pre-auth", was sich sonst verbieten würde) keine Probleme mit der Anmeldung gehabt (den Unsinn mit der SID als Cookie läßt Du ja hoffentlich inzwischen bleiben, auch wenn Du dazu nichts weiter geschrieben hast), wie Du hier in mehreren Threads und in Code-Beispielen auf GitHub nachlesen kannst. Auch andere (die Threads findest Du selbst) hatten i.d.R. Erfolg, wenn sie Port 49443 (richtig) verwendeten.

Hier gab es mal ein paar Diskussionen zu diesem Thema ab der Version 06.98 (daraus wurde dann FRITZ!OS 7): https://www.ip-phone-forum.de/threads/tr-064-problem-e-mit-6-98-inhouse-labor.299082/ und nach #1 geht Dein Request ja auch nicht an die Adresse "fritz.box" (wie sie sicherlich in der SCPD als presentationURL steht?) und enthält wohl gar keinen passenden Header, wenn nicht doch von Postman einer automatisch generiert wird für die verwendete IP-Adresse und Portnummer - wie soll man das sehen/wissen bei dem, was Du bisher gezeigt hast?

Im oben verlinkten AVM-Dokument kann man auch sehen (z.B. im Punkt 10.5 und 10.6), wie ICH mir die Protokollierung von Request und Response vorstellen würde - ob und wie man das mit Postman realisiert bzw. realisieren kann, will ich gar nicht selbst erkunden. Willst Du dafür ein Beispiel "aus meiner Feder" (in diesem Falle halt mit (POSIX-)Shell-Code) sehen, schau Dir die Debug-Ausgabe von juis_check an - SO stelle ich mir das vor.

Denn es gibt eben so viele "Nebenkriegsschauplätze" beim Zugriff auf die TR-064-Funktionen (die AVM auch bei jeder neuen FRITZ!OS-Version mit ändert, schon damit neue Funktionen dort auch verfügbar sind), daß man (bzw. ich, aber vielleicht fühlt sich ja auch jemand anders berufen, Dir zu helfen, der ohne dieses auskommt) sich peinlich genau an die AVM-Dokumentation halten sollte … zumindest erst einmal so lange, bis man eine funktionierende(!) Lösung hat und mit der kann man dann herumspielen und meinetwegen auch die Unterschiede zwischen unverschlüsseltem und verschlüsseltem Interface austesten.

Denn wieso eine (korrekt aufgerufene) TR-064-Funktion Dir anstelle eines SOAP-Fehlers am Ende eine HTML-formatierte Fehlermeldung liefern soll (wie in #1 als erstes gezeigt), kannst Du mir vermutlich auch nicht erklären? Beim nächsten Request mit Namespace-Angabe (wo Du eben genau den geänderten Request NICHT mehr zeigst, weshalb ich der Feststellung:
In meinem Eingangspost hatte ich genau diese Parameter (url, alle Headers, den Body und die Response) bereits angegeben.
auch widersprechen würde), hast Du dann vermutlich irgendeinen anderen (vielleicht auch nur syntaktischen?) Fehler eingebaut, wenn das Ergebnis Invalid Action lautet - nur WIE soll man das sehen, wenn Du den zugehörigen Request nicht mehr zeigst?

Man weiß ja nicht mal, ob das nun erneut mit dem zusätzlichen HTTP-Cookie sid war oder ohne - mal abgesehen davon, daß ich immer noch nicht verstanden habe, wo es gestanden haben soll, daß man die SID in einen Cookie-Header packen solle/müsse/könne. Und wenn ich nichts überlesen habe, gab es seit #1 GAR KEINE Einzelheiten mehr zu dem, was da noch getestet wurde - immer nur ein "funktioniert auch anders nicht".

Allerdings mit Ausnahme des Screenshots mit den Response-Headern, wo aber auch gleich das nächste Fragezeichen auftaucht, woher denn der oben erwähnte und im Screenshot gezeigte WWW-Authenticate-Header kommen mag, wenn da doch "basic pre-auth" mit dem HTTP-Request gemacht wurde - aber ob das auch wirklich der Fall war, sieht man ja wieder nicht und kann/muß es nur raten, weil es hier noch nicht einen (gezeigten) Request mit einem Authorization-Header zu sehen gab. Ich habe jedenfalls bisher noch in keinem (bereits "vorauseilend" authentifizierten) TR-064-Request (mit gültigen Credentials) eine erneute Aufforderung zur Anmeldung (nichts anderes ist dieser Response-Header) erhalten.

Ich würde ja gerne helfen, aber das ist mir (zumindest bisher) noch deutlich zu dünn, als daß da mehr als die paar Ideen für einen Ansatz, die ich bereits geäußert habe, herauskommen könnten.
 
Zuletzt bearbeitet:
Danke für die ausführliche Antwort.
Ich versuche mal auf einen gemeinsamen Nenner zu kommen.
Daher habe ich mich an den Beispielen in Deinem Github-Repo versucht.
Ich wollte die Config ausgeben lassen, erhalte allerdings folgenden Fehler:

Code:
$PSVersionTable.PSVersion

Major  Minor  Build  Revision
-----  -----  -----  --------
5      1      26100  7019

.\config.ps1 -Username all -Password **** -Filename config.txt
Es wurde kein Parameter gefunden, der dem Parameternamen "SkipHeaderValidation" entspricht.

Dann habe ich Dein Beispiel fürs Gerät genommen und so modifiziert, dass es nach meinem Verständnis die IP ausgeben sollte:

Code:
Param([Parameter(Mandatory = $True, Position = 0, HelpMessage = 'the username to login to TR-064')][string]$Username,
      [Parameter(Mandatory = $True, Position = 1, HelpMessage = 'the password to login to TR-064')][string]$Password,
      [Parameter(Mandatory = $False, Position = 3, HelpMessage = 'the internal TR-064 (TLS protected) port, defaults to 49443')][string]$Port = 49443,
      [Parameter(Mandatory = $False, Position = 4, HelpMessage = 'the IP address of the FRITZ!Box, defaults to 192.168.178.1')][string]$Address = "192.168.178.1")

$WebClient = New-Object System.Net.WebClient
$xml_query='<?xml version="1.0"?><soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" soap:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"><soap:Body><u:GetExternalIPAddress xmlns:u="urn:dslforum-org:service:WANIPConnection:1"/></soap:Body></soap:Envelope>'

$WebClient.Encoding = [System.Text.Encoding]::UTF8
$WebClient.Credentials = New-Object System.Net.NetworkCredential($Username, $Password)
[System.Net.ServicePointManager]::ServerCertificateValidationCallback = {$true}
$WebClient.Headers.Set("Content-Type", 'text/xml; charset="utf-8"')
$WebClient.Headers.Set("SOAPACTION", 'urn:dslforum-org:service:WANIPConnection:1#GetExternalIPAddress')
$url = "https://" + $Address + ":" + $Port + "/upnp/control/wanipconnection1"
$response = [xml]$WebClient.UploadString($url, $xml_query)

$response.Envelope.Body.InnerXml

Funktioniert allerdings leider auch nicht:

Code:
.\test.ps1 -Username all -Password ****
Ausnahme beim Aufrufen von "UploadString" mit 2 Argument(en):  "Der Remoteserver hat einen Fehler zurückgegeben: (500)
Interner Serverfehler."
In C:\Users\Chris\Downloads\test.ps1:15 Zeichen:1
+ $response = [xml]$WebClient.UploadString($url, $xml_query)
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [], MethodInvocationException
    + FullyQualifiedErrorId : WebException

-- Zusammenführung Doppelpost by stoney

Okay, Update. Habe jetzt das neueste Powershell aka pwsh (7.5.4) installiert.
Das Config-Beispiel liefert jetzt:

Code:
.\config.ps1 -Username all -Password **** -Filename config.txt




s:Client
UPnPError


866
second factor authentication required

Mein angepasstes Beispiel:

Code:
.\test.ps1 -Username all -Password ****
MethodInvocationException: C:\Users\Chris\Downloads\test.ps1:15
Line |
  15 |  $response = [xml]$WebClient.UploadString($url, $xml_query)
     |  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     | Exception calling "UploadString" with "2" argument(s): "The SSL connection could not be established, see inner
     | exception."
 
Zuletzt bearbeitet von einem Moderator:
Jetzt hast Du mich irgendwo verloren …

Was genau ist denn das für eine config.ps1, die da von Dir aufgerufen wird?

Wenn das am Ende mein GetConfigFile.ps1 aus dem YourFritz-Repo sein sollte - war Dir der Name zu lang und die Auto-Completion (per TAB) zu unbequem, so daß da unbedingt weitere "Unklarheiten" in das Problem eingeführt werden mußten? Wenn es das nicht sein sollte und das eine andere Datei ist - wie genau sieht da dann der Code aus? Wenn ich das richtig sehe im Ergebnis des Aufrufs mit PS 7, ist da die 2FA für den Download der Einstellungsdatei erforderlich - nun mag das ja mittlerweile bei der von Dir verwendeten FRITZ!OS-Version so sein.

Ich hatte das ursprünglich mal vor vielen Jahren hier besprochen: https://www.ip-phone-forum.de/threads/fritzbox-7270-sicherung-automatisieren.283404/post-2138929 und dann Ende 2024 nur noch eine geänderte Version nachgeschoben, die auch mit neueren PowerShell-Versionen funktioniert, aber eben nicht zwangsläufig auch mit neuen FRITZ!OS-Versionen, die inzwischen eine Zwei-Faktor-Authentifizierung für den Download der Konfiguration erfordern. Wie man die 2FA per TR-064 durchführen (lassen) kann, steht in der AVM-Dokumentation.

Wie man die abschaltet (und damit vermutlich auch mein originales Skript wieder zum Laufen bringt), steht ebenfalls in diesem Board, nämlich hier: https://www.ip-phone-forum.de/threa...estätigungen-deaktivieren.314515/post-2524118 oder auch in anderen Beiträgen in dem Thread dort (wenn einem der Aufruf der URL nicht konveniert).

Das (neuere) Skript arbeitet da also (auch bei neueren FRITZ!OS-Versionen) genau wie vorgesehen (und auch so, wie in diesem Falle vom Hersteller mit der 2FA dafür später eingeführt) - auch wenn Du da keine Konfigurationsdatei kriegst, dürfte der Rest genau so funktionieren, wie er soll. Das läßt sich ja leicht prüfen, wenn man es mal mit falschen Credentials probiert - dann sollte (zumindest würde ich das annehmen) ein anderer Fehler auftreten.

Du müßtest Dich jetzt mal festlegen, womit Du genau weiter probieren willst (Plattform, Sprache, FRITZ!OS-Version, mit oder ohne 2FA, etc.) … denn auch PowerShell hat sich in den letzten Jahren deutlich weiterentwickelt (mein GitHub-Repo war auch nur EIN Hinweis, wo man nachlesen kann, wie die (SOAP-)Syntax und die Abläufe aussehen sollten) … nicht zuletzt deshalb habe ich ja das neue GetConfigFile.ps1 für neuere PS-Versionen überhaupt nur geschrieben und gezeigt.

Wenn ich das richtig sehe, willst Du einerseits unbedingt die (veraltete) WebClient-Klasse verwenden: https://learn.microsoft.com/en-us/dotnet/api/system.net.webclient?view=net-10.0 - nur funktioniert das eben nicht länger mit TLS-gesicherten Verbindungen, denn das "Abschalten" der Zertifikatprüfung über ServicePointManager-Callbacks (Zeile 12 in Deinem Schnipsel) hat keinen Effekt mehr auf TLS-Funktionen: https://learn.microsoft.com/en-us/dotnet/api/system.net.servicepointmanager?view=net-10.0 (roter Kasten).

Wenn Du die Fehlermeldung, die Dir ja von PowerShell "angekündigt" wird (Zitat: "… see inner exception.") einfach mal ernst nimmst und eben auch diese "innere Exception" anzeigen läßt, steht da garantiert irgendetwas zur Gültigkeit des von der FRITZ!Box präsentierten Zertifikats.

Solange die also nicht ein zur aufgerufenen URL passendes und gültiges Zertifikat hat, muß man diese Prüfung (in PowerShell zumindest) schon irgendwie abschalten - EINEN Weg dahin (jetzt sogar ohne explizite Nutzung von .NET-Klassen, stattdessen mit PS-Modulen, deren Interface einigermaßen stabil sein sollte) habe ich im neuen GetConfigFile.ps1 gezeigt und vermutlich wäre es schlauer gewesen, DIESE Version für Dein Problem als Vorlage zu verwenden. Oder eben eine ältere PowerShell-Version, wo WebClient einen Versuch des Abschaltens der Zertifikatprüfung noch berücksichtigt.

Aber hier wurden/werden eben wieder verschiedene Probleme und Fehler vermischt - ich denke auch nicht, daß es wirklich sinnvoll ist, vorhandene Beispiele nur einfach abzuändern, ohne den Sinn des Ganzen verstanden zu haben.

Nachdem das neue Beispiel für PS 7 ja mit der neuen PS-Version funktionierte, hätte man sich auch fragen können, warum es das überhaupt gab … und dann eben den eigenen Versuch auf der richtigen(!) Vorlage aufbauen. Es gibt (oder gab bisher) in diesem Board auch nur einen einzigen Thread, in dem von (meinem) GetConfigFile.ps1 die Rede ist bzw. war (Link siehe weiter oben - jetzt kommt dieser Thread hier bald dazu) - der wäre auch nicht so schwer zu finden gewesen und da stand dann etwas ausführlicher, warum es überhaupt 9 Jahre später eine neuere Version für PS 7 braucht (daß die neue Version für PS 7 gedacht war, steht allerdings in der zugehörigen README.md, aber zugegebenermaßen nicht der Grund für das "Nachreichen").



Bitte das jetzt Folgende nicht mißverstehen … aber ich bin mir nicht sicher, was Du dem BISHERIGEN Verlauf dieses Threads an (ggf. neuen) Erkenntnissen entnommen hast (dazu äußerst Du Dich ja nicht mehr) und was genau inzwischen Dein Ziel ist.

Du schreibst zwar etwas von "auf einen gemeinsamen Nenner kommen" - andererseits finde ich, Du zielst mehr auf einen "Beweis" ab, daß auch meine Beispiele eben nicht funktionieren … indem Du irgendwelche Änderungen daran vornimmst, ohne Zusammenhänge verstanden zu haben.

Meine BEISPIELE und anderen (auch mal sehr ausführlichen) Ausführungen in diesem Board sollen (hier immer wieder betont in diversen Threads) Prinzipien zeigen und Zusammenhänge erklären und zum eigenen Mitdenken anregen - sie sind explizit nicht als "Rezepte" zum einfachen Nachkochen gedacht bzw. da, wo das anders sein sollte (und ich eine "Lösung" anbieten will), schreibe ich es i.d.R. dazu.

Weder zum Thema SID für TR-064 noch zur Frage "TLS or plain" für HTTP (bzw. SOAP) kann ich bisher erkennen, ob meine Argumentation bei Dir auf fruchtbaren Boden gefallen ist oder nicht (oder ob Du es einfach nur "auch anders probiert" hast und nun aber wieder zurück willst, weil das eben "auch nicht funktioniert" hat - wenn auch aufgrund anderer Probleme, wie ich versucht habe zu zeigen) … und auch explizite Nachfragen dazu (z.B. zum Cookie-Header bzw. ob es irgendwo eine Quelle für dieses Vorgehen gab) ignorierst Du.

Auch hast Du m.W. noch nicht ein einziges Wort darüber verloren, ob Du Dir die aktuellen AVM-Dokumente überhaupt mal angesehen hast, wie ich es Dir empfohlen hatte … oder ob Du nur auf der Basis von Beispielen zu Deinem Ziel gelangen willst.

Wenn Du in künftigen Beiträgen etwas "zusammenfassen" willst, damit wir WIRKLICH auf einen gemeinsamen Nenner kommen (und ich nicht irgendwelche Argumente ständig wiederholen muß wie eine kaputte Vinyl-Platte), dann schließe dabei doch bitte einmal ein, was Du von meinen bisherigen Worten akzeptiert hast und was nicht bzw. wo Du immer noch der Ansicht bist, irgendein Faktor wäre irrelevant (wie bei Port 49000 vs. 49443 weiter oben). Das macht dann auch das Verfolgen und Verstehen Deiner weiteren Bemühungen leichter … sollte es welche geben (an mir soll es nicht liegen).
 
Ich möchte eigentlich nur einen Probe-Request absetzen und habe mich für die externe IP entschieden.
Ich beziehe mich auf "eigentlich". Möchtest du TR-064 technisch verstehen? Oder möchtest du, wie ich als DAU, TR-064 nur anwenden, weil dir die FritzOS-GUI zu umständlich ist, z.B. um ein paar Daten zwecks Monitoring abzufragen oder etwas einstellen.

Für diese Zwecke nutze ich die FritzBoxShell / jhubig @ github The script allows you to control/check your FritzBox from the terminal with a shell script. It is planned to add more functions in the future. The shell script uses cURL to create an SOAP request based on the TR-064 protocol to talk to the AVM Fritz!Box and AVM Fritz!Repeater.

Seit ca. einem Jahr experimentiere ich mit der Version 1.0.dev herum und bin sehr zufrieden. Damit erhalte ich einen unkomplizierten Überblick über meinen second life Zoo (Fritz!Box OS 6.x - 7.x - 8.x) im LAN und VPN/IPSec. Vor einigen Tagen wollte ich mein aufgesetztes script erweitern und konnte nun auf die brandneue Version umsteigen: v1.2.0 - BACKUP Fix + Fritz!Box OS 8 Compatibility Nichts grafisches, aber einiges lässt sich automatisieren. sh/bash kannst du? Heute habe ich in Rekordgeschwindigkeit von zwei handvoll Fritzboxen je ein aktuelles BACKUP-Config.export erstellt. Vielleicht ist die https://github.com/jhubig/FritzBoxShell auch etwas für dich.
 
Zuletzt bearbeitet:
Jetzt hast Du mich irgendwo verloren …

Was genau ist denn das für eine config.ps1, die da von Dir aufgerufen wird?

Wenn das am Ende mein GetConfigFile.ps1 aus dem YourFritz-Repo sein sollte - war Dir der Name zu lang und die Auto-Completion (per TAB) zu unbequem, so daß da unbedingt weitere "Unklarheiten" in das Problem eingeführt werden mußten?
Ja genau. Das ist Dein GetConfigFile.ps1. Ich habe halt den Code kopiert und wollte nicht so viel tippen bei der Ausführung. Damit wollte ich nur mal testen ob es generell bei mir nicht funktioniert oder was sonst das Problem ist.
Mit der neusten Powershell-Version wird ja zumindest mal etwas ausgegeben.
Du müßtest Dich jetzt mal festlegen, womit Du genau weiter probieren willst (Plattform, Sprache, FRITZ!OS-Version, mit oder ohne 2FA, etc.) … denn auch PowerShell hat sich in den letzten Jahren deutlich weiterentwickelt (mein GitHub-Repo war auch nur EIN Hinweis, wo man nachlesen kann, wie die (SOAP-)Syntax und die Abläufe aussehen sollten) … nicht zuletzt deshalb habe ich ja das neue GetConfigFile.ps1 für neuere PS-Versionen überhaupt nur geschrieben und gezeigt.
Powershell habe ich jetzt nur gewählt, weil Du es einsetzt. Eigentlich soll am Ende eine App stehen mit der ich Geräte in andere Gruppen schieben oder sie deaktivieren kann.
Am Anfang eines Projekts wähle ich eigentlich immer einfache Beispiele um die generelle Funktionalität zu testen und hangele mich dann zu schwierigeren vor.
Daher auch Postman. Aber wenn das bereits fehlschlägt ist es natürlich doof.
Wenn ich das richtig sehe, willst Du einerseits unbedingt die (veraltete) WebClient-Klasse verwenden: https://learn.microsoft.com/en-us/dotnet/api/system.net.webclient?view=net-10.0 - nur funktioniert das eben nicht länger mit TLS-gesicherten Verbindungen, denn das "Abschalten" der Zertifikatprüfung über ServicePointManager-Callbacks (Zeile 12 in Deinem Schnipsel) hat keinen Effekt mehr auf TLS-Funktionen: https://learn.microsoft.com/en-us/dotnet/api/system.net.servicepointmanager?view=net-10.0 (roter Kasten).
Will ich gar nicht. Ich wollte einfach ein funktionierendes Beispiel als Basis verwenden.
Wenn Du die Fehlermeldung, die Dir ja von PowerShell "angekündigt" wird (Zitat: "… see inner exception.") einfach mal ernst nimmst und eben auch diese "innere Exception" anzeigen läßt, steht da garantiert irgendetwas zur Gültigkeit des von der FRITZ!Box präsentierten Zertifikats.
Aussagekräftig ist das leider nicht:
Code:
.\test.ps1 -Username all -Password ****
MethodInvocationException: test.ps1:15
Line |
  15 |  $response = [xml]$WebClient.UploadString($url, $xml_query)
     |  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     | Exception calling "UploadString" with "2" argument(s): "The SSL connection could not be established, see inner
     | exception."
exMessage: Exception calling "UploadString" with "2" argument(s): "The SSL connection could not be established, see inner exception."
exInnerMessage: The SSL connection could not be established, see inner exception.
exInnerInnerMessage: The SSL connection could not be established, see inner exception.
exInnerInnerInnerMessage: There is no Runspace available to run scripts in this thread. You can provide one in the DefaultRunspace property of the System.Management.Automation.Runspaces.Runspace type. The script block you attempted to invoke was: $true
exInnerStack:    at System.Net.HttpWebRequest.GetResponse()
   at System.Net.WebClient.GetWebResponse(WebRequest request)
   at System.Net.WebClient.DownloadBits(WebRequest request, Stream writeStream)
   at System.Net.WebClient.UploadBits(WebRequest request, FileStream readStream, Byte[] buffer, Int32 chunkSize, Byte[] header, Byte[] footer)
   at System.Net.WebClient.UploadDataInternal(Uri address, String method, Byte[] data, WebRequest& request)
   at System.Net.WebClient.UploadString(Uri address, String method, String data)
   at CallSite.Target(Closure, CallSite, Object, Object, Object)
Bitte das jetzt Folgende nicht mißverstehen … aber ich bin mir nicht sicher, was Du dem BISHERIGEN Verlauf dieses Threads an (ggf. neuen) Erkenntnissen entnommen hast (dazu äußerst Du Dich ja nicht mehr) und was genau inzwischen Dein Ziel ist.

Du schreibst zwar etwas von "auf einen gemeinsamen Nenner kommen" - andererseits finde ich, Du zielst mehr auf einen "Beweis" ab, daß auch meine Beispiele eben nicht funktionieren … indem Du irgendwelche Änderungen daran vornimmst, ohne Zusammenhänge verstanden zu haben.
Gemeinsamer Nenner Powershell halt. Ein Script in einer Sprache die Du nachvollziehen kannst. Mit einem sehr einfachen Beispiel.
Meine BEISPIELE und anderen (auch mal sehr ausführlichen) Ausführungen in diesem Board sollen (hier immer wieder betont in diversen Threads) Prinzipien zeigen und Zusammenhänge erklären und zum eigenen Mitdenken anregen - sie sind explizit nicht als "Rezepte" zum einfachen Nachkochen gedacht bzw. da, wo das anders sein sollte (und ich eine "Lösung" anbieten will), schreibe ich es i.d.R. dazu.

Weder zum Thema SID für TR-064 noch zur Frage "TLS or plain" für HTTP (bzw. SOAP) kann ich bisher erkennen, ob meine Argumentation bei Dir auf fruchtbaren Boden gefallen ist oder nicht (oder ob Du es einfach nur "auch anders probiert" hast und nun aber wieder zurück willst, weil das eben "auch nicht funktioniert" hat - wenn auch aufgrund anderer Probleme, wie ich versucht habe zu zeigen) … und auch explizite Nachfragen dazu (z.B. zum Cookie-Header bzw. ob es irgendwo eine Quelle für dieses Vorgehen gab) ignorierst Du.

Auch hast Du m.W. noch nicht ein einziges Wort darüber verloren, ob Du Dir die aktuellen AVM-Dokumente überhaupt mal angesehen hast, wie ich es Dir empfohlen hatte … oder ob Du nur auf der Basis von Beispielen zu Deinem Ziel gelangen willst.

Wenn Du in künftigen Beiträgen etwas "zusammenfassen" willst, damit wir WIRKLICH auf einen gemeinsamen Nenner kommen (und ich nicht irgendwelche Argumente ständig wiederholen muß wie eine kaputte Vinyl-Platte), dann schließe dabei doch bitte einmal ein, was Du von meinen bisherigen Worten akzeptiert hast und was nicht bzw. wo Du immer noch der Ansicht bist, irgendein Faktor wäre irrelevant (wie bei Port 49000 vs. 49443 weiter oben). Das macht dann auch das Verfolgen und Verstehen Deiner weiteren Bemühungen leichter … sollte es welche geben (an mir soll es nicht liegen).
Ich habe mein Powershell-Script doch gepostet.
Es verwendet Port 49443.
Es ruft einen Endpunkt auf, der so in der http://192.168.178.1:49000/tr64desc.xml beschrieben ist.
Die aufgerufene Methode ist auch hier beschrieben: https://fritz.support/resources/TR-064_WAN_IP_Connection.pdf
Was soll ich noch tun???
Für diese Zwecke nutze ich die FritzBoxShell / jhubig @ github The script allows you to control/check your FritzBox from the terminal with a shell script. It is planned to add more functions in the future. The shell script uses cURL to create an SOAP request based on the TR-064 protocol to talk to the AVM Fritz!Box and AVM Fritz!Repeater.

Seit ca. einem Jahr experimentiere ich mit der Version 1.0.dev herum und bin sehr zufrieden. Damit erhalte ich einen unkomplizierten Überblick über meinen second life Zoo (Fritz!Box OS 6.x - 7.x - 8.x) im LAN und VPN/IPSec. Vor einigen Tagen wollte ich mein aufgesetztes script erweitern und konnte nun auf die brandneue Version umsteigen: v1.2.0 - BACKUP Fix + Fritz!Box OS 8 Compatibility Nichts grafisches, aber einiges lässt sich automatisieren. sh/bash kannst du? Heute habe ich in Rekordgeschwindigkeit von zwei handvoll Fritzboxen je ein aktuelles BACKUP-Config.export erstellt. Vielleicht ist die https://github.com/jhubig/FritzBoxShell auch etwas für dich.
Danke für die Idee.
Eigentlich dachte ich, dass es ja nicht so schwer sein könnte ein paar HTTP-Requests abzusetzen, aber offenbar doch.
 
Was soll ich noch tun???
Das habe ich doch geschrieben … einfach den passenden Code für die jeweilige PowerShell-Version benutzen, wenn Du jetzt die PS-Beispiele nachvollziehen willst. Für die neue Version 7 hast Du hingegen den alten Code "modifiziert" und warum der in moderneren PS-Versionen SO nicht mehr funktionieren kann, habe ich versucht zu (er-)klären.

Am Ende besagt ja die Fehlermeldung in der "inner exception" auch, daß der Versuch, $true als Skript-Block zu verwenden (steht so in Zeile 12 bei Dir, wird aber erst wirksam, wenn der Request per UploadString gestartet werden soll in Zeile 15, deshalb wird das auch als Fehlerort für die "outer exception" angegeben) so nicht funktioniert. Das geschieht eben dann, wenn der TLS-Server dem Client sein Zertifikat präsentiert.

Mir ist es auch vollkommen egal, welche Sprache Du am Ende verwenden willst. Ich selbst habe Dich auch auf eine POSIX-Shell-Implementierung (für einen anderen SOAP-Service, aber da ging es ja auch nur um die Frage, wie eine Protokollierung aussehen sollte) hingewiesen: https://github.com/PeterPawn/YourFr...a51c28b8081bd24beeb91c43/juis/juis_check#L786

Ich verstehe also auch nicht, warum Du nun der Ansicht bist, PowerShell wäre der (einzige?) gemeinsame Nenner - solange das irgendetwas ist, wo man sowohl alles Relevante für den Request (am besten sogar den "rohen" HTTP-Verkehr) und die Response sehen kann … das habe ich seit #4 doch mehrfach(!) deutlich betont, oder?

Wenn Dir PS nicht liegt oder Du gar keine Erfahrung damit haben solltest, nimm einfach ein Tool (oder auch eine andere Sprache), das Dir eher zusagt … solange Du damit die notwendigen Infos für eine Fehlersuche zur Verfügung stellen kannst (und das dann auch immer machst), ist das (mir zumindest) völlig egal - was es dazu bräuchte, habe ich jetzt auch mehrmals erklärt (oder es zumindest versucht).

Das verwendete OS ist mir ebenso absolut schnuppe - Du hast bisher auch nicht wirklich erwähnt, welche Plattform Du verwendest (aus der Angabe "Postman" kann man das auch nicht sicher schließen). Wenn Du ein passendes Gerät für eine Shell-basierte Lösung hast (das kann eine native Linux-Installation sein oder WSL2 unter Windows oder HomeBrew-Software auf einem Mac), dann bringt Dir ja vielleicht die angesprochene FritzBoxShell tatsächlich auch etwas - auch wenn ich verstanden zu haben glaubte, daß Du nicht nur irgendwelchen fremden Code aufrufen willst, sondern das Ziel eine eigene Lösung (inkl. Implementierung) wäre.

Als Beispiel (halt in Shell-Code mit cURL, aber auch hier im Board schon mehrfach thematisiert) taugt das auch allemal - wobei es eben (auch wegen der notwendigen Variabilität beim finalen Aufruf von cURL, wenn da nicht nur die Nutzung einer(!) Funktion das Ziel ist) nicht so ganz leicht zu durchschauen ist (zumindest nicht ohne Erfahrungen mit Shell-Programmierung), denn es gibt dort (afaik and iirc) keine Debug-Möglichkeiten (jenseits der standardmäßigen Optionen für die Shell selbst).



Es ist ja offenbar auch nicht so, daß hier bisher überhaupt nicht passiert wäre und gar keine Fortschritte erzielt wurden - immerhin gelingt mittlerweile ja der Kontakt zum FRITZ!OS, wenn passender Code für PS 7 verwendet wird. Wenn man's richtig macht, ist das auch nicht auf PowerShell beschränkt - immerhin war hier eine Frage von @jhubig beim TR-064-Aufruf mit cURL ja auch der Auslöser, daß ich das neuere PS-Beispiel überhaupt (vor einem Jahr) eingecheckt habe.

Eigentlich dachte ich, dass es ja nicht so schwer sein könnte ein paar HTTP-Requests abzusetzen, aber offenbar doch.
Eigentlich ist die Benutzung der TR-064-Funktionen bei AVM auch wirklich keine "rocket science" … nur muß man sich damit (wie mit so vielem im Leben) etwas ausführlicher befassen und kann es tatsächlich nicht einfach mal so aus dem Ärmel schütteln. Selbst mit jahrelanger Berufserfahrung als Software-Architekt/-Entwickler gelingt das (hier ist "aus dem Ärmel schütteln" gemeint, nicht die Benutzung von TR-064 an sich) nur wenigen - spätestens dann, wenn man erkannt hat, daß es eben nicht nur "ein paar HTTP-Requests" sind, die es dafür braucht … ich hoffe mal, wenigstens diese Erkenntnis konnte ich vermitteln.
 
  • Like
Reaktionen: Ldwg2002
Ich hatte gerade mal einen passenden Rechner beim Wickel und habe schnell einen Test gemacht.
C-ähnlich:
# SPDX-License-Identifier: GPL-2.0-or-later
###################################################################################
#                                                                                 #
# get external IP address for FRITZ!Box devices in (IP) router mode using plain   #
# or encrypted HTTP protocol                                                      #
#                                                                                 #
###################################################################################
Param([Parameter(Mandatory = $true, Position = 0, HelpMessage = 'the username to login to TR-064')][string]$Username,
      [Parameter(Mandatory = $true, Position = 1, HelpMessage = 'the password to login to TR-064')][string]$Password,
      [Parameter(Mandatory = $false, Position = 3, HelpMessage = 'the IP address of the FRITZ!Box, defaults to 192.168.178.1')][string]$Address = "192.168.178.1",
      [Parameter(Mandatory = $false, Position = 4, HelpMessage = 'the internal TR-064 (TLS protected) port, defaults to 49443')][string]$Port = 49443)
$servicetype = "WANIPConnection:1"
$controlpoint = "/upnp/control/wanipconnection1"
$action = "GetInfo"
# no input parameters for this function call
$inparms = @{
}
$responsenode = "GetInfoResponse"
# show results
$outparms = @{
    "NewExternalIPAddress" = "IP(v4) Address:"
}
$params = [string]::Empty
# build input parameter list
foreach ($param in $inparms.GetEnumerator()) {
    $params = $params + "<" + $param.Name + ">" + $param.Value + "</" + $param.Name + ">"
}
$body = '<?xml version="1.0"?><s:Envelope xmlns:s="http:#schemas.xmlsoap.org/soap/envelope/" s:encodingStyle="http:#schemas.xmlsoap.org/soap/encoding/"><s:Body><u:' + $action + ' xmlns:u="urn:dslforum-org:service:' + $servicetype + '">' + $params + '</u:' + $action + '></s:Body></s:Envelope>'
$headers = @{
    "Content-Type" = 'text/xml; charset="utf-8"'
    "SOAPACTION" = 'urn:dslforum-org:service:' + $servicetype + '#' + $action
}
$pw = ConvertTo-SecureString $Password -AsPlainText -Force
$credential = New-Object System.Management.Automation.PSCredential ($Username, $pw)
if ($port -eq 49000) {
    $proto = "http"
}
else {
    $proto = "https"
}
$uri = $proto + "://" + $Address + ":" + $Port + $controlpoint
try {
    $Error.Clear()
    if ($proto -eq "https") {
        $response = Invoke-WebRequest -Method "POST" -Credential $credential -Uri $uri -Body $body -Headers $headers -SkipHeaderValidation -SkipCertificateCheck
    }
    else {
        # unencrypted authentication needs an additional parameter
        $response = Invoke-WebRequest -Method "POST" -Credential $credential -Uri $uri -Body $body -Headers $headers -SkipHeaderValidation -SkipCertificateCheck -AllowUnencryptedAuthentication
    }
    if ($response.StatusCode -eq 200) {
        $answer = [xml]$response.Content
        foreach ($out in $outparms) {
            Write-Host $out.Values $answer.DocumentElement.Body.$responsenode.GetElementsByTagName($out.Keys).InnerText
        }
    }
}
catch {
    foreach ($err in $Error.GetEnumerator()) { Write-Host $err.ToString() }
}
Mit dem o.a. (PowerShell-)Skript funktioniert (für PS 7) das Ermitteln der externen IP(v4)-Adresse sowohl bei verschlüsselter als auch bei unverschlüsselter Kommunikation - bei passender FRITZ!Box-Konfiguration (die Box muß im Router-Modus ohne PPP sein, siehe Layer3Forwarding:GetDefaultConnectionService). HIER ist also keine verschlüsselte Kommunikation erforderlich - was (nach meiner Erfahrung) aber nicht für alle Funktionen gelten muß, auch wenn sich da wohl immer wieder etwas ändert.

Will man mit PowerShell auch das unverschlüsselte Interface nutzen, muß man (bei "basic auth" ... und "digest auth" kann das verwendete Invoke-WebRequest nicht von alleine: https://learn.microsoft.com/en-us/p...ebrequest?view=powershell-7.5#-authentication) zusätzlich einen entsprechenden Parameter angeben - man sollte es aber einfach vermeiden, selbst wenn man sich im eigenen LAN noch so sicher fühlen mag. Bei "plain HTTP" ist jedenfalls "eavesdropping" nur eine Fingerübung ... und Angriffstechniken im LAN (u.a. MAC-Spoofing - https://byte-sized.de/hacking/mac-spoofing-wie-funktioniert-der-angriff/ falls sich jemand damit befassen will) gibt es auch genug. Die wenigsten Privatleute dürften passende Abwehrmaßnahmen in ihrem LAN betreiben ...
 
Zuletzt bearbeitet:
Danke für das Script, Stand PowerShell7.
Die wenigsten Privatleute dürften passende Abwehrmaßnahmen in ihrem LAN betreiben ...
weil der Verbraucher weder (s)eine Geräte-MAC-Adresse kennt, noch von einer randomized-MAC-address gehört hat, geschweige denn den Unterschied erklären kann und was wann nützlich ist. Zur allgemeinen Verwirrung trägt bei, dass manche Unternehmen eine gewürfelte MAC-Adresse als private MAC-Adresse bezeichnen und damit Sicherheit und Trust suggerieren, obwohl die Identität (auch im LAN ohne IAM) verschleiert wird, was ja Ziel des Würfelns ist. Zu allem Überfluss wird nun noch zwischen dauerhafter Randomisierung und nicht persistenter Randomisierung unterschieden.

Kein Verbraucher (Privatleute) macht sich jemals Gedanken zu einem praktikablen Identity-Access-Magangement (IAM oder IPAM) das über ein (möglichst langes, "geheimes") WLAN-Passwort (als technischer PSK) hinaus geht.

Ohne zu wissen ob überhaupt bzw. wie IAM praktiziert wird, schüren Stichworte wie MAC-Spoofing im Kontext von "Privatleuten" und randomized MAC addresses m.E. Panikmache.und komplette Volksverwirrung. Für den technisch versierten Leser ist solch ein Hinweis hilfreich und meist bekannt.

Meine Praxiserfahrung: Jugendliche Spielsüchtige (sogenannte gaming junkies) unternehmen mit MAC-Spoofing ernsthafte Versuche die technischen Netzregelungen (IAM, IPAM) eines Verbraucher-Netzadmins (z.B. als Haushaltsvorstand) zu umgehen. Das ist nun völlig off topic, muss m.E. aber im Zusammenhang mit MAC-Spoofing beim Verbraucher erwähnt werden.
 
Kostenlos!

Statistik des Forums

Themen
247,941
Beiträge
2,277,275
Mitglieder
377,024
Neuestes Mitglied
RobGorter