Callmonitor 1.*

[miwu]

Du must der Fritz-Box (oder eben jedem Rechner in Deinem Subnet) den Zugriff auf svdrp erlauben, folgender Eintrag in die /etc/vdr/svdrphosts.conf schaltet Alle Hosts bei einer Subnet-Mask von 255.255.255.0 frei:

192.168.<was auch immer>.0/24

oder Du trägst halt nur die IP Deiner Box ohne Subnet Mask ein.

Weitere Infos:
http://www.open7x0.org/wiki/Svdrphosts.conf

Viel Erfolg!

Miwu

 

[ao]

Super, vielen Dank!

Das war genau das, was ich gesucht hatte.

 

[Izzy]

CallMonitor bringt Box zum 2x täglichen Absturz

Auf Anraten meines Vorredners klemme ich mich mit dem Thema mal hier rein (wenn ich dafür besser einen eigenen Thread aufmachen soll, z.B. wegen Übersichtlichkeit, mach ich das auch - müsst es mich nur wissen lassen).

Also, wie der Titel sagt: Ich habe mir kürzlich mein erstes Freetz installiert, und dort auch CallMonitor eingebaut. Zuvor lief die Box recht stabil - doch nach dieser Änderung hatte ich täglich mindestens 2 Reboots (siehe auch den Thread ab hier). Nachdem ich CallMonitor abgeschaltet habe, ist die Box jetzt zumindest seit über 36 Stunden stabil durchgelaufen. Der letzte Reboot fand statt, als ich den CallMonitor-Start über das Freetz WebIF von "automatisch" auf "manuell" umschalten wollte, während CallMonitor noch lief (das hat er nicht verkraftet - und war nach dem Boot wieder aktiv). Nachdem ich ihn manuell über das "Dienste" Menü gestoppt hatte, konnte ich ihn jedoch problemlos und ohne Reboot auf "manuell" setzen. Seitdem, wie getippst, alles stabil.

Gern würde ich mit passenden Logauszügen aufwarten - aber unmittelbar vor dem "Knall" brechen diese ab (hatte zur Analyse "logread -r" über telnet am Laufen). Und nach dem Boot sind sie halt weg, da nicht permanent gespeichert.

Welche Informationen wären zur Eingrenzung (möglichst mit anschließender Beseitigung ) des Problems hilfreich, und wo finde ich sie?

 

[wengi]

Hi Izzy,

Ich habe hier genau die gleiche konstellation wie Du am laufen. Nur ohne Voip und ohne reboots. Es _sollte_ als prinzipiell funktionieren.

ich erinnere mich an andere Benutzer, die ähnliches berichtet haben. buehmann wird sich wohl noch daran erinnern, wo und was das war...

Das Syslog lässt sich recht einfach permanent auf einen USB Stick speichern. Habe ich hier auch am laufen. Dies könnte dich eventuell ein bischen weiter bringen.
Beim Kompilieren einfach das Syslog-Webinterface auswählen. Dann USB Stick ran und Speicherpfad dementsprechend ändern. /var/media/....

Falls Du Deine Callers konstant speicherst (wie ich das auch mache) wäre es eine Erklärung für die steigende TFFS Auslastung. (War im anderen Thread angesprochen)

Ich hoffe wenigstens ein bischen geholfen zu haben.

wengi

@buehman: Eine Idee, wann Version 1.12 in freetz landet?

 

[ao]

Falls Du Deine Callers konstant speicherst (wie ich das auch mache) wäre es eine Erklärung für die steigende TFFS Auslastung.

Heisst das, dass TFFS irgendwann überläuft, wenn man die Callers permanent speichert?
TFFS wird doch (m.E.) automatisch aufgeräumt, wenn es zu voll wird. Aber was genau wird denn beim Aufräumen gelöscht? Auch die Callers? Wohl eher nicht, und daher frage ich mich halt, was passiert, wenn - irgendwann - zu viele Callers gespeichert werden müssen.

 

[cuma]

Ich bezweifele, dass du soviele Einträge hast, dass das TFFS voll wird. Bei der 7170 besteht es aus 256 KB in den komprimiert gespeichert wird, was bei Texten bekanntlich gut funktioniert. Es sollten also locker mal 50000 Einträge platz haben. Die Konfigurationsdaten kann man dann vernachlässigen.
Anzumerken ist noch, dass die Freetz Hauptseite anzeigt wieviel _unkomprimierte_ KB im TFFS sind, womit die Prozentangabe total nichtssagend ist!

 

[wengi]

Wenn Dein TFFS wegen der Callers voll ist hast Du das komplette deutsche Telefonbuch im Speicher :bier:

wengi

 

[ao]

