lahmer Callmonitor auf ge(freez)fritztem Speedport W900

[Telefonmännchen]

Hallo Forum,

ich habe seit einem Update meiner Firmware meines Speedportes W900 ein merkwürdiges Problem. Zwischen einem Anruf und der Darstellung des Anrufes auf der dBox vergehen teilweise mehrere Minuten. Dieses zeigte sich erstmalig mit einem vor ca. zwei Wochen erstelltem Freetz-Image mit dem Callmonitor. Beim letzten Mal war das noch der 1.12.4 und mit dem heutigen Tag der 1.12.5. Ich habe mehrere Listener erstellt, die auch laut Syslog ordnungsgemäß ausgeführt werden.

Ein Deaktivieren der Rückwärtssuche brachte auch keine Verbesserung. Kann es evtl. sein, daß der aktuelle Callmonitor nicht mit einem relativ großen Telefonbuch auf der FritzBox klarkommt? Wurde da etwas in letzter Zeit verändert? Mit einem älteren Callmonitor hatte ich mit meinen ca. 270 Einträgen keine solchen Probleme. Dort haben sich zwar die Logger vervielfacht und irgendwann die Box abstürzen lassen. Dieses hatte ich aber mit einem Workaround beseitigt (ich weiß, nur an den Symptomen gebastelt). Zwischen erstem Klingeln und der Darstellung vergingen zwar auch ein paar Sekunden, aber das bewegte sich im Bereich von 8-10 Sekunden.

Ich habe mir schon einen Wolf gesucht und keinerlei ähnliche Berichte gefunden. Wie kann ich das, ohne das Telefonbuch zu verkleinern, verbessern? Ich benötige dieses große Telefonbuch, damit ich erstens in den täglichen Statusmails die Anrufe mit Namen aufgelöst bekomme und zweitens im Klartext in der Mailinformation nach einem verpassten Anruf sehe, wer versucht hat, mich anzurufen. Ich bekomme diese Mails als SMS aufs Handy und da ist es extrem hilfreich. Leider stehen ja nicht alle Anrufer im öffentlichen Telefonbuch und schon gar nicht die Handynummern.

Im Anhang mal eine anonymisiertes Logfile. Ich habe nur die persönlichen Daten, nicht aber die Zeiten geändert. Daran ist erkennbar, daß zwischen Erkennung des Anrufes durch den Callmonitor und der Signalisation per dbopopup ca. 5 Minuten und 20 Sekunden vergehen.

