7050 hängt sich mind. täglich auf

m0e

Neuer User
Mitglied seit
30 Jun 2007
Beiträge
106
Punkte für Reaktionen
0
Punkte
0
Hallo,

Meine Fritz!Box 7050 mit 14.04.33ds26-15.2 hängt sich jede Nacht auf, und manchmal auch zwischendurch irgendwann (aber eher selten). Zuerst dachte ich es hängst mit der Nacht-WLanabschaltung zusammen, aber nach dem Deaktivieren derselben bleibt das Problem bestehen. Meine zweite Vermutung war, dass mein Laptop beim WLan-Abmelden irgendetwas verursacht, was die Box zum Hängen bringt, aber auch das kann ich vermutlich ausschliessen, ich teste seitdem jeden Abend 10 Minuten nachdem der letzte Rechner aus ist ob ich noch ein Freizeichen bekomme..
Das Aufhängen bedeutet bei mir, dass alles leuchtet als wäre es normal (Power, DSL, und die Info-Wlan-LED), aber die Box per NW nicht ansprechbar ist, und angeschlossene Telefone kein Freizeichen bekommen. Anrufe von draussen bekommen die Ansage "vorrübergehend nicht erreichbar".
Auf der Box läuft lediglich dropbear und callmonitor (1.10.2), Ram sollte also kein Problem sein. DS-Mod sagt mir aktuell 15608 von 30348 KB belegt, im TFFS sind 28 von 128 KB belegt. free auf der Box sagt 5132 frei.
Ich hab keine Ahnung was (vor allem nachts) das Aufhängen verursacht, cron o.ä. läuft nicht, also das einzige was die Box regelmässig nachts macht, ist die DSL-Verbindung zu trennen und wiederherzustellen. Beim Suchen hab ich nur syslogd als Verursacher gefunden, der aber bei mir nicht läuft. Was ich allerdingst nicht weiß, was ist das:
Code:
ps -w | grep log
  812 root       1432 S   logger -t callmonitor -p daemon.info
Wo (und warum) loggt der Callmonitor da hin, in /var/log/ gibts nichts ausser mod.log und mod_load.log..

Ansonsten fällt mir nichts mehr ein, wonach ich suchen könnte, laut den Signaturen hier betreiben ja einige ne 7050 mit Callmonitor und dropbear, also kanns ja eigentlich auch kein generelles Instabilitätsproblem sein.. Hat irgendjmd. ne Idee?

Meine DS-Mod Config:
Code:
egrep -v  "(^#|^$)"  .config
DS_HAVE_DOT_CONFIG=y
DS_AVM_VERSION_04_33=y
DS_TYPE_FON_WLAN_7050=y
DS_AVM_VERSION_STRING="04.33"
DS_TYPE_LANG_DE=y
DS_TYPE_LANG_STRING="de"
DS_TYPE_STRING="7050"
DS_INSTALL_BASE=y
DS_INSTALL_MODULE=y
DS_REPLACE_BUSYBOX=y
DS_TARGET_REF="4mb_26"
DS_KERNEL_REF="4mb_26"
DS_KERNEL_LAYOUT="ar7"
DS_HIDDEN_ROOT=y
DS_SQUASHFS_LZMA=y
DS_ROOTFS_VARTAR=y
DS_KERNEL_MTD_SIZE=59
DS_HAS_PHONE=y
DS_HAS_WLAN=y
DS_HAS_USB=y
DS_BRANDING_avm=y
DS_REMOVE_HELP=y
DS_REMOVE_ASSISTANT=y
DS_REMOVE_LIBTR069=y
DS_REMOVE_USB_MODULE=y
DS_PATCH_SIGNED=y
DS_PATCH_WEBSRV=y
DS_PATCH_UPNP=y
DS_LANG_DE=y
DS_LANG_STRING="de"
DS_PACKAGE_DROPBEAR=y
DS_PACKAGE_INADYN=y
DS_PACKAGE_VIRTUALIP_CGI=y
DS_PACKAGE_WOL_CGI=y
DS_DL_SITE="ftp://ftp.avm.de/fritz.box/fritzbox.fon_wlan_7050/firmware"
DS_DL_SOURCE="fritz.box_fon_wlan_7050.14.04.33.image"
DS_MOD_DL_NUM_SITES="5"
DS_MOD_DL_SITE_1="http://dsmod.3dfxatwork.de"
DS_MOD_DL_SITE_2="http://dsmod.wirsind.info"
DS_MOD_DL_SITE_3="http://dsmod.magenbrot.net"
DS_MOD_DL_SITE_4=""
DS_MOD_DL_SITE_5=""
DS_VERBOSITY_LEVEL=0
DS_FAVICON_DSL123=y
DS_FAVICON_STRING="dsl123"
DS_SQUASHFS_BLOCKSIZE_65536=y
DS_LIB_libgcc_s=y
DS_LIB_ld_uClibc=y
DS_LIB_libcrypt=y
DS_LIB_libdl=y
DS_LIB_libm=y
DS_LIB_libnsl=y
DS_LIB_libpthread=y
DS_LIB_libuClibc=y
DS_LIB_libutil=y
DS_DOWNLOAD_TOOLCHAIN=y
DS_TARGET_CROSS="mipsel-linux-uclibc-"
DS_TARGET_MAKE_PATH="toolchain/target/bin"
DS_TARGET_CFLAGS="-Os -W -Wall -pipe -march=mips32 -mips32 -Wa,--trap -msoft-float"
DS_JLEVEL=1
DS_KERNEL_CROSS="mipsel-unknown-linux-gnu-"
DS_KERNEL_MAKE_PATH="toolchain/kernel/bin"
DS_TARGET_GCC_VERSION="4.2.0"
DS_TARGET_UCLIBC_VERSION="0.9.28"
DS_TARGET_BINUTILS_VERSION="2.17.50.0.16"
DS_TARGET_UCLIBC_CONFIG_MOD_26=y
DS_TARGET_UCLIBC_REF="mod_26"
DS_KERNEL_GCC_VERSION="3.4.5"
DS_KERNEL_GLIBC_VERSION="2.3.6"

