Callmonitor 1.*

[Izzy]

Derzeit noch recht häufig, weil ich mich mit all dem neuen Spielzeug erst vertraut machen muss

Aber ich denke dabei auch noch an etwas anderes: Nutzer mit "Shellophobie" (also fast 0 Shellerfahrung und auch Angst davor - ich denke da an so manchen "einfachen Windows Nutzer") tun sich schwerer damit, das jeweils per Telnet umzustellen, als auf der Oberfläche ein Passwort einzugeben. Und bevor Du jetzt das Argument bringst, dass diese sich wohl kaum ein Freetz Image selbst basteln - sie können es sich ja auch basteln lassen. Und müssen dann damit klar kommen. Kurzum: Es wäre auch "anwenderfreundlicher".

 

[buehmann]

@Izzy: Das wäre eine Sache, die Freetz für alle Konfigurationsdateien anbieten könnte/müsste/sollte, falls man das will. Ich mache nämlich nichts anderes, als meine Konfigurationsdateien bekanntzumachen. Das Freetz-Framework kümmert sich um darum, wie und ob die Dateien bearbeitet werden können.

Aber ich persönlich halte das zusätzliche Passwort für überflüssig; um die Freetz-Weboberfläche zu benutzen, muss man ja auch schon ein Passwort angeben (ich persönlich hatte allerdings auch noch nie Verwendung für die verschiedenen Sicherheitsstufen).

Und zur Trennung der Passwörter: Wenn ich ein Passwort hätte, um die Listener zu bearbeiten, könnte ich jedes andere Passwort übergehen.

Zu "unbekannt": Wenn keine Rufnummer übermittelt wird, ist SOURCE leer und die Callers werden gar nicht befragt. "unbekannt" zeigt der Callmonitor nie von sich aus an, das kannst du also auch nicht ersetzen. Natürlich kannst du die Nachrichten selbst anpassen, die du anzeigst: Wie das geht, steht kurz hier: [wiki]software:callmonitor:anpassen[/wiki]

 

[Izzy]

@Izzy: Das wäre eine Sache, die Freetz für alle Konfigurationsdateien anbieten könnte/müsste/sollte, falls man das will. Ich mache nämlich nichts anderes, als meine Konfigurationsdateien bekanntzumachen. Das Freetz-Framework kümmert sich um darum, wie und ob die Dateien bearbeitet werden können.

Hatte ich mir schon gedacht. Aber der Gedanke bezieht sich ja auch auf das ganze. Klar, dann gehört das eigentlich auch in einen anderen Thread - aber hier war halt gerade der passende Zusammenhang

Und zur Trennung der Passwörter: Wenn ich ein Passwort hätte, um die Listener zu bearbeiten, könnte ich jedes andere Passwort übergehen.

Mir ging es hier nicht um eine Trennung der Passwörter. Fakt ist doch: Sobald ich mich am WebIF angemeldet habe, können alle Aktionen ohne Eingabe eines Passwortes durchgeführt werden. Hacker könnten dies für XSS ausnutzen. Daher die Neueingabe des Passwortes bei "brenzligen" Dingen - wobei man als zusätzliche Sicherheitsstufe hier das ROOT Passwort (anstelle des ADMIN Passworts) abfragen könnte. Ist halt nur so ein Gedanke.

Zu "unbekannt": Wenn keine Rufnummer übermittelt wird, ist SOURCE leer und die Callers werden gar nicht befragt. "unbekannt" zeigt der Callmonitor nie von sich aus an, das kannst du also auch nicht ersetzen. Natürlich kannst du die Nachrichten selbst anpassen, die du anzeigst: Wie das geht, steht kurz hier: [wiki]software:callmonitor:anpassen[/wiki]

Herbstlichen Dank! Aber soweit werde ich für einen "Gag" nicht gehen

BTW: Box läuft nach 16h+ noch immer stabil...

 

[buehmann]

Fakt ist doch: Sobald ich mich am WebIF angemeldet habe, können alle Aktionen ohne Eingabe eines Passwortes durchgeführt werden. Hacker könnten dies für XSS ausnutzen.

