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

[er13]

Hallo zusammen,

ich habe in trunk einiges in Bezug auf das "allcfgconv -c"-Problem eingecheckt. Das Auslesen der Sip-Namen, das Verschicken von Mails sollte nun wieder funktionieren. Wäre nicht schlecht, wenn Ihr es testen und hier über die noch bestehenden Probleme berichten würdet.

Das Problem, dass callmonitor beim Booten automatisch nicht startet, habe ich nicht untersucht. Es könnte sein, dass es auch irgendwie mit "allcfgconv -c" zusammenhängt.
Edit: das Problem besteht weiterhin, hat also leider nichts wie erhofft mit -c zu tun.

Als Ersatz für "allcfgconv -c" werden von jetzt an zwei Methoden unterstützt:

• decode_passwords von PeterPawn-basierte. Das entsprechende Package habe ich "decrypt FRITZ!OS configs" genannt. Man muss dieses manuell auswählen. Callmonitor gibt zwar einen Hinweis, wählt es aber automatisch NICHT aus. AVM sieht es als potentielles Sicherheits-Risiko an und hat die -c Option daher in 6.20 und bei manchen Boxen sogar in 6.05 entfernt. Ich betrachte es als das Risiko bzw. die Entscheidung des Users, wenn er wieder irgendwelche Scripte mit in die Firmware aufnimmt, die es auf deutlich einfachere Art und Weise erlauben, an die sicherheitskritische Informationen wie Passwörter ranzukommen. Das ist der Grund, warum nichts automatisch selektiert wird, sondern der User es selbst bewusst machen muss.
• allcfgconv-c-basierte. Man kann nun das allcfgconv aus der alten Firmware, in der die -c Option noch unterstützt wurde, in das neue Image unter dem Namen allcfgconv-c (kein Leerzeichen dazwischen) kopieren (es wird erwartet, dass der User diesen Schritt selbst macht). Findet Callmonitor zur Laufzeit es vor, so versucht er dieses zu verwenden, in der Erwartung, dass dieses eben -c unterstützt. Der Sinn dahinter ist es, mögliche Risiken zu minimieren, die entstehen würden, wenn man das allcfgconv einfach mal überschreiben würde - nur Callmonitor würde das allcfgconv aus der alten Firmware verwenden, alle restlichen Firmware-Komponenten verwenden das originale zu der Fritz!OS-Version passende allcfgconv Binary.

Grüße,
Gene

 

[BenGurion_]

@er13
Danke Dir - hab mir gleich mal ein passendes Image inkl. decrypt gebaut ^^

 

[Peter931]

Es fehlen bei dir -f, -l und -m. Warum die Sachen jetzt Pflicht sind ... keine Ahnung. Damit funktioniert es aber. Die Daten hast du ja sowieso im Push Bereich schon abgelegt. Passwort braucht er nicht, das kommt wohl aus der Push-Konfig.

Seltsam. Ich habe gerade freetz-devel-12923 gebaut mit Callmonitor Version 1.20.9
Bei mir funktioniert das Senden von Emails weiterhin ohne -f -l -m.
Wie kann das sein?

in:cancel ^ ^999999 mailmessage -t [email protected] -s "Verpasster Anruf von ($SOURCE_DISP ) ($SOURCE_ENTRY ) an {$DEST_DISP} um ($TIMESTAMP )"

 

[BenGurion_]

Hast Du das Image mit dem decrypt-Plugin gebaut?

 

[Peter931]

Ja mit dem decrypt_fritzos_cfg

 

[JonnysRache]