Apr  5 21:15:54 fritz user.debug kernel: mcfw: group 224.0.1.60: 192.168.170.19 (cpmac:1) refresh EXCLUDE()
Apr  5 21:15:54 fritz user.debug kernel: mcfw: group 224.0.1.60: 192.168.170.19: setup timer (261secs)
Apr  5 21:16:52 fritz user.warn kernel: [avm_power]event: 27 not handled
Apr  5 21:16:53 fritz daemon.debug callmonitor: <<< timestamp=05.04.09 21:16:53 event=RING id=0 source=09876543210 dest=99999 provider=ISDN
Apr  5 21:16:53 fritz daemon.debug callmonitor: >>> in:request ID=0 TIMESTAMP=05.04.09 21:16:53 SOURCE=09876543210 DEST=99999 EXT= DURATION= PROVIDER=ISDN
Apr  5 21:16:58 fritz daemon.debug callmonitor: <<< timestamp=05.04.09 21:16:58 event=CONNECT id=0 ext=4 remote=09876543210
Apr  5 21:16:58 fritz daemon.debug callmonitor: >>> in:connect ID=0 TIMESTAMP=05.04.09 21:16:58 SOURCE=09876543210 DEST=99999 EXT=4 DURATION= PROVIDER=ISDN
Apr  5 21:17:54 fritz user.warn kernel: /proc/tffs: info request: success
Apr  5 21:17:55 fritz user.debug kernel: mcfw: group 0.0.0.0: query tiwlan:0 10sec
Apr  5 21:17:55 fritz user.debug kernel: mcfw: group 0.0.0.0: query cpmac:0 10sec
Apr  5 21:18:01 fritz user.debug kernel: mcfw: group 224.0.1.60: 192.168.170.19 (cpmac:1) refresh EXCLUDE()
Apr  5 21:18:01 fritz user.debug kernel: mcfw: group 224.0.1.60: 192.168.170.19: setup timer (261secs)
Apr  5 21:20:00 fritz user.debug kernel: mcfw: group 0.0.0.0: query tiwlan:0 10sec
Apr  5 21:20:00 fritz user.debug kernel: mcfw: group 0.0.0.0: query cpmac:0 10sec
Apr  5 21:20:08 fritz user.debug kernel: mcfw: group 224.0.1.60: 192.168.170.19 (cpmac:1) refresh EXCLUDE()
Apr  5 21:20:08 fritz user.debug kernel: mcfw: group 224.0.1.60: 192.168.170.19: setup timer (261secs)
Apr  5 21:22:05 fritz user.debug kernel: mcfw: group 0.0.0.0: query tiwlan:0 10sec
Apr  5 21:22:05 fritz user.debug kernel: mcfw: group 0.0.0.0: query cpmac:0 10sec
Apr  5 21:22:06 fritz user.debug kernel: mcfw: group 224.0.1.60: 192.168.170.19 (cpmac:1) refresh EXCLUDE()
Apr  5 21:22:06 fritz user.debug kernel: mcfw: group 224.0.1.60: 192.168.170.19: setup timer (261secs)
Apr  5 21:22:12 fritz daemon.info callmonitor: [9] event detected:
Apr  5 21:22:12 fritz daemon.debug callmonitor: [9+] detailed event data:
Apr  5 21:22:12 fritz daemon.debug callmonitor:   SOURCE_DISP='09876543210'
Apr  5 21:22:12 fritz daemon.debug callmonitor:   SOURCE_ENTRY='Anrufer Name [home]'
Apr  5 21:22:12 fritz daemon.debug callmonitor:     SOURCE_NAME='Anrufer Name [home]'
Apr  5 21:22:12 fritz daemon.debug callmonitor:     SOURCE_ADDRESS=''
Apr  5 21:22:12 fritz daemon.debug callmonitor:   DEST_DISP='99999'
Apr  5 21:22:12 fritz daemon.debug callmonitor:   DEST_ENTRY='Mein Name'
Apr  5 21:22:12 fritz daemon.debug callmonitor:     DEST_NAME='Mein Name'
Apr  5 21:22:12 fritz daemon.debug callmonitor:     DEST_ADDRESS=''
Apr  5 21:22:12 fritz daemon.debug callmonitor:   ID=0
Apr  5 21:22:12 fritz daemon.debug callmonitor:   EXT=
Apr  5 21:22:12 fritz daemon.debug callmonitor:   DURATION=
Apr  5 21:22:12 fritz daemon.debug callmonitor:   TIMESTAMP='05.04.09 21:16:53'
Apr  5 21:22:12 fritz daemon.debug callmonitor:   PROVIDER=ISDN
Apr  5 21:22:12 fritz daemon.info callmonitor:   EVENT=in:request
Apr  5 21:22:13 fritz daemon.debug callmonitor: [9:0] processing rule 'in:request' '^' '99999$' 'dboxpopup 192.168.170.8 " Ankommender Anruf von %0A %0A $SOURCE_NAME %0A $SOURCE %0A %0Afür Privat"'
Apr  5 21:22:13 fritz daemon.debug callmonitor: [9:0] event 'in:request' matches pattern 'in:request'
Apr  5 21:22:13 fritz daemon.debug callmonitor: [9:0] parameter SOURCE='09876543210' matches pattern '^'
Apr  5 21:22:13 fritz daemon.debug callmonitor: [9:0] parameter DEST='99999' matches pattern '99999$'
Apr  5 21:22:13 fritz daemon.debug callmonitor: [9:0] SUCCEEDED
Apr  5 21:22:13 fritz daemon.info callmonitor:   SOURCE='09876543210'
Apr  5 21:22:13 fritz daemon.info callmonitor:   DEST='99999'
Apr  5 21:22:13 fritz daemon.info callmonitor: [9:0] ACTION: 'dboxpopup 192.168.170.8 " Ankommender Anruf von %0A %0A $SOURCE_NAME %0A $SOURCE %0A %0Afür Privat"'
Apr  5 21:22:13 fritz daemon.debug callmonitor: [9:2] processing rule 'in:request' '^' '9XXXX9$' 'dboxpopup 192.168.170.8 "Achtung! %0a Ein Fax kommt."'
Apr  5 21:22:13 fritz daemon.debug callmonitor: [9:2] event 'in:request' matches pattern 'in:request'
Apr  5 21:22:13 fritz daemon.debug callmonitor: [9:2] parameter SOURCE='09876543210' matches pattern '^'
Apr  5 21:22:13 fritz daemon.debug callmonitor: [9:1] processing rule 'in:request' '^' '9XXXX4$' 'dboxpopup 192.168.170.8 " Ankommender Anruf von %0A %0A $SOURCE_NAME %0A $SOURCE %0A %0Afür Firma"'
Apr  5 21:22:13 fritz daemon.debug callmonitor: [9:1] event 'in:request' matches pattern 'in:request'
Apr  5 21:22:13 fritz daemon.debug callmonitor: [9:1] parameter SOURCE='09876543210' matches pattern '^'
Apr  5 21:22:13 fritz daemon.debug callmonitor: [9:1] parameter DEST='99999' does NOT match pattern '9XXXX4$'
Apr  5 21:22:13 fritz daemon.debug callmonitor: [9:1] FAILED
Apr  5 21:22:13 fritz daemon.debug callmonitor: [9:2] parameter DEST='99999' does NOT match pattern '9XXXX9$'
Apr  5 21:22:13 fritz daemon.debug callmonitor: [9:2] FAILED
Apr  5 21:22:13 fritz daemon.debug callmonitor: [9:5] processing rule 'in:request' '^0123456789$' '123456$' 'ether-wake -i eth0 00:00:00:00:00:00'
Apr  5 21:22:13 fritz daemon.debug callmonitor: [9:5] event 'in:request' matches pattern 'in:request'
Apr  5 21:22:13 fritz daemon.debug callmonitor: [9:5] parameter SOURCE='09876543210' does NOT match pattern '^0123456789$'
Apr  5 21:22:13 fritz daemon.debug callmonitor: [9:5] FAILED
Apr  5 21:22:13 fritz daemon.debug callmonitor: [9:3] processing rule 'in:cancel' '^' '99999$' 'mailmessage -t [email protected]'
Apr  5 21:22:13 fritz daemon.debug callmonitor: [9:3] event 'in:request' does NOT match pattern 'in:cancel'
Apr  5 21:22:13 fritz daemon.debug callmonitor: [9:3] FAILED
Apr  5 21:22:14 fritz daemon.debug callmonitor: [9:4] processing rule 'out:request' '99999$' '08003302424$' 'ether-wake -i eth0 00:00:00:00:00:00'
Apr  5 21:22:14 fritz daemon.debug callmonitor: [9:4] event 'in:request' does NOT match pattern 'out:request'
Apr  5 21:22:14 fritz daemon.debug callmonitor: [9:4] FAILED
Apr  5 21:22:22 fritz daemon.debug callmonitor: [10+] detailed event data:
Apr  5 21:22:22 fritz daemon.debug callmonitor:   SOURCE_DISP='09876543210'
Apr  5 21:22:22 fritz daemon.debug callmonitor:   SOURCE_ENTRY='Anrufer Name [home]'
Apr  5 21:22:22 fritz daemon.debug callmonitor:     SOURCE_NAME='Anrufer Name [home]'
Apr  5 21:22:22 fritz daemon.debug callmonitor:     SOURCE_ADDRESS=''
Apr  5 21:22:22 fritz daemon.debug callmonitor:   DEST_DISP='99999'
Apr  5 21:22:22 fritz daemon.info callmonitor: [10] event detected:
Apr  5 21:22:22 fritz daemon.info callmonitor:   EVENT=in:connect
Apr  5 21:22:22 fritz daemon.info callmonitor:   SOURCE='09876543210'
Apr  5 21:22:22 fritz daemon.info callmonitor:   DEST='99999'
Apr  5 21:22:22 fritz daemon.debug callmonitor:   DEST_ENTRY='Mein Name'
Apr  5 21:22:22 fritz daemon.debug callmonitor:     DEST_NAME='Mein Name'
Apr  5 21:22:22 fritz daemon.debug callmonitor:     DEST_ADDRESS=''
Apr  5 21:22:22 fritz daemon.debug callmonitor:   ID=0
Apr  5 21:22:22 fritz daemon.debug callmonitor:   EXT=4
Apr  5 21:22:22 fritz daemon.debug callmonitor:   DURATION=
Apr  5 21:22:22 fritz daemon.debug callmonitor:   TIMESTAMP='05.04.09 21:16:58'
Apr  5 21:22:22 fritz daemon.debug callmonitor:   PROVIDER=ISDN
Apr  5 21:22:22 fritz daemon.debug callmonitor: [10:0] processing rule 'in:request' '^' '99999$' 'dboxpopup 192.168.170.8 " Ankommender Anruf von %0A %0A $SOURCE_NAME %0A $SOURCE %0A %0Afür Privat"'
Apr  5 21:22:22 fritz daemon.debug callmonitor: [10:1] processing rule 'in:request' '^' '9XXXX4$' 'dboxpopup 192.168.170.8 " Ankommender Anruf von %0A %0A $SOURCE_NAME %0A $SOURCE %0A %0Afür Firma"'
Apr  5 21:22:22 fritz daemon.debug callmonitor: [10:1] event 'in:connect' does NOT match pattern 'in:request'
Apr  5 21:22:22 fritz daemon.debug callmonitor: [10:1] FAILED
Apr  5 21:22:22 fritz daemon.debug callmonitor: [10:2] processing rule 'in:request' '^' '9XXXX9$' 'dboxpopup 192.168.170.8 "Achtung! %0a Ein Fax kommt."'
Apr  5 21:22:22 fritz daemon.debug callmonitor: [10:0] event 'in:connect' does NOT match pattern 'in:request'
Apr  5 21:22:22 fritz daemon.debug callmonitor: [10:0] FAILED
Apr  5 21:22:22 fritz daemon.debug callmonitor: [10:3] processing rule 'in:cancel' '^' '99999$' 'mailmessage -t [email protected]'
Apr  5 21:22:22 fritz daemon.debug callmonitor: [10:3] event 'in:connect' does NOT match pattern 'in:cancel'
Apr  5 21:22:22 fritz daemon.debug callmonitor: [10:3] FAILED
Apr  5 21:22:22 fritz daemon.debug callmonitor: [10:4] processing rule 'out:request' '99999$' '08003302424$' 'ether-wake -i eth0 00:00:00:00:00:00'
Apr  5 21:22:23 fritz daemon.debug callmonitor: [10:2] event 'in:connect' does NOT match pattern 'in:request'
Apr  5 21:22:23 fritz daemon.debug callmonitor: [10:2] FAILED
Apr  5 21:22:23 fritz daemon.debug callmonitor: [10:5] processing rule 'in:request' '^0123456789$' '123456$' 'ether-wake -i eth0 00:00:00:00:00:00'
Apr  5 21:22:23 fritz daemon.debug callmonitor: [10:5] event 'in:connect' does NOT match pattern 'in:request'
Apr  5 21:22:23 fritz daemon.debug callmonitor: [10:5] FAILED
Apr  5 21:22:23 fritz daemon.debug callmonitor: [10:4] event 'in:connect' does NOT match pattern 'out:request'
Apr  5 21:22:23 fritz daemon.debug callmonitor: [10:4] FAILED
Apr  5 21:22:23 fritz user.warn kernel: [speedup] -> 125 MHz
Apr  5 21:22:25 fritz user.warn kernel: /proc/tffs: info request: success

