[Gelöst] [V3.0 IP4] CV TR064-Plugin Probleme bei Aktualisierung

[jensgulow]

Hallo,

ich mal wieder mit einem Problem mit dem TR064-plugin in der Cometvisu.
Lange Zeit lief das bei mir ziemlich stabil.
Nunmehr folgendes Problem:

Nach einem Neuaufruf (z.B. F5) wird alles korrekt geladen und auch angezeigt. Die dazugehörigen Bilder der Netzwerkkonsole:

CV tr064 Plugin 02.jpg

CV tr064 Plugin 03.jpg

Nach der ersten Aktualisierung kann allerdings die identische Adresse nicht mehr erfolgreich aufgerufen werden:

CV tr064 Plugin 04.jpg

Ist für mich ziemlich mystisch. Kann es sein, dass AVM da etwas am login Prozess geändert hat mit dem neuen Fritz-OS 7.29 (das habe ich)? Es sieht doch so aus, als ob die sid nicht mehr akzeptiert würde ..... oder habt ihr eine andere Erklärung? Oder besser noch: eine LÖSUNG?

[jensgulow]

@Chris M. Hast Du da eine Idee?

[jensgulow]

Ich habe mal ein wenig recherchiert....
Hier steht etwas davon, dass bei den neueren FritzOS Versionen das login und das auslesen der notwendigen SID etwas verkompliziert wurde .....

https://avm.de/fileadmin/user_upload/Gl ... 3Nov18.pdf

Nun bin ich ehrlich gesagt zu blöd die soap.php oder auch die proxy.php Datei des TR064 plugins anzupassen .....

Wenn mir jemand einen Anfangspunkt geben kann .....

Hier hat sich mal jemand auch per php Zugriff verschafft:

http://www.apfel-z.net/artikel/Fritz_Bo ... curl_wget/

Aber wie gesagt: das kriege ich selber nicht hin das TR 064-plugin dahingehend "umzubiegen" ....

[Chris M.]

Ich hab's gerade bei mir ausprobiert (CV Entwicklungsversion, Fritz!Box auch mit 07.29) - und es funktioniert. Es scheint also kein systematisches Problem zu sein.

Was Du zur Ursachensuche machen kannst: klick auf den nicht-funktionierenden proxy.php mit rechts und öffne ihn so ein einem neuen Tab. Das sollte funktionieren - wenn das Problem bei Dir aber nicht sporadisch ist, dann wird der Aufruf natürlich auch nicht funktionieren.
Dann kannst Du im Portainer vom CV Container die Konsole öffnen (also nicht die vom Browser, sondern die, mit der Du direkt auf das zu Grunde liegende Linux zugreifen kannst). Und dort führst Du diesen Befehl aus - wobei der Teil hinter der "sid" natürlich dem von der Browser-Konsole (bzw. dem vorhin geöffneten Tab) entsprechen muss:

Code: Alles auswählen

curl -k -v https://192.168.0.1:49443/calllist.lua?sid=bf2c86g1a435e84c

Was kommt da dann für eine Meldung?

[jensgulow]

Hallo Chris ... werde ich ausprobieren. Habe zwischenzeitlich die 0.12.0-dev als docker container auch installiert ...... Da funktioniert es...

[jensgulow]

Hier die Ausgabe der Konsole:

Code: Alles auswählen

* Expire in 0 ms for 6 (transfer 0x55a2b6dbad00)
*   Trying 192.168.0.1...
* TCP_NODELAY set
* Expire in 200 ms for 4 (transfer 0x55a2b6dbad00)
* Connected to 192.168.0.1 (192.168.0.1) port 49443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: none
  CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_128_GCM_SHA256
* ALPN, server did not agree to a protocol
* Server certificate:
*  subject: CN=dghjdghjdghjdghjdghjdghj.net
*  start date: Sep  3 20:38:29 2019 GMT
*  expire date: Jan 15 20:38:29 2038 GMT
*  issuer: CN=alskjdfglasjkhdfaksdflk.xyzz.net
*  SSL certificate verify result: self signed certificate (18), continuing anyway.
> GET /calllist.lua?sid=c161e8c9f5e44707 HTTP/1.1
> Host: 192.168.0.1:49443
> User-Agent: curl/7.64.0
> Accept: */*
>
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* old SSL session ID is stale, removing
< HTTP/1.1 303 See Other
< Connection: close
< Location: /
<
* Closing connection 0

subject:CN und issuer:CN habe ich geändert ....


Wenn ich die proxy.php im neuen Tab öffne:

Code: Alles auswählen

Error: proxy.php couldn't open URI "https://192.168.0.1:49443/calllist.lua?sid=c161e8c9f5e44707&max=6"

[Chris M.]

Ist das wirklich aus dem gleichen Container?

Du hast dort ein "HTTP/1.1 303 See Other" - das hatte ich auch, als ich von meinem lokalen Rechner aus das Curl ausgeführt habe. Sobald ich es aus dem Container habe laufen lassen hat es funktioniert.

Wie ist denn der Container angebunden? Ist es der "offizielle ElabNET" über den TWS installierte, oder ist es über Portainer selbst installiert? Ist es ein Bridge, Host oder MacVLAN?

[jensgulow]

Ja, habe es gerade noch einmal ausprobiert. Das ist aus dem Container. Es ist eine 0.11.2 als Docker über portainer installiert. Der Container ist mit macVLAN. Bisher (>2 Jahre) lief alles ohne Probleme. Hatte bloß gedacht es liegt am neuen FritzOS (weil das seit 2 Wochen auf 7.29. ist) ....

[Chris M.]

OK, dann versuche mal einen Container ganz nach Standard (also mit bridge) zu installieren und dort die hidden-Config und die CV-Config zu nutzen.
Geht es dann?

Falls ja, dann *vermute* ich, dass die Fritz!Box die Anmeldung (die die sid erzeugt) scharf gegen die Mac-Addresse bindet (evtl. erst seit der 07.29?). Und dann durch den MacVLAN-Modus die MAC der Abfrage durcheinander kommt.

[jensgulow]

Könnte wohl sein. Ich probiere es morgen mal. Jetzt geht es ja erstmal mit der 0.12.0-dev Version.
Warum auch immer.....
Der Container läuft ja auch mit MacVLAN....