Callmonitor 1.*

Status
Für weitere Antworten geschlossen.
Könnte man alternativ den syslogd-Puffer verringern und den Output-Pfad auf einen Netzwerkshare ändern?
 
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?
Nein, Standalone-Betrieb wird von mir nicht unterstützt. Von daher wäre ein Callmonitor-Forum unterhalb von Freetz angebrachter (falls das nicht schon zu tief geschachtelt ist).

Andreas
 
Könnte man alternativ den syslogd-Puffer verringern und den Output-Pfad auf einen Netzwerkshare ändern?
Ich vermute, dass das auch nicht so effektiv sein wird: Bei dieser Lösung verlierst du bei einem Absturz den Teil des Syslogs, der noch im Dateisystem-Puffer ist.

Andreas
 
...Und selbst wenn sie dies nicht täte, dürfte es höchstens ein paar Command-not-found-Meldungen im Log geben.

So hätte ich das auch gesehen - daher habe ich auch geschrieben "ins Blaue". Dass es sehr unwahrscheinlich ist, ist mir klar - aber Du weißt ja, was Pferde vor der Apotheke machen, wenn sie kein Gras fressen...

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

Dann mach ich mir gleich mal ein neues Image, und tausche ein paar Elemente aus: Privoxy + Tor fliegen raus (nutze ich derzeit eh nicht), stattdessen kommt Dropbear rein (benutze ich zwar auch nicht - schaded aber auch nicht).

Eventuell ist ein direktes Loggen übers Netz erfolgsversprechender (weil möglicherweise weniger gepuffert wird)

Wäre ein Gedanke. Ich hatte im ersten Schritt eher gedacht, einen USB-Stick einzuschieben. Für andere Dinge (Swap, DTMFBox Audio-Files) ist das eh sinnvoll. Dann kann das Syslog auch dort abgelegt werden - und wir schauen mal...

Könnte man alternativ den syslogd-Puffer verringern und den Output-Pfad auf einen Netzwerkshare ändern?
Ich vermute, dass das auch nicht so effektiv sein wird: Bei dieser Lösung verlierst du bei einem Absturz den Teil des Syslogs, der noch im Dateisystem-Puffer ist.

Wobei das dann hier wohl auch zutreffen dürfte? Sollte eigentlich nicht - hängt aber davon ab, was den Reboot letztendlich auslöst. Wenn es der WatchDog ist, sollte er die (lokalen) Filesysteme zumindest sauber schließen - sodass das mit dem Stick klappen sollte. Aber wer weiß, wo die Pferde noch überall rumhängen...
 
So hätte ich das auch gesehen - daher habe ich auch geschrieben "ins Blaue". Dass es sehr unwahrscheinlich ist, ist mir klar - aber Du weißt ja, was Pferde vor der Apotheke machen, wenn sie kein Gras fressen...
Schon klar; mit den Erwartungen und Aussagen wie "kann gar nicht sein" ist das immer so eine Sache. Falls wir durch Experimente ausschließen können, dass dropbear irgendetwas mit der Problematik zu tun hat, umso besser.

Andreas
 
@wengi: Version 1.12.2 ist doch längst in freetz-trunk. (Danke.)
Bei welcher Revision? Ich habe gerade zu 2491 aktualisiert - "make menuconfig" meint nach wie vor: "CallMonitor v1.11". Oder ist das nur im Menü nicht aktualisiert?

Edit: Hier mal was in der .packages steht:
Code:
syslogd-cgi-0.2.3
downloader-0.2
callmonitor-1.11
avm-firewall-2.0.3c
dnsmasq-2.45
dtmfbox-0.5.0
privoxy-3.0.8
tor-0.1.2.19
fstyp-0.1
haserl-0.9.24
modcgi-0.2
 
Zuletzt bearbeitet:
Neues Image gerade gebacken - das Summary bestätigt: callmonitor-1.12.2 -- Also kein Grund zur Panik ;)

Habe mir jetzt also auch Dropbear mit installiert. Werde am Wochenende das Image mal einspielen und ein bisserl testen. Ergebnisse sollten dann am Montag vorliegen - zumindest "vorläufige Hochrechnungen" a la "Uptime, 24h, sonnig - das Image hält" (oh shit Werbung - ich meinte natürlich: "Anzahl Reboots noch auf 0" :silly:)
 