Gruß Telefonmännchen

 

[buehmann]

Guten Morgen, Telefonmännchen,

die 5 Minuten von Erkennen des Anrufs bis zur Bearbeitung der ersten Regel sind eindeutig zu lang. Und deine Vermutung ist richtig: Zwischen den beiden Logausgaben passiert eigentlich nur das Nachschlagen von SOURCE und DEST in den Telefonbüchern.

Kann es evtl. sein, daß der aktuelle Callmonitor nicht mit einem relativ großen Telefonbuch auf der FritzBox klarkommt? Wurde da etwas in letzter Zeit verändert?

Die letzten Änderungen in diesem Bereich waren vor 7-8 Monaten.

Wie kann ich das, ohne das Telefonbuch zu verkleinern, verbessern?

Hast du schon überprüft, dass es mit einem kurzen Telefonbuch besser wird?

Ich habe gerade folgendes ausprobiert; vielleicht kannst du das einmal nachvollziehen: Auf der Konsole

time phonebook --local get 123456789

Bei einem Telefonbuch mit 270 Einträgen dauert das bei mir beim Finden des ersten Eintrags 0,55 Sekunden, beim letzten 1,33 Sekunden, bei einem nicht vorhandenen Eintrag 1,35 Sekunden.

Bitte überprüfe vorher, ob /var/cache/phonebook/avm dein Telefonbuch enthält.