Gruss Maurice
 
@m0e: brute force Angriffe von aussen auf dropbear, die dropbear auf ca. 100% cpu-Last treiben, sind auch eine denkbare Ursache, wenn der dropbear port nach aussen freigegeben ist.

Geht ping auf die fritzbox noch (falls per WLAN nicht, probieren ob per LAN)? Wenn das auch nicht geht, dann läuft nicht einmal der linux kernel mehr richtig - oder es hat ein hardware Problem.

spblinux
 
Dropbear ist offen, das mit Bruteforce hab ich mir auch gerade gedacht und ausprobiert. Habe von einem externen Host einen Bruteforce mit 20 Threads und 100 Versuchen gestartet. Es gab nur max. 6 dropbear-Prozesse, der Ram ging laut free nicht unter 4000, das einzige was zu spüren war, war die CPU-Last. Das Webinterface der Box reagierte extrem träge.. Aber sie hats trotzdem überlebt.
Ping, DHCP o.ä. geht nicht (auch nicht per Kabel), die Box ist komplett tot .
Momentan hab ich gerade die DSL-Trennungszeit auf 12-13 Uhr verschoben und warte um zu testen obs daran liegt. Als nächstes werd ich eine Originalfirmware testen..

Gruss Maurice
 
Ich hab das gleiche Problem und glaube, dass es am Callmonitor liegt. Seit ich auf den verzichte (ist noch installiert, aber nicht gestartet), läuft die Box sehr stabil.
Vorher als Callmonitor noch lief hatte ich auch täglich Komplettabstürze (Box ist eingefroren, nur die LEDs leuchteten noch). Viel spannendes hat der Callmonitor dabei nicht gemacht, nur eine E-Mail-Benachrichtigung über entgangene Anrufe.
 
Hallo,
Wo (und warum) loggt der Callmonitor da hin
der Callmonitor loggt die erkannten Anrufereignisse (in:request etc.) mit den dazugehörigen Infos (Nummern, Namen, Zeiten, ...) ins Syslog. Wenn du keinen Syslogd gestartet hast, der die Nachrichten in eine Datei schreibt oder ins Netz schickt, sollten die Nachrichten einfach im Nirwana verschwinden.

Ich habe auch ab und an (immer nach der Nacht) eine eingefrorene Box, aber nicht täglich, sondern in unregelmäßigen größeren Abständen.

@Tarnkappe: Falls du noch irgendwelche genauere Hinweise darauf hast, dass der Callmonitor daran beteiligt ist oder in welcher Weise, wäre ich dankbar.

Viele Grüße,

Andreas
 
Heute hat meine Box zum ersten Mal die Nacht überlebt, ich hatte den Callmonitor deaktiviert. Das es mit Sicherheit daran liegt, kann man nun noch nicht sagen, aber es sieht momentan sehr danach aus..
Danke für den Tipp, ich werde das weiter testen/beobachten..