Da sieht man mal, wie alt wir geworden sind! Ich weiß nicht mal mehr, wann ich die zum letzten Mal gesehen habe. Mag aber auch daran liegen, dass man Dank moderner Technik die Werbung ganz gut "überspringen" kann ;)
 
Hallo,

ich habe auch ein paar Beobachtungen zu den Abstürzen gemacht.

Bei mir stellte es sich so dar, das die Box nicht unbedingt rebootet , meistens kam es einfach dazu, dass der dsld abstürzte, was aber kein Stück besser ist als ein Total-Reboot, wenn man eine VOIP-Flat hat.

Ich tat Folgendes:
- Update von stabiler dsmod-Firmware mit 2.4er Kernel (29.04.15) mit Freetz 1.0 (29.04.57-freetz-1.0)
- Danach begannen sofort die dsld-Probleme, offenbar immer, wenn die Box genutzt wurd, allerdings nicht zwingend während der Nutzung. Was heißt das? Ich hatte irgendwann resigniert und die Box nachts durchstarten lassen. Damit lief sie dann bis zum Abend so ziemlich ungenutzt vor sich hin, meist stabil, d.h. ohne dsld-Abstürze. Nach ein paar Anrufen begann dann der dsld immer wieder (während Telefonate geführt worden sind oder auch nicht) abzustürzen.
- Ich konfigurierte den syslogd, der ständig auf meinen kleinen Server logte, allerdings kam hierbei nix raus, der Output ist immer nur so, z.B.:

Code:
2008-07-19 19:37:24    User.Error    <hochgeheime lokale IP ;)>    Jul 19 19:37:19 dsld[3456]: VPN led value = 0
- dann recoverte ich die Box auf eine original Firmware - lief stabil
- ich spielte wieder das freetz-Image ein, schaltete jedoch dtmfbox und callmonitor ab - lief stabil
- ich schaltete dtmfbox ein - lief stabil für 24h
- ich schaltete den Callmonitor ohne listener und ohne Suche im Telefonbuch oder bei den Online-Anbietern ein - lief stabil für 24h
- ich nahm meine Listener in Betrieb - lief stabil für 24h
- ich schaltete die Nutzung des Fritz-Box-Telefonbuchs und der ONline-Abfragen zu - Problem trat wieder auf
- ich schaltete beides wieder ab - es blieb dabei
- ich recoverte wieder und betreibe den Callmonitor nun seit 2 Tagen mit meinen Listeners und meinen Callers, aber ohne Fritz-Box-Telefonbuch und ohne Rückwärtssuche - läuft stabil

Es scheint also zumindest in meinem Fall so zu sein, dass der Callmonitor immer dann irgendwelche Überlastungen hervorruft, sobald die beiden genannten Optionen auch nur einmal aktiviert waren.

Können alle anderen, die diese Probleme haben vielleicht bestätigen, dass sie die beiden Optionen zumindest mal zugeschaltet hatten?

Vielleicht hat buehmann eine Idee, wo sich hier etwas fest im System verankern könnte?

Viel Erfolg!

Miwu
 
Zuletzt bearbeitet:
Hallo Miwu,

danke für deine Beobachtungen; das sind bisher mit Abstand die nützlichsten.

Ich hatte auch gerade einen Verdacht. Aber bei der genaueren Analyse bin ich auf ein paar Widersprüche zu dieser Hypothese gestoßen.

Der Verdacht hätte vorausgesetzt, dass du in deinen Listenern keinen der Befehle "mail", "config" und "dial" benutzt (oder diese Befehle in deinem Testzeitraum zumindest nicht ausgeführt wurden). Außerdem hättest du höchstens die Version 1.11 benutzen dürfen. Passt das soweit schon einmal?

Was mich stutzig gemacht hat, waren die Aussagen "der dsld stürzt ab" und "eine Aktivierung der Funktionen reicht, um dauerhaft zu Instabilitäten zu führen". Da der dsld und der Callmonitor keine Berührungspunkte haben außer den Konfigurationsdateien in /var/flash/ und diese auch persistent sind, schien mir das der Knackpunkt zu sein, genauer die ar7.cfg.