Viele Grüße

Andreas

 

[Telefonmännchen]

Danke, daß du Dir dieses Problem mal anschaust. Ich habe mal Deine Tests gemacht und Antwortzeiten von ca. 20 Sekunden erhalten. Allerdings erhalte ich auf der Rudi-Console vom Freetz keine time-Angaben, sondern nur den gefundenen Eintrag. Und handgestoppt dauert die Abfrage 20 Sekunden bis zur Antwort. Die Antwortzeit beim ersten Eintrag liegt auch bei unter einer Sekunde. Ich habe auch festgestellt, daß wohl in letzter Zeit ein paar Telefonnummern dazugekommen sind. Ich dachte, es ist identisch mit meinem Outlook. Es handelt sich um 327 Einträge, die sich ja auf 981 Zeilen wegen der Mehrfacheinträge pro Name (home, work, mobile) aufblähen. Trotzdem sollten sich die Abfragezeiten nicht so stark von den Deinigen unterscheiden, selbst wenn es jetzt 50 Einträge mehr sind. Es ging ja mit alten Versionen auch schon mal schneller. Und die Abfragezeit 20 Sekunden unterscheidet sich auch stark von den protokollierten fünf Minuten. Aber es läuft ja zu diesem Moment auch weiter nichts. Im Syslog kann ich auch das Hochtakten auf 125 MHz während des Suchlaufes beobachten. Also ganz normal.

