Callmonitor 1.*

[kriegaex]

Keine Ahnung, ob das reguläre Ausdrücke (rA) sind. Aber Sternchen und andere Meta-Zeichen kann man mittels Escape-Sequenz oder (eckiger) Klammerung auch darstellen in rA, es muß nur richtig gemachrt werden.

 

[buehmann]

Ja, es sind reguläre Ausdrücke. Man kann also den Sternchen oder anderen Metazeichen ihre besondere Bedeutung auf genau die geschilderte Art und Weise nehmen. Damit ein Ausdruck genau auf "**2" passt, könnte man z.B. "^\*\*2$" oder "^[*][*]2$" nehmen.

Das eigentliche Problem ist aber, dass interne Anrufe von der Fritz!Box nicht signalisiert werden (der Callmonitor bekommt also nichts davon mit). Zumindest war es so beim letzten Mal, als ich das ausprobiert habe.

Viele Grüße,
Andreas

 

[silberwolf]

So, habs probiert. Die Schreibweise von Buehmann funktioniert. Allerdings stimmt auch die zweite Aussage: interne Anrufe werden nicht erkannt...

 

[silberwolf]

Folgende Idee hätte ich noch (geht nur, wenn Du ISDN hast!):

Es gab im Forum Projekte die den analogen Eingang der Fritzbox nutzen. Dies könnte man sich wie folgt zu nutze machen:

1) Du musst das Anschlusskabel der Fritzbox modifizieren und zwar so, dass Du an der Analog/ISDN Seite die analogen Kontakte abgreifst und die dann z.B. an FON3 anschließt. (siehe dazu den Anhang).

2) Du musst im WebIF der FB unter Einstellungen > Telefonie > Telefoniegeräte > Festnetz auf analog stellen, die MSN "000000" eintragen, speichern, dann wieder auf ISDN zurück stellen.

3) Du konfigurierst die Doorline so, dass sie extern raustelefoiert und zwar über die analoge Leitung (also sie ruft "*10#000000" an)

4) Du konfigurierst eine Rufumleitung im WebIF der FB, und zwar alles was an FON3 geht, soll "**51" (also Dein Telefon) anrufen als Parallelruf.

5) Jetzt noch die Listeners einstellen:

out:request ^ 000000$ Aktion
     |      |    |       |> sollte klar sein
     |      |    |> die externe analoge Rufnummer Deiner FB
     |      |> hier muss ^ stehen (jede Quell-Nummer), sonst ruft ja keiner die "000000" an
     |> wenn das Doorline-Modul rausruft

Das Aufwendigste ist der Kabelpatch. Suche bitte im Forum nach ner alten CallThrough/CallBack Lösung. Dort war das beschrieben und davon hab ich auch die Idee. Der Callmonitor müsste ansprechen, da das Doorline-Modul "extern" rauswählt. Parallel wird auch noch Dein ISDN-Telefon angerufen.

Ich hab keine Ahnung, ob es Funktioniert und leider weiß ich auch nicht mehr, wer damals die Anleitung zum CallBack geschrieben hatte.

 

[mistr]

Frage zur Aktivierung des Wlan

Hallo,
ich möchte über mein Handy das Wland aktivieren.
Ich habe folgende Einträge im Listener:

in:cancel ^015Handynummer ^06VIPNummer config wlan on
in:cancel ^ ^ mailmessage

Wenn ich den Test laufen lasse, erhalte ich als Ergebnis:

[0:1] processing rule 'in:cancel' '^' '^' 'mailmessage'
[0:1] event 'in:cancel' matches pattern 'in:cancel'
[0:1] parameter SOURCE='015*********' matches pattern '^'
[0:1] parameter DEST='06**********' matches pattern '^'
[0:1] SUCCEEDED
[0:1] ACTION: 'mailmessage'
[0:0] processing rule 'in:cancel' '^015**********' '^06**********' 'config wlan on'
[0:0] event 'in:cancel' matches pattern 'in:cancel'
[0:0] parameter SOURCE='015**********' matches pattern '^015**********'
[0:0] parameter DEST='06************' matches pattern '^06*************'
[0:0] SUCCEEDED
[0:0] ACTION: 'config wlan on'
off

Wenn ich die Nummer dann vom Handy währle, erhalte ich nur die Mailmessage.

Im Log sieht das dann so aus:

Sep 11 21:45:49 fritz daemon.info callmonitor: [16] EVENT=in:request SOURCE='015*******' DEST='*******' SOURCE_NAME='' DEST_NAME='1und1'
Sep 11 21:45:49 fritz daemon.info callmonitor: [16+] SOURCE_DISP='015*************' DEST_DISP='********' ID=0 EXT= DURATION= TIMESTAMP='11.09.07 21:45:49' PROVIDER=SIP4
Sep 11 21:45:52 fritz daemon.info callmonitor: [17] EVENT=in:cancel SOURCE='015********' DEST='*********' SOURCE_NAME='' DEST_NAME='1und1'
Sep 11 21:45:52 fritz daemon.info callmonitor: [17+] SOURCE_DISP='015***************' DEST_DISP='**********' ID=0 EXT= DURATION=0 TIMESTAMP='11.09.07 21:45:52' PROVIDER=SIP4
Sep 11 21:45:52 fritz daemon.info callmonitor: [17:1] ACTION: 'mailmessage'

Was mache ich falsch, dass das Wlan nicht eingeschaltet wird?

Danke im Voraus
Michael

 

[buehmann]

Schalt den Debug-Modus (des Callmonitors) an, dann siehst du im Log die einzelnen Schritte wie beim Testanruf.

Als blinde Vermutung: Steht (im realen Log) bei DEST das, was du erwartest ("06....")? Da DEST_NAME='1und1' ist, könnte ich mir vorstellen, dass dort eher soetwas wie "SIP1" steht. Entsprechend müsstest du deine Regeln anpassen.

Andreas

 

[mistr]

Das war der reale log, in DEST stand die Rufnummer, aber ohne Vorwahl. Nachdem ich dies im Listener geändert habe, sieht der Log nun so aus:

Sep 12 06:33:04 fritz daemon.debug callmonitor: <<< timestamp=12.09.07 06:33:04 event=DISCONNECT id=0 duration=0 
Sep 12 06:33:04 fritz daemon.debug callmonitor: >>> in:cancel ID=0 TIMESTAMP=12.09.07 06:33:04 SOURCE=0****** DEST=8****** EXT= DURATION=0 PROVIDER=SIP4 
Sep 12 06:33:04 fritz daemon.info callmonitor: [4] EVENT=in:cancel SOURCE='015********' DEST='8******' SOURCE_NAME='' DEST_NAME='1und1' 
Sep 12 06:33:04 fritz daemon.info callmonitor: [4+] SOURCE_DISP='015*******' DEST_DISP='8****' ID=0 EXT= DURATION=0 TIMESTAMP='12.09.07 06:33:04' PROVIDER=SIP4 
Sep 12 06:33:04 fritz daemon.debug callmonitor: [4:0] processing rule 'in:cancel' '^01*******' '^8*****' 'config wlan on' 
Sep 12 06:33:04 fritz daemon.debug callmonitor: [4:0] event 'in:cancel' matches pattern 'in:cancel' 
Sep 12 06:33:04 fritz daemon.debug callmonitor: [4:0] parameter SOURCE='015**********' matches pattern '^015********' 
Sep 12 06:33:04 fritz daemon.debug callmonitor: [4:0] parameter DEST='8******' matches pattern '^8******' 
Sep 12 06:33:04 fritz daemon.debug callmonitor: [4:0] SUCCEEDED 
Sep 12 06:33:04 fritz daemon.info callmonitor: [4:0] ACTION: 'config wlan on' 
Sep 12 06:33:04 fritz daemon.debug callmonitor: [4:1] processing rule 'in:cancel' '^' '^' 'mailmessage' 
Sep 12 06:33:04 fritz daemon.debug callmonitor: [4:1] event 'in:cancel' matches pattern 'in:cancel' 
Sep 12 06:33:04 fritz daemon.debug callmonitor: [4:1] parameter SOURCE='01***********' matches pattern '^' 
Sep 12 06:33:04 fritz daemon.debug callmonitor: [4:1] parameter DEST='8******' matches pattern '^' 
Sep 12 06:33:04 fritz daemon.debug callmonitor: [4:1] SUCCEEDED 
Sep 12 06:33:04 fritz daemon.info callmonitor: [4:1] ACTION: 'mailmessage' 
Sep 12 06:33:08 fritz user.err webcm[3705]: Second instance already running
Sep 12 06:33:09 fritz user.err webcm[3705]: Second instance already running
Sep 12 06:33:10 fritz user.err webcm[3705]: Second instance already running
Sep 12 06:33:11 fritz user.err webcm[3705]: Second instance already running
Sep 12 06:33:12 fritz user.err webcm[3705]: Second instance already running
Sep 12 06:33:13 fritz user.err webcm[3705]: Second instance already running
Sep 12 06:33:14 fritz user.err webcm[3705]: Second instance already running
Sep 12 06:33:15 fritz user.err webcm[3705]: Second instance already running
Sep 12 06:33:16 fritz user.err webcm[3705]: Second instance already running
Sep 12 06:33:17 fritz user.err webcm[3705]: Second instance already running