Ja, dagegen ist das Freetz-Interface nicht gefeit: http://fritz.box:81/cgi-bin/rudi_shellcmd.cgi?script=echo+You+have+been+hacked.+Deleting...;+find+/

Andreas

PS: Mir ist gerade aufgefallen, dass sich die Rudi-Shell überhaupt nicht um die Sicherheitsstufen kümmert ...

 

[Izzy]

Genau dafür gibt es beim originalen WebIF den "Session Timeout". Vielleicht sollten wir das mal an passender Stelle anbringen? Inbesondere was die Rudi-Shell betrifft, halte ich das für ein sehr hohes Risiko - das würde nämlich nicht nur eventuelle Hacker per XSS betreffen, sondern auch "unbedarfte" User (Papa geht mal eben telefonieren, und Junior ändert derweil ein paar Einstellungen)...

Uptime: 17:34 und alles stabil. Beim vorigen Image wäre der erste Reboot schon lange überfällig gewesen...

P.S.: Hätte ich die URL anklicken sollen?

 

[buehmann]

Mal sehen, wie viele sich trauen, die URL anzuklicken. ;-) An alle anderen: Sie tut nichts Böses. (Hmm, das sagt wohl jeder Angreifer ...)

Andreas

 

[Izzy]

"tut nichts böses" => Sieht nur so aus, gelle? Hab sie zwar nicht angeklickt, aber die Anzeige dürfte so aussehen, als ob einige Dateien gelöscht würden

TAFT: 19:06h, Frisur - äh, Fritz stabil...

 

[Izzy]

So - die Fritte läuft nun seit fast 2 Tagen stabil - im gleichen Zeitraum hatte ich mit dem vorigen Image bereits 3-4 Reboots hinter mir. Zeit für ein kurzes Resümee: Was habe ich geändert?

Image:
- Tor und Privoxy entfernt, um Platz zu schaffen
- Dropbear hinzugefügt (siehe weiter oben stehende Vermutung)
- DECO hinzugefügt (war ja noch Platz da )
- CallMonitor jetzt 1.12.2 (vorher 1.11), da trunk aktualisiert

Konfiguration:
- Debug Logging für CallMonitor aktiviert
- Start des CallMonitors von "automatisch" auf "manuell" gesetzt
- DTMFBox in's RAM installiert (war vorher nur im Image enthalten, aber nicht installiert)

Jetzt bleibt mir nur noch, die beiden Einstellungen in CallMonitor wieder zu invertieren (eine nach der anderen) und zu schauen, ob die Fritte stabil bleibt. Und dann bleibt die Frage, was jetzt für die Instabilität verantwortlich war. Vielleicht kann man da mal vergleichen, was allen Betroffenen gemeinsam ist? Die verrückte Vermutung wäre ja, dass sie alle kein Dropbear installiert haben...

 

[ao]

@all:
Wie versprochen melde ich mich noch einmal zurück bzgl. der Stabilität meines CM - inzwischen 1.12.2 mit Freetz-devel-2500. Ich habe zwar die FW für meine 7170 aktualisiert, aber die Pakete sind dieselben (ggf. updated) und alles läuft weiterhin stabil:

• AVM-Firewall 2.0.4_beta
• Callmonitor 1.12.2
• Checkmail 0.4.1
• Dropbear 0.51
• Syslogd
• Virtual IP
• Wake on LAN

Hallo Andreas,

wie kann man eigentlich vermeiden, dass Einträge, bei denen nur die Stadt (anhand der Vorwahlsuche bei Google) bzw. das Mobilfunknetz (die Vorwahl-Zuordnungen stimmen seit der Einführung der Portierung eh nicht mehr ) gefunden wurde, in den Callers gespeichert werden, aber trotzdem alle anderen ("echten" Einträge, also Nummer mit Namen) in den Callers gespeichert werden (dauerhaft)?
Könntest Du das evtl. in einer zukünftigen Version berücksichtigen? (Achtung, FR )

Außerdem habe ich noch eine Frage zur Ausgabe von Text via txt2osd, ausgelöst durch einen Anruf, leider ohne Ausgabe auf meinem DVB-T Receiver (Siemens Gigaset M740 AV - aber es hatte mal funktioniert).

Mein listener sieht so aus:

in:request ^ ^ echo "txt2osd -s 16 -t /data/SISAN06.TTF -f FF000000 -b BBDDDDDD -c 0 -d 12000 -e 0 -x 28 -y 29 Anruf von $SOURCE ($SOURCE_NAME)" | nc -w2 m741 10102

m741 ist der Name meines Receivers und wird auch korrekt nach der IP aufgelöst. Der Port ist offen und auf dem Receiver ist unter etc/vdr/svdrphosts.conf auch 192.168.178.0/24 eingetragen, um allen Clients aus dem lokalen Netz Zugriff auf den Receiver/VDR zu erlauben.

syslogd sagt:

Sep  7 22:20:18 fritz user.err telefon[574]: SIGCHLD received!
Sep  7 22:20:18 fritz daemon.info callmonitor: [1] event detected:
Sep  7 22:20:18 fritz daemon.info callmonitor:   EVENT=in:request
Sep  7 22:20:18 fritz daemon.info callmonitor:   SOURCE='0xxxxxxxxxx'
Sep  7 22:20:18 fritz daemon.info callmonitor:   DEST='0xxxxxxxxxx'
Sep  7 22:20:18 fritz daemon.info callmonitor: [1:0] ACTION: 'echo "txt2osd -s 16 -t /data/SISAN06.TTF -f FF000000 -b BBDDDDDD -c 0 -d 12000 -e 0 -x 28 -y 29 Anruf von $SOURCE ($SOURCE_NAME)" | nc -w2 m741 10102'
Sep  7 22:20:36 fritz daemon.info callmonitor: [2] event detected:
Sep  7 22:20:36 fritz daemon.info callmonitor:   EVENT=in:cancel
Sep  7 22:20:36 fritz daemon.info callmonitor:   SOURCE='0xxxxxxxxxx'
Sep  7 22:20:36 fritz daemon.info callmonitor:   DEST='0xxxxxxxxxx'

 

[Izzy]

Frage zu Debug-Log Meldung bei Aufspielen eines Firmware-Updates

Da habe ich wieder einmal ein Firmware-Update gemacht (noch ein wenig mehr abgespeckt, und dafür noch eSpeak und KnockD untergebracht), und beobachte fleißig das Debug-Log per "logread -r" via telnet. Folgendes fiel mir während des Updates auf:

Callmon versucht im Sekundentakt ein "Auto-Dialing *96*5# to enable phone interface" während des Kopierens des Images zur Box (konnte die Meldung leider nicht exakt kopieren, da sie "aus dem Fenster gerollt" ist, und seltsamerweise kein ScrollBuffer da war - wie kann man den eigentlich vergrößern?). Scheint keine "negativen Seiteneffekte" zu haben - dennoch: Ist das beabsichtigt?

 

[olistudent]

Der Callmonitor macht das immer, wenn er versucht auf die Telefonschnittstelle zu zugreifen und die nicht da ist.

MfG Oliver

 

[Izzy]

OK - Danke Dir. Also "normal"

 

[buehmann]

Hallo ao,

wie kann man eigentlich vermeiden, dass Einträge, bei denen nur die Stadt (anhand der Vorwahlsuche bei Google) bzw. das Mobilfunknetz (die Vorwahl-Zuordnungen stimmen seit der Einführung der Portierung eh nicht mehr ) gefunden wurde, in den Callers gespeichert werden

eine solche Unterscheidung ist momentan nicht möglich. Natürlich kannst du die Suche bei Google komplett abschalten, aber dann siehst du davon auch nichts mehr.

(Achtung, FR )

Herrje, immer diese Benutzer mit ihren komischen Wünschen ... ;-)

Außerdem habe ich noch eine Frage zur Ausgabe von Text via txt2osd

OK, das gehört nicht zum Callmonitor. Das Log sieht aber gut aus, das heißt, der Befehl wird ausgeführt. Funktioniert er denn außerhalb des Callmonitors (mit genau den gleichen Werten für SOURCE und SOURCE_NAME)?

Gruß,

Andreas

 

[ao]

Kein Problem, Andreas!