Um die E-Mail-Konfiguration oder das Passwort für die Weboberfläche aus der ar7.cfg in entschlüsselter Form auszulesen, benutzt der Callmonitor den Befehl "allcfgconv -C ar7 -O -". Bedarf für dieses Auslesen besteht in folgenden Fällen:
  • mail
  • config
  • dial
  • phonebook, falls das AVM-Telefonbuch gelesen wird
  • phonebook immer
Wäre ich auf den letzten Punkt nicht gestoßen, hätte alles gepasst. Der Verdacht wäre dann gewesen, dass der Aufruf von "allcfgconv -C ar7 -O -" irgendwelche Änderungen an der ar7.cfg durchführt, die den dsld instabiler werden lassen. (allcfgconv ist nach eigener Aussage für "convert configuration" zuständig, schien aber bisher bei mehrfachen Aufrufen (ein Aufruf wird wohl bei Firmware-Updates von AVM gemacht) keine negativen Auswirkungen zu haben; allein der nette Seiteneffekt, dass man damit die Passwörter entschlüsseln kann, war der Grund, dass ich es benutzt habe.)

Aber vielleicht könntest du das trotzdem einmal durchspielen, um diese Ursache ggf. ausschließen zu können: Recover, Freetz-Image aufspielen, Box einrichten, Zustand von ar7.cfg sichern, "cfg2sh ar7 webui" aufrufen, ar7.cfg mit dem vorherigen Zustand vergleichen.

Viele Grüße und nochmals vielen Dank,

Andreas
 
Hallo Andreas,

dass du in deinen Listenern keinen der Befehle "mail", "config" und "dial" benutzt
Ich benutze diese Befehle (alle) nicht nur in meinen Listeners, auch in ein paar anderen Scripts, die auf meiner Box laufen habe ich sie verarbeitet. In der stabilen Phase haben die beiden ersten definitiv funktioniert (nutze config, um mir bei einem bestimmten Anruf eine Freigabe für ein paar Minuten freischalten zu lassen und lasse mich darüber per mailmessage informieren), bei dial bin ich mir nicht sicher, ob ich das auskommentiert hatte, ich spiele ja parallel mit dtmfbox)

Außerdem hättest du höchstens die Version 1.11 benutzen dürfen.
Habe ich (die Version, die im Fretz 1.0 drin ist), ich hatte einige Stunden nach dem Erscheinen der 1.12 mal diese ausprobiert, allerdings führte das zum kompletten Ausfall der Box, allerdings lief sie auch schon vorher nicht sauber.

Was mich stutzig gemacht hat, waren die Aussagen "der dsld stürzt ab"
Ja, das war tatsächlich so, ich habe mal irgendwo anders gelesen, dass bei der Fritz-Box bei gewissen Überlastungsszenarien offenbar entweder immer der dsld über die Wupper geht oder sich die Box komplett rebootet (das hatte ich auch ab und zu mal, aber nur so aller 3 Tage bis ich halt per cron jede Bacht rebootet habe). Anfangs dachte ich, dass da von meinem doch recht großen Versionssprung von meiner ursprünglichen Firmware auf die neue kommt, allerdings trat das Phänomen auch nach einem kompletten recover auf, womit ich das nun auch ausschließen kann.

Aber vielleicht könntest du das trotzdem einmal durchspielen, um diese Ursache ggf. ausschließen zu können: Recover, Freetz-Image aufspielen, Box einrichten, Zustand von ar7.cfg sichern, "cfg2sh ar7 webui" aufrufen, ar7.cfg mit dem vorherigen Zustand vergleichen.
Gerne mache ich das, allerdings muß ich Dich dafür bis Anfang Oktober vertrösten (morgen gehts in den Urlaub und ich brauche da meine Box unbedingt funktionierend wegen Callback, deswegen möchte ich vorher nicht mehr experimentieren). Heute habe ich auch noch eine 7270 geliefert bekommen, war ja bei 1&1 neulich schön billig, dann kann ich mal tagsüber rumspielen und falls es längere Ausfälle gibt kann ich immernoch auf die neue Box failovern ;)

Ich könnte Dir im Moment höchstens mit Infos zu meiner aktuellen Box aushelfen. Sorry, das ich da etwas feige bin.

Vielen Dank für Deine super Arbeit (und natürlich immernoch besonders für roku.sh)

Miwu
 