Sieht so aus, als ob  man nicht zwei Regeln gleichzeitig ausführen lassen kann. 

Ich habe dann den Listener folgendermaßen abgeändert:

in:cancel ^015********* ^8****** config wlan on
in:cancel !^015******** ^ mailmessage

Danach gibt der Log dann eine Erfolgsmeldung aus:

 DEST=8***** EXT= DURATION=0 PROVIDER=SIP4 
Sep 12 06:53:31 fritz daemon.info callmonitor: [6] EVENT=in:cancel SOURCE='015*********' DEST='8*****' SOURCE_NAME='' DEST_NAME='1und1' 
Sep 12 06:53:31 fritz daemon.info callmonitor: [6+] SOURCE_DISP='015********' DEST_DISP='8*****' ID=0 EXT= DURATION=0 TIMESTAMP='12.09.07 06:53:30' PROVIDER=SIP4 
Sep 12 06:53:31 fritz daemon.debug callmonitor: [6:1] processing rule 'in:cancel' '!^015*******' '^' 'mailmessage' 
Sep 12 06:53:31 fritz daemon.debug callmonitor: [6:1] event 'in:cancel' matches pattern 'in:cancel' 
Sep 12 06:53:31 fritz daemon.debug callmonitor: [6:1] parameter SOURCE='015********' does NOT match pattern '!^015********' 
Sep 12 06:53:31 fritz daemon.debug callmonitor: [6:1] FAILED 
Sep 12 06:53:31 fritz daemon.debug callmonitor: [6:0] processing rule 'in:cancel' '^015*******' '^8*****' 'config wlan on' 
Sep 12 06:53:31 fritz daemon.debug callmonitor: [6:0] event 'in:cancel' matches pattern 'in:cancel' 
Sep 12 06:53:31 fritz daemon.debug callmonitor: [6:0] parameter SOURCE='015*********' matches pattern '^015********' 
Sep 12 06:53:31 fritz daemon.debug callmonitor: [6:0] parameter DEST='8*****' matches pattern '^8*****' 
Sep 12 06:53:31 fritz daemon.debug callmonitor: [6:0] SUCCEEDED 
Sep 12 06:53:31 fritz daemon.info callmonitor: [6:0] ACTION: 'config wlan on'

Das Wlan wird dann jedoch nicht eingeschaltet.

Irgendwo habe ich was davon gelesen, das der Sicherheitslevel bei der Fritzbox geändert werden muss. Kann es daran liegen und wie kann ich das ändern?

Gruß
Michael

 

[buehmann]

Hallo Michael,

benutz für solche längeren Log-Auszüge besser einen [noparse]

...

[/noparse]-Block; dann wird der Beitrag übersichtlicher.

Sieht so aus, als ob man nicht zwei Regeln gleichzeitig ausführen lassen kann.

Doch, zwei oder mehr Regeln sind gar kein Problem. Bei dir werden ja auch beide Regeln ausgewertet. Was sich dort in Quere kommt, scheinen die beiden Aktionen zu sein (beide benutzen webcm). Wenn wirklich eine der beiden Aktionen deswegen nicht erfolgreich ist, würde ich sie einfach etwas verzögern (z.B. mailmessage um 10 Sekunden: "sleep 10; mailmessage").

Sep 12 06:53:31 fritz daemon.debug callmonitor: [6:0] SUCCEEDED
Sep 12 06:53:31 fritz daemon.info callmonitor: [6:0] ACTION: 'config wlan on'

Das Wlan wird dann jedoch nicht eingeschaltet.

Die Regel funktioniert; das config-Kommando wird ausgeführt. Aber vielleicht gibt es dort ein Problem. Schau mal ins Webinterface, ob dort nach dem Befehl das WLAN ein-/ausgeschaltet ist.

Sicherheitslevel gibt es nur beim ds-mod; damit kann man nur einstellen, was man über das Webinterface machen kann. Hat mit deinem Problem nichts zu tun.

Viele Grüße,
Andreas

 

[mistr]

Hallo Andreas,

Im Webinterface bleibt das Wlan auch deaktiviert.