Optisch weist das AVM-Telefonbuch bis auf die bei deutschen Namen leider manchmal üblichen Umlaute die entsprechend umgesetzt sind (ä --> ä , ö --> à , ü --> ü¶) keine weiteren Auffälligkeiten auf. Das ß habe ich schon eliminiert. Im Moment habe ich, wenn ich nicht gerade teste, alle Telefonbucheinträge in den Callers drin und ganz normale Reaktionszeiten. Die Abfrage des AVM-Telefonbuches ist dann deaktiviert.

Ich habe gerade mal die Abfrage wieder aktivieren wollen. Dabei ist mir die Box abgestürzt. Leider habe ich keine Logausgabe. Nach dem Reboot habe ich die Abfrage wieder deaktiviert und jetzt ist sie zumindest wieder stabil. Ich komme immer mehr zu der Überzeugung, daß irgendetwas im Telefonbuch nicht ganz korrekt ist, denn dieses wird ja auch beim Neustart des Callmonitors nach Konfigurationsänderungen eingelesen. Ich werde es mal testweise verkleinern und die Umlaute entfernen. Mal schauen, wie es sich dann verhält. Im Normalfall pflege ich das Telefonbuch mit den AVM-Tool FritzBox-Monitor.

Gruß Telefonmännchen

PS: Ich muß mir sowieso mal ein neues Image bauen, da ich beim letzten den SSH-Server vergessen habe und somit keinen Zugriff per Putty sondern nur über die Rudi-Shell des Freetz habe. Ich brauche aber nächste Woche den Server, wenn ich weg bin. Das Problem habe ich aber schon in beiden letzten Trunks mit dem 1.12.5er Callmonitor.

Update:
Ich habe gerade mal aus dem Telefonbuch sämtliche Umlaute entfernt und habe derzeitig eine Antwortzeit von ca. 2:30 Minuten für den letzten Telefonbucheintrag. Mit einem Telefonbuch mit ca. 120 Einträgen habe ich eine Antwortzeit von 1:45 Minuten. Also auch nicht besonders schnell. Irgendwo ist der Wurm drin.

 

[buehmann]

Hallo,

Ich habe mal Deine Tests gemacht und Antwortzeiten von ca. 20 Sekunden erhalten.

das ist nicht ohne, aber auch nicht vergleichbar mit meinen Messungen (ich hatte nur 270 Einträge, du 981); hochgerechnet dürfte die Antwortzeit bei mir dann 3,5 Sekunden betragen.

Im Moment habe ich, wenn ich nicht gerade teste, alle Telefonbucheinträge in den Callers drin und ganz normale Reaktionszeiten.

Das dürfte nicht sein; die Zugriffe auf Callers und das AVM-Telefonbuch sind identisch realisiert. Höchstens beim Caching kann etwas schiefgegangen sein bei dir, so dass bei jeder Anfrage das AVM-Telefonbuch über das Webinterface abgerufen wird. Deswegen nochmal meine Frage: Existiert /var/cache/phonebook/avm und enthält deine 981 Zeilen?

Andreas

PS:

Optisch weist das AVM-Telefonbuch bis auf die bei deutschen Namen leider manchmal üblichen Umlaute die entsprechend umgesetzt sind (ä --> ä , ö --> à , ü --> ü¶) keine weiteren Auffälligkeiten auf. Das ß habe ich schon eliminiert.

Das habe ich nicht verstanden; wer hat die Umlaute umgesetzt, und warum hast du das Eszett entfernt?

 

[Telefonmännchen]