113.06.23 rev29613 / freetz-devel-12925 // 6.23
Mailversand ( mailmessage -t [email protected] -s "Verpasste ..) klappt , Sip Update auch.
Habe es erst mit der "decrypt FRITZ!OS configs" Variante Probiert und nun mit allcfgconv-c aus einer Downgrade Firmware meiner 7490 Box.

Allerdings startet Callmonitor bei einem Reboot nicht automatisch.
In der Seriellen Console taucht jedoch beim Booten der Eintrag "Starte Callmonitor" auf.
Habe es jetzt im Einzelbenutzer sowie Mehrbenutzermodus probiert. Im Mehrbenutzermode habe ich den User Callmonitor mit den Rechten
- FRITZ!Box Einstellungen
- Sprachnachrichten, Faxnachrichten, FRITZ!App Fon und Anrufliste
bei Callmonitor gewählt.

 

[BenGurion_]

Kann ich bestätigen - die decrypt-Variante funktioniert gut

 

[JonnysRache]

Also bei mir starte Callmonitor immer noch nicht automatisch. Weder mit der decrypt noch mit der allcfgconv-c Option.
Das Problem besteht schon seit ca. Trunk 12912 akutell in Revision 12944.
Dafür bekomme ich häufig beim Image Bauen immer den gleichen Fehler:

ERROR: Build failed.
make: *** [source/target-mips_gcc-4.8.4_uClibc-0.9.33.2-nptl/callmonitor-0c996b3e69/build/freetz/callmonitor-0c996b3e69/src/recode] Fehler 1

Habe jetzt schon make clean, make callmonitor clean und löschen des freetz caches mit anschließenden Reboot probiert.

 

[er13]

@JonnysRache:
Dass Callmonitor automatisch nicht startet, hat doch nichts mit allcfgconv -c zu tun, es ist ein anderes Problem (ich kam leider noch nicht dazu mich mit diesem auseinanderzusetzen).

Wegen dem recode-Buildfehler: poste bitte den eigentlichen Fehler - das, was Du gepostet hast, ist nur eine Meldung von make "es ist davor ein Fehler aufgetreten". Wenn Du nicht weiß, wovon ich spreche, dann führe bitte folgende Befehle aus und hänge die Logdatei hier an:

make callmonitor-distclean; make callmonitor-precompiled 2>&1 | tee callmonitor-precompiled.log

 

[Matthy]

Also bei mir starte Callmonitor immer noch nicht automatisch. Weder mit der decrypt noch mit der allcfgconv-c Option.
Das Problem besteht schon seit ca. Trunk 12912 akutell in Revision 12944.

Als Workaround benutze ich folgenden Eintrag in der rc.custom:

delay -d 120 CALLMON /etc/init.d/rc.callmonitor restart

Das stellt sicher, dass der Callmonitor 2 Minuten nach dem Start der Box gestartet wird. Da klappt's dann.

 

[er13]

@alle, die das Problem haben, dass der callmonitor beim Booten nicht startet:

• Ist unmitttelbar nach dem Booten etwas in Bezug auf den Callmonitor in den Logdateien zu sehen? Wenn ja, was?
• Verwendet Ihr eventuell ein Online-Telefonbuch?

 

[Matthy]

• Ist unmitttelbar nach dem Booten etwas in Bezug auf den Callmonitor in den Logdateien zu sehen? Wenn ja, was?
• Verwendet Ihr eventuell ein Online-Telefonbuch?

Im syslog erscheint nur folgendes:

Jan  1 01:01:09 fritz user.notice FREETZMOD: Reading AVM's phone book ... done. Starting callmonitor ... done.

Danach ist der Callmonitor-Dienst aber dennoch nicht gestartet.
Ein Onlinetelefonbuch benutze ich aktuell nicht. Ich hatte aber davor mal meine Gmail-Kontakte als Onlinetelefonbuch eingebunden, aber dann wieder entfernt.

 

[JonnysRache]

Ok gerade war es wieder soweit das Make fehlschlug als Callmonitor an der Reihe war. Habe die Log nun erstellt.

Openvpn Version mit Menuconfig gewechselt -> Box ist nach dem Flashen nicht gestartet ( /sbin/init nicht gefunden & nand ecc error etc. ) -> Make clean (hilft bei dem fehler nach dem flashen) -> Make bricht bei Callmonitor ab.

Logs reiche ich nach wenn Freetz wieder läuft.

Edit:
Sehe gerade das Make nach dem

make callmonitor-distclean; make callmonitor-precompiled 2>&1 | tee callmonitor-precompiled.log

durchgelaufen ist. Mal sehen ob die Box damit startet.

 

[er13]

Ok gerade war es wieder soweit das Make fehlschlug als Callmonitor an der Reihe war. Habe die Log nun erstellt. Sehe gerade das Make durchgelaufen ist.

Ich brauch' natürlich die Logausgaben von einem fehlschlagenden Build...

Box ist nach dem Flashen nicht gestartet ( /sbin/init nicht gefunden & nand ecc error etc. ) -> Make clean (hilft bei dem fehler nach dem flashen).

Ok, "hilft bei dem Fehler nach dem Flashen" ist aus der Kategorie Aberglaube. Ich würde entweder einen Hardware-Defekt oder irgendein Parallel-Build-Problem vermuten. Beschreib' mal Dein Build-System. Welche Hardware, wieviele CPU-Kerne, Anzahl Jobs in freetz .config, etc.

 

[BenGurion_]

Also ich habe auf meiner 7270 eben ein neues Image mit der 12953 gebaut.
Kein Abbruch beim Callmonitor und erfolgreich geflasht - CM startet auch einwandfrei:

Feb 20 01:27:01 fritz daemon.debug callmonitor: entering DEBUG mode 
Feb 20 01:27:01 fritz user.notice FREETZMOD: Reading AVM's phone book ... done. Starting callmonitor ... done. 
Feb 20 01:27:01 fritz daemon.debug callmonitor: including /usr/lib/callmonitor/actions.d/config.sh 
Feb 20 01:27:01 fritz daemon.debug callmonitor: including /usr/lib/callmonitor/actions.d/dboxlcd.sh 
Feb 20 01:27:01 fritz daemon.debug callmonitor: including /usr/lib/callmonitor/actions.d/dial.sh
Feb 20 01:27:01 fritz daemon.debug callmonitor: including /usr/lib/callmonitor/actions.d/mail.sh 
Feb 20 01:27:01 fritz daemon.debug callmonitor: including /usr/lib/callmonitor/actions.d/messages.sh 
Feb 20 01:27:01 fritz daemon.debug callmonitor: including /usr/lib/callmonitor/actions.d/musicpal.sh 
Feb 20 01:27:02 fritz daemon.debug callmonitor: including /usr/lib/callmonitor/actions.d/rc.sh 
Feb 20 01:27:02 fritz daemon.debug callmonitor: including /usr/lib/callmonitor/actions.d/roku.sh 
Feb 20 01:27:02 fritz daemon.debug callmonitor: including /usr/lib/callmonitor/actions.d/samsung.sh

 

[JonnysRache]

Also die angehängte Logdatei ist direkt nach dem einem Fehlgeschlagen Make erstellt worden. Warum es nach "make callmonitor-distclean; make callmonitor-precompiled" wieder komplett ohne Fehlermedung durchläuft weiß ich auch nicht genau. Ich vermute mal das irgendwo in einem Cache oder dergeleichen noch eine alte Pfad angabe steht die erst durch obigen Befehle korrigiert wird nachdem sich etwas im Svn bei Callmonitor geändert hat.

ERROR: Build failed.
make: *** [source/target-mips_gcc-4.8.4_uClibc-0.9.33.2-nptl/callmonitor-0c996b3e69/build/freetz/callmonitor-0c996b3e69/src/recode] Fehler 1

Es wird bei dem Fehler im falschen Ordner gesucht! Der Pfad stimmt soweit, nur das /src/recode in einem Cm Order mit anderer Nummer liegt.

Der Trick mit dem "delay" Befehl in der rc.costum klappt bei mir auch einwandfrei.
Nach jedem Reboot ist der Dienst am laufen. Wäre nur die Frage warum es einen Restart braucht.
Habe jetzt die Syslogs durchsucht und sogar die Serielle Schnitstelle angelötet.
Aber selbst da steht nichts anders als " Gestartet".

Was den gelegentlichen Fehler nach dem Flashen angeht, such ich noch den Fehler.
Vielleicht wirklich ein Fehler im Flash....?
Habe auf diesem Rechner der zugegebenermaßen Übertaktet ist 3 Jahre lang Freetz für meinen alten W920v gebaut.
Ebenso U-boot Mod Images für Tp-Link, Openwrt und gestern erst noch Neutrino-Hd/ Nevis.

#
Debian GNU/Linux 7.8 (wheezy)
Amd Phenom2 X4 @ 3600Mhz
SSD1 für Debian Sys
SSD2 für Debian Home
8Gb Ram
2 Jobs in Freetz

Bis zum Wechsel W920v -> 7490 hatte ich mit dem Setup eigentlich auch keine Probleme beim Freetz bau.
Der alte Stand:

Boxtyp
W920V_7570
AVM-Firmwareversion
04.92
Freetz-Version
freetz-devel-11997M

Für den Router habe ich das aktuelle Svn in einen anderen Ordner ausgecheckt, Mit 2 Make Menüconfig Fenster nebeneinander alles per Hand eingestellt und noch den freetz.ccache gelöscht.

 

[er13]

@JonnysRache: ich wiederhole mich ungern, aber poste doch bitte den eigentlichen Fehler statt dieser nutzlosen make-Meldung, die in etwa so viel wie "es ist ein Fehler passiert" bedeutet. Und wegen der vermuteten falschen Versionsnummer: welche Version steht denn in make/callmonitor/callmonitor.mk in Deiner Working-Copy?

@alle mit dem Problem, dass der callmonitor beim Booten nicht startet: die gute Nachricht - ich kann das Problem auf meiner Testbox nachstellen/nachvollziehen. Mit 99%-er Wahrscheinlichkeit handelt es sich um denselben Bug wie #2665 bzw. es ist nur eine weitere Ausprägung von diesem. callmonitor-daemon ist ein Shell-Script.

 

[BenGurion_]

@er13
Gut zu hören wegen dem Bootproblem - das habe ich nämlich an meiner neuen 4790 auch :-|

 

[er13]

@alle, die das Problem haben, dass der callmonitor beim Booten nicht startet: könntet Ihr bitte testen, ob r12978 auch für Euch das Problem behebt - auf meiner Testbox tut es. Danke!

 

[BenGurion_]

Hab ich gestern gerade schon eingespielt -> Problem bei mir behoben