Callmonitor funktionert mit der Regel !^015********** ebenfalls, da brauche ich das sleep nicht einzufügen.

Kann ich das Problem noch irgendwie eingrenzen?

Gruß
Michael

 

[buehmann]

Hi,

du könntest mal von Hand den config-Befehl aufrufen. Das geht so: callaction config wlan on
Wenn das nicht funktioniert, das Aktivieren per Ankreuzen und Übernehmen im AVM-Webinterface aber geht, müsste ich mal schauen, ob sich da irgendetwas geändert hat ("config wlan" ruft nämlich intern das Webinterface auf).

Andreas

 

[Matthy]

Ich hatte auch mal Probleme mit "config wlan on". Ursache war (oder ist), dass in dem Skript, was die Parameter auswertet die falsche Parameteranzahl erwartet wurde (oder wird). Mit "config wlan on on" bzw. "config wlan off off" geht es.

 

[buehmann]

Tatsächlich, genau da ist ein Fehler im Skript. Und warum sagt mir das keiner? ;-)
Ist in der nächsten Version behoben.

Andreas

PS: Habe gerade einmal nachgeschaut: Der Fehler ist in Version 1.9.1 dazugekommen.

 

[mistr]

Ich habe jetzt im Listener config wlan on on eingetragen, (wie Matthy berichtete), und nun klappt es. Kann solange damit leben, bis ne Berichtigung kommt.

Danke für die Hilfe

Michael

 

[buehmann]

callmonitor-1.10.2

Hallo,

so, Version 1.10.2 behebt den Fehler bei "config wlan [on|off]". Weitere neue Kleinigkeiten:

• Wartungsseite: Button, um den Rückwärtssuche-Cache manuell zu leeren.
• Listener-Konversioncode entfernt (für Format vor v1.0; wer so einen alten Callmonitor immer noch benutzt, ist selbst schuld ;-))

Viele Grüße,
Andreas

 

[bolle]

Hallo Andreas, ich wollte frgane ob es möglich ist hier: http://www.ip-phone-forum.de/showpost.php?p=942409&postcount=1542 auch eine MSN auch auszuschliesen? Ich weiß ist nicht direkt Callmonitor aber ich glaube, dass du mir trotzdem weiterhelfen kannst!

Gruß BOLLE

 

[buehmann]

Hallo Bolle,

sorry, ich kenne mich mit der calllog-Datei überhaupt nicht (mehr) aus. An deiner Stelle würde ich erst einmal herausbekommen (durch Nachlesen oder Ausprobieren), welche Argumente diesem Skript beim Aufruf übergeben werden. Wenn du Glück hast, ist die MSN dabei und du kannst sie mit einer gewünschten vergleichen.

Andreas

 

[kriegaex]

Callmonitor startet immer neue Subprozesse, die nicht terminieren

Ich habe Probleme mit CM 1.10.2: Immer, wenn ein ein- oder ausgehender Anruf stattfindet (klingeln reicht schon), werden zwei neue CM-Prozesse (keine Zombies, alle "Running") gestartet, die nicht mehr terminieren und die ganze Rechenzeit verbrauchen. Direkt nach dem Start sind es noch fünf Prozesse, dann nach dem ersten Anruf sieben, dann neun usw.

Im strace sieht man:

/usr/sbin/callmonitor: 
/mod/pkg/callmonitor/usr/lib/callmonitor/applets/callmonitor.sh: line 1: 
cannot open /tmp/callers: no such file

Ralf Friedl half mir beim Analysieren. Er schreibt in einer E-Mail:

So wie es aussieht, wird diese Meldung immer wieder ausgegeben. Am Ende laufen zwei Prozesse, (...) die beide nur darauf warten, daß andere von ihnen gestartete Prozesse beendet werden. Es gibt aber keine solchen Prozesse, daher blockiert der Aufruf nicht, sondern kommt mit Fehler zurück. Der Aufrufer kömmert sich aber nicht darum und ruft wait gleich wieder auf.

Das Ergebnis sind zwei Prozesse, die die ganze verfügbare CPU-Zeit verbrauchen. Wenn bei jedem Anruf weitere solche Prozesse dazukommen, ist irgendwann die stärkste Box überlastet.

Siehe zu diesem Problem auch dort. Zunächst dachte ich, es hinge mit usermand zusammen, den ich aus der Firmware gestrippt habe. Aber das ist es nicht, weil es mit und ohne usermand passiert, wie inzwischen klar ist. Die Box läuft stabil, wenn Callmonitor deaktiviert ist.