Nachtrag: Irgendwas scheint aber zu passieren, wenn ich Dein Kommando aufrufe. Ich tat in meinem Leichtsinn:

allcfgconv -C ar7 -O -

Es kam keinerlei Ergebnis, ich brach nach ein paar Minuten ab mit Ctrl+C

dann aber:

var/flash # ls -la ar7.cfg
crw-r--r-- 1 root root 240, 113 Sep 5 19:23 ar7.cfg

Es scheint also irgendeine Änderung zu geben, der Zeitpunkt meines Kommandos stimmt mit der angegebenen Zeit überein....
 
Sorry, war ein Tippfehler: Es muss "-o -" heißen (klein-Oh), und ein "-c" fehlt auch noch, um genau den Aufruf zu reproduzieren, den der Callmonitor macht. Deswegen hatte ich dich auf "cfg2sh ar7" verwiesen; dort weiß ich, dass der richtige Aufruf drinsteckt. :)

Und hab einen schönen Urlaub!

Andreas
 
Danke, hatte ich nicht so wahrgenommen, ich habe mir den Aufruf mal aus der cfg2shkopiert und ausgeführt, nun bekomme ich die ar7.cfg, nur das meine ganzen Passwörter lesbar sind. Das Änderungsdatum der Datei hat sich bei meinem Zugriff wieder geändert (es ist aber nicht das Datum in der Kopfzeile...).

Vielen Dank für die guten Wünsche, bis morgen muß ich nich durchhalten :p

Viele Grüße

Miwu
 
"dsld stürzt ab..." => Das hat aber nicht unbedingt mit CallMonitor zu tun. Dieses Problem hatte ich bereits mit der offiziellen Firmware - allerdings nur so 1-2 Mal im Monat maximal. Telefon ging noch, LAN ging noch - nach draußen tot, und auf die Fritte kam ich auch nicht mehr...

So: Und wie aus meiner Signatur zu sehen, habe ich vor wenigen Stunden ein neues Image eingespielt (wie angekündigt) - ohne Privox/Tor, dafür mit Dropbear und DECO (Tor/Privoxy mussten raus, sonst hätte der Platz im Image nicht gereicht). Jetzt warte ich neugierig, was passiert: Sowohl CallMonitor als auch DTMFBox sind gestartet - auch wenn bei letzterem noch nix konfiguriert ist (da muss ich mich erst noch einlesen, da ich beides zuvor noch nicht genutzt hatte)...

Andreas: Wenn ich die Listeners bearbeiten will, bekomme ich die "DAU" Fehlermeldung (darf ich nicht). Ich weiß, ich müsste da irgendwo eine "0" per "echo" hinbefördern... Aber ließe sich das nicht ähnlich umgehen wie bei den Callers? Also dass CallMonitor statt einem Link ins "Einstellungen" Menü das selbst ausliest, zum Bearbeiten anbietet, und dann wieder zurück schreibt? Für weniger versierte Anwender ist es sicher besser, wenn nicht alles "freigeschaltet" wird (was mit der "0" ja der Fall wäre).
 
Bei den Callers wird nichts umgangen; die Callers sind einfach schon auf einer anderen Sicherheitsstufe bearbeitbar. Das ganze folgt den Vorgaben aus Freetz.

Der Unterschied zwischen beiden Dateien ist der, dass man mit den Callers auch als Angreifer nichts Gefährliches machen kann, mit den Listeners dagegen beliebigen Code ausführen kann.

Andreas
 
Dann wäre es doch sicher eleganter, vor dem Speichern ein Passwort abzufragen (was nach dem Speichern natürlich wieder zurückgesetzt wird) - anstatt die Sicherheitsstufe für die ganze Box zu ändern (was zurückzusetzen man sicher nicht selten "vergisst")? Ersteres (Passwort) wäre an eine Aktion (Speichern) gebunden - letzteres gälte systemweit (was es ja so gefährlich macht).

BTW: Was müsste ich denn in die Callers eintragen, damit statt "unbekannt" z.B. "WolleRoseKaufen" angezeigt wird? "unbekannt" anstelle der/als Rufnummer?
 
Wie oft änderst du was an deinen Einstellungen? Ich hab die seit Monaten nciht angerührt, und das als dochrecht aktiver Mensch auf der Box.
 
Status
Für weitere Antworten geschlossen.
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.