Die Datei /var/cache/phonebook/avm existiert und enthält das Telefonbuch oder zumindest die Daten aus dem AVM-Telefonbuch (981 Datensätze). Wenn ich es mit der Rudi-Shell abrufe werden alle Umlaute durch die dargestellten Zeichenkombinationen ersetzt. Kann also auch an der Shell liegen. Das ß was nur in zwei Namen auftaucht habe ich schon aus Komptibilitätsgründen zur dBox durch Doppel-S ersetzt, also gar nich tert im Telefonbuch eingegeben. Mit dem Hinweis wollte ich nur der Nachfrage vorbeugen, ob das ß oder andere Sonderzeichen im Telefonbuch zu finden sind. Das alles heißt eigentlich, daß die Daten vorhanden sind und auch so benutzt werden sollten. Ich habe auch sporadisch in den Ereignissen die Meldung "Anmeldung an der FRITZ!Box Benutzeroberfläche von IP-Adresse 127.0.0.1." Da mein Log durch den Absturz wieder blank ist, kann ich jetzt auch nicht nachvollziehen, was das ausgelöst hatte. Ich tippe aber mal auf den Callmonitor, denn ich meine da einen Zusammenhang mit den Restarts nach Konfigurationsänderungen herstellen zu können. Die Einträge tauchen aber nicht bei einem eingehenden Anruf auf.

Ich habe jetzt wieder eine Console (habe mir mal ein neue Image mit SSH gebacken und immer noch identische Probleme). Die Telefonbuchabfrage gab das folgende Bild:

/var/mod/root # time phonebook --local get 123456789

Command exited with non-zero status 1
real    0m 30.65s
user    0m 8.22s
sys     0m 22.30s

Und jetzt mal das Ergebnis mit einer existierenden Rufnummer am Ende des Telefonbuches.

Command exited with non-zero status 1
real    0m 58.81s
user    0m 15.63s
sys     0m 38.46s

Dieses läßt sich mit fast identischen Zeiten nachvollziehen. Heißt, wenn ich die 123456789 teste, habe ich eine Antwort nach der Hälfte der Zeit, die für eine Abfrage einer existierenden Nummer benötigt wird. Jeweils drei Tests - Zufall!?

Gruß Telefonmännchen

 

[buehmann]

Hi,

super. Danke für das Feedback.

Die Datei /var/cache/phonebook/avm existiert und enthält das Telefonbuch

Gut; eine mögliche Fehlerursache weniger.

Wenn ich es mit der Rudi-Shell abrufe werden alle Umlaute durch die dargestellten Zeichenkombinationen ersetzt.