Das ist jetzt nicht das erste Mal, daß eine CM-Version die Box ausbremst und/oder zum Reboot zwingt. Evtl. solltest Du mal über ein Redesign nachdenken oder anfangen, ein bißchen mit Einrückungen und Kommentaren zu arbeiten, um die verwirrende Vielzahl von Modulen etwas übersichtlicher zu gestalten. Da das CM-Paket auch von Dir "extern" gepflegt wird, haben wir es nicht im SVN-Repository und sehen nicht automatisch beim Einchecken die Diffs, was es erschwert, Änderungen zu erkennen, weil man immer manuell "diffen" müßte. Evtl. hast Du Lust, in Zukunft den CM in unserem SVN zu pflegen? Du bist jedenfalls herzlich dazu eingeladen von meiner Seite aus. Oliver hat bestimmt auch nichts dagegen. Dein Paket ist so wichtig und wird so häufig verwendet, daß es gut wäre, wenn ein gemeinsames Versionsmanagement mit dem DS-Mod stattfinden würde.

 

[buehmann]

Hallo Alexander,

danke für die Hiobsbotschaft. Ich werde mal sehen, dass ich das Problem reproduzieren kann und die Ursache feststellen.

Evtl. solltest Du mal über ein Redesign nachdenken oder anfangen, ein bißchen mit Einrückungen und Kommentaren zu arbeiten

Ich hoffe, ihr beide habt nicht wirklich gedacht, dass ich in der Lage bin, mit dem Code in der Form aus dem Installationspaket zu arbeiten. Das ist nur eine "gestrippte" Version; die Quellen liegen im SVN-Repository hier, inclusive Einrückungen, sonstigem Whitespace, Kommentaren und sämtlichen Versionen bis zurück in die 0.1-Zeit:

http://svn.berlios.de/svnroot/repos/callmonitor/fritzbox/callmonitor/trunk

Damit erübrigt sich vermutlich auch die freundliche Einladung, dem Callmonitor im ds-mod-Repository ein Zuhause zu verschaffen, oder gibt es noch überzeugende Argumente für einen Umzug?

Nochmals danke,

Andreas

 

[buehmann]

So,

ich schaffe es nicht, das Fehlverhalten mit den zwei zusätzlichen Prozessen, die ständig auf Kindprozesse warten, zu reproduzieren. Das Fehlen von /tmp/callers hat anscheinend nichts damit zu tun, denn es ist vorgesehen, dass diese Datei (= Reverse-Lookup-Cache) fehlt. (Die Fehlermeldung beim versuchten Zugriff wird momentan in Kauf genommen, anstatt die Existenz vorher zu überprüfen.)

Ich habe auch alle Stellen inspiziert, an denen ich explizit "wait" einsetze und konnte in keinem Fall Hinweise auf eine mögliche Endlosschleife finden.

Da das Problem bisher noch nie aufgetreten ist (und der Code, der sich um das Anrufhandling in eigenen Prozessen kümmert, schon lange nicht mehr geändert wurde), denke ich, es liegt an deiner Umgebung, Alexander. Im Verdacht habe ich die Busybox; vielleicht hat sich dort im Verhalten der ash etwas geändert. Wenn deine Signatur stimmt, benutzt du Version 1.7.2; finde ich dazu irgendwo die passenden Patches für eine Integration in ds26-15.2 oder könntest du sie mir bitte zukommen lassen?

Gruß,
Andreas

 

[kriegaex]

Ich hoffe, ihr beide habt nicht wirklich gedacht, dass ich in der Lage bin, mit dem Code in der Form aus dem Installationspaket zu arbeiten. Das ist nur eine "gestrippte" Version;

Wer weiß, wozu Du in der Lage bist? ;-) Das erklärt trotzdem einiges, danke.

http://svn.berlios.de/svnroot/repos/callmonitor/fritzbox/callmonitor/trunk

Damit erübrigt sich vermutlich auch die freundliche Einladung, dem Callmonitor im ds-mod-Repository ein Zuhause zu verschaffen, oder gibt es noch überzeugende Argumente für einen Umzug?

Ich denke, die gibt es: Wir würden automatisch sofort Deine neuesten Versionen testen, Du würdest automatisch die neuesten DS-Mod-Entwicklungen mitbekommen und könntest z.B. direkt meine Umgebung nachvollziehen, weil FW 29.04.40 und BusyBox 1.7.2 eingecheckt sind. Kannst es Dir ja nochmal überlegen, PN folgt.