Ok, danke Euch Beiden für die Erklärung!

Lässt sich die TFFS-Anzeige in Freetz ggf. ändern, so dass sie aussagekräftiger ist?

 

[Izzy]

Hi wengi,

Ich habe hier genau die gleiche konstellation wie Du am laufen. Nur ohne Voip und ohne reboots. Es _sollte_ als prinzipiell funktionieren.

Anderes hätte mich eigentlich auch gewundert - sonst wäre ich sicher nicht der erste, der solches berichtet...

ich erinnere mich an andere Benutzer, die ähnliches berichtet haben. buehmann wird sich wohl noch daran erinnern, wo und was das war...

Das wäre sehr gut - vielleicht käme daher bereits der entscheidende Hinweis. Ich denke dabei an so etwas wie Konfigurationsfehler (auch wenn ich da noch gar nichts dran gemacht habe), fehlende oder falsche Dateien/Libraries...

Beim Kompilieren einfach das Syslog-Webinterface auswählen. Dann USB Stick ran und Speicherpfad dementsprechend ändern. /var/media/....

:blonk: Da hätte ich auch drauf kommen können. Beim Kompilieren hatte ich schon drauf geachtet... Also gleich mal geschaut, was noch so an USB-Speicher rumgeistert (IMHO habe ich noch ein paar alte "Chips" von meiner nicht mehr vorhandenen ersten DigiCam, die ich per Cardreader anschließen könnte. 256MB sollten dafür ja locker reichen - auch wenn ich noch Swap mit draufpacke

Falls Du Deine Callers konstant speicherst (wie ich das auch mache) wäre es eine Erklärung für die steigende TFFS Auslastung.

Da sollte wäre fett gedruckt werden - womit soll ich die Callers denn speichern, wo ich CallMonitor wegen Stabilität abgeschaltet habe... Nö, das kann es nicht sein.

Ich hoffe wenigstens ein bischen geholfen zu haben.

Hast Du definitiv - Allerbesten Dank!

Anzumerken ist noch, dass die Freetz Hauptseite anzeigt wieviel _unkomprimierte_ KB im TFFS sind, womit die Prozentangabe total nichtssagend ist!

Heisst das im Zusammenhang mit meinem vorigen Post (im anderen Thread), dass die Aussage "120k / 256k" Belegung, er hat 125k unkomprimierte Daten im TFFS - also bei einer mal eben als Hausnummer angenommenen Kompressionsrate von 75%, wären tatsächlich nur 30k tatsächlich belegt?

 

[ao]

Heisst das im Zusammenhang mit meinem vorigen Post (im anderen Thread), dass die Aussage "120k / 256k" Belegung, er hat 125k unkomprimierte Daten im TFFS - also bei einer mal eben als Hausnummer angenommenen Kompressionsrate von 75%, wären tatsächlich nur 30k tatsächlich belegt?

Genau so habe ich cuma verstanden.
Es wäre wie gesagt hilfreich, wenn die Anzeige dahingehend angepasst werden könnte, aber leider habe ich keine Idee wie das ginge.

 

[olistudent]

Anzumerken ist noch, dass die Freetz Hauptseite anzeigt wieviel _unkomprimierte_ KB im TFFS sind, womit die Prozentangabe total nichtssagend ist!

Wir fragen den TFFS-Füllstand direkt aus /proc/tffs ab. Das sollte eigentlich der "wirkliche" Füllstand sein.

Sorry fürs OT.

MfG Oliver

 

[cuma]

Ja stimmt, sorry. Hab das falsch in Erinnerung gehabt. Vielleicht war das mal so. Ich hatte mal einen Patch zum komprimierten Speichern gebastelt, den ich noch benutze.
@ao: Als Kompressionsrate hab ich mal 3/4 angenommen, da alle Einstellungen nur aus Texten bestehen. Wahrscheinlich ist die noch besser. Jedenfalls braucht man sich keine Sorgen wegen den Callers zu machen.

 

[Perseus]

Ich habe Folgendes vor:

Ich rufe die Box an, ohne dass ein angeschlossenes Telefon klingelt (1), soll passieren: sie öffnet einen Port für SSH (2) und startet dropbear (3).
Ich rufe erneut an, der Port wird geschlossen und dropbear beendet, wieder ohne Klingeln.


Nach zahllosen Stunden in dem Thread hier und im Wiki hab ich mir folgendes zusammengereimt, korrigiert mich bitte, wenn ich falsch liege:

1) Einen Befehl für Nichtklingeln gibt es nicht, somit ist kein Eintrag in den Listeners dazu möglich. "Workaround" besteht darin, eine neue VOIP-Nummer anzuschaffen, die in der AVM-Oberfläche registriert wird, für die jedoch kein Anschluss zugewiesen wird, sodass die Listener auf jene Nummer reagieren können und es nirgends klingelt.