Bzgl. txt2osd:
Habe ich es jetzt (erst) richtig verstanden, dass der Befehl txt2osd ja nicht von der Fritzbox kommt, sondern mittels des echo-Befehls erst auf meinem Receiver ausgeführt wird?
Ich komme jetzt drauf (bin halt Linux-technisch noch nicht so versiert), weil Du schreibst, dass txt2osd ja nichts mit dem CM zu tun hat.

Und dass das bei mir nicht klappt, wäre damit auch verständlich, denn auf dem Receiver (mit neuer mod. FW, nämlich einem VDR statt original Siemens-Müll) gibt es kein txt2osd mehr. Stattdessen gibt es dort jetzt mesg, was ich aber zuerst noch ausprobieren muss.

Also, falls txt2osd in der Tat nichts mit dem CM zu tun hat, hat sich meine Frage diesbzgl. erledigt.
Aber prinzipiell wäre mein o.g. Kommando (echo) aus der Fritzbox schon korrekt, oder?
Anders gefragt: Wird im FB-syslog überhaupt eine Fehlermeldung kommen, wenn (falls ich das richtig verstanden habe) der echo-Befehl mittels pipe und nc den Befehl eigentlich nur an das Zielgerät (Receiver) durchreicht? Sorry, das ist wohl etwas zu OT...

 

[buehmann]

Ja, du schickst nur den langen String "txt2osd ..." übers Netz an den Receiver; der muss diesen Befehl interpretieren. Deswegen hat das nichts mit dem Callmonitor zu tun.

Und nein, im Syslog wirst du die Fehlermeldungen deines Befehls nicht sehen; beim Testanruf müssten sie allerdings angezeigt werden. Aber viel einfacher ist es, den Befehl von Hand auf der Konsole auszuprobieren.

Andreas

PS: Für VDR gibt es übrigens schon eine Benachrichtigungsfunktion; "vdr m741" dürfte gehen.

 

[ao]

Und ein VDR Fritzbox Plugin gibt es auch. Und nun wieder on-topic...
Danke für Deine Hilfe, Andreas!

 

[Izzy]

Unbekannte Anrufer und rawmessage

Hi Andreas,

bei "unbekannten" Anrufern (also ohne Rufnummernübermittlung) gibt es u.U. ein Problem bei der Anzeige durch "Drittsoftware" aka "3rd Party Utils", wenn $SOURCE als alleiniges Merkmal herhält:

Sep  9 21:33:54 fritz daemon.debug callmonitor: [59:0] processing rule 'in:request' '^' '^' 'rawmsg -t "${SOURCE}" 192.168.x.y -p 7777'
Sep  9 21:33:54 fritz daemon.debug callmonitor: [59:0] event 'in:request' matches pattern 'in:request'
Sep  9 21:33:54 fritz daemon.debug callmonitor: [59:0] parameter SOURCE='' matches pattern '^'
Sep  9 21:33:54 fritz daemon.debug callmonitor: [59:0] parameter DEST='XXXXXX' matches pattern '^'
Sep  9 21:33:54 fritz daemon.debug callmonitor: [59:0] SUCCEEDED

Die Nachricht wurde offensichtlich abgeschickt ("SUCCEEDED") - leider zeigte mir CallMon2 nichts an ("${SOURCE}" wurde zu ""). Jetzt könntest Du freilich sagen, da soll CallMon2 ran - aber kommt da überhaupt was an, wenn Du was leeres schickst? Könnte man hier nicht einen (konfigurierbaren) String, z.B. "Unbekannt" (oder einfach eine "0") schicken? Die Alternative, hier SOURCE_DISP zu nehmen, fällt in vielen Fällen flach, da CallMon dann "echte" Rufnummern nicht mehr (benutzerdefiniert) auflösen könnte (ich denke da an "Mehrbenutzer", von denen der eine die Callers nicht bearbeiten kann - der könnte mit CallMon2 aber noch immer seine "lokalen Callers" auf dem PC pflegen).

Die "0" hätte hier den Vorteil, dass man die auch wieder im lokalen Telefonbuch abfangen könnte. Ob das mit "unbekannt" geht, weiß ich nicht - erwartet werden ja nur Ziffern...

 

[buehmann]

Hallo Izzy,

aber kommt da überhaupt was an, wenn Du was leeres schickst?

Na klar, der Leerstring, den du abschickst, kommt auch an.

