tr-064: python-post mit lua/sid geht nicht

[hansvonhugo]

Hallo,

ich versuche mitel (micro-) python von einem Raspberry pico per TR-064 auf die Fritzbox zu zu greifen. Teile des Zugrifs klappen schon ganz gut, aber der Aufruf mittels lua/sid klappt nicht.

Hintergrund: Eigendlich möchte ich über einen TR-064-Zugriff das Gastnetz ein- und ausschalten. Ich möchte aber erst einmal zu testen, ob ich einen grundsätzlichen Zugriff überhaupt hinbekomme und die grundsätzliche Kommunikation via TR_064 zu lernen. Da ich kein Beispiel für micropython gefunden habe, habe ich versucht ein Beispiel aus der c't nachzubauen (Artikel aus c't 19/23, Listing zu den darin verwendeten Scripten hier fbsec.py und hier fbgetmacaddr.py ) Diese Beispiele sind zwar bash-Skripte, haben für mich aber den Vorteil, dass dir Kommunikation durch die curl-Aufrufe und darin enthaltenenn Body/Envelope-Daten und Header halbwegs nachvollziehbar ist. Darüber hinaus ist das Zugriffsverfahren mittels Secret statt gespeichertem Passwort gut geeignet, für das was ich vorhabe. Die Kommunikation mittels TR-64 klappt (nach einigem Rumprobieren und mit der Hilfe von Peter-Pawn) grundsätzlich anscheinend schon, nur der finale Abruf der Daten mittels lua/sid klappt nicht.

Hier der Auszug aus dem verwendeten Code, der nicht funktioniert - der gesamte Code ist als Datei angehängt :

# request MAC-List with lua
FBluaControl ='/devicehostlist.lua?sid='
url = FBhost_https + FBPort + FBluaControl + FBlua
print("post url=",url)
response = requests.post(url, headers={'Content-Length': '0'})   
print('response.text=', response.text)

Der oben aufgeführte code gibt kein Ergebnis, bzw der Ergebnisstring "response" bleibt leer - Ergebnis wie folgt:

WLAN-Verbindung ok
FBlua= 2734670666a717b4
post url= https://fritz.box:49443/devicehostlist.lua?sid=2734670666a717b4
response.text=

Der aufgeführte lua-Wert ist der, der aus dem vorhergehenden TR-064-Aufruf extrahiert wurde - Bei Bedarf füge ich die Ergebnisse der vorhergehenden TR-064-Aufrufe gerne bei.

Hier der Teil aus dem bash-Script den ich versuche nachzubilden (ergänzt um echo-Befehle um die Details des Aufruf und der lua/sid zu sehen (das Bashskipt funktioniert und gibt die gewünschten Werte in "r" zurück):

FBlua=$(xmlstarlet sel -t -v //NewX_AVM-DE_HostListPath <<<${r})
echo "FBLUA "${FBlua}

r=$(curl -s -k -m 5 "${FBhost}${FBlua}")
echo "curl -s -k -m 5 ${FBhost}${FBlua}"

Was ich erfolglos probiert habe:
- keine Angabe eines Length Headers => gibt Fehler "411 Length Required"
- angabe eines Header > 0 => gibt gar kein ergebnis; das Programm scheint nach dem request-Aufruf abzubrechen
- verwenden von get => kein ergebnis; Antwort String ist leer

Meine Erwartung wäre, dass der letzte Aufruf mittels sid/lua einen String mit Daten zurückgibt, so wie im bash-script - was aber nicht geschieht.

Hat jemand eine Idee, woran es liegen könnte? - bin für jede Hilfe dankbar ...

 

[PeterPawn]

1. Das ist nun mal ein GET, was da erfolgen soll - einfach mal die Optionen des curl-Aufrufs aus dem Beispiel genauer untersuchen oder siehst Du da irgendwo eine Option mit data-Bezug, die für einen POST-Aufruf sprechen würde?

2. Bei einem GET braucht es dann auch keinen zusätzlichen Header, auch nicht mit der Größe des Inhalts ... schlicht weil es keinen solchen Inhalt gibt (https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods/GET - zweiter Satz).

 

[hansvonhugo]

Das das eher ein get ist, hatte ich auch schon vermutet und ausprobiert - gibt leider auch kein Rückgabewert - hier nochmal Aufruf und Ergebnis:

FBluaControl ='/devicehostlist.lua?sid='
url = FBhost_https + FBPort + FBluaControl + FBlua
print("get url=",url)
response = requests.get(url )

Ergebnis: Keine Rückgabe

FBlua= da15645a52db546b
get url= https://fritz.box:49443/devicehostlist.lua?sid=da15645a52db546b
response.text=

Irgendwelche Vermutungen woran das liegen könnte?

 

[PeterPawn]

Warum muß man denn Vermutungen anstellen? Der Request wird ja wohl auch noch Status-Informationen liefern und die geben in aller Regel Auskunft darüber, wo das Problem liegt - zumindest einen "Tipp" sollte man daraus dann auch ableiten können.

Ich hoffe mal, daß Du den GET-Request dann auch wirklich zeitnah zum vorhergehenden SOAP-Request ausführst. Dein "Zerpflücken" der vom SOAP-Request gelieferten Antwort läßt mich daran irgendwie zweifeln ... eigentlich steht ja im Rückgabewert die komplette URL (ab der "Wurzel" für den (UPnP-)Server) und warum Du da jetzt die SID herausfummelst und den Dateinamen parallel dazu fest verdrahtest (das ist ohnehin ein Risiko, denn AVM kann den jederzeit ohne weitere Ansagen ändern ... beschrieben ist nur das Interface und nicht das "Format" der URL in der Antwort), verstehe ich einfach nicht.

Jedenfalls hat die ausgegebene SID ein "Verfallsdatum" ... lt. Dokumentation (irgendwo beim Download von Telefonbüchern war das mal so beschrieben, wenn ich mich richtig erinnere) sollen diese Session-IDs nur 30 Sekunden gültig sein (was früher nicht funktionierte, da konnte man mit diesen SIDs auch deutlich länger zugreifen und vor allen nicht nur auf TR-064-Interfaces). Wenn Du das also nicht alles "auf einen Rutsch" ausführen läßt, könnte auch die SID ganz simpel nicht länger gültig sein - aber das gibt dann eben auch den passenden Status-Code.

Ansonsten kannst Du auch selbst in der Lua-Datei nachlesen, was da passiert und wann welcher Fehlercode generiert wird - die steht in der Firmware unter dem Pfad /etc/default.Fritz_Box_HW185/avm/upnp/devicehostlist.lua, wobei die zweite Verzeichnisebene vom Modell der Box abhängig ist (hier ist es eine 7490).

 

[hansvonhugo]

Der status ist 200 - also "ok", aber Du hast mich trotzdem mit deinem Hinweis in die richtige Richtung geschoben. Ich habe nochmal nachgeschaut welche Methoden/Eigenschaftenm das verwendete Request-Objekt hat um dort ggf. erweiterete Status-Informationen auszulesen und dabei gesehen, dass es noch eine read-Funktion gibt. Ich hatte angenommen, dass das ergebnis des get auch in der eigenschaft text gespeichert wird, was aber nicht der fall ist. die Daten aus dem get werden vielmehr mittels nachfolgendem read gelesen - lange Rede kurzer Sinn: der Aufruf hatte funktioniert, ich hab es bloss nicht gemerkt und nicht die Daten auf die richtige weise abgerufen. Insofern: Problem gelöst und Dir vielen Dank!