Callmonitor 1.13 und höher: Ankündigungen und Bedienung

[ao]

Na toll, hatte ich mir doch gedacht.

Außerdem ist mir ist eben aufgefallen, dass der Eintrag bei der Ortsvorwahl im AVM-WebGUI falsch war.
Laut diesem AVM-HowTo gehört nämlich ins 1. Feld die Null und ins 2. Feld der Rest der Ortsvorwahl.
Stattdessen hatte ich im 1. Feld die komplette Ortsvorwahl und im 2. Feld die Durchwahl eingetragen.

(inzwischen korrigiert)

Aber egal, die Darstellung im Freetz-WebGUI ist immer fehlerhaft, was auch immer ich im AVM-WebGUI eintrage.
Wie kann ich denn den Fehler (ggf. in meinem Setup) eingrenzen?

Der Html-Code des Frames sieht an der Stelle so aus:

<fieldset>
<legend>Standortangaben</legend>

<table width='100%'>
<colgroup>
<col width='25%' span='2'>
<col width='50%'>
</colgroup>
<tr>
<td>Landesvorwahl</td>
<td><input disabled size=3 value='310311'>
<input disabled size=4 value='49'></td>
</tr>
<tr>
<td>Ortsvorwahl</td>
<td><input disabled size=3 value='0'>
<input disabled size=4 value=''></td>
<td>
<a target='_blank' href='http://fritz.box/cgi-bin/webcm?getpage=..%2Fhtml%2Fde%2Fmenus%2Fmenu2.html&var%3Alang=de&var%3Apagename=sipoptionen&var%3Amenu=fon'>Ändern</a>
</td>
</tr>
</table>

</fieldset>

 

[_ub_]

klar, es wäre prima wenn SSH vom MP verstanden würde... openssh könnte man auf dem MP natürlich nachinstallieren, aber die ursprüngliche Idee war ja, Anrufer auf dem MP "nativ" anzuzeigen, d.h. ohne ihn zu modifizieren.

Denn wenn ich schon Veränderungen am MP mache, wär's einfacher ich lege dort ein kleines call.cgi ab und greife von der FB per wget drauf zu, als dafür openssh auf dem MP zu installieren...

kann man den ssh-client der FB so einrichten, dass er sich (wie putty) notfalls auch per telnet einloggt?

mit expect könnte man das login timing wohl absichern, aber expect ist in freetz bzw busybox nicht enthalten, oder?

kann man expect per script simulieren, d.h. auf den login prompt warten und "root" (geht am MP ohne passwort 8) eingeben? Leider reichen meine shell-Kenntnisse nicht so weit.

 

[buehmann]

Aber egal, die Darstellung im Freetz-WebGUI ist immer fehlerhaft, was auch immer ich im AVM-WebGUI eintrage.

Hi, die Einstellungen aus dem AVM-Webinterface werden einmalig beim Start des Callmonitors gelesen. Solange du also den Callmonitor nicht neustartest, ändert sich and der Darstellung im Freetz-UI nichts. (Ja, das sollte ich dazuschreiben.)

Schau erst einmal, wie es dann aussieht.

Andreas

PS: Falls ein Fehler bestehen bleibt, lass uns ihn bitte in einem separaten Thread behandeln.

 

[buehmann]

kann man den ssh-client der FB so einrichten, dass er sich (wie putty) notfalls auch per telnet einloggt?

Nein, Telnet und SSH sind zwei paar Schuhe. Putty ist einfach ein Client, der beides kann.

Andreas

PS:

mit expect könnte man das login timing wohl absichern [...] kann man expect per script simulieren?

Deswegen benutzte ich das Wort "eklig" ;-)

 

[ao]

Hi, die Einstellungen aus dem AVM-Webinterface werden einmalig beim Start des Callmonitors gelesen. Solange du also den Callmonitor nicht neustartest, ändert sich and der Darstellung im Freetz-UI nichts. (Ja, das sollte ich dazuschreiben.)

Danke, Andreas, jetzt sieht alles prima aus! Eine Info im CM-WebGUI wäre sinnvoll. Im Freetz-Wiki habe ich einen entsprechenden Hinweis eingefügt.

 

[bodega]

Wegen der MusicPal Geschichte, liegt es wohl tatsächlich an dem URL-Encoding. # ist ein recht ungünstiges Zeichen und verboten.

So dürfte es aber auch gehen (1sec):

