Kommunikation callmonitor <> webcm funktioniert nicht

[gurkäää]

Hallo,
ich hatte heute endlich mal Zeit, freetz auszuprobieren. Gleich den aktuellen Trunk (rev 3356) mit der neuen AiO-Firmware. Installation hat funktioniert, allerdings tut der callmonitor noch nicht wirklich, was er soll.
Erst mal wird der Port nicht automatisch angeschaltet, ich bekomm ständig

May 19 17:45:14 fritz daemon.info callmonitor: Trying again in 1 seconds ...
May 19 17:45:15 fritz daemon.info callmonitor: Auto-dialing #96*5* to enable telefon's interface ...

Von Hand wählen ist kein Problem, dann funktionierts das zumindestens. Hilft mir aber nicht weiter, da ich mit callmonitor nichts anfangen kann. Es scheint so, als ob der mit webcm nicht richtig kommunizieren kann: Alles, was darüber läuft, funktioniert nicht, z. B.:

# callaction config wlan
error

Bei

# callaction config wlan on

passiert einfach nichts.
Selbst wenn ich das Passwort der Box rausnehme, funktionierts nicht, obwohl ich dann ganz viele Anmeldung von 127.0.0.1 angezeigt bekomme, mit Passwort nicht.

Landes- und Ortsvorwahl werden auch nicht korrekt übernommen, da stehen "HTML-Reste" drin, vom Anfang eines Dokuments. Ich vermute mal, dass das auch über webcm abgefragt wurde, aber ordentlichen Output eine Fehlermeldung in HTML zurück kam, die dann auseinander genommen wurde.

Ich kann nur ganz vage vermuten, ist wie gesagt mein erster Versuch mit freeze:
Ich hab maln bisschen von Hand mit dem webcm rumexperimentiert... Kanns sein, dass callmonitor die Session-Id (sid) per POST nicht mitsendet? Ohne die gehts nicht. Ist das vielleicht neu in dieser Firmware?

 

[Silent-Tears]

Nun, interessanter Einstieg hier im Forum, aber nun gut. Vielleicht verifizierst du deine Vermutung/Behauptung schlicht, indem du den callmonitor mit einer anderne Firmware testest? Denn hier zumindest tut er das, was er soll.

Die Sache mit dem Port (und der händischen - einmaligen - Anwahl hätte dir die Boardsuche schon gezeigt.

Poste doch mal deine Listener (verfälschte rufnummern), damit jemand versuchen kann, das nachzustellen, und dazu am bestne deine debug-Logs vom Callmonitor (Also der Teil im Syslog, nachdem du den Debug-Mode angestellt hast und callmonitor neu gestartet)

 

[gurkäää]

Danke schon mal.

Nun, interessanter Einstieg hier im Forum, aber nun gut.

Hehe, wenn du meinst.

Vielleicht verifizierst du deine Vermutung/Behauptung schlicht, indem du den callmonitor mit einer anderne Firmware testest? Denn hier zumindest tut er das, was er soll.

Würd ungern downgraden grade, vielleicht mach ichs morgen doch mal. Hast du denn die selbe Firmware? Sonst jemand bei dem z. B. WLAN ausschalten über callmonitor mit der 54.04.74 funktioniert?

Die Listener ist noch leer, es hängt ja direkt an den Actions, also man kann auch über callaction direkt nachvollziehen, ob der Fehler auftritt.
Der Debug-Output gibt genau das, was ich geschrieben hab, halt sehr oft. Sonst nichts.

PS:

Die Sache mit dem Port (und der händischen - einmaligen - Anwahl hätte dir die Boardsuche schon gezeigt.

Ja... hatte sie auch. Aber wie gesagt, bringt letztendlich nichts.


Edit:
Ahh! Habs gefunden: Technical Note von AVM. Es wurde tatsächlich eine Session-ID eingeführt, um Cross Site Request Forgery zu verhindern. Das ist ein Sicherheitsproblem, bei dem ein Angreifer dann erfolgt hätte, wenn man noch in der Box eingeloggt ist und eine bösartige Seite aufruft.

 

[olistudent]

Hm, sehr interessant. Danke für das Dokument.

MfG Oliver

 

[MrXYZ]

Edit:
Ahh! Habs gefunden: Technical Note von AVM. Es wurde tatsächlich eine Session-ID eingeführt, um Cross Site Request Forgery zu verhindern. Das ist ein Sicherheitsproblem, bei dem ein Angreifer dann erfolgt hätte, wenn man noch in der Box eingeloggt ist und eine bösartige Seite aufruft.

Das würde auch das Verhalten von Transmission Remote Gui erklären das ich neuerdings habe.