2) Irgendwo in der 35. Zeile des 17. Posts geschätzte 27 Seiten weiter vorn wurde der Pseudowert "toggle" eingeführt, mit dem ich Forwarding an/abschalten kann und nur einen Listener bemühen muss (die Funktion hab ich gleich mal in die Wiki gepostet).

3) Ich kann einen Listener schreiben, der mir dropbear startet - aber wie beende ich das dann? Wenn ich einen Listener auf die gleiche Nummer schreibe, der mir dropbear beendet, dann weiß ich nicht was passiert, da irgendwo ganz weit vorn steht, dass eine bestimmte Reihenfolge der Abarbeitung der Listener nicht garantiert ist, sodass das Beenden durchaus vor dem Start aufgerufen werden könnte, was den Dropbear dann ja laufen lassen würde...
Ich bräuchte also irgendeine Art Toggle-Skript, das mir dabei hilft, ihn zu beenden, wenn er läuft und ihn zu starten, wenn er nicht läuft...aber wie?



Unabhängig vom obigen hab ich das Problem, dass YAC nur auf den Testanruf des Callmonitors reagiert, aber schweigt, wenn das Telefon "richtig" klingelt?

in:request ^ ^ yac 192.168.178.20

Ich habe die Debug-Ausgaben aktiviert, aber wo finde ich die? Was ist mit System-Log gemeint? Weder in der Ereignisanzeige der AVM-Oberfläche, noch in den von Freetz aus erreichbaren Logfiles habe ich den Log.

 

[buehmann]

Wow, was ist denn hier los?

@Izzy + wengi: Der aktuelle Stand bezüglich des Aufhängens der Box ist immer noch, das es bei manchen auftritt, bei manchen überhaupt nicht, wenn, dann mehr oder weniger (un)regelmäßig, und anscheinend irgendwie mit dem Callmonitor zusammenhängt. Irgendwelche Muster/Zusammenhänge/genaue Absturzsymptome konnte noch niemand beobachten. :noidea:

@wengi: Version 1.12.2 ist doch längst in freetz-trunk. ;-) (Danke.)

@Perseus: Ja, der Callmonitor beobachtet nur und hat keinen Einfluss auf das Klingeln etc.; das musst du separat unterdrücken.

Ja, wir sollten bald mal diesen viel zu langen Thread schließen und in Zukunft für jedes Teilproblem einen eigenen aufmachen.

Es gibt noch aus Zeiten, bevor ich den Callmonitor übernommen habe, eine Funktion droptoggle, die dropbear startet oder stoppt: Ich zitiere mal aus actions.d/dropbear.sh:

## start or stop ssh daemon
RC_DROPBEAR="/mod/etc/init.d/rc.dropbear"
droptoggle() {
    if [ -x "$RC_DROPBEAR" ]; then
        if [ "$("$RC_DROPBEAR" status)" = "running" ]; then
            "$RC_DROPBEAR" stop
        else
            "$RC_DROPBEAR" start
        fi
    fi
}

Ein einfacher Ansatz für dich wäre also

droptoggle; config forward 42 toggle

aber das ist fehlerträchtig (wenn eine der Umschaltungen mal nicht funktioniert, sind die Zustände genau entgegengesetzt, also entweder ist dropbear aus oder der Port zu). Du solltest dir also vielleicht etwas Passenderes mithilfe von rc.dropbear und config zusammenstellen.

Viele Grüße,
Andreas

PS: Ach so, um das System-Log anzusehen, installierst du am besten das Paket syslog-cgi. Ansonsten manuell "syslogd -C" starten und dann z.B. mit "logread -f" verfolgen.

 

[Izzy]

Wow, was ist denn hier los?

Es geht auf Weihnachten zu

@Izzy + wengi: Der aktuelle Stand bezüglich des Aufhängens der Box ist immer noch, das es bei manchen auftritt, bei manchen überhaupt nicht, wenn, dann mehr oder weniger (un)regelmäßig, und anscheinend irgendwie mit dem Callmonitor zusammenhängt. Irgendwelche Muster/Zusammenhänge/genaue Absturzsymptome konnte noch niemand beobachten. :noidea:

Zumindest ist das Problem schonmal bekannt. Vielleicht habe ich - aus Deinen anderen Angaben heraus - eine Idee, aber wahrscheinlich geht die voll in's Blaue statt in's Schwarze:

Es gibt noch aus Zeiten, bevor ich den Callmonitor übernommen habe, eine Funktion droptoggle, die dropbear startet oder stoppt: Ich zitiere mal aus actions.d/dropbear.sh:

Aha. Und was passiert, wenn dropbear nicht installiert ist? Ich weiß, sollte eigentlich nix passieren. Aber ist vielleicht das zufällig all denen gemeinsam, die das Problem haben? Ich habe Dropbear nämlich nicht mit reingepackt, weil ich eigentlich keinen SSH Zugang auf die Fritte brauche.

@wengi: Version 1.12.2 ist doch längst in freetz-trunk. ;-) (Danke.)

Entnehme ich dem Smiley richtig, dass das erst kürzlich (also nach r2475) passiert ist? Bei mir ist nämlich noch eine 1.11 drin...

Ja, wir sollten bald mal diesen viel zu langen Thread schließen und in Zukunft für jedes Teilproblem einen eigenen aufmachen.

Feel free 2 split Ich meine, wenn das hier geht...

Andreas: Hast Du vielleicht noch ein paar Tipps, wo sich Material für die Fehleranalyse finden ließe? Wie ich schon schrieb, bricht "logread -f" via telnet bereits zusammen, bevor die relevanten Informationen den Weg über's Netz gefunden haben. Weiß ich definitiv, weil es mir einmal wenige Sekunden nach einem Gesprächsaufbau passierte ("Hallo Hallo" mit dem Gegenüber war bereits ausgetauscht, Gespräch also bereits wenige Sekunden zugange) - das Log aber noch nicht einmal den Beginn desselben mitbekommen hatte.

 

[ao]

Ja, wir sollten bald mal diesen viel zu langen Thread schließen und in Zukunft für jedes Teilproblem einen eigenen aufmachen.

Gute Idee! Vielleicht wäre es dann hilfreich, wenn alle neuen Threads mit "Callmonitor 1.x: ..." anfangen, sonst gehen die doch irgendwie unter. Noch besser wäre, wenn man den Callmonitor eine ganze Ebene hochschieben würde, also neben Freetz: Erstens ist Freetz neben Asterisk auf der FB bisher das einzige Unterforum bei den Fritz-Modifikationen und zweitens kann man den Callmonitor ja auch ohne Freetz als Standalone nutzen, oder?
Back on topic: Bei mir läuft der CM 1.11 (29.04.59-freetz-devel-2461) ohne Reboots meiner 7170.

 

[Izzy]

Bei mir läuft der CM 1.11 (29.04.59-freetz-devel-2461) ohne Reboots meiner 7170.

Schreib doch bitte mal dazu, welche anderen Mods Du mit drauf hast, und was Du ggf. vom Original-Kram entfernt hast. Im obigen Kontext: Dropbear hast Du m.W. drauf, gelle?

 

[ao]

Bin grad unterwegs, so dass ich alle Mods erst später auflisten kann, sorry.
Dropbear? Das war doch, um sich per ssh auf der Box anmelden zu können, richtig? Dann habe ich dropbear drauf, ja. Außerdem (aus der Erinnerung) noch checkmaild, syslogd, wol - also nicht viele Mods.

 

[Izzy]

Das würde meinen Verdacht bestätigen: Du hast also Dropbear drauf. Ich schau mal, dass ich mir ein neues Image aus dem aktuellen trunk bastele, und testweise Dropbear mit integriere.

 

[buehmann]

Aha. Und was passiert, wenn dropbear nicht installiert ist? Ich weiß, sollte eigentlich nix passieren.

Ja, sollte nicht, und aus folgendem Grund ist das als Fehlerursache sehr unwahrscheinlich: dropbear wird nur in der erwähnten droptoggle-Funktion angesprochen, die aber als Aktion nur aufgerufen wird, wenn ein Benutzer sie in die Listeners schreibt. Und selbst wenn jemand sie aufruft, der dropbear nicht installiert hat: Die Funktion überprüft am Anfang, ob dropbear da ist. (Und selbst wenn sie dies nicht täte, dürfte es höchstens ein paar Command-not-found-Meldungen im Log geben.)

Entnehme ich dem Smiley richtig, dass das erst kürzlich (also nach r2475) passiert ist?

Ja, die Revision mit dem Update auf 1.12.2 im Trunk ist entstanden, während ich die Antwort schrieb.

Wie ich schon schrieb, bricht "logread -f" via telnet bereits zusammen, bevor die relevanten Informationen den Weg über's Netz gefunden haben.

Eventuell ist ein direktes Loggen übers Netz erfolgsversprechender (weil möglicherweise weniger gepuffert wird): Dafür brauchst du einen Syslog-Dämon auf einem anderen Rechner und musst den syslogd auf der Fritzbox so konfigurieren, dass er die Lognachrichten weiterleitet.

Andreas