wget -O - "http://admin:[email protected]/admin/cgi-bin/ipc_send?show_msg_box%20Hallo§MusicPal!§%231"

 

[_ub_]

MusicPal, ein letztes Mal

@Marco, das ist Gedankenübertragung: genau so funktioniert es. Ich hatte vorhin nämlich einmal die ganze Kette von der FB zum /bin/ipc_send durchgetestet und stellte fest:

Mit '#' und '§' waren wir auf der falschen Fährte, diese Zeichen kommen unversehrt bei /bin/ipc_send an. Das eigentliche Problem scheint in musicpalmessage zu liegen. Mit dieser Action im callmonitor

in:request ^ ^ musicpalmessage admin:admin@musicpal:1234

kommt beim host nämlich das an:

~ $ nc -l -p 1234
GET /admin/cgi-bin/ipc_send?show_msg_box%20Anruf%20an%2012345678%3b%20Berlin%a7von%2087654321%3b%20Berlin%a710 HTTP/1.0
Host: musicpal
User-Agent: callmonitor/1.15
Authorization: Basic YWRtaW46YWRtaW4=

Es fehlt das '#'... Wenn man's ergänzt und zur Simulation denselben String mit nc an den host schickt, erscheint die Nachricht wie gewünscht für 10s und verschwindet wieder:

/var/mod/root # cat | nc musicpal 80
GET /admin/cgi-bin/ipc_send?show_msg_box%20Anruf%20an%2012345678%3b%20Berlin%a7von%2087654321%3b%20Berlin%a7#10 HTTP/1.0
Host: musicpal
User-Agent: callmonitor/1.15
Authorization: Basic YWRtaW46YWRtaW4=

@Andreas, kannst Du Dir das in callmonitor nochmal anschauen? Wenn das wie mit wget und in der Simulation mit nc funktioniert, können wir die ganze Trickserei mit menu_collapse, netcat-Logins etc bleiben lassen...

 

[bodega]

Hallo Ulf,

es reicht ja aus, das #-Zeichen durch ein %23 zu ersetzen. Die §-Zeichen sind kein Problem für die URL. Jedoch müssen mindestens zwei Zeilen gefüllt sein (zwei § in der URL), damit der Timeout auch funktioniert.

Da benötigt man nur das eine wget. Wollte das nur nochmal angemerkt haben. Meinst du, du könntest das mit dem Callmonitor testen?

 

[_ub_]

@Marco, guter Hinweis, dass Timeout nur mit zwei Zeilen funktioniert! Scheint echt so, war mir gar nicht aufgefallen.

Dass wget funktioniert, war mir bei meinen Tests mit nc ja auch aufgefallen; es dauerte allerdings eine Weile, bis mir das fehlende '#' im request vom callmonitor auffiel; erst hatte ich Leerzeichen in den Variablen in Verdacht, aber die werden von getmsg ja sauber ersetzt.

Ich denke, jetzt braucht nur noch musicpalmessage zweizeilig und mit '#' zu senden, und die Sache funktioniert, oder?

Weder '#' noch '§' scheinen offenbar urlencoded zu sein müssen, zumindest bei wget und nc. Zumindest funktioniert zB das hier:

wget -q -O- http://admin:admin@musicpal/admin/cgi-bin/ipc_send?show_msg_box%20Hallo§%20§#1

 

[bodega]

Hey, das geht ja auch so
Hatte es im Browser getestet und da funktioniert es nur, wenn man das # durch %23 ersetzt.

Somit sind alle Fallstricke auf einem Streich eliminiert

 

[buehmann]

Hey, danke! Ich habe tatsächlich das # aka %23 vergessen, was lustig ist, weil ich mich noch genau daran erinnere, wie ich die Hexcodes von § und # nachgeschaut habe. Wenn ich das nachtrage, dürfte es auch mit getmsg funktionieren.

Andreas

PS:

Jedoch müssen mindestens zwei Zeilen gefüllt sein (zwei § in der URL), damit der Timeout auch funktioniert.

Welcher Entwickler hat denn das verbrochen? Meint ihr, ich sollte in jedem Fall "§§#$timeout" (URL-kodiert) anhängen, damit es auch mit einer Zeile funktioniert? Könntet ihr kurz überprüfen, ob das akzeptiert wird?

 

[_ub_]

in jedem Fall "§§#$timeout" (URL-kodiert) anhängen