Interessant; da scheint sich die Kodierung des Telefonbuchs/des Webinterface geändert zu haben (die Umlaute sehen nach Unicode/UTF-8 aus). Ich glaube momentan nicht, dass das etwas mit dem Zeitproblem zu tun hat, aber könntest du für mich die Kodierung mal überprüfen? (Am besten einen Testeintrag ins AVM-Telefonbuch machen mit "äöüß" im Namen und irgendeinem eindeutigen Wort; dann mit "phonebook start" den Cache aktualisieren, und mir den hexdump der passenden Zeile schicken, ungefähr so:

grep "DasWort" /var/cache/phonebook/avm | hexdump

schon aus Komptibilitätsgründen zur dBox durch Doppel-S ersetzt

Ich strebe beim Telefonbuch und sämtlichen Benachrichtigungsfunktionen an, dass sämtliche Umlaute out-of-the-box funktionieren. Deswegen sollten wir das beheben; aber höchstwahrscheinlich hängt das mit dem vorherigen Punkt zusammen.

"Anmeldung an der FRITZ!Box Benutzeroberfläche von IP-Adresse 127.0.0.1."

Der Callmonitor ruft das Telefonbuch (und andere Dinge) über das Webinterface ab und loggt sich dafür ein.

Und jetzt mal das Ergebnis mit einer existierenden Rufnummer am Ende des Telefonbuches: 58.81s

Bei mir sinds beim 981. Eintrag knapp 19 Sekunden; evtl. ist der Speedport etwas schwächer auf der Brust, was die CPU angeht.

Ich hätte nie gedacht, dass mal knapp 1000 Einträge im Telefonbuch benutzt werden würden; deswegen experimentiere ich gerade mit einer Datenstruktur, mit der jede Telefonnummer (auch aus 1000 Stück) momentan in 0,6 Sekunden gefunden wird.

Jeweils drei Tests - Zufall!?

Dass es die Hälfte war? Ja, vermutlich steht der andere Eintrag ungefähr in der Mitte (momentan wird nur sequentiell von oben nach unten gesucht). Dass es reproduzierbar ist, ist ja schon einmal gut.

Viele Grüße

Andreas

 

[Telefonmännchen]

Ich habe zu danken.

So, habe mal den Testeintrag unter dem einfallsreichen Namen "Testeintrag äöüß", privat: 0987654321, mobil:0123456789, gesch.: leer gemacht und folgenden Hexdump erhalten.

/var/mod/root # phonebook start
Reading AVM's phone book...done.
/var/mod/root # grep "Testeintrag" /var/cache/phonebook/avm | hexdump
0000000 3930 3738 3536 3334 3132 5409 7365 6574
0000010 6e69 7274 6761 c320 c3a4 c3b6 c3bc 209f
0000020 685b 6d6f 5d65 300a 3231 3433 3635 3837
0000030 0939 6554 7473 6965 746e 6172 2067 a4c3
0000040 b6c3 bcc3 9fc3 5b20 6f6d 6962 656c 0a5d
0000050

Bei mir sinds beim 981. Eintrag knapp 19 Sekunden; evtl. ist der Speedport etwas schwächer auf der Brust, was die CPU angeht.

Ich hätte nie gedacht, dass mal knapp 1000 Einträge im Telefonbuch benutzt werden würden; ...

Die CPU läuft bei Vollspeed laut Syslog mit 125 MHz. Keine Ahnung, wie die der Original-Fritz-Boxen tickt. Eigentlich ist das ja auch nicht von AVM vorgesehen. Durch ihre automatische Zuordnung der Kurzwahlen begrenzt AVM das ja eigentlich auf 100 Einträge. Durch einen ini-Eintrag kann man halt dieses beim AVM FritzBox-Monitor abschalten und somit mehr als 100 Einträge rüberschieben. Intern wird natürlich mit mehreren Datenfeldern gearbeitet, so daß sich die Einträge verdeifachen. Ich finde es halt recht informativ, wenn die Rufnummern in der täglichen Pushmail und der "Anruf verpasst"-Mail mit Namen aufgelöst werden. So kann man auch mal nach Wichtigkeit über einen Rückruf entscheiden, wenn man nicht am Ort ist und die Benachrichtigung nur per SMS oder Mail erhält. Darum trage ich den größten Teil meiner/unserer Kommunikationpartner im Telefonbuch ein. Dieses faßt mehr, als die Telefonbücher der Gigasets. Und wenn die Namen in der FritzBox sind, werden sie ja auch auf dem Telefondisplay dargestellt.

Ich kann erst morgen dann weitertesten. Muß (resp. "darf" muß man ja heutzutage schon sagen) zur Nachtschicht. Danke schon mal.

Gruß Telefonmännchen

 

[Silent-Tears]

Du hast aber den Multiplikator vergessen bei dem Speddport. Denn multipliziert mit 2 läuft das Ding dann doch auf 210mhz, ebenso wie die 7170. Die sind übrigens nahezu Baugleich, nur der DECT-Murks ist beim Speddport mehr dran und der seltsame Schalter zum Modem umstellen.

 

[buehmann]

Hallo Telefonmännchen,

deswegen experimentiere ich gerade mit einer Datenstruktur, mit der jede Telefonnummer (auch aus 1000 Stück) momentan in 0,6 Sekunden gefunden wird.

vielleicht hast du Lust, diese Testversion einmal auszuprobieren: ftp://ftp.berlios.de/pub/callmonitor/preview/callmonitor-1.12.5b-freetz.tar.bz2
Sie speichert die Telefonbücher als Bäume, um die Nummern schneller finden zu können. Es wäre toll, wenn du ein paar Erfahrungen sammeln würdest, inwieweit dies in deinem Fall eine Verbesserung ist. (Mit den Vergleichsmessungen von oben, aber auch gerne im täglichen Betrieb, falls du die Testversion dort einsetzen magst.)

Außerdem habe ich dafür gesorgt, dass die Einträge aus dem AVM-Telefonbuch richtig umkodiert werden, damit die Umlaute wieder stimmen. (Das konnte ich allerdings noch nicht testen; für deinen Testeintrag: Da es /var/cache/phonebook/avm als Datei nicht mehr gibt; solltest du so etwas wie "phonebook --local get 0987654321 | hexdump" benutzen.)

Viele Grüße

Andreas

 

[Telefonmännchen]

Hallo Andreas,

Hut ab, Du bist genial. Natürlich hatte ich Lust, die Version 1.12.5b mal auszuprobieren. Habe heute eine Image erstellt und auf den Speedport geflasht. Mußte erst mal nachschauen, wie addons integriert werden, aber zum Glück ist im Wiki alles schön dokumentiert. Die ersten Tests sehen sehr vielversprechend aus. Ich habe mal alle vorher gemachten Tests mit den gleichen Rufnummern wiederholt und sehr gute Ergebnisse erzielt. Ebenso habe ich live getestet. Die Antwortzeiten am Fernseher sind jetzt wieder so, wie ich sie von früher her kenne. Das Telefonbuch auf dem Speedport ist wieder das mit den Umlauten.

Im Anhang mal die Testergebnisse:

/var/mod/root # time phonebook --local get 123456789
Testeintrag äöüß [mobile]
real    0m 0.60s
user    0m 0.31s
sys     0m 0.30s


--> gleiche Abfrage mit existierender Rufnummer (letzter Eintrag im Telefonbuch)
Command exited with non-zero status 1
real    0m 1.95s
user    0m 1.53s
sys     0m 0.41s


/var/mod/root # phonebook --local get 0987654321 | hexdump
0000000 6554 7473 6965 746e 6172 2067 f6e4 dffc
0000010 5b20 6f68 656d 0a5d
0000018

Nochmals vielen Dank. Ich werde dann erst mal weitertesten. Bin aber ab Ostermontag Mittag nicht mehr zu Hause. Dann muß die Box mal eine Woche ohne Eingriffe problemlos durchlaufen und mich schön über etwaige eingehende Anrufe und sonstige Ereignisse per Mail und SMS informieren. Das funktioniert soweit ich es getestet habe auch problemlos. Wenn ich nach den Ferien wieder da bin, werde ich auch mein eigenes dboxlcd-Script wieder in den Listeners aktivieren. Ich habe da ein selbst angepasstes mit etwas größerer Darstellung (nur Name des Anrufers) auf dem Display.

Wenn es noch was zu testen gibt, dann nur zu. Mein SSH-Server läuft wieder und sollte auch von außen erreichbar sein. An den Orten, an denen ich mich die nächste Woche aufhalte, habe ich Internetzugriff und somit Zugriff auf meine Box. Nur eine neue Firmware möchte ich remote nicht flashen. Noch mal vielen Dank für den schnellen Support.

Gruß Telefonmännchen

 

[buehmann]

Hi,

danke für die erste Testrückmeldung. Schön, dass es bisher auch bei dir ohne Probleme funktioniert.

real 0m 0.60s

Ja, das sieht vernünftig aus.

--> gleiche Abfrage mit existierender Rufnummer (letzter Eintrag im Telefonbuch)
Command exited with non-zero status 1
real 0m 1.95s

Ähm, hier hast du dich verschrieben, oder? Das dürfte eine nicht existierende Rufnummer sein (aber die hat keine Position im Telefonbuch ...?). Die zusätzlichen 1,3 Sekunden dürften bei den folgenden Abfragen im Cache (vermutlich leer) und in den Callers verbracht werden; wieviele Einträge hast du dort ungefähr? (phonebook list callers; phonebook list cache)

0000000 6554 7473 6965 746e 6172 2067 f6e4 dffc
0000010 5b20 6f68 656d 0a5d

Perfekt, das ist Latin1-Kodierung. ("I don't even see the code. All I see is blonde, brunette, redhead." )

Andreas

 

[Telefonmännchen]

Ähm, hier hast du dich verschrieben, oder? Das dürfte eine nicht existierende Rufnummer sein ....

Hallo Andreas,

kann sein, daß ich mich bei der zu suchenden Telefonnummer vertippt habe. Die Ausgaben sind alle cut 'n paste. Hier noch mal die Ausgabe mit der überprüften Rufnummer und auch dem gefundenem Namen.

/var/mod/root # time phonebook --local get 0XXXXXXXXX
Zxxxxxxx [home]
real    0m 1.19s
user    0m 0.39s
sys     0m 0.75s

Die Abfrage von "phonebook list callers" listet meine Telefonbucheinträge in den Callers auf aber nicht die Anzahl. Der Cache des Putty ist aber nicht groß genug und so wird es aus dem Terminal rausgeschoben. Ich habe aber mal über das Webinterface meine Callers "nachgezählt". Es sind 474.

Bei "phonebook list cache" wird ## cache (/var/cache/phonebook/callers) ausgegeben.

"I don't even see the code. All I see is blonde, brunette, redhead."

Ja, und ich bin einer, der nur die grünen Symbole runterfallen sieht. ;-) Und manchmal sind es nur lauter Fragezeichen. Noch mal Danke.

Gruß Telefonmännchen

 

[Silent-Tears]

Die Abfrage von "phonebook list callers" listet meine Telefonbucheinträge in den Callers auf aber nicht die Anzahl. Der Cache des Putty ist aber nicht groß genug und so wird es aus dem Terminal rausgeschoben. Ich habe aber mal über das Webinterface meine Callers "nachgezählt". Es sind 474.

Mach mal ein:

phonebook list callers|wc -l

daraus und dann hast du die Zeilen gezählt.

 

[Telefonmännchen]

Mach mal ....

Korrekt, und obige Angabe stimmt. Ich habe es nur ein wenig umständlicher gemacht. Danke!

Gruß Telefonmännchen