Gruss Maurice
 
@Tarnkappe: Falls du noch irgendwelche genauere Hinweise darauf hast, dass der Callmonitor daran beteiligt ist oder in welcher Weise, wäre ich dankbar.
Leider nein, ich wüsste auch nicht, was ich da noch weiter tun könnte. Es ist ja keine bestimmte Aktion, bei der die Box sich verabschiedet. Es passiert irgendwann einfach so.
Aber dass es mit dem Callmonitor zu tun hat, scheint ja auch der letzte Beitrag von m0e zu bestätigen.
Möglicherweise liegt es am parallel installierten Dropbear? Aber das kann man im Moment nur vermuten....
 
Hallo!

Ich habe es leider nie weiter verfolgt, da ich auch auf den Callmonitor verzichten kann. Aber die Probleme die Ihr beschreibt, waren bei mir genau so passiert und zwar meistens nach ca 11 h. Ich hatte auch den patch für dropbear eingespielt.
Erst nach dem deaktivieren des Callmonitors war sofort schluss mit den Aufhängern.

Ich habe dann aufgeben.

Gruß Henning
 
...
Ich habe auch ab und an (immer nach der Nacht) eine eingefrorene Box, aber nicht täglich, sondern in unregelmäßigen größeren Abständen.
...

Es scheint wirklich am Callmonitor zu liegen. Als workaround (wer den Callmonitor benötigt, so wie ich)

in der crontab ein Eintrag

1 * * * * /mod/etc/init.d/rc.callmonitor restart

Das startet den Callmonitor dann halt jede Stunde neu.
Seitdem läuft die Fritzbox jedoch durch :D

Ein Downgrade auf Kernel24 und altes dsmod (bei dem der Callmonitor sauber lief) ist keine Option, die WLAN Feldstärke ist beim 14.04.33 um Welten besser als beim 14.04.26

CYA
 
Hi,

interessant. Leider hilft es mir nicht dabei weiter, das Problem zu finden (oder erstmal zuverlässig zu reproduzieren). Könntest du mir bitte wenn möglich noch weitere Informationen liefern zu deiner Konfiguration? (Einstellungen des Callmonitors, wieviele Anrufe circa im Zeitraum bis zum Einfrieren der Box, was wird dabei ausgeführt (Listeners), kannst du vielleicht einen steigenden Speicherverbrauch des Callmonitors beobachten?)

Gruß,
Andreas
 
Hallo buehmann,

Also, Fritzbox 7050, dsmod 26
in der listeners stehen 4 dboxen, ein yac PC.
Im Moment sind die Boxen temporär nicht erreichbar, bis zum Upgrade auf 14.04.33 lief mindestens 1 Jahr lang 14.04.26 mit der gleichen Konfiguration. Ich hab die Konfigs wirklich nur kopiert.

in:request ^ ^ dboxpopup xxx.xxx.xxx.xxx
in:request ^ ^ dboxpopup xxx.xxx.xxx.xxx
in:request ^ ^ dboxpopup xxx.xxx.xxx.xxx
in:request ^ ^xxxxxxx dboxpopup xxx.xxx.xxx.xxx
in:request ^ ^ yac xxx.xxx.xxx.xxx

Ich werde mal versuchen, das Ganze irgendwie in regelmässigen Abständen protokollieren zu lassen.
 
Log

OK, ich mache jetzt folgendes:

per /sbin/mailer lasse ich mir die augabe von


free
total used free shared buffers
Mem: 30352 26840 3512 0 2788
Swap: 0 0 0
Total: 30352 26840 3512

ps | grep call
2463 root 1548 S /bin/ash /usr/sbin/callmonitor
2464 root 1432 S logger -t callmonitor -p daemon.info
2474 root 1548 S /bin/ash /usr/sbin/callmonitor
2476 root 1548 S /bin/ash /usr/sbin/callmonitor
2477 root 1548 S /bin/ash /usr/sbin/callmonitor
3082 root 1432 S /bin/sh -c /var/tmp/callmonit.sh
3083 root 1428 S /bin/sh /var/tmp/callmonit.sh

top | grep call
2463 root S 1548 1 0.0 5.0 callmonitor
2477 root S 1548 2463 0.0 5.0 callmonitor
2476 root S 1548 2463 0.0 5.0 callmonitor
2474 root S 1548 2463 0.0 5.0 callmonitor