Zwischen zwei '§' wird im Zweifel ein '%20' benötigt. Die Zeichen '§' und v.a. '#' sollten mE besser nicht URL-encoded sein.

Teste ich heute abend nochmal!

@Bodega: Hatte es anfangs auch immer einfach im Browser getestet und völlig unterschätzt, was moderne Browser dem eingegebenen URL auf dem Weg zum host alles antun... wget und nc sind zum Glück noch nicht so consumer-orientiert 8)

 

[buehmann]

Ob komplett leere Zeilen akzeptiert werden, war Teil meiner Frage. Es wäre toll, wenn du das heute Abend probieren könntest. Das '#' muss URL-kodiert werden, da es in URLs eine Sonderbedeutung hat (steht zwischen Query und Fragment).

 

[bodega]

Man darf nur nicht vergessen, dass ipc_send eine kostenlose Zugabe ist, ähnlich wie Fritz!Fax.

Habe mir auch mal die Mühe gemacht, die wget-Befehle hier zu ergänzen: Link.

 

[_ub_]

ipc_send getestet: funktioniert!

wenn ich an meinem MP (1.64FW) teste, funktionieren Variationen dieses Aufrufs:

wget -q -O- http://admin:admin@musicpal-lan/admin/cgi-bin/ipc_send?show_msg_box%20Hallo§%20§#1

unter folgenden Bedingung:

• genau zwei Zeilen Nutzlast werden mit § getrennt ausgegeben (zzgl 1 Zeile für §#1)
• zwischen den letzten beiden '§' vor dem '#' steht mindestens ein Leerzeichen (%20)
• der URL wird nicht von normalen Browsern, sondern von Kommandozeilentools wie wget oder nc abgesetzt (geht sogar unter DOS mit http_get.exe)
• solange der Zeichensatz stimmt (zB Latin1), ist unerheblich, ob die Sonderzeichen '§' und '#' URL-encoded (%A7, %23) sind oder nicht. Leerzeichen u.ä. in der auszugebenden Nachricht müssen URL-encoded sein (%20).

Wenn wir das so implementieren, dürfte der Anrufer-Ausgabe am MusicPal nichts mehr im Wege stehen...

Gruß
Ulf

 

[buehmann]

Hallo Ulf,

danke für das Testen. Eine Nachfrage zu "genau zwei Zeilen": Bei drei oder mehr Zeilen funktioniert es auch nicht mehr mit dem Timeout? (Abgesehen davon, dass Zeile 3 bis n nicht mehr angezeigt wird.)

Andreas

 

[_ub_]

ja, genau.

 

[buehmann]

Dann müsste diese Version von musicpalmessage funktionieren für beliebig viele Eingabezeilen (überzählige werden abgeschnitten), oder? https://svn.berlios.de/svnroot/repo...ase/usr/lib/callmonitor/actions.d/musicpal.sh

Andreas

 

[buehmann]

callmonitor-1.15.1: MusicPal, GoYellow

Hallo,

Version 1.15.1 enthält die neue Aktion musicalpalmessage, mit der man Nachrichten auf dem Display eines MusicPals von Freecom darstellen kann. Es werden maximal zwei Zeilen unterstützt; die Anzeigedauer (standardmäßig 25 Sekunden) kann über die Umgebungsvariable MUSICPAL_TIMEOUT verändert werden. Für den Fall, dass die Anzeige vorher freigegeben werden soll, steht die Aktion musicalpalclear bereit.

Einige Beispiele:

# Standardnachricht, Benutzername und Passwort "admin"
musicpalmessage musicpal.domain.my

# eigene Nachricht mit zwei Zeilen, andere Zugangsdaten
musicpalmessage --user="root" --password="secret" musicpal.domain.my "Wichtiger Anruf${LF}von ${SOURCE}!"

# alternative Syntax
musicpalmessage root:[email protected] "Wichtiger Anruf${LF}von ${SOURCE}"

# Nachricht löschen
musicpalclear musicpal.domain.my

Außerdem ist mir aufgefallen, dass GoYellow seine Rückwärtssuche-Seiten geändert hat: Ich habe die entsprechenden Anpassungen beim Callmonitor vorgenommen.

Viel Spaß

Andreas

 

[olistudent]

Fügt jemand die neue Aktion bitte noch im Trac Wiki ein?

Danke,
Oliver