Könnte man hier nicht einen (konfigurierbaren) String, z.B. "Unbekannt" (oder einfach eine "0") schicken?

Selbst ist der Mann (du bist es doch, der SOURCE in jedem Fall verschickt):

rawmsg -t "${SOURCE:-0}" 192.168.x.y -p 7777

(Mit ":-" gibst du einen Default-Wert an, falls die Variable leer ist.)

Was du da machst, ist übrigens gefährlich: Du benutzt ${SOURCE} als Template. Sobald darin bestimmte Sonderzeichen auftauchen, wird nicht das ankommen, was du denkst. Mach also lieber so etwas (Template "%s" und die Nachricht als Parameter)

rawmsg -t "%s" 192.168.x.y:7777 "${SOURCE:-0}"

Gruß,
Andreas

 

[Izzy]

Selbst ist der Mann (du bist es doch, der SOURCE in jedem Fall verschickt):

rawmsg -t "${SOURCE:-0}" 192.168.x.y -p 7777

(Mit ":-" gibst du einen Default-Wert an, falls die Variable leer ist.)

:blonk: Ich muss mich erst noch daran gewöhnen, dass das ja auch "gewöhnlicher" Shell-Code ist - da hatte ich wohl wieder einen Aussetzer... Danke Dir!

Was du da machst, ist übrigens gefährlich: Du benutzt ${SOURCE} als Template. Sobald darin bestimmte Sonderzeichen auftauchen, wird nicht das ankommen, was du denkst. Mach also lieber so etwas (Template "%s" und die Nachricht als Parameter)

rawmsg -t "%s" 192.168.x.y:7777 "${SOURCE:-0}"

Was ich da mach, stammt aus der Doku von CallMon2 Gut, ich bin also nicht alleine mit dem "was nicht mitbekommen" Danke auch für diesen Tipp, den ich sogleich umsetzen werde (beides zusammen freilich)! Und dann mal schauen, ob der CallMon2 Author 'ne EMail Addresse hat, damit man ihm den Tipp "forwarden" kann

 

[Izzy]

mailmessage

Muss nochmal was "Dummes" fragen. Habe folgenden Listener konfiguriert:

in:disconnect ^ 27373745$ mailmessage -s "Faxeingang von $SOURCE" "Das Faxgerät verzeichnete gerade eine eingehende Verbindung.${LF}${LF}Zeitpunkt: ${TIMESTAMP}${LF}Quelle: ${SOURCE_DISP}${LF} Dauer: $(f_duration ${DURATION}) Stunden"

Erwartet hätte ich jetzt eine Mail mit dem Betreff "Faxeingang von 012345678" und dem Inhalt

Das Faxgerät verzeichnete gerade eine eingehende Verbindung.

Zeitpunkt: 10.09.08 12:04:28
Quelle: (0123) 45678; Musterstadt
Dauer: 00:00:37 Stunden

Es ging gerade ein Fax ein, eine Mail wurde auch verschickt, der Betreff stimmt auch - nur der Text hält sich überhaupt nicht an die Vorgabe:

Anruf an 98765
von 45678
45678; Musterstadt

10.09.08 12:04:28

Was mache ich falsch? Den Text der Mail kann ich wohl nicht selbst festlegen? Ich hätte nämlich gern die Dauer mit drin - damit ich weiß, ob das nicht eher ein "Voice" Anrufer ("WolleRoseKaufe?") war (der dann sicher schneller wieder auflegt, als ein Fax übertragen wäre)...

Edit: Örgs, sorry - gerade das Kleingedruckte in der Howto entdeckt, mit dem Link zum Anpassen der Benachrichtigungstexte... :blonk:

Also gibbet nur eine Standard-Nachricht, egal für was - keine Templates für verschiedene Rufnummern zum Bleistift. Dürfte ich das als "FR" anmelden? Vielleicht gar direkt über das WebIF anpassbar - wie das z.B. auch bei DTMFBox geht? :habenwol:

Edit2: für den Anfang würde ja vielleicht auch schon ein "-n <Nachrichtentext-Template>" als zusätzlicher Parameter reichen, womit man den gewünschten mail_body analog zu obigem Beispiel übergeben könnte