Senden. Das im 15 Minuten Abstand. Jetzt verändere ich den Abstand, in dem ich den callmonitor neustarte solange, bis es wieder hängenbleibt. Wir werden der Sache hoffentlich näher kommen :)
 
Ich habe die gleiche Fritzbox mit dem gleichen Problem. Allerdings ohne Dropbear. Dropbear scheint demzufolge nicht der Verursacher zu sein. Bei mir hängt sich die Box irgendwann in der Nacht auf.
 
Bei mir habe ich das gleiche Problem gehabt - besonders heftig wurde es, nachdem ich das interne Telefonbuch der Fritz (mit der Fritz!Monitor-Software) gefüllt habe. Mindestens alle 12 Stunden (mal nachts, mal tagsüber, nach mehr oder weniger viele eingehenden Anrufen) ist die Box komplett stehengeblieben.

Jetzt habe ich den callmonitor ausgestellt und zumindest hat die Box jetzt wieder deutlich mehr Stabilität.

Viele Grüße,
Markus.
 
Da kommen wir der Sache schon mal näher.
@msdv: Kannst du bitte etwas mehr zu deiner Konfiguration sagen. Ideal wäre, wenn du deine .config zu der Firmware posten würdest, die abstürzt. "Stehengeblieben" heißt eingefroren? Womöglich mit leuchtenden LEDs? Stimmts? Das ist das typische Verhalten von 7050 in solchen Fällen.
@all: Das Abschalten von callmonitor bringt uns nicht viel weiter. Ich weiß natürlich, dass jeder von euch zuhause mindestens eine Hexe hat, die es nicht leiden kann, dass ihr Fernquatsch-Gerät nichts tut. Das spiegelt sich auf dem Familienklima. Aber zumindest bei denen, wo es noch halbwegs geht, bitte, bitte weiter forschen, nicht aufhören. Wir suchen nach einer Kombination der Umstände, die eine 7050 sicher und reproduzierbar zum Absturz bringt. Der Hinweis mit dem Telefonbuch war schon gut, Andreas braucht aber sicherlich noch mehr Anhaltspunkte.

Mir ist z.B. Paar Mal aufgefallen, dass die Box abstürzt, wenn (oder nachdem) ein zweites Telefonat kommt, wenn man gerade ein Telefongespräch führt.

Es wäre vll. auch interessant, welche und wieviele Aktionen callmonitor ausführt (Listeners). Bei mir sind es nur YAC und AYAC - Aufrufe.

MfG
 
Hallo zusammen,

das Verhalten ist richtig beschrieben - bei der Box leuchten die normalen LEDs.
Meine .config habe ich angehängt.

In der callmonitor-Konfiguration hatte ich nur:

in:cancel ^ ^ mailmessage -s "Verpasster Anruf ($SOURCE) ($SOURCE_NAME)"
in:request ^ ^ mailmessage -s "Eingegangener Anruf ($SOURCE) ($SOURCE_NAME)"

Viele Grüße,
Markus
 

Anhänge

  • config.txt
    8.3 KB · Aufrufe: 4
Wir suchen nach einer Kombination der Umstände, die eine 7050 sicher und reproduzierbar zum Absturz bringt. Der Hinweis mit dem Telefonbuch war schon gut, Andreas braucht aber sicherlich noch mehr Anhaltspunkte.
Richtig, momentan stochern wir hier ja ziemlich im Nebel. Zum Telefonbuch: Der Callmonitor kopiert das Telefonbuch in eine Textdatei (in /var, als ins RAM), um es nicht bei jedem Anruf aufwendig aus dem Webinterface auslesen zu müssen. Bei größerem Telefonbuch steigt also der Speicherbedarf ein wenig; vielleicht kommt es dann schneller zu einem Speichermangel (?). Ich hoffe, hannebambel bekommt mit seinen Logs in dieser Richtung noch etwas heraus.

Was mich schon seit längerem stutzig werden lässt, ist, dass es immer wieder und häufig heißt, die Box sei "nachts" stehengeblieben. Was macht denn die Box besonderes in der Nacht? (Irgendwelche regelmäßigen Dinge wie der Push-Service zum Beispiel. Gibt es da noch etwas anderes?) Ich gehe mal davon aus, dass bei uns allen Anrufe, bei denen der Callmonitor aktiv wird, im größerem Umfang eher tagsüber stattfinden.

Grüße,

Andreas
 
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.