Erstellt vor 3 Jahren

Geschlossen vor 2 Jahren

Zuletzt geändert vor 2 Jahren

#2499 closed defect (fixed)

7490: Reboot bei Anrufbeantworter/Telefoniegeräte

Erstellt von: kroki0815 Verantwortlicher:
Priorität: high Meilenstein: freetz-next
Komponente: unknown Version: devel
Stichworte: Beobachter:
Product Id: 7490 Firmware Version: 06.10-28311 / 06.20

Beschreibung

Hi,
wenn man in der WebGui auf Telefonie→ANrufbeantworter oder Telefonie→Telefoniegeräte klickt, dann ist die WebGui nicht mehr erreichbar und die Box startet nach ein paar Minuten neu. In der Origonal-Release tritt der Fehler nicht auf.

Letzte Meldung im dmesg:
[ 181.750000] AVM_WATCHDOG_ungraceful_release: handle 3 (ctlmgr) still registered!

Gruß Kroki

Anhänge (26)

.config (64.2 KB) - hinzugefügt von kroki0815 vor 3 Jahren.
.config
.config.2 (63.9 KB) - hinzugefügt von kroki0815 vor 3 Jahren.
.config für die Release 113.06.05
config(cas1711) (59.3 KB) - hinzugefügt von Cas1711 vor 3 Jahren.
config-cschuette.txt (62.8 KB) - hinzugefügt von CarstenSchuette vor 3 Jahren.
.config_Black.txt (59.9 KB) - hinzugefügt von blackstar vor 3 Jahren.
FB7390 Reboot Telefon
AbsturzTel(1).txt (51.7 KB) - hinzugefügt von blackstar vor 3 Jahren.
FB7390 Reboot Telefon
unhide_keep_avm_uclibc.diff (615 Byte) - hinzugefügt von er13 vor 3 Jahren.
config-20140816.txt (61.4 KB) - hinzugefügt von CarstenSchuette vor 3 Jahren.
CarstenSchuette config, keine ISDN-/Fax-Funktion
avm.uclibc.config.vr9-vs-freetz.uclibc.config.vr9.diff (4.9 KB) - hinzugefügt von er13 vor 3 Jahren.
avm.uclibc.config.vr9.from.labor7490sources vs freetz.uclibc.config.vr9
bug2499-possible-fix.diff (2.9 KB) - hinzugefügt von er13 vor 3 Jahren.
6.05-6.20.var_flash.diff (22.0 KB) - hinzugefügt von er13 vor 3 Jahren.
freetzmount_uppercase_mountpoints.patch (2.5 KB) - hinzugefügt von er13 vor 3 Jahren.
freetzmount_capitalized_mountpoints.v2.patch (2.9 KB) - hinzugefügt von er13 vor 3 Jahren.
der etwas bessere Workaround, macht nur den ersten Buchstaben groß, behandelt sowohl "mount per Label" als auch "mount per CustomPrefix"
freetzmount_change_default_back_to_fixed_prefix.patch (1.8 KB) - hinzugefügt von er13 vor 3 Jahren.
crashlogs.txt (7.2 KB) - hinzugefügt von JMC vor 3 Jahren.
ein paar Crashlogs
libmodmount.sh.diff (3.1 KB) - hinzugefügt von PeterPawn vor 3 Jahren.
diff for libmodmount.sh to act on AVM changes within udev-mount-sd
.config.3 (60.5 KB) - hinzugefügt von udo vor 3 Jahren.
config.txt (62.5 KB) - hinzugefügt von JMC vor 3 Jahren.
aktuelle .config Testbox
7390.06.20-do_umount_locked.diff (1.9 KB) - hinzugefügt von er13 vor 3 Jahren.
ein klassisches Beispiel fürs Auseinanderlaufen eines Code-Clones ;-)
lua_query_values.tar.gz (842 Byte) - hinzugefügt von PeterPawn vor 3 Jahren.
tar-File enthält keine Verzeichnisse !
.config.4 (59.3 KB) - hinzugefügt von HarryT vor 3 Jahren.
.config on Mint default settings for 7490
config.2.txt (61.5 KB) - hinzugefügt von blackstar vor 2 Jahren.
7390 ohne FREETZMOUNT ohne OpenWRT Patch Absturz bei genutzem Onlinespeicher
config_work.txt (62.5 KB) - hinzugefügt von blackstar vor 2 Jahren.
Funktioniert (?)
.config_work_12829 (16.6 KB) - hinzugefügt von KingTutt vor 2 Jahren.
.config_not_working (58.8 KB) - hinzugefügt von jampr vor 2 Jahren.
Absturz bei Klick auf Telefoniegeräte
Bildschirmfoto von »2015-02-08 13:36:02«.png (64.9 KB) - hinzugefügt von wl_michael vor 2 Jahren.
Freetz-Info

Alle Anhänge herunterladen als: .zip

Änderungshistorie (400)

Geändert vor 3 Jahren durch kroki0815

.config

comment:1 Antwort: Geändert vor 3 Jahren durch kroki0815

Ich nochmal ….

Es sind eigentlich alle Menüpunkte unterhalb Telefonie, bis auf das Telefonbuch.

Und immer nur diese Meldung:
[ 195.720000] AVM_WATCHDOG_ungraceful_release: handle 3 (ctlmgr) still registered!

Box ist per ssh noch ca. 3 Minuten erreichbar, dann startet sie neu.

Soweit ich bis jetzt sehen kann funktioniert die Box aber ansonsten ohne Probleme.

Gruß Kroki

Zuletzt geändert vor 3 Jahren von kroki0815 (vorher) (Diff)

comment:2 Geändert vor 3 Jahren durch JMC

Das Problem habe ich auch - der einzige Weg der bei mir funktioniert: Recover machen und Image aufspielen, Sicherungen einspielen (AVM und Freetz Sicherung), DECTs neu anmelden und funktioniert. Bis zum nächsten Upgrade habe ich festgestellt. Lässt sich aber leider mit meiner zweiten 7490 die ich als Testbox hab nicht nachstellen. Die funktioniert und funktioniert - hat allerdings die SIPs nicht registriert

comment:3 Geändert vor 3 Jahren durch kroki0815

Das ist dann aber ziemlich umständlich, hab 6 DECT Telfone dran und noch 6 Dect200 Steckdosen … das artet dann ja in Arbeit aus :-).
Nach Downgrade auf die 113.06.05 läuft alles wieder ohne Probs.

Hab übrigens nur SIP-Accounts und drei AB's konfiguriert, kein Festnetz.

comment:4 Geändert vor 3 Jahren durch make

Der Vollständigkeit halber: Ich kann das Problem mit der gleichen FW-Version auf einer 7390 nicht nachzustellen. Schon mal mit den verschiedenen aktivierten Remove-Patches ausprobiert, welcher der Auslöser sein könnte?

comment:5 Geändert vor 3 Jahren durch JMC

Ich hab bei meiner 7490 garkeine removes an. Das alleine kanns nicht sein leider

Edit:
Ich habe das Problem nur nach einem upgrade. Das Labor Image von gestern läuft nach recover auch bei mir ohne Probleme.

Zuletzt geändert vor 3 Jahren von JMC (vorher) (Diff)

comment:6 Geändert vor 3 Jahren durch CarstenSchuette

Ebenfalls der Vollständigkeit halber: Bei mir funktionieren alle Menüpunkte des WebIF einwandfrei, 7490, Labor von gestern.

Zuletzt geändert vor 3 Jahren von CarstenSchuette (vorher) (Diff)

comment:7 Geändert vor 3 Jahren durch kroki0815

Also ich hab auch nochmal bischen probiert:

Release 7490_06.05-freetz-devel-11941: Alles OK

Release 7490_06.05-freetz-devel-12217: Die Übersicht wird nicht angezeigt. Telefonniegeräte, Schurlostelefone, Eigenen Rufnummern unvollständig, bzw. wird nur der Kopf angezeigt, aber keine Geräte.

Keine Änderung der Konfig … Es muss sich also im Freetz irgendwas geändert haben, was auf die GUI Auswirkungen hat.

Zuletzt geändert vor 3 Jahren von kroki0815 (vorher) (Diff)

comment:8 Geändert vor 3 Jahren durch CarstenSchuette

Ich würde eher vermuten, dass einer der Freetz-Patches das WebIF kaputtschreibt. Oder deine Config irgendwas austauscht, was das WebIF nicht mag.

Zuletzt geändert vor 3 Jahren von CarstenSchuette (vorher) (Diff)

Geändert vor 3 Jahren durch kroki0815

.config für die Release 113.06.05

comment:9 Geändert vor 3 Jahren durch ns123

Ich hatte ein ähnliches Problem: #2480
Bei mir war das Problem gelöst nachdem ich das Recovery-Image wiederhergestellt hatte.

comment:10 Geändert vor 3 Jahren durch Cas1711

Ich habe das Problem auch. Nach einem Recover habe ich meine Tel. Nummern und die Geräte wieder eingetragen, danach wurden „Telefoniegeräte“ und „Eigene Rufnummern“ korrekt angezeigt.
Nach Neustart der 7490 ist das Problem jedoch wieder da, sobald ich unter „Telefonie“ die Punkte
„Telefoniegeräte“ oder „Eigene Rufnummern“ aufrufe ist die 7490 nicht mehr erreichbar und bootet nach ein paar Minuten.
Eventuell hängt es von den Geräten ab, ich habe ISDN, Dect, VoiP, FritzFon (Android), Fax sowie AB eingetragen.

comment:11 Geändert vor 3 Jahren durch kroki0815

Ich habe inzwischen auf das Original-Beta-Image gewechselt. Hier gibts es jetzt keinerlei Probleme mehr. Läuft insgesamt wesentlich stabiler. Alle zusätzlichen Softwarepakete habe ich auf einen Raspberry PI ausgelagert. Bin jetzt rundum glücklich. :-)

Gruß
Kroki

comment:12 Geändert vor 3 Jahren durch Cas1711

Auf das Beta-Image ohne Freetz kann ich nicht wechseln, ich brauche die debug.cfg um meinen FHEM Homeserver starten zu können und das hat AVM ja nun verhindert.
Ansonsten läuft die Beta ohne Freetz problemlos, irgendwas geht also bei Freetz schief.

comment:13 Geändert vor 3 Jahren durch Whoopie

Warum kannst Du nicht die rc.custom statt der debug.cfg nehmen?

comment:14 Geändert vor 3 Jahren durch er13

@alle, die das Problem haben: könntet Ihr bitte alle Remove-Patches abwählen und schauen, ob das Problem weiterhin besteht. In jedem Fall bitte jeder, bei dem das Problem besteht, seine .config anhängen (zwecks Gemeinsamkeiten suchen, etc.).

@Whoopie: weil es ohne freetz es keine rc.custom gibt ;-)

comment:15 Antwort: Geändert vor 3 Jahren durch JMC

Ich häng meine später mal an wenn ich ran komme. Aber ich habe bei mir keinen einzigen Remove-Patch an. Bei mir tritt das hier beschriebene Problem auch nur in folgender Konstellation auf:

  • Image geflasht, Box rebootet teilweise von alleine, spätestens beim aufrufen der Telefonie Einstellungen
  • Recover, AVM Einstellungen zurückgespielt, Freetz-Image geflasht, Freetz Einstellungen zurückgespielt → alles ok
  • Flash eines aktuelleren Freetz Image (auf Basis einer neueren Labor Version) → fängt von vorne an.

Geändert vor 3 Jahren durch Cas1711

comment:16 Geändert vor 3 Jahren durch Cas1711

meine Konfig config(cas1711) hängt an.
Auch nach Recover und Einspielen des Freetz Labor Images kann ich nicht mehr auf die Telefonnummern und Geräte zugreifen, die 7490 ist dann nicht mehr erreichbar und bootet nach ein paar Minuten von selbst.

comment:17 Geändert vor 3 Jahren durch Cas1711

Auch mit Revision 12275 und der aktuellen Labor 113.06.10-28463 funktioniert das GUI für die Telefon Funktionen nicht, die 7490 stürzt ab sobald man zugreift.
Ansonsten scheint alles zu laufen.
Noch irgendwelche Vorschläge zur Fehlereingrenzung ??

comment:18 Geändert vor 3 Jahren durch CarstenSchuette

Hui, ich hatte das Problem eben auch. Im syslog steht zu dem Crash:

Jul 26 11:32:45 fritz user.err ctlmgr[1663]: /var/flash/crash.log opened
Jul 26 11:32:45 fritz user.err ctlmgr[1663]: 2014-07-26 11:32:45(1) [Segmentation fault] /usr/bin/avm/ctlmgr(1663) CRASHED at strcmp+0xc (/lib/libc.so.0 at 00038a0c) accessing 0+0x7553746e (/lib/libhtmltemplate.so.0 at 49caf46e)
Jul 26 11:32:45 fritz user.err ctlmgr[1663]: SIGNO 11 ERRNO 0 CODE 1
Jul 26 11:32:45 fritz user.err ctlmgr[1663]: Version: 06.10-28463
Jul 26 11:32:45 fritz user.err ctlmgr[1663]: Watchdog triggered 8 seconds ago
Jul 26 11:32:45 fritz user.err ctlmgr[1663]: No bugmsg
Jul 26 11:32:45 fritz user.err ctlmgr[1663]: ze: 00000000 at: 00000001 v0: 2ae5da00 v1: 0000004f
Jul 26 11:32:45 fritz user.err ctlmgr[1663]: a0: 7fc72497 a1: 7553746f a2: 75537470 a3: 7fc72498
Jul 26 11:32:45 fritz user.err ctlmgr[1663]: t0: 00000000 t1: 53d375bd t2: 8071bae0 t3: 00000001
Jul 26 11:32:45 fritz user.err ctlmgr[1663]: t4: 80000000 t5: 00000073 t6: 0000005b t7: 323d2f64
Jul 26 11:32:45 fritz user.err ctlmgr[1663]: s0: 2b311be0 s1: 2b98fbb8 s2: 004b0000 s3: 2b58c618
Jul 26 11:32:45 fritz user.err ctlmgr[1663]: s4: 00000000 s5: 00000000 s6: 00000001 s7: 2b59ed30
Jul 26 11:32:45 fritz user.err ctlmgr[1663]: t8: 00000000 t9: 2ae5da00 k0: 00000001 k1: 00000000
Jul 26 11:32:45 fritz user.err ctlmgr[1663]: gp: 2b311be0 sp: 7fc72390 fp: 004d0000 ra: 2b2f5cb9
Jul 26 11:32:45 fritz user.err ctlmgr[1663]: FA 7553746e 0+0x7553746e (/lib/libhtmltemplate.so.0 at 49caf46e)
Jul 26 11:32:45 fritz user.err ctlmgr[1663]: PC 2ae5da0c strcmp+0xc (/lib/libc.so.0 at 00038a0c)
Jul 26 11:32:45 fritz user.err ctlmgr[1663]: RA 2b2f5cb8 0+0x2b2f5cb8 (/usr/share/ctlmgr/libtamconf.so at 00002cb8)
Jul 26 11:32:45 fritz user.err ctlmgr[1663]: Code: 90830000  24870001  24a60001 <14600003> 90a20000  03e00008  00021023  00e02021  1062fff7 
Jul 26 11:32:45 fritz user.err ctlmgr[1663]: [bt]  2b2f5cb4 [2b2f5c06] <0+0x2b2f5c07>+0xae (/usr/share/ctlmgr/libtamconf.so at 00002c06)
Jul 26 11:32:45 fritz user.err ctlmgr[1663]: [bt]  2b2f5fbc [2b2f5d1e] <0+0x2b2f5d1f>+0x29e (/usr/share/ctlmgr/libtamconf.so at 00002d1e)
Jul 26 11:32:45 fritz kern.emerg kernel: [ 1191.700000] AVM_WATCHDOG_ungraceful_release: handle 4 (ctlmgr) still registered!

WebIF ist weg, laufende Telefonate werden unterbrochen. Ein paar Minuten später startet die Box neu. Ich habe ein paar harmlose Removal-Patches aktiv. Harmlos deshalb, weil das Deaktivieren sämtlicher Removals das Problem nicht löst. Rein spaßeshalber habe ich den Crash auch mal an AVM gemeldet.

Zuletzt geändert vor 3 Jahren von CarstenSchuette (vorher) (Diff)

Geändert vor 3 Jahren durch CarstenSchuette

Geändert vor 3 Jahren durch blackstar

FB7390 Reboot Telefon

comment:19 Geändert vor 3 Jahren durch Cas1711

Noch eine Info zum Problem mit den Laborversionen.
Wenn man eine funktionierende 113.06.05 auf die Labor Version updatet funktionieren die VoiP Telefonnummern nicht mehr( nicht registriert)
und ein Zugriff auf die Tel. Einstellungen führt zum Reboot der 7490.
Ohne Freetz funktioniert beides mit den Labor Versionen.
Hat wirklich keiner eine Idee wie man da weiterkommt oder ist die 7490 einfach von Freetz unsupportet ?

comment:20 Geändert vor 3 Jahren durch CarstenSchuette

Zuletzt geändert vor 3 Jahren von CarstenSchuette (vorher) (Diff)

comment:21 als Antwort auf: ↑ 15 ; Antwort: Geändert vor 3 Jahren durch er13

Replying to JMC:

  • Recover, AVM Einstellungen zurückgespielt, Freetz-Image geflasht, Freetz Einstellungen zurückgespielt → alles ok
  • Flash eines aktuelleren Freetz Image (auf Basis einer neueren Labor Version) → fängt von vorne an.

Könntest Du bitte folgendes machen:

  1. Recover, AVM Einstellungen zurückspielen, vorletzte AVM-Labor-Version (ohne Freetz) einspielen
  2. Auf die letzte AVM-Labor (wieder ohne Freetz) upgraden
  3. AVM-Einstellungen sichern

Und dann nochmal das gleiche, diesmal allerdings überall mit Freetz.

Vergleiche die beiden "AVM-Einstellungen" Dateien. Gibt es verdächtige/unerwartete Unterschiede?

Alternativ könnte auch der Vergleich der gesicherten AVM-Einstellungen "bevor das Problem angefangen hat aufzutreten" vs. "das Problem tritt jetzt reproduzierbar auf" helfen.

comment:22 Geändert vor 3 Jahren durch CarstenSchuette

Es gab ja gestern eine neue Laborversion. Treten eure Probleme damit auch noch auf?

Ich habe heute einen Test gemacht, nämlich meinen Freetz-Trunk komplett gelöscht und einen nackten Freetz-Build für die 7490 ohne irgendwelche Paketauswahlen oder Änderungen gebaut. Mit dieser Version lässt sich die Telefonieseite im AVM-WebIF aufrufen. Jetzt weiß ich allerdings nicht, ob das an der neuen Laborversion oder dem Freetz-Build liegt.

comment:23 Geändert vor 3 Jahren durch Cas1711

Hast du denn mal eine VoiP Nummer eingerichtet, registriert sie sich, kann man telefonieren ?
Geht das auch noch nach einem Neustart der Box ?
Kann man dann noch über GUI die Nummer ansehen/ändern ?

comment:24 Geändert vor 3 Jahren durch CarstenSchuette

Ja, das geht alles, auch nach einem Neustart der Box. Hast du den "remove brandings"-Patch drin?

Zuletzt geändert vor 3 Jahren von CarstenSchuette (vorher) (Diff)

comment:25 Geändert vor 3 Jahren durch Cas1711

nein, ich hatte es ohne remove Patche versucht.

comment:26 als Antwort auf: ↑ 21 Geändert vor 3 Jahren durch JMC

Replying to er13:

Alternativ könnte auch der Vergleich der gesicherten AVM-Einstellungen "bevor das Problem angefangen hat aufzutreten" vs. "das Problem tritt jetzt reproduzierbar auf" helfen.

Habe ich mal gemacht, da ich die Einstellungen Nachts automatisch sichern lasse. Bei den "plaintext" Sachen im Export ist mir kein Unterschied aufgefallen - ich vermute das Problem eher im Binary-Bereich (wenn überhaupt aus der Sicherung ersichtlich). Ich hab mal in meine letzten Syslogs geguckt von einem Flash-Versuch, da sind keine Crashes mehr zu finden. Ganz am Anfang hatte ich vor dem Reboot der Box immer noch ein Crash vom faxd oder ctlmgr - siehe #2480 da hatte ich mal einen Auszug gepostet.

Das "blöde" ist - ich habe extra für sowas eine zweite 7490 hier liegen um nicht immer die Produktive Box (und damit auch Telefon und Co) zu zerbasteln, und da lässt sich das Problem einfach in der Form nicht nachstellen.

comment:27 Geändert vor 3 Jahren durch CarstenSchuette

Ja, den Crash des faxd hatte ich gestern auch - da der aber nur einmal aufgetreten ist, ab ich mir nichts bei gedacht.

comment:28 Geändert vor 3 Jahren durch CarstenSchuette

Zuletzt geändert vor 3 Jahren von CarstenSchuette (vorher) (Diff)

comment:29 Geändert vor 3 Jahren durch JMC

Ich komme derzeit leider einfach nicht dazu, mal schauen ob ich am WE mal Zeit habe.

@Carsten: Bzgl deines (mittlerweile editierten) Posts im anderen Ticket: Interessanterweise passiert das ganze bei mir aber nur dann, wenn ich ja upgrade. Wenn das Problem bei dir ohne DSL nicht auftritt erklärt das auch, warum meine Testbox keine Zicken macht. Ich werde dann mal diese "in Betrieb" nehmen mit einem alten DECT und DSL-Sync und gucken ob ich dann dort mein Problem wie auf der Hauptbox nachgestellt bekomme. Ist mal interessant zu wissen :)

comment:30 Geändert vor 3 Jahren durch JMC

Ich hab eben ein paar Minuten gehabt um mal kurz an die Hauptbox zu gehen und nachdem in #2518 die Leute ja recht zufrieden waren hab ich nochmal kurz getestet. Bei meiner 7490 führt (von der Labor ab) ein Firmware-Upgrade zu einer Reboot-Schleife - leider immer noch. Egal ob mit oder ohne DSL-Sync (das ist scheinbar anders als bei Carsten) - ich hab es geschafft mal das crash.log zu bekommen bevor die Box dauernd rebootet:

root@fritz:/var/mod/root# cat /var/flash/crash.log
1970-01-01 01:00:54 [Segmentation fault]
faxd[2830] crashed at 2acd3a0c (/lib/libc.so.0: strcmp + 0xc) accessing 0x7553746f
Version: 06.10-28510
at: 00000001 v0: 2acd3a00 v1: 00000046
a0: 0041750b a1: 7553746f a2: 75537470 a3: 0041750c
t0: 00000000 t1: 00000036 t2: 8071bae0 t3: 00000001
t4: 80000000 t5: 00000073 t6: 0000005b t7: 333d2f64
s0: 0041f0b0 s1: 2aab6000 s2: 7fe3e2d0 s3: 2acd2c60
s4: 80000001 s5: 2aab80b0 s6: 2ad3b000 s7: 2ad3b000
t8: 00000000 t9: 2acd3a00
gp: 0041f0b0 sp: 7fe3dea8 fp: 7fefc2d0 ra: 00402cf7
[bt] Code: 24870001 24a60001 <14600003> 90a20000
[bt] 00402cf2 [/usr/bin/faxd at 2cf3]
[bt] 0040356a [/usr/bin/faxd at 356a]
[bt] 00403ac0 [/usr/bin/faxd at 3ac0]
[bt] 00402536 [/usr/bin/faxd at 2536] main + 0x916
1970-01-01 01:00:55 [Segmentation fault]
faxd[2822] crashed at 2acd3a0c (/lib/libc.so.0: strcmp + 0xc) accessing 0x7553746f
Version: 06.10-28510
at: 00000001 v0: 2acd3a00 v1: 00000044
a0: 0041750b a1: 7553746f a2: 75537470 a3: 0041750c
t0: 00000000 t1: 00000037 t2: 8071bae0 t3: 00000001
t4: 80000000 t5: 00000073 t6: 0000005b t7: 333d2f64
s0: 0041f0b0 s1: 2aab6000 s2: 7fe19790 s3: 2acd2c60
s4: 80000001 s5: 2aab80b0 s6: 2ad3b000 s7: 2ad3b000
t8: 00000000 t9: 2acd3a00
gp: 0041f0b0 sp: 7fe19368 fp: 7fb8a8f0 ra: 00402cf7
[bt] Code: 24870001 24a60001 <14600003> 90a20000
[bt] 00402cf2 [/usr/bin/faxd at 2cf3]
[bt] 0040356a [/usr/bin/faxd at 356a]
[bt] 00403ac0 [/usr/bin/faxd at 3ac0]
[bt] 00402536 [/usr/bin/faxd at 2536] main + 0x916
1970-01-01 01:00:54 [Segmentation fault]
faxd[2824] crashed at 2acd3a0c (/lib/libc.so.0: strcmp + 0xc) accessing 0x7553746f
Version: 06.10-28510
at: 00000001 v0: 2acd3a00 v1: 00000044
a0: 0041750b a1: 7553746f a2: 75537470 a3: 0041750c
t0: 00000000 t1: 00000036 t2: 8071bae0 t3: 00000001
t4: 80000000 t5: 00000073 t6: 0000005b t7: 333d2f64
s0: 0041f0b0 s1: 2aab6000 s2: 7fefa3a0 s3: 2acd2c60
s4: 80000001 s5: 2aab80b0 s6: 2ad3b000 s7: 2ad3b000
t8: 00000000 t9: 2acd3a00
gp: 0041f0b0 sp: 7fef9f78 fp: 7fc52360 ra: 00402cf7
[bt] Code: 24870001 24a60001 <14600003> 90a20000
[bt] 00402cf2 [/usr/bin/faxd at 2cf3]
[bt] 0040356a [/usr/bin/faxd at 356a]
[bt] 00403ac0 [/usr/bin/faxd at 3ac0]
[bt] 00402536 [/usr/bin/faxd at 2536] main + 0x916

Das von er13 beschriebene Verfahren muss ich noch testen, aber auch ein Versuch das ganze auf der Testbox eben nachzustellen führt nicht zum gewünschten Ergebnis: Die rebootet nämlich nicht. Ich bin kurz davor die Boxen zu tauschen, das einzige was mich davon abhält ist die Befestigung der Produktiv-Box mit Kabelbindern hinten durch die Lüftungsschlitze…

comment:31 Geändert vor 3 Jahren durch CarstenSchuette

Ich kann dir nur empfehlen, deaktiviere den integrierten Faxempfang. Das hat bei mir geholfen.

comment:32 Geändert vor 3 Jahren durch Cas1711

AVM hat die Lab Version mit der Freetz Probleme hat nun released, Image liegt unter ftp.avm.de/fritz.box/fritzbox.7490/firmware/deutsch/FRITZ.Box_7490.113.06.20.image.

Kann die version jemand in Freetz aufnehmen ?

comment:33 Geändert vor 3 Jahren durch Whoopie

  • Firmware Version von 113.06.10-28311 nach 06.10-28311 / 06.20 geändert
  • Zusammenfassung von 7490-Labor Reboot bei Anrufbeantworter/Telefoniegeräte nach 7490: Reboot bei Anrufbeantworter/Telefoniegeräte geändert

comment:34 Geändert vor 3 Jahren durch CarstenSchuette

Hier nochmal ein Crashlog mit der 6.20er-Firmware. Das Ganze tritt auf, sobald ich auf meiner Box den "integrierten Faxempfang" zur Config hinzufügen will. Der Wizard läuft durch, sobald das Gerät aber aktiviert wird, crasht die Box:

Aug 14 21:46:42 fritz user.err ctlmgr[1614]: /var/flash/crash.log opened
Aug 14 21:46:42 fritz user.err ctlmgr[1614]: 2014-08-14 21:46:42(1) [Segmentation fault] /usr/bin/avm/ctlmgr(1614) CRASHED at strcmp+0xc (/lib/libc.so.0 at 00038a1c) accessing 0+0x7553746e (/lib/libhtmltemplate.so.0 at 49bc146e)
Aug 14 21:46:42 fritz user.err ctlmgr[1614]: SIGNO 11 ERRNO 0 CODE 1
Aug 14 21:46:42 fritz user.err ctlmgr[1614]: Version: 06.20
Aug 14 21:46:42 fritz user.err ctlmgr[1614]: Watchdog triggered 3 seconds ago
Aug 14 21:46:42 fritz user.err ctlmgr[1614]: No bugmsg
Aug 14 21:46:42 fritz user.err ctlmgr[1614]: ze: 00000000 at: 00000001 v0: 2ae5da10 v1: 0000004f
Aug 14 21:46:42 fritz user.err ctlmgr[1614]: a0: 2b0c74ab a1: 7553746f a2: 75537470 a3: 2b0c74ac
Aug 14 21:46:42 fritz user.err ctlmgr[1614]: t0: 00000000 t1: 53ed1222 t2: 8071bae0 t3: 00000001
Aug 14 21:46:42 fritz user.err ctlmgr[1614]: t4: 80000000 t5: 00000073 t6: 0000005b t7: 323d2f64
Aug 14 21:46:42 fritz user.err ctlmgr[1614]: s0: 2b0cebb0 s1: 2b8d3d18 s2: 2ba37c20 s3: 2b570ac0
Aug 14 21:46:42 fritz user.err ctlmgr[1614]: s4: 2b3e9e28 s5: 2ba37890 s6: 2b9a7bc8 s7: 2b3e9ed8
Aug 14 21:46:42 fritz user.err ctlmgr[1614]: t8: 00000000 t9: 2ae5da10 k0: 00000001 k1: 00000000
Aug 14 21:46:42 fritz user.err ctlmgr[1614]: gp: 2b0cebb0 sp: 7ffc52d0 fp: 2ba37910 ra: 2b08753d
Aug 14 21:46:42 fritz user.err ctlmgr[1614]: FA 7553746e 0+0x7553746e (/lib/libhtmltemplate.so.0 at 49bc146e)
Aug 14 21:46:42 fritz user.err ctlmgr[1614]: PC 2ae5da1c strcmp+0xc (/lib/libc.so.0 at 00038a1c)
Aug 14 21:46:42 fritz user.err ctlmgr[1614]: RA 2b08753c 0+0x2b08753c (/usr/share/ctlmgr/libtelcfg.so at 0000353c)
Aug 14 21:46:42 fritz user.err ctlmgr[1614]: Code: 90830000  24870001  24a60001 <14600003> 90a20000  03e00008  00021023  00e02021  1062fff7 
Aug 14 21:46:42 fritz user.err ctlmgr[1614]: [bt]  2b087538 [2b08748a] <0+0x2b08748b>+0xae (/usr/share/ctlmgr/libtelcfg.so at 0000348a)
Aug 14 21:46:42 fritz user.err ctlmgr[1614]: [bt]  2b09420c [2b09414e] <0+0x2b09414f>+0xbe (/usr/share/ctlmgr/libtelcfg.so at 0001014e)
Aug 14 21:46:42 fritz user.err ctlmgr[1614]: Signal Segmentation fault while doing crashdump (2)
Aug 14 21:46:42 fritz user.err ctlmgr[1614]: 2014-08-14 21:46:42(2) [Segmentation fault] /usr/bin/avm/ctlmgr(1614) CRASHED at 0+0x2ad4c5f8 (/lib/libavmcsock.so.2 at 000515f8) accessing 0+0x2ba36ffc (/lib/libhtmltemplate.so.0 at 000c0ffc)
Aug 14 21:46:42 fritz user.err ctlmgr[1614]: SIGNO 11 ERRNO 0 CODE 1
Aug 14 21:46:42 fritz user.err ctlmgr[1614]: ze: 00000000 at: 18102092 v0: ffff0000 v1: 2ba37008
Aug 14 21:46:42 fritz user.err ctlmgr[1614]: a0: 3c1c0000 a1: ffff8000 a2: 27bd8000 a3: 279c0000
Aug 14 21:46:42 fritz user.err ctlmgr[1614]: t0: 00000000 t1: 00000000 t2: 00000000 t3: 00000000
Aug 14 21:46:42 fritz user.err ctlmgr[1614]: t4: 00000000 t5: 7f000001 t6: 00412640 t7: 0399e021
Aug 14 21:46:42 fritz user.err ctlmgr[1614]: s0: fffffef0 s1: 2ad4ad00 s2: 00000000 s3: 7ffc54b8
Aug 14 21:46:42 fritz user.err ctlmgr[1614]: s4: 2b09414f s5: 000064f7 s6: 2ba37ca0 s7: 00000000
Aug 14 21:46:42 fritz user.err ctlmgr[1614]: t8: 00000105 t9: 2ae848e4 k0: 00000001 k1: 00000000
Aug 14 21:46:42 fritz user.err ctlmgr[1614]: gp: 2ad7d0a0 sp: 7ffc4870 fp: 2ba37910 ra: 2ad4cad8
Aug 14 21:46:42 fritz user.err ctlmgr[1614]: FA 2ba36ffc 0+0x2ba36ffc (/lib/libhtmltemplate.so.0 at 000c0ffc)
Aug 14 21:46:42 fritz user.err ctlmgr[1614]: PC 2ad4c5f8 0+0x2ad4c5f8 (/lib/libavmcsock.so.2 at 000515f8)
Aug 14 21:46:42 fritz user.err ctlmgr[1614]: RA 2ad4cad8 0+0x2ad4cad8 (/lib/libavmcsock.so.2 at 00051ad8)
Aug 14 21:46:42 fritz user.err ctlmgr[1614]: Code: 10000027  24630008  004a5024 <5544000b> 8c6bfff4  55670009  8c6bfff4  8c6b0000  01656024 
Aug 14 21:46:42 fritz user.err ctlmgr[1614]: [bt]  2ad4cad0 [2ad4c364] <0+0x2ad4c364>+0x76c (/lib/libavmcsock.so.2 at 00051364)
Aug 14 21:46:42 fritz user.err ctlmgr[1614]: [bt]  2ad4b950 [2ad4afb4] <0+0x2ad4afb4>+0x99c (/lib/libavmcsock.so.2 at 0004ffb4)
Aug 14 21:46:42 fritz user.err ctlmgr[1614]: [bt]  !7ffc4fb0 rtsignal trampoline on stack
Aug 14 21:46:42 fritz user.err ctlmgr[1614]: [bt]  2ae5da14 mempcpy+0x444 (/lib/libc.so.0 at 000385d0)
Aug 14 21:46:42 fritz kern.emerg kernel: [ 1695.560000] AVM_WATCHDOG_ungraceful_release: handle 16 (ctlmgr) still registered!

Geändert vor 3 Jahren durch blackstar

FB7390 Reboot Telefon

comment:35 Geändert vor 3 Jahren durch blackstar

Hallo
der selbe Fehler tritt bei mir auch an einer 7390 auf die .config hängt
weiter oben.
hier noch nen Syslog

comment:36 Geändert vor 3 Jahren durch CarstenSchuette

Ein weiteres Problem: Auf einer 7490 mit 6.20-Firmware und einem Minimal-Freetz (keine Patches, keine Pakete, nur Freetz) sind sämtliche am ISDN-Bus angeschlossenen Geräte tot. Beim Abnehmen des Hörers bleibt es still. Im Log finde ich dazu rein gar nichts. Mit der Original-Firmware funktioniert das.

Tauscht Freetz irgendwas in der Firmware aus?
Vielleicht irgendeine Bibliothek, die AVM neuerdings selbst mit ausliefert…?

comment:37 Geändert vor 3 Jahren durch er13

In 12334:

  • add hidden menuconfig option FREETZ_KEEP_AVM_UCLIBC - makes it possible to disable replacement of uClibc
  • refs #2499

Geändert vor 3 Jahren durch er13

comment:38 Geändert vor 3 Jahren durch er13

Habe leider noch keinen vernünftigen Ansatzpunkt, von daher lasst uns mal versuchen einiges auszuschließen.

Mit dem unhide_keep_avm_uclibc.diff kann die in r12334 eingebaute Option sichtbar gemacht werden, mit der gesteuert werden kann, ob die freetz Version von uClibc installiert werden soll oder die von AVM beibehalten. Schaltet diese ein und testet mal.

Bootet die Box überhaupt (habe selbst auf der Box nichts getestet)? Wenn ja, tritt der Fehler immer noch auf?

Seid darauf vorbereitet, dass Ihr die Box recovern müsst.

Zum Hintergrund: AVM hat bisher keine .config für 0.9.33.2 veröffentlicht. Die von freetz verwendete .config ist geraten. Die von freetz verwendete 0.9.33.2-Version ist außerdem stark gepatcht. Könnte sein, dass eines der Patches zum einen Fehler einbaut, die es in der AVM-Version nicht gibt, zum anderen die binäre Kompatibilität verletzt.

Zuletzt geändert vor 3 Jahren von er13 (vorher) (Diff)

comment:39 Antwort: Geändert vor 3 Jahren durch CarstenSchuette

Mit der Original uClibc startet die Box, die Telefonieeinstellungen lassen sich aufrufen und der integrierte Faxempfang lässt sich einrichten, ohne dass die Box abschmiert. Die integrierten Anrufbeantworter funktionieren auch.

Aber:

Der integrierte Faxempfang funktioniert nicht. Die Box nimmt das Gespräch an, man hört aber keinen "Faxton". ISDN-Endgeräte sind tot, das Display zeigt Datum und Uhrzeit, aber beim Abnehmen bleibt es still in der Leitung. Eingehende Gespräche werden nicht signalisiert. Im Syslog sehe ich dazu aber gar nichts. "dtrace" erkennt zwar die Controller, zeigt gar keine Ausgaben an.

Mit der Original uClibc funktioniert außerdem das Firmware-Update aus Freetz heraus nicht mehr. Nach dem Klicken auf "Firmware hochladen" bleibt Firefox auf "Connecting…" hängen, es passiert auch nach 10 Minuten nichts mehr. Auch dazu steht im Syslog nichts wirklich Brauchbares. Update über das AVM WebIF funktioniert, ist aber nicht so schön :)

Zuletzt geändert vor 3 Jahren von CarstenSchuette (vorher) (Diff)

Geändert vor 3 Jahren durch CarstenSchuette

CarstenSchuette config, keine ISDN-/Fax-Funktion

comment:40 Geändert vor 3 Jahren durch er13

Nochmal, um sicherzustellen, dass ich Dich richtig verstehe. Der in der Description beschriebene Fehler tritt mit AVM-uClibc nicht mehr auf: alle AVM-Telefonie/AB/FAX-WebIF-Seiten lassen sich aufrufen, ohne dass die Box abschmiert. Auch nach einem Reboot?

Könnte es bitte noch jemand bestätigen (nur für den Fall, dass es nur bis zum nächsten Update funktioniert)?

@Carsten: Das mit "ISDN-Endgeräte" sind tot. Seit wann gibt es denn diesen Fehler? Erst seit dem 6.20-Release? Oder hatten die Labors den auch schon? Dadrüber berichtet hast Du zum ersten Mal erst gestern. Die letzte Labor ist ja immer noch auswählbar, wenn Du Dir unsicher bist seit wann, so könntest Du bitte testen? Danke!

comment:41 Geändert vor 3 Jahren durch er13

In 12335:

  • make FREETZ_KEEP_AVM_UCLIBC simply depend on FREETZ_REAL_DEVELOPER_ONLY (eliminates the need to apply any patches to unhide the option)
  • refs #2499

comment:42 Antwort: Geändert vor 3 Jahren durch CarstenSchuette

@er13: Richtig, die Seiten lassen sich aufrufen, zumindest bei mir. Daher sollte das auf jeden Fall nochmal jemand bestätigen.

Aber ISDN/Faxdienst funktionieren nicht. Dieses Problem ist zeitgleich mit den Abstürzen aufgetreten, also mit der letzten Version, in der das WebIF noch fehlerfrei funktionierte funktionierten auch noch ISDN/Faxdienst. Seit einigen Labors und mit der Final 6.20 aber eben nicht mehr.

Zuletzt geändert vor 3 Jahren von CarstenSchuette (vorher) (Diff)

comment:43 als Antwort auf: ↑ 42 Geändert vor 3 Jahren durch er13

Replying to CarstenSchuette:

Dieses Problem ist zeitgleich mit den Abstürzen aufgetreten, also mit der letzten Version, in der das WebIF noch fehlerfrei funktionierte funktionierten auch noch ISDN/Faxdienst. Seit einigen Labors und mit der Final 6.20 aber eben nicht mehr.

Welche Version ist nun die letzte, in der das fehlerfrei noch funktionierte? Ich hätte eigentlich gedacht, dass es 6.05-release wäre, aber Dein Satz "seit einigen Labors" lässt vermuten, dass es auch Labors gegeben hat, in denen alles noch funktionierte? Könntest Du diese interpretation bitte bestätigen? Oder ist es vielleicht doch 6.05?

Ich hätte da denke ich fast alle Labors liegen und könnte ein paar Downgrade-Patches basteln. Sollten wir genauen Zeitpunkt feststellen können, ab dem es nicht mehr funktioniert, so würde das die Suche nach der Ursache um einiges erleichtern.

comment:44 Geändert vor 3 Jahren durch CarstenSchuette

@er13: Das kann ich dir nicht mehr so genau sagen, es kann auch schon mit der 06.05 aufgetreten sein. Ich compiliere gerade nochmal gegen die 06.05 und berichte dann. Soll ich dafür ein eigenes Ticket aufmachen?

Zuletzt geändert vor 3 Jahren von CarstenSchuette (vorher) (Diff)

comment:45 Geändert vor 3 Jahren durch colonia27

Gerade durch Zufall über das Ticket gestolpert. Das Verhalten deckt sich mit meinen Erfahrungen mit einer der letzten Labors vor einigen Wochen. Hab ich nicht weiter verfolgt, weil ich auf ne stable zurück bin wegen Produktivbox.
Jedenfalls könnte ich die bootloops und reboots bei Zugriff auf Telefoniefunktionen unterbinden indem ich meine angeschlossene USB HDD während dem bootvorgang abgestöpselt hab. Nachdem sie oben war, Platte wieder dran und gut.
Natürlich kommt das Problem wieder sobald man in den Telefoniefunktionen spielt.
Vielleicht hilft die Info bei der weiteren Fehlersuche

comment:46 Geändert vor 3 Jahren durch CarstenSchuette

@er13: Test hat ergeben, dass die ISDN-Telefonie und der Faxdienst tot sind, tritt auch mit der 06.05 auf. Das war aber nicht immer so, ich bin mir ziemlich sicher, dass das mit der 06.05 schon funktioniert hat. Da ich Faxdienst/ISDN brauche, muss ich jetzt leider wieder zurück auf die ungefreetzte Version.

comment:47 Geändert vor 3 Jahren durch er13

Da 7490-6.05 auf gcc-4.7/uClibc-0.9.32/NON-NPTL basiert, handelt es sich um ein anderes/neues Problem, welches jedoch nichts mit dem Problem aus diesem Ticket zu tun hat. Bitte ein neues Ticket aufmachen (damit es in diesem nicht untergeht) und alle Erkenntnisse dort nochmal zusammenfassen. Danke!

comment:48 Geändert vor 3 Jahren durch Cas1711

Hi Carsten, bei mir läuft ISDN-Telefonie einwandfrei sowohl von extern ( NTBA) als auch am internen S0 Bus.
Ich hab es mit 7490_06.05-freetz-devel-12332 am laufen, 7490_06.05-freetz-devel-12297 war auch OK.
Fax hab ich nicht aktiv. Mit 06.20 hab ich den bekannten Absturz beim Zugriff auf Telefon Settings, auch ohne Patche FAX und AB.

comment:49 Geändert vor 3 Jahren durch CarstenSchuette

Es wäre übrigens schon, wenn ihr FREETZ_REAL_DEVELOPER_ONLY mal im Wiki ergänzen könntet. Die Suche findet dazu nix. Nach einigem Gesuche habe ich dann die config/custom.in "gefunden" und dass ich mir da die Option selbst einbauen muss. Habe aber vorher immer irgendwas zum Auskommentieren gesucht…. ;)

Meine Ausfälle des ISDN-Bus sind behoben, das lag an einem defekten Kabel. Bleibt also das Problem des abstürzenden faxd mit der Freetz-uClibc. Mit der Original-AVM-uClibc laufen übrigens die selbst kompilierten Dinge nicht, vnstat und rddstats zeigen z.B. keine Grafiken an etc., also keine Lösung….

Zuletzt geändert vor 3 Jahren von CarstenSchuette (vorher) (Diff)

Geändert vor 3 Jahren durch er13

avm.uclibc.config.vr9.from.labor7490sources vs freetz.uclibc.config.vr9

comment:50 Geändert vor 3 Jahren durch er13

Sehe an den .config-Unterschieden (noch) nichts, was die Abstürze erklären würde. Ein paar BSD-compatibility/SYSv4 Sachen - diese werden von AVM jedoch nicht verwendet. UCLIBC_HAS_FENV ist in der AVM .config gesetzt, die entsprechenden Symbole lassen sich in der binären Version jedoch nicht finden ⇒ Vermutung, die dem 7490labor beiliegende uClibc .config ist nicht die richtige…

comment:51 Geändert vor 3 Jahren durch er13

In 12362:

  • add warning pointint out that freetz support for 6.10/6.20 firmwares is unstable
  • refs #2499

comment:52 Antwort: Geändert vor 3 Jahren durch Cas1711

Die Warnung passt so nicht, da nur bei der Labor Version.
Die Warung gehört an die final Version 6.20, Freetz ist da unbrauchbar (zumindest bis 7490_06.20-freetz-devel-12370).

comment:53 als Antwort auf: ↑ 52 Geändert vor 3 Jahren durch er13

Replying to Cas1711:

Die Warnung passt so nicht, da nur bei der Labor Version.

Ach nee? Hast Du es getestet?

comment:54 Geändert vor 3 Jahren durch Cas1711

Ja sicher habe ich das getestet. Sobald man auf die Tel. Einstellungen zugreift stürzt das GUI ab.
Mit 06.20 und Freetz devel-12370.
Also der bekannte Fehler wegen dem kroki0815 am 5.7. das Ticket aufgemacht hat.

comment:55 Geändert vor 3 Jahren durch er13

@Cas1711: Ich habe nicht umsonst einen Teil Deines Kommentars zitiert. Hint: mein Sarkasmus und meine Frage beziehen sich nur auf diesen Teil.

Geändert vor 3 Jahren durch er13

comment:56 Geändert vor 3 Jahren durch er13

Hallo zusammen,

könntet Ihr bitte einen frischen Checkout machen und den angehängten Patch testen?

Wichtig 1: _frischer_ Checkout

Wichtig 2: Ihr könnt schon Eure alte .config verwenden, müsst allerdings auf die download-toolchain umstellen (keine selbstgebaute und auch "keine selbstgebaute als download")

Ich habe auf meiner Test-7490 unter 6.05 eine Sip-Nummer eingerichtet und den Anrufbeantworter eingeschaltet. Die eingerichtete Nummer ist erreichbar gewesen, der Anrufbeantworter hat funktioniert.

Danach habe ich von 6.05 auf 6.20 mit dem Patch oben upgedatet. Die Nummer ist weiterhin erreichbar, der Anrufbeantworter funktioniert weiterhin.

Ich kann problemlos unter Telefonie alles mögliche anklicken ohne dass die Box rebootet. Ich kann die Fax-Funktion einrichten, ich kann die Fax-Funktion unter Telefonie/Telefoniegeräte wieder löschen ohne dass die Box rebootet.

Ich habe zur Sicherheit die Box neu gestartet. Es ändert sich nichts, es funktioniert alles weiterhin wie erwartet ohne Reboots/Abstürze.

Sieht also einerseits nicht schlecht aus, andererseits habe ich mir nicht die Mühe gemacht, den Fehler mit der alten Toolchain nachzustellen. Es kann also sein, dass das Einrichten einer Sip-Nummer nicht ausreichend ist, um den Fehler zu provozieren. Es kann auch sein, dass es genauso wie bei JMC ist - an einer Box lässt sich der Fehler nachstellen, an der anderen nicht. Meine Testbox läuft im ATA-Modus hinter einer anderen.

VG

Geändert vor 3 Jahren durch er13

comment:57 Geändert vor 3 Jahren durch CarstenSchuette

@er13: Was sind denn die Unterschiede im Toolchain, nur mal so als Anhaltspunkt?

comment:58 Geändert vor 3 Jahren durch er13

@Carsten: s. #1939 - alles bis inkl. r12430 außer r12429

comment:59 Antwort: Geändert vor 3 Jahren durch hawkeye80

@er13
Meine 7490 crashte auch nachdem ich kurz nach Erscheinen auf die 6.20+freetz upgedatet hatte wenige Minuten nach dem Startup automatisch. Ohne Webinterface Aufruf, kein SIP, ein MF-T Dect und einen Sat-Receiver als Call-Monitor.

Habe dann heute mal deinen Patch versucht. Ergebnis: Noch bevor ich die Freetz config wiederherstellen und das External flashen konnte bootete die Box wieder neu. Anschließend auch ebenfalls ohne Web-Zugriff nach ca. 1-3 Minuten Uptime.

Habe "Download and use precompiled toolchains" aktiv, jedoch habe ich "Standard C++ Library (GNU libstdc++)" und nicht uClibc++, da ich zuletzt E-MailRelay verwendete. Vielleicht macht das ja auch einen Unterschied.

comment:60 als Antwort auf: ↑ 59 Geändert vor 3 Jahren durch er13

Replying to hawkeye80:

Meine 7490 crashte auch nachdem ich kurz nach Erscheinen auf die 6.20+freetz upgedatet hatte wenige Minuten nach dem Startup automatisch. Ohne Webinterface Aufruf, kein SIP, ein MF-T Dect und einen Sat-Receiver als Call-Monitor.

Dann handelt es sich bei Deinem Problem (vermutlich) um ein anderes. Hier geht es ausschließlich um die Crashes, die man erzwingen kann, indem man im AVM web-if auf Telefonie/irgendwas geht, und die verschwinden, wenn man die AVM-Version von uClibc beibehält.

Versuche bitte Dein Problem einzugrenzen - schalte alle RemovePatches, AVM-/Freetz-Dienste aus bis das System stabil läuft. Wenn Du es eingegrenzt hast, öffne bitte ein neues Ticket. Mit Deiner aktuellen Beschreibung können wir leider nichts anfangen. "uClibc++ vs. libstdc++" ist selten das Problem, Du kannst es aber leicht prüfen, es gibt kaum C++-abhängige Dienste, schalte sie alle aus. Crasht das System immer noch, dann hat es nichts mit C++ zu tun.

comment:61 Geändert vor 3 Jahren durch Cas1711

Sobald ich auf die Telefon Settings zugreife (auch ohne aktives FAX und AB) stürzt das GUI ab.
VoiP, ISDN, Fritz.fon und Dect sind aktiv.
Ich hab es mit frischem Checkout versucht.

comment:62 Antwort: Geändert vor 3 Jahren durch er13

Verdammt… Warum funktioniert es bei mir?

@alle: hat einer von Euch den Tipp von colonia27 versucht?

@Carsten: hast Du DECT aktiviert? (alle anderen - JMC, kroki0815, Cas1711 - haben es aktiv)

Edit: habe bei mir DECT eingerichtet, einen USB-Stick angeschlossen, erst ohne Reboot und dann mit Reboot getestet ⇒ die Box läuft und weigert sich abzustürzen. Ich kann raustelefonieren, ich kann angerufen werden. Habe Fax eingeschaltet und mich selbst angerufen, Fax nimmt ab und piept fröhlich in die Leitung. Telefonie/Irgendwas lässt sich aufrufen, die Optionen lassen sich ab- und einschalten und nix passiert - die Box läuft einfach.

Morgen hänge ich sie direkt an die DSL-Leitung (alle oben beschriebenen Tests wurden im ATA-Modus durchgeführt).

Edit2: welches Branding habt Ihr (eingeschtelt)?

Zuletzt geändert vor 3 Jahren von er13 (vorher) (Diff)

comment:63 Geändert vor 3 Jahren durch Cas1711

Ich hab eine 7490 von 1&1, Branding ist schon länger auf AVM umgestellt.
Recover mit 6.05 und 6.20 hab ich schon durchgeführt, es stand mal irgendwo das nach dem Ändern des Brandings ein Recover gemacht werden soll.
Gibt es bei der 7490 unterschiedliche HW Revisionen, unterschiedliche Bootloader Versionen ?

comment:64 Geändert vor 3 Jahren durch JMC

Meine Produktive ist auch eine 1&1 die vor langer Zeit auf AVM gebrandet wurde. Meine Testbox ist ne "originale" Rote AVM. Haben denn alle, die die reboot Probleme haben eine 1&1 Box (die evtl. im branding verändert worden ist?). Mir ist bisher zwar noch nie zu Ohren gekommen, dass es da tatsächliche Unterschiede gibt, aber wer weiß?

comment:65 Geändert vor 3 Jahren durch er13

Meine Testbox, auf der sich der Fehler bisher nicht nachstellen lässt, ist auch eine originale (rote) AVM-Box.

Edit: noch eine Frage. Habt Ihr sonst noch was auf der Box außer freetz? FHEM, LCR, fritzload, etc.?

Edit2: @JMC: könntest Du eventuell folgendes testen? Sichere die Konfigurationen Deiner beiden Boxen. Und dann mach einen Swap der beiden Boxen, sprich spiel' auf die TestBox das Image und die Einstellungen der ProductiveBox ein und umgekehrt. Wie verhalten sich die beiden Boxen danach? Wandert der Fehler mit der Hardware oder mit der Software-Konfiguration mit?

Zuletzt geändert vor 3 Jahren von er13 (vorher) (Diff)

comment:66 als Antwort auf: ↑ 62 Geändert vor 3 Jahren durch CarstenSchuette

Replying to er13:

@Carsten: hast Du DECT aktiviert? (alle anderen - JMC, kroki0815, Cas1711 - haben es aktiv)

Nein.

Edit2: welches Branding habt Ihr (eingeschtelt)?

Ich habe das AVM-Branding aktiv, aber keinen Remove-Patch für die unnötigen Brandings.

Replying to er13:

…eine originale (rote) AVM-Box.

Meine ist eine schwarze von 1&1.

Edit: noch eine Frage. Habt Ihr sonst noch was auf der Box außer freetz? FHEM, LCR, fritzload, etc.?

Nein.

Zuletzt geändert vor 3 Jahren von CarstenSchuette (vorher) (Diff)

comment:67 Geändert vor 3 Jahren durch Cas1711

Meine ist eine schwarze von 1&1, Branding AVM.
Umgestellt hatte ich das Branding mit dem ruKernelTool, danach Recover.
Ich hab FHEM auf einem Stick installiert und rufe es über die debug.cfg auf, also nichts auf der Box selber installiert.
Ich hab das Problem aber auch wenn ich neu auschecke auf die 6.20 umstelle und garnichts modifiziere.
Die orginal 6.20 ohne Freetz läuft problemlos, dann hab ich eben nur keine debug.cfg die ich zum starten von FHEM nutzen kann,

comment:68 Geändert vor 3 Jahren durch er13

@Cas1711: FHEM ist streng genommen das, was ich nicht hören wollte. Wie genau wird FHEM gestartet, insbesondere wird LD_PRELOAD überladen oder irgendetwas mit mount -o bind ... angestellt (ich habe FHEM-Pakete gesehen, bei denen einzelne libc-Bibliotheken mitgeliefert wurden und dann auf eine der beiden Arten oben "geladen" bzw. "drübergeladen" wurden)?

Oder andersrum, wenn Du das starten von FHEM in debug.cfg abschaltest, ändert sich etwas in Bezug auf den Fehler? Mir wäre es lieber, wenn Du - bis der Fehler eingegrenzt ist - alle Tests mit komplett abgeschaltetem FHEM durchführst. Danke!

comment:69 Geändert vor 3 Jahren durch Cas1711

@er13: Das Problem ist unabhängig von FHEM.
Ich habe ein Recover mit 6.05 gemacht, und dann Freetz mit 6.05 installiert (ohne irgendetwas mit FHEM) dann habe ich in Freetz nur auf 6.20 umgestellt mit make erstellt und auf die Box installiert und dann tritt das Problem auf.

FYI: FHEM lasse ich laufen indem ich einfach auf den Stick das FHEM Verzeichnis kopieren ( also \uStor01\fhem ) und dann in der debug.cfg
aufrufe mit: /var/media/ftp/uStor01/fhem/fhem/startfhem. Ich kann den Stick auch abziehen, Freetz 6.20 stürzt reproduzierbar ab sobald ich die Tel. Settings aufrufe.

comment:70 Geändert vor 3 Jahren durch blackstar

Hallo zusammen
was mir heute beim rumtesten mit meiner 7390 aufgefallen ist.
Vesion 6.04 WLAN zum Handy kein Problem
update auf 6.10 Labor freetz Handy baut keine saubere Datenverbindung mehr auf.
Datenverbindung neu eingerichtet → datenverbindung wieder stabil.
die beiden Patche von er13 mit eingespielt
Datenverbindung wieder instabil
Datenverbindung neu eingerichtet → datenverbindung wieder stabil.
inwieweit das mit dem Problem hier zu tun hat weiß ich nicht wenn es irrrelevant ist bitte ignorieren
weiß aber noch das ich nach dem Update 7490 auch WLAN Probleme hatte und die auch neu einrichten mußte
Gruß Black

Zuletzt geändert vor 3 Jahren von blackstar (vorher) (Diff)

comment:71 Geändert vor 3 Jahren durch er13

So liebe freetz-Freunde,

so langsam finde ich es nicht mehr lustig. Meine Test-7490 (original AVM, keine 1&1) hängt nun direkt an der DSL-Leitung. Ich habe meine 3 ISDN-Nummern und eine VoIP-Nummer eingerichtet. Eines meiner Mobilteile ist an der IDSN-Basis-Station angemeldet, das andere an der FritzBox. Ich kann raustelefonieren, ich kann angerufen werden (unter allen Nummern). Ich habe die Faxfunktion der Box eingeschaltet, Fax nimmt zumindest ab (ob ein Fax auch übertragen werden kann, habe ich nicht getestet). Ich habe einen USB-Stick angeschlossen und alles auch mit diesem, ohne diesen, sofort nach dem Anstecken und auch nach einem Neustart getestet (Stichwort Hinweis von colonia27). Es bleibt alles beim alten - ich kann beliebigen Menüeintrag im AVM-WebIf aufrufen - die Box weigert sich weiterhin abzustürzen.

Dass es an der Hardware (original AVM vs. 1&1) liegt, glaube ich nicht. Es muss an irgendeiner Software-Konfiguration liegen (Re-Branding ist für mich auch eine Software—Konfiguration).

Könntet Ihr bitte aufzählen, was Ihr alles auf der Box eingerichtet (i.e. welche Funktionen eingeschaltet) habt und welche externen Geräte angeschlossen/angemeldet habt. Hängen Eure Boxen an einer ADSL- oder VDSL-Leitung? Habt Ihr immer die alte Konfiguration übernommen? Hat einer von Euch sich die Mühe gemacht, nach einem Recover alles manuell neu einzugeben statt die alte Konfiguration zu übernehmen?

JMC hat ja beschrieben, er kann die Box für einen gewissen Zeitraum bis zum nächsten Update heilen. Das versuche ich jetzt mal. Ich flashe das gleiche Image einfach nochmal…

comment:72 Geändert vor 3 Jahren durch er13

Muss meinen Kommentar oben etwas revidieren.

Habe jetzt unter /var/flash ein crash.log gefunden

2014-09-06 23:15:23 [Segmentation fault]
faxd[3173] crashed at 2acd3a2c (/lib/libc.so.0: strcmp + 0xc) accessing 0x7553746f
Version: 06.20
at: 00000001 v0: 2acd3a20 v1: 00000075
a0: 0041750b a1: 7553746f a2: 75537470 a3: 0041750c
t0: 00000000 t1: 540b796b t2: 8071bae0 t3: 00000001
t4: 80000000 t5: 00000073 t6: 0000005b t7: 323d2f64
s0: 0041f0b0 s1: 2aab6000 s2: 7fed2c70 s3: 2acd2c80
s4: 2b833420 s5: 004acc50 s6: 004accf0 s7: 00000000
t8: 00000000 t9: 2acd3a20
gp: 0041f0b0 sp: 7fed2200 fp: 7fc618f8 ra: 00402cf7
[bt] Code: 24870001 24a60001 <14600003> 90a20000
[bt] 00402cf2 [/usr/bin/faxd at 2cf3]
[bt] 0040356a [/usr/bin/faxd at 356a]
[bt] 00403ac0 [/usr/bin/faxd at 3ac0]
[bt] 00403bec [/usr/bin/faxd at 3bec]
[bt] 00404536 [/usr/bin/faxd at 4536] fax_machine + 0x202
[bt] 004025bc [/usr/bin/faxd at 25bc] main + 0x99c

Also hat faxd offensichtlich einen segfault produziert, die Box hat dabei aber NICHT neu gebootet.


Inzwischen habe ich nicht nur das gleiche Image nochmal geflashed, sondern auch ein neu erstelltes (keine .config Änderung allerdings) - alle Menü-Einträge im AVM-WebIf sind weiterhin aufrufbar - die Box stürzt NICHT ab. Diff der gesicherten Konfigurationen (vor dem Flashen vs. nach dem Flashen) zeigt keine Auffälligkeiten.

Edit: für heute Schluss, faxd-Segfault konnte ich bisher nicht neu provozieren.

Zuletzt geändert vor 3 Jahren von er13 (vorher) (Diff)

comment:73 Geändert vor 3 Jahren durch CarstenSchuette

Dieser segfault ist aber genau der, der hier auch schon in Kommentar Nr. 30 beschrieben steht.

Zuletzt geändert vor 3 Jahren von CarstenSchuette (vorher) (Diff)

comment:74 Geändert vor 3 Jahren durch Liggy

faxd erhält den Segmentation fault beim Zugriff auf die Adresse 0x7553746f. Ist eigentlich schon irgendwem aufgefallen, dass dieser Wert in ASCII umgewandelt "uSto" bedeutet? Fehlt nur noch das "r01" dahinter. Ich denke hier läuft entweder ein indirekter Speicherzugriff falsch oder die Zieladresse wird irgendwo überschrieben.

comment:75 Geändert vor 3 Jahren durch CarstenSchuette

Kann das also sein, dass der faxd nur abstürzt, wenn man eingestellt hat, dass die empfangenen Faxe auf dem USB-Medium gespeichert werden sollen? Ich bin unterwegs und kann das leider zurzeit nicht testen….

comment:76 Geändert vor 3 Jahren durch colonia27

Das würde meine Beobachtung aus comment 45 erklären. Denn bei abgezogen Stick/Platte werden Fax und AB-Nachrichten ja intern gespeichert. Normalerweise landen die bei mir nämlich ebenfalls auf der HDD.
Testen kann ich aber nicht, liege am Strand :-)

Zuletzt geändert vor 3 Jahren von colonia27 (vorher) (Diff)

comment:77 Geändert vor 3 Jahren durch Cas1711

Falls auch jemand wegen z.B. FHEM auch die funktionierende debug.cfg braucht.
Ich hab nach http://freetz.org/wiki/help/howtos/development/repack_fw und http://www.ip-phone-forum.de/showthread.php?t=269844&p=2005841&viewfull=1#post2005841 die debug.cfg wieder aktiviert und es funktioniert.
Nach dem booten der Box läuft FHEM wieder.
(Ich braucht den Start des FHEM Servers wegen Urlaub jetzt)

comment:78 Geändert vor 3 Jahren durch CarstenSchuette

Ja, das passt. Bei mir crasht der faxd bzw. das WebIF, sobald ich sage, dass die eingehenden Faxe auf dem USB-Speicher angelegt werden sollen. Lasse ich sie "intern ablegen", funktioniert auch der Faxdienst.

Der Anrufbeantworter kann seine Nachrichten aber problemlos auf dem Stick speichern, nur der Faxdienst mag nicht.

Zuletzt geändert vor 3 Jahren von CarstenSchuette (vorher) (Diff)

comment:79 Antwort: Geändert vor 3 Jahren durch JMC

Bei mir scheint aber auch der AB zank zu machen. Hab meine Produktive Box eben auf 6.20 gehoben (Fax vorher gelöscht) - jetzt habe ich tatsächlich das Verhalten, dass hier beschrieben wird (Web-IF nicht mehr erreichbar und dann rebootet die Box 2-3 Minuten später) (VORHER: Box rebootet nach ~1 Minute auch ohne Aktion im Web-IF von alleine) - ich begebe mich vielleicht später mal ran und probiere rauszufinden ob ich es auf der Testbox nachstellen kann.

Sep 16 10:13:49 fritz user.err ctlmgr[2131]: /var/flash/crash.log opened
Sep 16 10:13:49 fritz user.err ctlmgr[2131]: 2014-09-16 10:13:49(1) [Segmentation fault] /usr/bin/avm/ctlmgr(2131) CRASHED at strcmp+0xc (/lib/libc.so.0 at 00038a2c) accessing 0+0x7553746e (/lib/libhtmltemplate.so.0 at 49c2246e)
Sep 16 10:13:49 fritz user.err ctlmgr[2131]: SIGNO 11 ERRNO 0 CODE 1
Sep 16 10:13:49 fritz user.err ctlmgr[2131]: Version: 06.20
Sep 16 10:13:49 fritz user.err ctlmgr[2131]: Watchdog triggered 7 seconds ago
Sep 16 10:13:49 fritz user.err ctlmgr[2131]: No bugmsg
Sep 16 10:13:49 fritz user.err ctlmgr[2131]: ze: 00000000 at: 00000001 v0: 2ae5da20 v1: 0000006f
Sep 16 10:13:49 fritz user.err ctlmgr[2131]: a0: 7fccea87 a1: 7553746f a2: 75537470 a3: 7fccea88
Sep 16 10:13:49 fritz user.err ctlmgr[2131]: t0: 00000000 t1: 5417f13d t2: 8071bae0 t3: 00000001
Sep 16 10:13:49 fritz user.err ctlmgr[2131]: t4: 80000000 t5: 00000073 t6: 0000005b t7: 333d2f64
Sep 16 10:13:49 fritz user.err ctlmgr[2131]: s0: 2b311be0 s1: 2b879188 s2: 004b0000 s3: 2b5bd040
Sep 16 10:13:49 fritz user.err ctlmgr[2131]: s4: 00000000 s5: 00000000 s6: 00000001 s7: 2b5b97b8
Sep 16 10:13:49 fritz user.err ctlmgr[2131]: t8: 00000000 t9: 2ae5da20 k0: 00000001 k1: 00000000
Sep 16 10:13:49 fritz user.err ctlmgr[2131]: gp: 2b311be0 sp: 7fcce980 fp: 004d0000 ra: 2b2f5cb9
Sep 16 10:13:49 fritz user.err ctlmgr[2131]: FA 7553746e 0+0x7553746e (/lib/libhtmltemplate.so.0 at 49c2246e)
Sep 16 10:13:49 fritz user.err ctlmgr[2131]: PC 2ae5da2c strcmp+0xc (/lib/libc.so.0 at 00038a2c)
Sep 16 10:13:49 fritz user.err ctlmgr[2131]: RA 2b2f5cb8 0+0x2b2f5cb8 (/usr/share/ctlmgr/libtamconf.so at 00002cb8)
Sep 16 10:13:49 fritz user.err ctlmgr[2131]: Code: 90830000  24870001  24a60001 <14600003> 90a20000  03e00008  00021023  00e02021  1062fff7 
Sep 16 10:13:49 fritz user.err ctlmgr[2131]: [bt]  2b2f5cb4 [2b2f5c06] <0+0x2b2f5c07>+0xae (/usr/share/ctlmgr/libtamconf.so at 00002c06)
Sep 16 10:13:49 fritz user.err ctlmgr[2131]: [bt]  2b2f5fbc [2b2f5d1e] <0+0x2b2f5d1f>+0x29e (/usr/share/ctlmgr/libtamconf.so at 00002d1e)
Sep 16 10:13:49 fritz kern.emerg kernel: [  219.000000] AVM_WATCHDOG_ungraceful_release: handle 4 (ctlmgr) still registered!
Sep 16 10:14:13 fritz kern.info kernel: [  242.430000] /proc/tffs: info request: success

Edit:
Hab die beiden (AVM roten…) 7390 die ich noch mit Freetz in Betrieb hab gestern Abend noch auf 6.20 gehoben. Da ist sogar jede menge remove kram an (weil sonst kein Platz ist) und das funktioniert ohne Probleme. Kein Reboot, web-if funktioniert super. Die einzige Box mit der ich das Nachstellen kann ist meine 1&1 7490 deren Branding auf AVM gesetzt worden ist. Brat mir doch einer ein Storch!

Zuletzt geändert vor 3 Jahren von JMC (vorher) (Diff)

comment:80 als Antwort auf: ↑ 79 Geändert vor 3 Jahren durch KingTutt

Replying to JMC:

Edit:
Hab die beiden (AVM roten…) 7390 die ich noch mit Freetz in Betrieb hab gestern Abend noch auf 6.20 gehoben. Da ist sogar jede menge remove kram an (weil sonst kein Platz ist) und das funktioniert ohne Probleme. Kein Reboot, web-if funktioniert super. Die einzige Box mit der ich das Nachstellen kann ist meine 1&1 7490 deren Branding auf AVM gesetzt worden ist. Brat mir doch einer ein Storch!

Es gibt aber auch einen anderen Bericht, wo es auch bei einer 7390 auftritt, siehe IPFF. Auch dort crashed des ctlmgr in einem Stringvergleich im Zusammenhang mit der libhtmltemplate.so.0

Es betrifft vermutlich nicht nur eine spezielle HW sondern das FW Release 06.20 mit einer bestimmten Konfiguration. Zumindest gibt es inzwischen Berichte über 7390 und 7490.

comment:81 Geändert vor 3 Jahren durch PeterPawn

Kann jemand etwas zu den Einstellungen des Anrufbeantworters der Box im Kontext dieses Fehlers sagen ?

Dabei meine ich nicht so sehr das Problem mit dem faxd, sondern den aus dem falschen Speicherzugriff beim strcmp in der libtamconf.so resultierenden segfault (zum faxd-Error ist bisher zu wenig zu sehen).

Das "Beschimpfen" der libhtmltemplate.so ist ja eher zufällig, das ist halt irgendeine Lib an der Adresse, wo a1 beim Aufruf des strcmp mehr oder weniger hinzeigt (das 6e vs. 6f würde ich auf alignment schieben). Wenn man aber davon ausgeht, daß strcmp sicherlich mit zwei "Operanden" arbeiten muß (irgendwas mit irgendwas vergleichen), sollte man schon mindestens zwei Operanden erwarten und das bei MIPS (per Konvention) auch in den Registern a0 und a1.

Bei Berücksichtigung des Hinweises aus 74, daß es sich bei "7553746f" um "uSto" in hex handelt, sieht das doch wirklich sehr nach einem vagabundierenden Pointer aus und alle Abstürze (libtamconf, libtelcfg und faxd) haben irgendetwas mit der potentiellen Speicherung von Nachrichten/Faxen/Ansagen auf einem USB-Volume zu tun.

Wenn irgendwo in den erwähnten Libs (in einer gemeinsam genutzen Subroutine in den Quellen) beim Zugriff auf den potentiellen Pfad des USB-Speichers derselbe Fehler lauert (also schon im AVM-Source), dann kommt vielleicht wirklich bei allen diesen Libs etwas dahingehend durcheinander, daß ein Pointer falsch übergeben wird. Da braucht ja bloß jemand fest davon auszugehen, daß der erste "Pfadteil" nach dem NAND (also das hinter /var/media/ftp) in jedem Fall mit einem Großbuchstaben beginnt (bei AVM auch eher nur implizit der Fall über den Vendor-Name, wenn ich es richtig gesehen habe) und das in einem regulären Ausdruck nicht richtig abfangen.

Tritt denn das Problem auch auf, wenn man auf das "Umbenennen" der USB-Pfade verzichtet und die AVM-Namensgebung beibehält, also FREETZMOUNT wegläßt (falls das überhaupt geht, da habe ich keine Ahnung) ?
Alternativ könnte man ja auch mal versuchen, ein eigenes Volume mit GROSSBUCHSTABEN einzuhängen (dann muß das aber auch das zur Speicherung benutzte sein und es sollte auch mind. ein Anruf/Fax dort abgelegt sein), um das als mögliches Fehlerquelle auszuschließen.

Daß der Absturz mal beim Zugriff auf das AVM-GUI an sich und manchmal erst beim Zugriff auf eine der Telefoniefunktionen auftritt, würde ich - ad hoc - dann auch erst einmal auf die Umstände schieben, also auf Nachrichten auf dem AB oder in der Fax-Box, die in der Anrufliste die entsprechenden Buttons darstellen oder auch Nachrichten auf dem AB, die dann in der Übersichtsseite unten rechts beim AB schon einen Zugriff auf den USB-Speicher auslösen.
Für mich sieht das im Kontext der verschiedenen Fehlerstellen nach dem Vergleich eines in der Anrufliste gespeicherten Pfades mit den gemounteten Volumes aus, um die entsprechenden Links zum Anhören/Ansehen zu generieren oder auch auszulassen, falls das Volume nicht verfügbar ist.

Das sind aber zugegebenermaßen alles nur theoretische Überlegungen, ich kann leider nicht selbst testen (bzw. genauer: ich will eigentlich nicht, da ich selbst kein Freetz-Image verwende).

comment:82 Geändert vor 3 Jahren durch JMC

Fax ist bei mir raus, ich habe noch den AB drin mit Speicherung auf USB. Bei mir stürzt die Box reproduzierbar jedesmal - und wirklich JEDES mal (also sagen wir so, ich habs 18 mal getestet… sagen wir mal mir war langweilig und ich hab das mal testen wollen von remote aus) ab wenn ich auf Telefonie → Telefoniegeräte gehe. Ping und Internet geht, nach ein paar Minuten rebootet scheinbar ein Watchdog dann die Box weil das Webif weg ist.

comment:83 Geändert vor 3 Jahren durch PeterPawn

Zeit für Fehlersuche per IRC ? Jetzt ?

Das Reboot ist logisch … es stürzt ja der ctlmgr ab und der ist über watchdog abgesichert. Da der auch das Webinterface macht, reagiert die Box nicht mehr. Allerdings sollte ein per Telnet erneut gestarteter ctlmgr den Restart per Watchdog sogar abwenden können (hängt ein wenig von der konkreten Reihenfolge der Timer ab).

Zuletzt geändert vor 3 Jahren von PeterPawn (vorher) (Diff)

comment:84 Geändert vor 3 Jahren durch JMC

So, Workaround gefunden der nachstellbar bei mir das Problem löst: den Stick nochmal als UStor01 mounten wie von PeterPawn vermutet. Haben das gerade mal getestet und bei mir klappt es danach ohne weitere Probleme. Ich habs jetzt mal in meine rc.custom geschrieben damit ich es auch ja nicht vergesse ;)

Bitte mal die anderen testen ob das auch hilft

mkdir /var/media/ftp/UStor01 && mount /dev/sda1 /var/media/ftp/UStor01/

Wobei sda1 natürlich davon abhängt, welches Volume da gemountet wird ;)

Zuletzt geändert vor 3 Jahren von JMC (vorher) (Diff)

comment:85 Geändert vor 3 Jahren durch PeterPawn

Das 'mkdir' davor nicht vergessen, besser wäre - wenn die Vermutung stimmt, daß AVM jetzt die Existenz der "Anhänge" abfragt, bevor der entsprechende Button/Link generiert wird und daß dabei die kühne Annahme getroffen wird, der "Volume"-Pfad müsse mit einem Großbuchstaben beginnen - eine (vorübergehende) Änderung des Mount-Mechanismus von FREETZMOUNT, damit der Anfangsbuchstabe des MP-Verzeichnisses automatisch richtig gesetzt wird, bis AVM da nachgebessert hat.
Ich weiß zwar nicht, ob es USB-Geräte mit einem kleingeschriebenen Vendor-Namen gibt, die dürften dann aber (immer vorausgesetzt, die angenommene Fehlerursache stimmt) ähnliche Probleme mit der originalen Firmware machen.

comment:86 Geändert vor 3 Jahren durch er13

Krass, wenn das mit dem Großbuchstaben stimmt :-(

Edit: auf meiner Testbox wird per Volumename gemountet und der Volumename besteht ausschließlich aus Kleinbuchstaben. Sowohl der AB als auch das Fax sind so konfiguriert, dass sie die Daten auf dem Stick speichern. Trotzdem führen bei mir die AVM WebIf-Aufrufe zu keinen Abstürzen → es muss noch irgendeine Bedingung zusätzlich erfüllt sein.

Zuletzt geändert vor 3 Jahren von er13 (vorher) (Diff)

comment:87 Geändert vor 3 Jahren durch JMC

Ja, es muss eine AB-Nachricht vorliegen. Ich habs natürlich auch entsprechend gegengetestet mehrfach mittlerweile und es bleibt nachstellbar so: AB-Nachricht da, kein Ordner mit großem U → ctlmgr crash. AB-Nachricht da, Ordner mit großem U da, alles gut.

Edit: Und die nicht vorhandene AB-Nachricht war auch der Grund warum ich das nicht nachstellen konnte auf der Testbox…

Zuletzt geändert vor 3 Jahren von JMC (vorher) (Diff)

comment:88 Antwort: Geändert vor 3 Jahren durch PeterPawn

@er13: Du hast offensichtlich Recht mit der Annahme, daß da noch mindestens eine weitere Rahmenbedingung erfüllt sein muß (zusätzlich zur vorhandenen oder auch nur vermuteten Datei auf dem USB-Volume beim AB/Fax).

Ein Test (ohne Freetz, aber mit Mounten nach Volume-Label mit der "originalen Firmware") bringt bei mir auch den Fehler erst einmal nicht zum Vorschein. Bei der Aufzeichnung von Anrufen war das Volume unter "system" gemountet, so stehen die Pfade dann auch in der /var/flash/fx_cg bei den entsprechenden Anrufen.

Nach dem Umbenennen des Volumes auf "sYstem" werden in der Übersichtsseite unten rechts beim AB die Links vollkommen normal korrigiert, d.h. sie zeigen anschließend auf "/var/media/ftp/sYstem/FRITZ…". In der Anrufliste allerdings bleiben die - nunmehr falschen und daher toten - Links bei "/var/media/ftp/system/FRITZ…" stehen (für Faxe und für AB-Messages).

Ich kann also mit der originalen Firmware den vermuteten Fehler nicht nachstellen.

In meinen Augen ist es jedoch bemerkenswert, daß an allen drei bisher aufgetretenen Absturzstellen (ich habe faxd, libtamconf und libtelcfg "auf dem Zettel") anhand eines Hexdumps der betreffenden Binärdatei ein Durchsuchen der Datei /var/media/devmap (i.d.R. ein Symlink auf /var/tmp/mediadevmap) mit dem Ausdruck "%*[^:]:%m[^.]\n" plausibel erscheint, den ich - auch ohne Kenntnis der dort genau eingesetzten Regexp-Engine - als die Suche nach dem Mountpoint eines Volumes in der Mapping-Datei interpretieren würde.

Diese Suche taucht offenbar in dieser Form auch nur an den bisherigen drei Absturzstellen auf. Ein grep über die gesamte Firmware fördert jedenfalls nur diese drei Dateien als Fundstellen zutage. Es wird allerdings wieder etwas "merkwürdiger" dadurch, daß diese Fundstellen auch in früherer Firmware schon vorhanden sind. Wenn ich es richtig verstehe, tritt das Problem aber vor 06.20 nicht auf, oder ?

Trotzdem werde ich das Gefühl nicht los, daß es wirklich mit dem anderen Mount-Verhalten beim FREETZMOUNT und der Ablage von Anhängen auf dem USB-Speicher zu tun hat (und zwar weniger im Moment der Ablage, als vielmehr beim "Wiederfinden" dieser Dateien, denn der Absturz erfolgt ja nicht beim Anruf, sondern beim GUI-Zugriff und auch da an "unterschiedlichen Stellen").

Hat denn jemand *ohne* FREETZMOUNT im Image das Problem bei sich reproduzieren können ? Oder kann mal jemand mit dem (reproduzierbaren) Problem das FREETZMOUNT aus seinem Image werfen als Test ?

Der einzige augenfällige Unterschied beim Mounten zwischen der neuen AVM-Implementierung (udev-mount-sd) und FREETZMOUNT, das auf der alten Implementierung (run_mount) basiert, ist der unterschiedliche Zeitpunkt der Benachrichtigung der anderen Komponenten über das neue Volume. Bei AVM wird erst das Mapping in der o.a. Datei eingetragen, bei FREETZMOUNT (in der libmodmount.sh) erst nach der Benachrichtigung der anderen Komponenten (die sich dann ihrerseits um die FRITZ-Verzeichnisse auf den Volumes kümmern).

Vielleicht hilft ja auch schon das Löschen einer vorhandenen Anrufliste … wann genau das Problem beim Suchen des Anhangs auftritt, ist ja nur "geraten"; das kann ein sehr alter nicht vorhandener Anhang genauso sein, wie ein "taufrischer". Wenn ich JMC gestern richtig verstanden habe, hat er bei sich zuerst die Anrufliste gelöscht, sich dann selbst angerufen und eine neue Nachricht auf dem AB hinterlassen und genau mit dieser kann er das Problem jetzt in der beschriebenen Weise reproduzieren (Groß- vs. Kleinschreibung). Das würde wieder für "neue" Nachrichten sprechen …

Vielleicht spielt ja aber auch das verwendete Dateisystem eine Rolle ? Ein NTFS-Volume wird eben nicht über ein normales Mount eingebunden, sondern über den Userland-Treiber und fuse. Kann mal jemand mit dem reproduzierbaren Problem dazu noch etwas schreiben ?

Die Reboots treten ja wohl auch nur bei den Leuten auf, bei denen der ctlmgr in libtamconf oder libtelcfg abstürzt. Der pure faxd ist an sich keine Komponente, die über einen Watchdog abgesichert wird, da bleibt der Reboot dann wohl aus und man sieht es nur im /dev/debug oder in der crash.log, wenn da etwas passiert. Jedenfalls solange nicht gerade im Moment des Absturzes eine Resource gelockt ist, die dann anderen Komponenten nach einer gewissen Zeit sauer aufstößt. Insofern könnte das Problem weiter verbreitet sein, als es den Anschein hat und nur bei vielen nicht bemerkt werden. Ein Blick in die /var/flash/crash.log könnte auch bei anderen hilfreich sein.

comment:89 Geändert vor 3 Jahren durch JMC

Ich habe nicht die gesamte Anrufliste gelöscht sondern die beiden vorhandenen AB-Aufnahmen (waren schon älter) bevor wir unsere Tests gemacht haben (weil in meiner Anrufliste sonst kein Fax oder AB-Nachricht da war). Dann habe ich mich selber angerufen, auf den AB gequatscht und konnte dann wie oben beschrieben das Verhalten nachstellen.

Mein Stick ist vfat, NTFS benutze ich nicht. Auftreten tut der Fehler seit einer Labor-Version 6.10-xxxxx (die ja dann zu 6.20 wurde), m.M. nach war es bei der ersten Laborversion noch nicht der Fall, kannn rückschauend aber auch an nicht vorhandenen AB-Nachrichten gelegen haben.

Ich werde mal versuchen mit meiner Testbox das ganze nachzustellen (jetzt weiß ich ja, was ich wahrscheinlich brauche) und kann dann da in ruhe testen und alles mögliche zu/weg patchen. Ich schau mal ob ich am WE dazu komme.

Edit:
Also wenn der Faxempfang auf USB aktiv ist schmiert nicht einfach der ctlmgr ab und rebootet die Box nach einer Weile sondern die Box rebootet im Kreis - ca. nach 30 Sekunden seit dem ersten Ping. Das konnte ich jetzt an meiner Testbox nachstellen als ich dann auch mal einen USB-Stick angeschlossen habe (gleiches Image wie auf der produktiven Box, also mit Freetzmount). Das gleiche image nochmal ohne FREETZMOUNT gebaut ergibt übrigens den gleichen Fehler (zumindest an der Stelle mit dem Faxempfang)

Hier hilft das von oben mit UStor01 scheinbar nicht, probiere jetzt mal in den paar Sekunden in denen das WebIF geht den Faxempfang zu deaktivieren.

Edit 2:
Gleiche Ausgangssituation für alles nachfolgende: in der Anrufliste anrufe auf dem AB (allerdings nicht angezeigt in der Liste der AB-Nachrichten auf der Startseite da export der Produktivbox)

freetzmount an und KEIN Ordner UStor01:

  • ctlmgr crash bei Telefonie → Telefoniegeräte/Eigene Rufnummern

freetzmount an und Ordner UStor01 als SYMLINK auf uStor01 gemacht:

  • ctlmgr crash bei Telefonie → Telefoniegeräte/Eigene Rufnummern

freetzmount an und Ordner UStor01 VORHANDEN (nicht gemountet oder gesymlinkt):

  • ctlmgr crash bei Telefonie → Telefoniegeräte/Eigene Rufnummern

freetzmount an und Ordner UStor01 GEMOUNTET:

  • KEIN ctlmgr crash bei Telefonie → Telefoniegeräte/Eigene Rufnummern

freetzmount AUS:

  • KEIN ctlmgr crash bei Telefonie → Telefoniegeräte/Eigene Rufnummern

Es ist also m.M. nach Freetzmount das mit dem kleinen u am Anfang dazu führt.

Zuletzt geändert vor 3 Jahren von JMC (vorher) (Diff)

Geändert vor 3 Jahren durch er13

comment:90 Geändert vor 3 Jahren durch er13

@JMC: verstehe ich es richtig, Deine Tests lassen sich wie folgt zusammenfassen:

  • ein Dummy-Verzeichnis/Symlink, dessen Name mit einem Großbuchstaben beginnt, hilft nicht
  • ein Symlink, dessen Name mit einem Großbuchstaben beginnt und der auf den echten Mountpoint zeigt, hilft ebenso nicht
  • der einiz funktionierende Workaround ist - es muss sichergestellt werden, dass der Name des echten Mountpounts mit einem Großbuchstaben beginnt

Der oben angehängte Patch verändert das Verhalten von FreetzMount dahingehend, dass das Volume-Label uppercased wird (erstmal nur als Hack). Könntet Ihr bitte testen, ob es das Problem sicher bei allen workaroundet.

comment:91 Geändert vor 3 Jahren durch RoiDanton

Ich habe hier ein ganz ähnliches Problem. Mit Freetz 11860 und AVM 6.05 auf der 7490 alles super. Sobald ich auf 6.20 aktualisiere (zuerst 12339 im August, heute mit 12463) startet die Fritzbox kurz nach dem Reboot neu, was sich dann endlos wiederholt. An den Einstellungen habe ich nichts geändert, weder für das neue Image noch die Settings von Fritz und Freetz.

Interessant ist: Sobald ich den USB-Stick abstecke, bleibt der Reboot aus! Auf dem USB Stick werden AB und Faxe gespeichert sowie das Freetz Swap File. External habe ich nicht.

Habe mir nun nicht alles hier genau durchgelesen, daher weiß ich nicht genau, ob es nicht genau so eine Schilderung schon gibt. Falls ja, bitte entschuldigt.

Ich mache mir nun ein neues Image mit 6.05 und der aktuellen Freetz Build. Schade im Moment, hätte gerne die 6.20 laufen.

comment:92 Geändert vor 3 Jahren durch JMC

@er13
Ja, richtig. Entweder beginnt der Mount direkt mit einem Großbuchstaben oder aber es wird (sehr unschön wie bei mir) zweimal gemountet

@RoiDanton
Ja, das ist genau das Problem das hier mehrfach beschrieben ist ;)

Edit:
Der Patch führt bei mir zu /­var/­media/­ftp/­UUStor01 als Mountpoint. Funktioniert aber ohne Probleme. Also den kleinen Schönheitsfehler noch weg dann wärs eigentlich ok. Bricht natürlich alle alten Pfade, ich werd auf meinen Boxen dann links anlegen von den alten Ordnernamen auf die neuen, da meine Backup-Script etc… das so drin haben.

Zuletzt geändert vor 3 Jahren von JMC (vorher) (Diff)

Geändert vor 3 Jahren durch er13

der etwas bessere Workaround, macht nur den ersten Buchstaben groß, behandelt sowohl "mount per Label" als auch "mount per CustomPrefix"

comment:93 Geändert vor 3 Jahren durch er13

So, der Schönheitsfehler (es war allerdings ein richtig krasser Denkfehler meinerseits ;-)) sollte in der Version 2 des Patches behoben sein. Könntet Ihr bitte testen, ob es Abstürze gibt, wenn man FreetzMount auf "Mount by Label" einstellt? Danke!

comment:94 Antwort: Geändert vor 3 Jahren durch JMC

Mit dem v2 Patch ist es richtig. Test mit "Partitionsname (falls vorhanden) als Mountpoint nutzen." war erfolgreich, keine Probleme. Hier war der Name dann auch komplett großgeschrieben in meinem Fall.

comment:95 als Antwort auf: ↑ 39 Geändert vor 3 Jahren durch er13

Replying to CarstenSchuette:

Mit der Original uClibc startet die Box, die Telefonieeinstellungen lassen sich aufrufen und der integrierte Faxempfang lässt sich einrichten, ohne dass die Box abschmiert. Die integrierten Anrufbeantworter funktionieren auch.

Mit der Aussage hast Du mich auf die falsche Fährte geleitet. Dass der Austausch von uClibc scheinbar hilft, kann vermutlich dadurch erklärt werden, dass die externen Datenträger in dieser Konstellation einfach nicht gemountet wurden? War das so? Kannst Du Dich noch erinnern?

comment:96 als Antwort auf: ↑ 94 ; Antwort: Geändert vor 3 Jahren durch er13

Replying to JMC:

Mit dem v2 Patch ist es richtig. Test mit "Partitionsname (falls vorhanden) als Mountpoint nutzen." war erfolgreich, keine Probleme. Hier war der Name dann auch komplett großgeschrieben in meinem Fall.

Ich hoffe, dass Dein Label nicht "USTOR01" hieß, sondern wirklich was komplett anderes (insbesondere mit dem ersten Buchstaben ungleich U). Der Name sollte nur dann "komplett großgeschrieben" sein, wenn das Label des Datenträgers auch komplett groß ist, ansonsten sollte der Case nur des ersten Buchstaben geändert werden. Wenn das nicht der Fall ist, dann ist noch ein Bug drin, den ich aber vom Lesen her nicht sehe.

comment:97 als Antwort auf: ↑ 96 Geändert vor 3 Jahren durch JMC

Replying to er13:

Ich hoffe, dass Dein Label nicht "USTOR01" hieß, sondern wirklich was komplett anderes (insbesondere mit dem ersten Buchstaben ungleich U). Der Name sollte nur dann "komplett großgeschrieben" sein, wenn das Label des Datenträgers auch komplett groß ist, ansonsten sollte der Case nur des ersten Buchstaben geändert werden. Wenn das nicht der Fall ist, dann ist noch ein Bug drin, den ich aber vom Lesen her nicht sehe.

Es war was ganz anderes. Ich sage zu 99% auch, dass das Label komplett groß war (ROMPAQ durch das formatieren vom Stick mit nem HP Flash Utility) aber kanns derzeit nicht überprüfen da ich nicht in der Nähe bin, wird aber so sein schätze ich.

comment:98 Antwort: Geändert vor 3 Jahren durch blackstar

Hallo
mit Deinem Patch funktioniert es jetzt auf der 7390 nur z.B. bei mir HDD als mount Point mag er nicht ist definitv groß geschrieben.

Gruß Black

comment:99 als Antwort auf: ↑ 98 Geändert vor 3 Jahren durch er13

Replying to blackstar:

nur z.B. bei mir HDD als mount Point mag er nicht (ist definitv groß geschrieben).

"Mag er nicht" ist eine sehr detaillierte Beschreibung. Ich hoffe, Du erwartest nicht, dass ich auf Basis dieser einen Fix bereitstelle (irgendwelche konkreten Fehlermeldungen, hast Du versucht es in der command-line manuell zu mounten, usw).

Ansonsten ändert man Workaround nichts in Bezug darauf, ob "er HDD mag oder nicht". Wenn es jetzt mit HDD nicht funktioniert, dann hat es auch früher (i.e. ohne Patch) nicht funktioniert. Daher streng genommen, gehört gar nicht in dieses Ticket.

Und nochmal zur Klarstellung. Alles, was mein Patch macht, ist - er stellt sicher, dass der erste (und nur der erste) Buchstabe des Mountpoints ein Großbuchstabe ist, die restlichen Buchstaben werden nicht verändert, bleiben also so wie sie sind. Das Label / das CustomPrefix dürfen durchaus auch Kleinbuchstaben enthalten.

comment:100 Geändert vor 3 Jahren durch er13

In 12487:

FreetzMount:

  • ensure the 1st character of the mount point is an upper-case one
  • this reported to workaround stability problems for the 6.20 firmware series (looks like some strange assumption in AVM binary code), see #2499 for details
  • refs #2499

BIG FAT WARNING: all users using mount points with lower-case characters should adjust their configurations after updating to this revision

comment:101 Geändert vor 3 Jahren durch er13

Es wäre nicht schlecht, wenn neben JMC und blackstar noch ein paar mehr Leute (kroki0815, Cas1711, CarstenSchuette, colonia27, KingTutt) bestätigen würden, dass die in r12487 eingecheckten Änderungen das Problem für sie workarounden. Wenn das der Fall ist, dann würde ich "Freetz support is unstable" bei 6.20 entfernen (dieses Ticket war der Grund, warum ich es eingeführt habe).

Weiterhin würde ich Euch bitten, zu kontrollieren, ob damit auch die faxd-Probleme verschwinden (dies ist insofern schwieriger, da diese ja zu keinen Reboots geführt haben, sondern lediglich zum Befüllen von /var/flash/crash.log).

Danke!

comment:102 Geändert vor 3 Jahren durch JMC

@er13: Bei mir haben die faxd Probleme zum reboot der Box nach ein paar Sekunden uptime geführt. Ohne vorherigen crash des ctlmgr und ansprechenden watchdog-reboot. Sowohl auf der Produktiven als auch auf der Testbox (wenn USB Stick vorhanden ist und das speichern auf USB-Stick an war)

Die aktuelle r12487 werde ich gleich testen und dann meinen Post editieren

comment:103 Geändert vor 3 Jahren durch er13

@JMC: r12487 ist identisch mit freetzmount_capitalized_mountpoints.v2.patch, kannst Dir den Aufwand also sparen, da Du ja den Patch schon getestet hast.

comment:104 Geändert vor 3 Jahren durch blackstar

Hallo er13 sorry für die saloppe Fehlerbeschreibung :(
was ich meinte ich hatte
Partitionsname (falls vorhanden) als Mountpoint nutzen.
genutzt der Mountpoint hieß also nicht "uStor01" sondern "HDD"
jetzt habe ich
Partitionsname (falls vorhanden) als Mountpoint nutzen. entfernt und den Standart Mountpoint (UStor01) verwendet.
damit funktioniert es sowohl auf der 7390 (1&1) und 7490 (avm) sauber und zuverlässig.
@er danke für den Fix

edit: nach clean der Config gehts doch

Zuletzt geändert vor 3 Jahren von blackstar (vorher) (Diff)

comment:105 Geändert vor 3 Jahren durch JMC

Möchte man den Faxempfang einrichten mit speichern auf dem USB-Stick schmiert der ctlmgr ab. Intern ablegen einrichten und danach probieren zu ändern auf USB-Stick schmiert ctlmgr ebenfalls ab. Daher kann ich leider nicht testen ob der Faxempfang auf USB jetzt meine Boxen immer noch abschießt

Edit:
Doch noch einen Weg gefunden, alten export eingespielt der noch den Faxempfang auf USB drin hatte. Damit stürzt die Box nach dem booten innerhalb von ~30 Sekunden ab. Ich bezweifel (ohne Beweise dafür zu haben natürlich :)) allerdings, dass es das gleiche ctlmgr Problem ist, eben weil die Box so schnell rebootet. Klick auf Telefoniegeräte bzw. eigene Rufnummern bringt die Box scheinbar auch sofort zum reboot - kann ich aber nicht genau bestätigen weil die reboots einfach zu schnell sind und nur zu 99% sagen.

Zuletzt geändert vor 3 Jahren von JMC (vorher) (Diff)

comment:106 Geändert vor 3 Jahren durch er13

@JMC: könntest Du bitte Freetz-Mount in den Modus "Mount per Custom-Prefix" umstellen und als Prefix das Standard-Prefix von AVM eingeben? Damit würdest Du quasi Freetz-Mount aus dem Image "entfernen" bzw. das Verhalten von diesem sollte in dem Modus 1-zu-1 dem von AVM entsprechen.

Wie verhält sich das System in diesem Modus? Kannst Du Fax-Empfang einrichten?

comment:107 Geändert vor 3 Jahren durch JMC

Was ist das Standard-Prefix? Ich hab seit ewigkeiten Freetzmount und noch nie drauf geachtet wie es ohne Freetzmount ist :(

Edit:
Hatte noch einen Ordner CHIPSBNK-v3-3-8-8-01 auf dem Speicher, hab also CHIPSBNK-v3-3-8-8- als prefix eingestellt und es wird jetzt in CHIPSBNK-v3-3-8-8-01 gemountet. Dann kann ich Telefoniegeräte klicken ohne direkten reboot, kurze Zeit später rebootet die Box aber trotzdem. Zeit hat aber gereicht um den per export eingerichteten Faxempfang zu löschen, werde jetzt mal probieren neu einzurichten.

Edit2:
Also einrichten geht auch in der Kombi nicht. Der Stick wird ohne Freetzmount als CHIPSBNK-v3-3-8-8-01 eingebunden. So hab ich es jetzt auch mit Freetzmount laufen, aber der Faxempfang is noch kaputt (lässt sich nicht auf USB einrichten und wenn auf USB eingerichtet führt zur Reboot-Schleife)

Zuletzt geändert vor 3 Jahren von JMC (vorher) (Diff)

comment:108 Geändert vor 3 Jahren durch er13

@JMC: ich genauso ;-) ich glaube es ist UStor oder vielleicht inzwischen auch USTOR…

Habe jetzt Deinen Edit gelesen. Könnte sein, dass es inzwischen der Name des Herstellers ist, damit gibt es wohl kein Standard-Prefix mehr…

comment:109 Geändert vor 3 Jahren durch JMC

Oh, hab deine Antwort nicht gesehen, gibt noch ein Edit2 oben.

Also einrichten geht auch in der Kombi nicht. Der Stick wird ohne Freetzmount als CHIPSBNK-v3-3-8-8-01 eingebunden. So hab ich es jetzt auch mit Freetzmount laufen, aber der Faxempfang is noch kaputt (lässt sich nicht auf USB einrichten und wenn auf USB eingerichtet führt zur Reboot-Schleife)

comment:110 Geändert vor 3 Jahren durch er13

@JMC: jetzt hast Du mich durch Deine neuen Testerkenntnisse etwas verwirrt. Könntest Du bitte nochmal kurz zusammenfassen, welche Probleme nun durch r12487 workaroundet/behoben werden und welche weiterhin bestehen? Danke!

comment:111 Geändert vor 3 Jahren durch JMC

Ist auch total verwirrend:
r12487 bewirkt im zusammenspiel mit dem default Mountpunkt UStor01:

  • Ist kein Faxempfang auf USB eingerichtet lässt sich das Web-IF in allen Punkten aufrufen und bedienen
  • Einrichten des Faxempfang auf USB lässt sich nicht abschließen, ctlmgr stürzt ab
  • Ist der Faxempfang auf USB eingerichtet rebootet die Box sofort beim Klick auf Telefoniegeräte/Eigene Rufnummern (nicht wie der ctlmgr Crash den wir weiter oben hatten wo telnet/ssh noch geht und man ctlmgr von Hand starten kann)
  • Die Box rebootet unabhängig davon nach ca. 30 Sekunden neu wenn der Faxempfang auf USB eingerichtet ist

Ändere ich den Mountpunkt in den Standard Mountpunkt (bei meinem Stick ist es CHIPSBNK-v3-3-8-8-01) mit r12487

  • Einrichten des Faxempfang auf USB lässt sich nicht abschließen, ctlmgr stürzt ab
  • Ist der Faxempfang auf USB eingerichtet lässt sich dsa Web-IF in allen Punkten aufrufen und bedienen
  • Die Box rebootet unabhängig davon nach ca. 30 Sekunden neu wenn der Faxempfang auf USB eingerichtet ist
Zuletzt geändert vor 3 Jahren von JMC (vorher) (Diff)

comment:112 Geändert vor 3 Jahren durch er13

In 12491:

FreetzMount:

  • limit r12487 to 6.20 & 6.10 (=6.20 labors) firmware series
  • refs #2499

comment:113 Geändert vor 3 Jahren durch kwtux

Habe mit der 7490 6.20 / 12495 genau das gleiche Problem.

  • Crash beim Zugriff auf "Telefoniegeräte"
  • Fax und AB Nachrichten werden auf einem Stick gespeichert.
  • Freetz mount Point fuer den Stick ist: "/­var/­media/­ftp/­uStor01"
  • Bin wieder zurueck auf 6.05 und alles funktioniert ohne Probleme

comment:114 Antwort: Geändert vor 3 Jahren durch JMC

Die Frage ist ja warum der mount Point nicht mit einem großen U beginnt denn das sollte in r12495 ja schon drin sein (dann ist das von dir beschriebene Problem nämlich weg)

comment:115 Geändert vor 3 Jahren durch Liggy

Ich kenne mich leider nicht so mit den Internas der Fritzbox und von Freetz aus. Aber mittlerweile hat AVM den Sourcecode der 6.20 Firmware für die 7490 veröffentlicht ftp://ftp.avm.de/fritz.box/fritzbox.7490/x_misc/opensrc/source-files-FRITZ.Box_7490-06.20.tar.gz. Könnte der bei der Problemlösung irgendwie weiterhelfen?

comment:116 als Antwort auf: ↑ 114 Geändert vor 3 Jahren durch kwtux

Replying to JMC:

Die Frage ist ja warum der mount Point nicht mit einem großen U beginnt denn das sollte in r12495 ja schon drin sein (dann ist das von dir beschriebene Problem nämlich weg)

Sorry mein Fehler: Der aktulle Mountpoint mit 6.0.5 ist: "/­var/­media/­ftp/­uStor01". Ich musste leider sehr schnell wieder zurueck zu einem stabilen System. Kann also durchaus sein, dass der Mountpoint mit "U" gesetzt war. Der Patch ist auf jeden Fall in em r12495 Build enthalten (habe kurz nachgeschaut). Dennoch habe es einen Crash sobald ich auf Telefoniegerate geclickt habe. Eventuell habe ich das ja ueberlesen… Es war noch ein Anruf auf dem AB. Keine Ahnung, ob vorher alles geloescht werden muss…

comment:117 Geändert vor 3 Jahren durch kwtux

sorry fuer die Typos…

also update von: "Firmware: 113.06.05 rev27580" (ohne Config-Änderung)
auf: Firmware "6.20 r12495" führt weiterhin zu einem Crash.

comment:118 Geändert vor 3 Jahren durch JMC

kannst du mal bitte r12487 auschecken und das bauen? Evtl. hat die Einschränkung die später reingekommen ist verhindert, dass der Patch angewendet wird. Mit der Version wurde mein uStor01 auf UStor01 geändert, und das ist richtig und so stürzt die Box auch nicht ab, wenn sie ohne klick auf eine der Sachen im webif mehrere Minuten stabil läuft (sprich nicht der Fax-Reboot zuschlägt)

comment:119 Antwort: Geändert vor 3 Jahren durch JMC

Ah, also ist der Mountpunkt unter 6.20 bei dir nicht bekannt, sondern du hast den Mountpunkt von 6.05 oben angegeben bei der Meldung, dass die 6.20 abschmiert. Dann ist der Grund für deinen Crash der Faxempfang auf den USB-Stick. Wenn du 6.20 benutzen willst änder es auf "Intern ablegen" und die Crashs sind weg

comment:120 als Antwort auf: ↑ 119 Geändert vor 3 Jahren durch kwtux

Replying to JMC:

Ah, also ist der Mountpunkt unter 6.20 bei dir nicht bekannt, sondern du hast den Mountpunkt von 6.05 oben angegeben bei der Meldung, dass die 6.20 abschmiert. Dann ist der Grund für deinen Crash der Faxempfang auf den USB-Stick. Wenn du 6.20 benutzen willst änder es auf "Intern ablegen" und die Crashs sind weg

Ja, das ist richtig. Ich muess erst einmal bei der 6.0.5 bleiben. Arbeite Fulltime Home-Office und möchte momentan keine weiteren Chrashes riskieren. Ich warte hier lieber auf eine finale Lösung. Im Moment bin ich dadurch leider keine große Hilfe. Benötigt wird freetz bei mir nur für dnsmasq (DHCP options für TFTP Boot) und quagga (RIP deamon). USBRoot ist nicht aktiviert.

comment:121 Geändert vor 3 Jahren durch kwtux

Sorry… und schon wieder habe ich etwas vergessen. Faxe werden bei mir nicht abgelegt sondern direkt per Mail weiter versendet. Der Button FAX ablegen ist bei mit nicht aktiviert. Keine Ahnung ob der USB-Stick als Cache genutzt wird bevor der Versand per Mail ausgeführt wird

comment:122 Geändert vor 3 Jahren durch JMC

Ah ok, wenn du nicht Speichern auf USB an hast sollte die Box auch eigentlich nicht von alleine rebooten wenn der Mountpunkt unter 6.20 UStor01 ist. Habe das gerade wie gesagt nochmal getestet mit alten und neuen FWs und kann das ganze reproduzieren und auch mit dem fix von oben beheben - solange kein USB-Speichern beim Fax-Empfang im Spiel ist.

Komisch…

comment:123 Geändert vor 3 Jahren durch kwtux

Das habe ich im groben konfiguriert: =============================================================================
Bezeichnung                     Anschluss
Int 1                               DECT
Int 2                               DECT
IP-Telefon 1                     LAN/WLAN
IP-Telefon 2                     LAN/WLAN
Anrufbeantworter 1           integriert (Aufzeichnen intern / Mail weiterleiten / Eigene Ansage)
Anrufbeantworter 2           integriert (Aufzeichnen intern / Mail weiterleiten / Eigene Ansage)
Anrufbeantworter Discard   integriert (kein Aufzeichnen / Nur Ansage)
Faxfunktion                     integriert  (nicht speichern Mail weiterleiten)
=============================================================================

USB-Gerät
=============================================================================
Typ Eigenschaften
Generic- SD/MMC USB-Speicher Gesamtkapazität: 14,81 GB Dateisystem: FAT Anschluss: USB 2.0, Geschwindigkeit: 480 Mbit/s =============================================================================

NAS (Online Speicher ist aktiviert)
=============================================================================
USB-Speicher uStor01 14,81 GB von 14,81 GB frei, verfügbar ist erstellt
=============================================================================

comment:124 Antwort: Geändert vor 3 Jahren durch er13

In 12507:

FreetzMount:

  • add support for the mount points naming scheme ${vendor}-${product}-${device_number}${partition_number} used by AVM as the default naming scheme since some time
  • refs #2499, refs #2572

comment:125 Geändert vor 3 Jahren durch er13

Wenn Ihr Namensgebung-Schema auf "Hersteller-Produkt als Präfix" einstellt, sollte sich FreetzMount was die Namen der MountPoints angeht genauso verhalten wie die Original-AVM-Firmware.

Ich wäre allen Betroffenen dankbar, wenn Ihr testen und Feedback geben würdet, inwieweit sich das Verhalten des Systems aufgrund der letzten FreetzMount-Anpassungen geändert hat. Welche Probleme sind verschwunden, welche bestehen weiterhin? Bisher hat sich leider nur JMC die Mühe gemacht…

comment:126 Geändert vor 3 Jahren durch blackstar

hallo
ich kann bei mir jetzt alle Punkte nurzen auch die AB übersich die bisher noch gezickt hatte
was mir aufgefallen ist wenn ich einen Telefonie Punkt anklicke bevor Freetz vollständig geladen ist bekomme ich den weißen Screen und es kommt zum Reboot

comment:127 als Antwort auf: ↑ 88 Geändert vor 3 Jahren durch er13

Replying to PeterPawn:

Der einzige augenfällige Unterschied beim Mounten zwischen der neuen AVM-Implementierung (udev-mount-sd) und FREETZMOUNT, das auf der alten Implementierung (run_mount) basiert, ist der unterschiedliche Zeitpunkt der Benachrichtigung der anderen Komponenten über das neue Volume. Bei AVM wird erst das Mapping in der o.a. Datei eingetragen, bei FREETZMOUNT (in der libmodmount.sh) erst nach der Benachrichtigung der anderen Komponenten (die sich dann ihrerseits um die FRITZ-Verzeichnisse auf den Volumes kümmern).

Hört sich so an, als sollten wir die AVM-Änderungen nachziehen. Um nicht aneinander vorbei zu reden, Du meinst diese Stelle? Der Code sollte früher - in etwa da - ausgeführt werden?

comment:128 Geändert vor 3 Jahren durch PeterPawn

@er13:

Ich denke, wir meinen beide dasselbe. Bei AVM läuft das in /etc/hotplug/udev-mount-sd irgendwo in der Nähe der Zeile 152.

Jedenfalls aktualisiert AVM in der aktuellen Firmware die DEVMAP vor allen Benachrichtigungen an die laufenden Dienste. Ob das wirklich mit dem Problem zusammen hängt ? Schaden kann die Änderung aber sicherlich auch nicht … aber ob das für ältere Firmware ein Problem darstellt, kann ich leider auch nicht testen.

Zuletzt geändert vor 3 Jahren von PeterPawn (vorher) (Diff)

comment:129 Geändert vor 3 Jahren durch kwtux

Habe nochmal mit dem build "7490_06.20-freetz-devel-12513.de_20140929-095847" probiert und erhalte immer noch einen reboot / crash mein klicken auf Telefoniegeraete.

comment:130 als Antwort auf: ↑ 124 Geändert vor 3 Jahren durch JMC

Replying to er13:

In 12507:

FreetzMount:

  • add support for the mount points naming scheme ${vendor}-${product}-${device_number}${partition_number} used by AVM as the default naming scheme since some time
  • refs #2499, refs #2572

Das hat bei meiner Testbox dazu geführt, dass beim ersten Start das Label als Mountpunkt benutzt worden ist statt der "alten" Einstellung festes Präfix.

  • Label komplett großgeschrieben, trotzdem schmiert ctlmgr ab.
  • Hersteller-Präfix komplett großgeschrieben, trotzdem schmiert ctlmgr ab.
  • Festes Präfix UStor (also UStor01), trotzdem schmiert ctlmgr ab.

r12497 funktioniert mit UStor ebenfalls nicht mehr.

Da das meine Testbox ist habe ich die eigentlich immer aus, und auch nicht mehr angehabt nach den letzten Tests. Jetzt bin ich mehr als baff… Ich werde nochmal noch ältere Versionen testen…

Edit:
r12487 funktioniert bei mir jetzt nur noch mit ${vendor}-${product}-${device_number}${partition_number - stelle ich wieder auf UStor01 funktioniert es - im Gegensatz zu früher - nicht mehr?!

Edit2:
Nachdem ich wieder auf UStor01 umgestellt hab geht das auch. Aber beim direkten downgrade von r12507 an runter auf r12497 und auf 12487 funktionierte es nicht. Erst das umstellen auf ${vendor}-${product}-${device_number}${partition_number und auf UStor zurück hat geholfen.

Zuletzt geändert vor 3 Jahren von JMC (vorher) (Diff)

comment:131 Geändert vor 3 Jahren durch PeterPawn

@all:

Ist denn JMC wirklich der Einzige, der das Problem auf seiner Box nachstellen kann ?

Die ursprüngliche Idee war es ja, daß AVM mit einem regulären Ausdruck und innerhalb dieses Ausdrucks mit einer "capturing group" das Auflösen des Mountpoints für den Speicher mit "alten" Faxen und AB-Nachrichten betreibt (anhand von Strings in den drei vom Fehler bisher betroffenen Libs/Bins vermutet) und dabei ein fehlendes "match" für diese Gruppe nicht richtig abgefangen wird, so daß anstelle eines Pointers auf einen Teil des Pfades nur "Garbage" im Parameter-Register a1 für den strcmp-Aufruf landet. Daraus resultiert dann der Zugriff auf die Adresse irgendwo bei 7553746F und das führt schließlich zum "segmentation fault". Soweit die Theorie, die erst einmal dem Anschein nach durch den Test von JMC bestätigt wurde. Das kann ja aber auch ein "false positive" gewesen sein … oder eine Kombination aus mehreren Faktoren, da sich ja auch mit der uLibc etwas getan hat bei einigen Problemkandidaten.

Dann ließ sich aber das Problem bei JMC durch Änderung von Groß- in Kleinschreibung und umgekehrt hervorrufen und auch wieder abstellen. Das - zusammen mit der Antwort von blackstar - führte dann zur Annahme, die Änderung würde eine Besserung bringen.

Habe ich bis hier etwas falsch verstanden oder falsch zusammengefaßt ?

Wenn nicht, bleiben ja immer noch die nicht näher beschriebenen Probleme beim Einrichten dex Faxempfangs auf einem USB-Stick (egal, wie der MP aussieht) und die Probleme von kwtux von heute morgen.

Da man ja mit der blanken Aussage "stürzt ab" nicht so richtig viel anfangen kann, meine Frage an die Betroffenen: Kann mal bitte jemand mit einem reproduzierbaren Problem die "crash.log"-Datei nach einem solchen Absturz sichern und hier anhängen ?

Wenn das am Ende zwei verschiedene Probleme sind (bisher war das alles mehr oder weniger dieselbe Ursache, nämlich daß beim strcmp-Aufruf ein "usto" in a1 stand anstelle einer "ordentlichen" Adresse für den Stringvergleich), dreht sich das Ganze hier nur im Kreis. Ansonsten war es wohl doch nicht die Ursache mit der Bezeichnung des MP und das ist alles nur heiße Luft bis hierher … dann sollte man aber auch systematisch weiter suchen und nicht nur durch "systematisches Probieren".

Wenn man von Anfang an die Meldungen noch einmal durchsieht, haben folgende Nutzer das Problem (oder eines mit sehr ähnlichen Symptomen) bisher bei sich gehabt:

kroki0815, Cas1711, CarstenSchuette, blackstar (auf einer 7390), JMC (konnte das Problem an- und abstellen mit der Änderung des MP, was jetzt aber auch nicht mehr funktioniert), colonia27, hawkeye80, er13 (faxd-Crash), frodo (im IPPF, auch eine 7390), RoiDanton, kwtux

Macht 11x Fehler, davon haben aber nur vier (fünf mit frodo im IPPF) ein passendes crash-Log vorzuweisen, das dann aber immer auf denselben Fehler hinauslief (s.o.). Mein Vorschlag steht weiter oben schon da, der Rest war mehr zur Begründung.

comment:132 Geändert vor 3 Jahren durch JMC

Ich hänge ein paar crash.logs gleich mal an. Da scheint aber noch irgendwas anderes im Busch zu sein - meine gestern funktionierende Config crasht heute den ctlmgr wieder. Ich habe nichts gemacht ausser die funktionierende Config gestern auszuschalten und heute morgen einzuschalten. Im ersten boot fliegt der ctlmgr dann ab bei den bekannten Stellen, dann starte ich die Box über das Freetz WebIF neu (ctlmgr restart bringt nichts, fliegt immer wieder ab) und anschließend funktioniert das WebIF auch an den bekanten Stellen. Ich werde jetzt von r12487 stückweise weitergehen (über r12497 zu r12513 und r12513 mit dem Patch für default UStor) und werde hier editieren.

@PeterPawn: Ich vermute die meisten nutzen es produktiv und haben daher nicht die Zeit/Lust das ganze ausführlich zu testen wie ich es mit der Testumgebung machen kann, ohne das es mich weiter stört oder Internet/Telefonie ausfallen. Wie man bei kwtux sieht ist er dann eher auf die alte Version zurück, weil er die Box nicht "erübrigen" kann

Edit:

Generell scheint es (bei mir) so zu sein, dass es beim ersten start nach einem Firmware-Update oder aus ausgeschaltetem Zustand (bis auf den letzten Test natürlich ;() zu einem ctlmgr crash führt. Daher vermutlich auch meine Verwirrung gestern.
Bei diesem Upgrade Versuch ist auch ohne den Patch die Einstellung auf Präfix geblieben bei mir, ist nicht auf Vendor umgesprungen.

Sehr detailiert sieht das dann so aus:
(Label ist in meinem Fall ROMPAQ)

  • r12487 eingestellt auf Prefix führt nach einschalten zu Crash
  • reboot gemacht
  • r12487 mit Prefix funktioniert, umgestellt auf Label
  • reboot gemacht
  • r12487 mit Label funktioniert
  • ausgeschaltet
  • r12487 eingestellt auf Label führt nach einschalten zu Crash
  • reboot gemacht
  • r12487 mit Label funktioniert, umgestellt auf Prefix
  • reboot gemacht
  • r12487 mit Prefix funktioniert
  • Upgrade auf r12497 (mit Prefix) mit reboot
  • r12497 eingestellt auf Prefix crasht
  • reboot gemacht
  • r12497 eingestellt auf Prefix funktioniert, umgestellt auf Label
  • reboot gemacht
  • r12497 mit Label funktioniert, umgestellt auf Prefix
  • reboot gemacht
  • Upgrade auf r12513 (mit Prefix) mit reboot
  • r12513 eingestellt auf Prefix crasht
  • reboot gemacht
  • r12513 eingestellt auf Prefix funktioniert, umgestellt auf Vendor
  • reboot gemacht
  • r12513 eingestellt auf Vendor funktioniert, umstellt auf Label
  • reboot gemacht
  • r12513 eingestellt auf Label funktioniert, umgestellt auf Prefix
  • ausgeschaltet
  • r12513 eingestellt auf Prefix funktioniert nach dem einschalten
Zuletzt geändert vor 3 Jahren von JMC (vorher) (Diff)

Geändert vor 3 Jahren durch JMC

ein paar Crashlogs

comment:133 Geändert vor 3 Jahren durch PeterPawn

@JMC:

Danke für den ausführlichen Test. Die Crash-Logs zeigen ja alle dasselbe Problem … a1 enthält keinen Pointer auf eine Zeichenkette, sondern die ersten 4 Zeichen des jeweiligen Mountpoint-Namens (das Label kann es ja nicht per se sein, da steht bei einigen Crashs ja auch "USto" drin).

Wenn das dann auch noch nach einem PoR mit schöner Regelmäßigkeit zum Crash führt, spricht es in meinen Augen eher für eine Race-Condition bei der Reihenfolge von irgendwelchen Aktionen im udev. Für den Absturz nach einen Update habe ich keine Idee, aber nach dem Einschalten befindet sich das USB-Subsystem ja erst einmal in einem anderen Zustand, als nach einen Neustart. Da gibt es definitiv einige Stellen (z.B. bei der Umschaltung eines GSM-Sticks), die in diesem Falle einen anderen Verlauf nehmen (ich gehe aber davon aus, daß Du keinen GSM-Stick mit SD-Card angeschlossen hast).

Ich würde jetzt erst einmal vorschlagen, daß er13 die Reihenfolge beim Mounten zwischen dem Eintrag in der DevMap und der Benachrichtigung der anderen Komponenten tauscht (das könnte ja genauso gut zum "mismatch" bei einem Regexp-Vergleich in der DevMap führen, wenn der Eintrag da einfach noch nicht drin steht in dem Moment, wo die Komponente ihn sucht) und JMC dann noch einmal testet, ob die "Startprobleme" damit vielleicht schon behoben sind. Ich will auch Eugene nicht die Arbeit zuschustern, aber dafür meinerseits einen Patch anzubieten, um die paar Zeilen etwas früher auszuführen, wäre sicherlich Unsinn …

Zuletzt geändert vor 3 Jahren von PeterPawn (vorher) (Diff)

comment:134 Geändert vor 3 Jahren durch er13

Es ist sehr unwahrscheinlich, dass ich vor So. dazu komme - habe einen Wiesn-Besuch…

comment:135 Geändert vor 3 Jahren durch JMC

Richtig, kein GSM-Stick und erst recht keinen mit mSD.

Mich wundert es, dass es nach dem letzten PoR nicht so geklappt hat wie die anderen male. Vielleicht ist hier auch nur ein etwas anderes Timing (langsamere/schnellere Initialisierung des USB-Sticks oder ähnliches) dafür verantwortlich, das würde vielleicht das andere Verhalten nach dem PoR erklären, aber nicht zwangsweise nach dem Upgrade. Ich kann leider nicht mehr dazu beitragen als immer zu testen, dafür stehe ich aber natürlich gerne zur Verfügung!

Geändert vor 3 Jahren durch PeterPawn

diff for libmodmount.sh to act on AVM changes within udev-mount-sd

comment:136 Geändert vor 3 Jahren durch PeterPawn

Wenn wir die Zeit bis Sonntag nicht einfach verstreichen lassen wollen, hänge ich hier mal ein diff-File für die libmodmount.sh ran. Wenn jemand Lust hat, kann er ja mal damit testen …

Einfach im Trunk-Verzeichnis mit 'patch -p0 <libmodmount.sh.diff' anwenden.

Ich habe die Reihenfolge der Aktionen beim Mounten eines neuen Volumes der von AVM in der 06.20 verwendeten angepaßt und auch die zusätzlichen Benachrichtigungen für einige neue Komponenten beim Mounten (und beim Dismounten) versucht 1:1 nachzuziehen.

Allerdings würde ich behaupten, daß insbesondere der gesamte umount-Vorgang bei aktiviertem Onlinespeicher wohl auch in der libmodmount.sh nicht mehr stimmt (und das auch nicht erst seit gestern, ich kann aber leider im Moment nicht weiter als bis zur 06.05 zurückverfolgen).

Wenn man keinen remove-Patch für die originale AVM-Implementierung verwendet (und stattdessen dann davfs2 direkt nimmt), erfolgt nach allem, was ich bisher in den modifizierten Dateien gesehen habe, keine "ordentliche Abmeldung" eines entfernten Storage-Volumes bei der davfs-Anwendung von AVM (oder ich bin nur zu blöd die richtige Stelle zu finden, wobei die AVM-Implementierung ja auch nur das davfs-Mount killt und (wenn noch ein anderer Cache existiert) dann wieder komplett neu startet).

Da besteht also wohl weiterer Handlungsbedarf, aber beim Mounten sollte eigentlich jetzt derselbe Vorgang ablaufen, wie im originalen AVM-Image.

comment:137 Geändert vor 3 Jahren durch JMC

Das wars leider - zumindest in meinem Fall mit dem PoR crash nicht :(

  • Box eingeschaltet mit Image ohne Patch, ctlmgr crash an den bekannten Stellen, reboot gemacht.
  • Kein ctlmgr Crash, Box ausgeschaltet.
  • Firmware-Upgrade gemacht auf die Version mit dem libmodmount.sh Patch, reboot gemacht.
  • ctlmgr Crash an den bekannten Stellen, reboot gemacht.
  • Kein ctlmgr Crash, Box ausgeschaltet.
  • Box eingeschaltet, ctlmgr crash an den bekannten Stellen, reboot gemacht.
  • Kein ctlmgr Crash, Box ausgeschaltet.
1970-01-01 01:01:39(1) [Segmentation fault] /usr/bin/avm/ctlmgr(2155) CRASHED at strcmp+0xc (/lib/libc.so.0 at 00038a2c) accessing 0+0x5553746e (/usr/share/ctlmgr/libtr064.so at 29ec946e)
SIGNO 11 ERRNO 0 CODE 1
Version: 06.20
Watchdog triggered 8 seconds ago
No bugmsg
ze: 00000000 at: 00000001 v0: 2ae5da20 v1: 00000046
a0: 7f8be3c7 a1: 5553746f a2: 55537470 a3: 7f8be3c8
t0: 00000000 t1: 00000063 t2: 8071bae0 t3: 00000001
t4: 80000000 t5: 00000073 t6: 0000005b t7: 323d2f64
s0: 2b30fbe0 s1: 2b8ccdb0 s2: 004b0000 s3: 2b5a4d98
s4: 00000000 s5: 00000000 s6: 00000001 s7: 2b5b7830
t8: 00000000 t9: 2ae5da20 k0: 00000001 k1: 00000000
gp: 2b30fbe0 sp: 7f8be2c0 fp: 004d0000 ra: 2b2f3cb9
FA 5553746e 0+0x5553746e (/usr/share/ctlmgr/libtr064.so at 29ec946e)
PC 2ae5da2c strcmp+0xc (/lib/libc.so.0 at 00038a2c)
RA 2b2f3cb8 0+0x2b2f3cb8 (/usr/share/ctlmgr/libtamconf.so at 00002cb8)
Code: 90830000  24870001  24a60001 <14600003> 90a20000  03e00008  00021023  00e02021  1062fff7
[bt]  2b2f3cb4 [2b2f3c06] <0+0x2b2f3c07>+0xae (/usr/share/ctlmgr/libtamconf.so at 00002c06)
[bt]  2b2f3fbc [2b2f3d1e] <0+0x2b2f3d1f>+0x29e (/usr/share/ctlmgr/libtamconf.so at 00002d1e)
Zuletzt geändert vor 3 Jahren von JMC (vorher) (Diff)

comment:138 Antwort: Geändert vor 3 Jahren durch PeterPawn

Danke für den Test. Die Reihenfolge ist es also schon mal nicht und auch der Unterschied zwischen dem msgsend an den multid oder upnpdevd ist dann offenbar nicht die Ursache.

Ich habe jetzt noch eine weitere Bitte. Könntest Du mal das ganze FREETZMOUNT komplett rauslassen aus dem Image (FREETZ_PATCH_FREETZMOUNT=N) ? Weiter oben habe ich mal geschrieben, daß ich nicht weiß, ob das überhaupt geht … nach dem, was ich jetzt gesehen habe, sollte es mit einer einzigen Änderung in 'make menuconfig' möglich sein.

Wenn dann immer noch der Crash auftritt, hat es eben wohl doch nichts mit dieser Stelle zu tun (was ich dann überhaupt nicht verstehe angesichts der Registerinhalte beim Crash, aber das Problem erinnert mich fatal an die Geschichte mit dem Pudding, dem Nagel und der Wand) … das Problem tritt jedenfalls mit keiner der möglichen Benennungen eines Mount-Points mit der originalen AVM-Firmware auf, da habe ich alle Kombinationen durch, die mir eingefallen sind.

Es gäbe auch noch einen anderen Test, der m.E. weiteren Erkenntnisgewinn bringen könnte. Wenn beim Start der Box kein USB-Speicher angeschlossen ist, startet die Box dann ohne Probleme und läßt sich das Telefon-GUI dann aufrufen ? Das würde ja wieder den Zusammenhang mit dem USB-Speicher wenigstens soweit bestätigen und absichern, daß man nicht an einer vollkommen anderen Stelle suchen muß.

Wenn man dann den Ablauf innerhalb des udev mit dem Kommando 'udevadm —debug monitor' protokollieren läßt, während man den Speicher erst nachträglich am USB-Port ansteckt, kann man erstens die einzelnen Schritte bei der Initialisierung des Speichers (und zwar als 'cold start' wie beim Einschalten) verfolgen und zweitens gleich noch feststellen, ob es bei der Absturzursache eine Rolle spielt, ob der Speicher beim Starten des FRITZ!OS oder später eingebunden wird.

Auch die zeitliche Abfolge der udev-Aktionen und des folgenden Absturzes könnte dann deutlicher werden, bisher ist zum Ablauf bis zum Crash ja nur zu sehen, daß es eine Aktion über den ctlmgr im Kontext des Anrufbeantworters (libtamconf.so) ist und der ctlmgr wird leider als zentrale Komponente von so ziemlich jeder Stelle aus aufgerufen (auch wenn es hier wohl die Abfrage von TAM-Einstellungen ist). Wenn Du von "bekannten Stellen" schreibst, verstehe ich im Moment darunter immer den Aufruf von Telefoniefunktionen über das AVM-GUI, ist das immer noch richtig ?

Du hattest früher davon berichtet, daß das Konfigurieren des internen Fax-Empfangs in keinem Fall funktioniert und zu einer Reboot-Schleife führt (wenn ich das richtig verstanden habe). Hat sich da im Lichte der neuen Erkenntnis zum Zusammenhang mit dem Aus-/Einschalten etwas geändert ?

Ansonsten kommt es (ohne den faxd, also ohne konfiguriertes internes Fax) nicht zu einem automatischen Reboot, nur weil die Box gestartet wird, sondern erst der Zugriff auf das GUI führt dann zum Absturz, oder ?

Der ctlmgr greift ja von sich aus weder auf libtamconf.so noch auch libtelcfg.so zu, erst wenn er durch Abfrage/Setzen von Einstellungen durch andere Komponenten dazu aufgefordert wird (eben z.B. durch das Lua-CGI). Der faxd greift (wahrscheinlich) natürlich selbst bei seinem Start auf diese Einstellungen zu und benutzt dazu nicht zwingend den ctlmgr, da er ja alleine "lauffähig" ist, was bei den anderen Stellen in den Libraries nicht der Fall ist, die brauchen einen "Host-Prozess".

comment:139 als Antwort auf: ↑ 138 Geändert vor 3 Jahren durch JMC

Replying to PeterPawn:

Ich habe jetzt noch eine weitere Bitte. Könntest Du mal das ganze FREETZMOUNT komplett rauslassen aus dem Image (FREETZ_PATCH_FREETZMOUNT=N) ? Weiter oben habe ich mal geschrieben, daß ich nicht weiß, ob das überhaupt geht … nach dem, was ich jetzt gesehen habe, sollte es mit einer einzigen Änderung in 'make menuconfig' möglich sein.

Richtig, ist es auch. Ich habe jetzt ohne Freetzmount 7 PoR gemacht und jedesmal klappten die sonst zu ctlmgr führenden Stellen ohne Problem. Das einrichten des Faxempfangs auf den USB-Stick schmeisst ctlmgr aber immer noch aus der Bahn:

1970-01-01 01:03:52(2) [Segmentation fault] /usr/bin/avm/ctlmgr(2048) CRASHED at 0+0x2ad4c5f8 (/lib/libavmcsock.so.2 at 000515f8) accessing 0+0x2b7b6ffc (/usr/share/ctlmgr/libtr064.so at 00148ffc)
SIGNO 11 ERRNO 0 CODE 2
ze: 00000000 at: 1810201e v0: ffff0000 v1: 2b7b7008
a0: 3c1c0000 a1: ffff8000 a2: 27bd8000 a3: 279c0000
t0: 00000000 t1: 00000000 t2: 00000000 t3: 00000000
t4: 00000000 t5: 7f000001 t6: 00412640 t7: 0399e021
s0: fffffef0 s1: 2ad4ad00 s2: 00000000 s3: 7fa6b0c8
s4: 2b09214f s5: 000064f7 s6: 2b8b6ca0 s7: 00000000
t8: 00000102 t9: 2ae849d4 k0: 00000001 k1: 00000000
gp: 2ad7d0a0 sp: 7fa6a480 fp: 2b8b6170 ra: 2ad4cad8
FA 2b7b6ffc 0+0x2b7b6ffc (/usr/share/ctlmgr/libtr064.so at 00148ffc)
PC 2ad4c5f8 0+0x2ad4c5f8 (/lib/libavmcsock.so.2 at 000515f8)
RA 2ad4cad8 0+0x2ad4cad8 (/lib/libavmcsock.so.2 at 00051ad8)
Code: 10000027  24630008  004a5024 <5544000b> 8c6bfff4  55670009  8c6bfff4  8c6b0000  01656024
[bt]  2ad4cad0 [2ad4c364] <0+0x2ad4c364>+0x76c (/lib/libavmcsock.so.2 at 00051364)
[bt]  2ad4b950 [2ad4afb4] <0+0x2ad4afb4>+0x99c (/lib/libavmcsock.so.2 at 0004ffb4)
[bt]  !7fa6abc0 rtsignal trampoline on stack
[bt]  2ae5da18 mempcpy+0x438 (/lib/libc.so.0 at 000385e0)

Es gäbe auch noch einen anderen Test, der m.E. weiteren Erkenntnisgewinn bringen könnte. Wenn beim Start der Box kein USB-Speicher angeschlossen ist, startet die Box dann ohne Probleme und läßt sich das Telefon-GUI dann aufrufen ? Das würde ja wieder den Zusammenhang mit dem USB-Speicher wenigstens soweit bestätigen und absichern, daß man nicht an einer vollkommen anderen Stelle suchen muß.

Wenn man dann den Ablauf innerhalb des udev mit dem Kommando 'udevadm —debug monitor' protokollieren läßt, während man den Speicher erst nachträglich am USB-Port ansteckt, kann man erstens die einzelnen Schritte bei der Initialisierung des Speichers (und zwar als 'cold start' wie beim Einschalten) verfolgen und zweitens gleich noch feststellen, ob es bei der Absturzursache eine Rolle spielt, ob der Speicher beim Starten des FRITZ!OS oder später eingebunden wird.

Ohne USB-Stick (mit konfiguriertem Freetzmount) ist nach einem PoR das Web-IF ganz normal nutzbar ohne Absturz.

Hier die Ergebnisse von udevadm —debug monitor - nach dem anstecken des Sticks ist ctlmgr übrigens abgeflogen beim klick auf Telefoniegeräte (Freetzmount im Image). Der gleiche Test ohne Freetzmount im Image hat ohne Probleme geklappt.

Mit Freetzmount

root@fritz:/var/mod/root# udevadm --debug monitor
run_command: calling: monitor
monitor will print the received events for:
UDEV - the event which udev sends out after rule processing
KERNEL - the kernel uevent

KERNEL[119.764493] add      /devices/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-3 (usb)
KERNEL[119.769669] add      /devices/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-3/1-3:1.0 (usb)
UDEV  [119.799480] add      /devices/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-3 (usb)
KERNEL[120.381630] add      /module/scsi_mod (module)
UDEV  [120.381889] add      /module/scsi_mod (module)
KERNEL[120.391606] add      /class/scsi_host (class)
KERNEL[120.393759] add      /bus/scsi (bus)
UDEV  [120.394056] add      /class/scsi_host (class)
KERNEL[120.394375] add      /class/scsi_device (class)
UDEV  [120.394643] add      /bus/scsi (bus)
UDEV  [120.394951] add      /class/scsi_device (class)
KERNEL[120.465988] add      /module/sd_mod (module)
KERNEL[120.467380] add      /class/scsi_disk (class)
UDEV  [120.467678] add      /module/sd_mod (module)
KERNEL[120.467991] add      /bus/scsi/drivers/sd (drivers)
UDEV  [120.471239] add      /class/scsi_disk (class)
UDEV  [120.471887] add      /bus/scsi/drivers/sd (drivers)
KERNEL[120.559960] add      /module/usb_storage (module)
UDEV  [120.560244] add      /module/usb_storage (module)
KERNEL[120.562407] add      /devices/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-3/1-3:1.0/host0 (scsi)
KERNEL[120.565903] add      /devices/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-3/1-3:1.0/host0/scsi_host/host0 (scsi_host)
UDEV  [120.566216] add      /bus/usb/drivers/usb-storage (drivers)
KERNEL[120.566516] add      /bus/usb/drivers/usb-storage (drivers)
UDEV  [120.744299] add      /devices/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-3/1-3:1.0 (usb)
UDEV  [120.744919] add      /devices/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-3/1-3:1.0/host0 (scsi)
UDEV  [120.745955] add      /devices/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-3/1-3:1.0/host0/scsi_host/host0 (scsi_host)
KERNEL[125.576654] add      /devices/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-3/1-3:1.0/host0/target0:0:0 (scsi)
KERNEL[125.577490] add      /devices/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-3/1-3:1.0/host0/target0:0:0/0:0:0:0 (scsi)
UDEV  [125.578515] add      /devices/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-3/1-3:1.0/host0/target0:0:0 (scsi)
KERNEL[125.578868] add      /devices/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-3/1-3:1.0/host0/target0:0:0/0:0:0:0/scsi_disk/0:0:0:0 (scsi_disk)
KERNEL[125.579570] add      /devices/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-3/1-3:1.0/host0/target0:0:0/0:0:0:0/scsi_device/0:0:0:0 (scsi_device)
KERNEL[125.590335] change   /devices/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-3/1-3:1.0/host0/target0:0:0/0:0:0:0 (scsi)
UDEV  [125.593695] add      /devices/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-3/1-3:1.0/host0/target0:0:0/0:0:0:0 (scsi)
UDEV  [125.596033] add      /devices/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-3/1-3:1.0/host0/target0:0:0/0:0:0:0/scsi_disk/0:0:0:0 (scsi_disk)
UDEV  [125.596311] add      /devices/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-3/1-3:1.0/host0/target0:0:0/0:0:0:0/scsi_device/0:0:0:0 (scsi_device)
UDEV  [125.598729] change   /devices/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-3/1-3:1.0/host0/target0:0:0/0:0:0:0 (scsi)
KERNEL[125.601075] add      /devices/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-3/1-3:1.0/host0/target0:0:0/0:0:0:0/block/sda (block)
KERNEL[125.604086] add      /devices/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-3/1-3:1.0/host0/target0:0:0/0:0:0:0/block/sda/sda1 (block)
KERNEL[125.605620] add      /devices/virtual/bdi/8:0 (bdi)
UDEV  [125.607623] add      /devices/virtual/bdi/8:0 (bdi)
UDEV  [125.664462] add      /devices/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-3/1-3:1.0/host0/target0:0:0/0:0:0:0/block/sda (block)
UDEV  [125.735497] add      /devices/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-3/1-3:1.0/host0/target0:0:0/0:0:0:0/block/sda/sda1 (block)
KERNEL[126.257175] add      /module/nls_cp437 (module)
UDEV  [126.259312] add      /module/nls_cp437 (module)
KERNEL[126.276193] add      /module/nls_iso8859_1 (module)
UDEV  [126.278261] add      /module/nls_iso8859_1 (module)

Ohne Freetzmount

root@fritz:/var/mod/root# udevadm --debug monitor
run_command: calling: monitor
monitor will print the received events for:
UDEV - the event which udev sends out after rule processing
KERNEL - the kernel uevent

KERNEL[212.214550] add      /devices/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-3 (usb)
KERNEL[212.217939] add      /devices/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-3/1-3:1.0 (usb)
UDEV  [212.250681] add      /devices/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-3 (usb)
KERNEL[212.811738] add      /module/scsi_mod (module)
UDEV  [212.812004] add      /module/scsi_mod (module)
KERNEL[212.825630] add      /class/scsi_host (class)
UDEV  [212.826628] add      /class/scsi_host (class)
KERNEL[212.827225] add      /bus/scsi (bus)
UDEV  [212.828213] add      /bus/scsi (bus)
KERNEL[212.828805] add      /class/scsi_device (class)
UDEV  [212.829820] add      /class/scsi_device (class)
KERNEL[212.896026] add      /module/sd_mod (module)
UDEV  [212.896314] add      /module/sd_mod (module)
KERNEL[212.896658] add      /class/scsi_disk (class)
UDEV  [212.897258] add      /class/scsi_disk (class)
KERNEL[212.897844] add      /bus/scsi/drivers/sd (drivers)
UDEV  [212.899649] add      /bus/scsi/drivers/sd (drivers)
KERNEL[212.983110] add      /module/usb_storage (module)
UDEV  [212.984480] add      /module/usb_storage (module)
KERNEL[212.986077] add      /devices/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-3/1-3:1.0/host0 (scsi)
KERNEL[212.986925] add      /devices/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-3/1-3:1.0/host0/scsi_host/host0 (scsi_host)
KERNEL[212.988056] add      /bus/usb/drivers/usb-storage (drivers)
UDEV  [212.989525] add      /bus/usb/drivers/usb-storage (drivers)
UDEV  [213.152013] add      /devices/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-3/1-3:1.0 (usb)
UDEV  [213.152592] add      /devices/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-3/1-3:1.0/host0 (scsi)
UDEV  [213.154607] add      /devices/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-3/1-3:1.0/host0/scsi_host/host0 (scsi_host)
KERNEL[217.988118] add      /devices/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-3/1-3:1.0/host0/target0:0:0 (scsi)
KERNEL[217.989305] add      /devices/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-3/1-3:1.0/host0/target0:0:0/0:0:0:0 (scsi)
UDEV  [217.989612] add      /devices/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-3/1-3:1.0/host0/target0:0:0 (scsi)
KERNEL[217.990138] add      /devices/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-3/1-3:1.0/host0/target0:0:0/0:0:0:0/scsi_disk/0:0:0:0 (scsi_disk)
KERNEL[217.991423] add      /devices/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-3/1-3:1.0/host0/target0:0:0/0:0:0:0/scsi_device/0:0:0:0 (scsi_device)
UDEV  [218.001669] add      /devices/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-3/1-3:1.0/host0/target0:0:0/0:0:0:0 (scsi)
UDEV  [218.003199] add      /devices/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-3/1-3:1.0/host0/target0:0:0/0:0:0:0/scsi_device/0:0:0:0 (scsi_device)
UDEV  [218.004346] add      /devices/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-3/1-3:1.0/host0/target0:0:0/0:0:0:0/scsi_disk/0:0:0:0 (scsi_disk)
KERNEL[218.009242] change   /devices/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-3/1-3:1.0/host0/target0:0:0/0:0:0:0 (scsi)
UDEV  [218.016720] change   /devices/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-3/1-3:1.0/host0/target0:0:0/0:0:0:0 (scsi)
KERNEL[218.020325] add      /devices/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-3/1-3:1.0/host0/target0:0:0/0:0:0:0/block/sda (block)
KERNEL[218.021617] add      /devices/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-3/1-3:1.0/host0/target0:0:0/0:0:0:0/block/sda/sda1 (block)
KERNEL[218.022099] add      /devices/virtual/bdi/8:0 (bdi)
UDEV  [218.023620] add      /devices/virtual/bdi/8:0 (bdi)
UDEV  [218.082497] add      /devices/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-3/1-3:1.0/host0/target0:0:0/0:0:0:0/block/sda (block)
UDEV  [218.146723] add      /devices/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-3/1-3:1.0/host0/target0:0:0/0:0:0:0/block/sda/sda1 (block)
KERNEL[218.493381] add      /module/nls_cp437 (module)
UDEV  [218.493704] add      /module/nls_cp437 (module)
KERNEL[218.511497] add      /module/nls_iso8859_1 (module)
UDEV  [218.512041] add      /module/nls_iso8859_1 (module)

Wenn Du von "bekannten Stellen" schreibst, verstehe ich im Moment darunter immer den Aufruf von Telefoniefunktionen über das AVM-GUI, ist das immer noch richtig ?

Ja das ist immer noch richtig. Eigene Rufnummern und Telefoniegeräte sind die beiden Stellen.

Du hattest früher davon berichtet, daß das Konfigurieren des internen Fax-Empfangs in keinem Fall funktioniert und zu einer Reboot-Schleife führt (wenn ich das richtig verstanden habe). Hat sich da im Lichte der neuen Erkenntnis zum Zusammenhang mit dem Aus-/Einschalten etwas geändert ?

Nein, da hat sich nichts geändert, ich glaube hier gibts aber ein Missverständniss. Der interne Fax-Empfang ist nicht generell betroffen, sondern nur dann wenn er auf den USB-Stick eingerichtet ist. Nicht "pauschal" - wenn er auf lokal ablegen eingestellt ist (sprich NAND) dann gehts.

Ansonsten kommt es (ohne den faxd, also ohne konfiguriertes internes Fax) nicht zu einem automatischen Reboot, nur weil die Box gestartet wird, sondern erst der Zugriff auf das GUI führt dann zum Absturz, oder ?

Korrekt, mit der oben erwähnten Einschränkung, dass das nur passiert wenn er auf USB eingerichtet ist. Hier crasht aber auch nicht der ctlmgr und ich kann ihn per telnet/ssh noch neustarten sondern die Box rebootet komplett innerhalb von ein paar Sekunden.

Edit: Erste Ergebnisse der Tests hinzugefügt
Edit2: Ergebnisse von udevadm —debug monitor hinzugefügt

Zuletzt geändert vor 3 Jahren von JMC (vorher) (Diff)

comment:140 Geändert vor 3 Jahren durch PeterPawn

@JMC:

Der Crash beim Einrichten des faxd ist aber erkennbar eine andere Stelle … das könnte man also erst einmal außen vor lassen bei der Suche nach der Ursache. Und der übersteht ja offenbar auch das Abschalten von FREETZMOUNT …

Wenn das Problem ohne FREETZMOUNT aber ansonsten komplett verschwunden ist, suchen wir (Du hast ja die Arbeit, ich versuche nur mir mögliche Ursachen vorzustellen ;)) wohl schon an der richtigen Stelle. Da wären dann - meiner Meinung nach, vielleicht gibt es ja Gegenstimmen ? - die Tests, die Deine Anwesenheit erfordern, noch wirklich wichtige Hinweise, um die Ursache etwas weiter einzugrenzen.

Der Absturz beim Einrichten des faxd sieht eher komisch aus, denn die libavmcsock.so ist auch (wie der ctlmgr) so ein kleines Sammelbecken für alle möglichen Funktionen (vorwiegend mit Netzwerkbezug) ohne klar umrissenen "Auftrag" - wenn man aus den dort versammelten Strings schlußfolgern will. Auf alle Fälle würde ich das in ein anderes Ticket auslagern … die Fehlerursache scheint *mir* hier vollkommen woanders zu liegen und ich würde als erstes mit einer "sauberen" Faxkonfiguration (leider geht das wegen der binären Form der telefon_misc nur parallel mit einer "sauberen" Telefoniekonfiguration, denn die Fax-Konfiguration erfolgt auch in der telefon_misc und nicht etwa in der fx_conf) bei der Fehlersuche an dieser Stelle starten. Aber das ist imho ja ohnehin eine andere Baustelle …

comment:141 Geändert vor 3 Jahren durch udo

Ich habe auf einer 7390 mit "FRITZ!OS 06.20-freetz-devel-12515", replace kernel und jeder Menge removal patches fast das gleiche Problem. In meinem Fall stürzt die Box aber nicht komplett ab. Lediglich das Web-Interface ist via fritz.box nicht mehr erreichbar. Internet, WLAN und sogar die Administration über fritz.box:81 funktionieren weiterhin. Die letzten Meldungen via dmesg lauten:

do_page_fault() #2: sending SIGSEGV to ctlmgr for invalid read access from
55646f73 (epc == 2ae62b9c, ra == 2b2d9cb9)
AVM_WATCHDOG_ungraceful_release: handle 5 (ctlmgr) still registered!


Geändert vor 3 Jahren durch udo

comment:142 Geändert vor 3 Jahren durch udo

… und USB ist bei mir auch im Spiel

rootfs on / type rootfs (rw)
/dev/root on / type squashfs (ro)
proc on /proc type proc (rw)
tmpfs on /var type tmpfs (rw)
dev on /dev type tmpfs (rw,nosuid)
sysfs on /sys type sysfs (rw)
devpts on /dev/pts type devpts (rw,mode=600)
/var/dev/nand on /var/media/ftp type yaffs2 (rw,sync)
usbfs on /proc/bus/usb type usbfs (rw)
/dev/sda1 on /var/media/ftp/Udos1GB type ext3 (rw,noatime,nodiratime,errors=continue,user_xattr,data=ordered)

comment:143 Antwort: Geändert vor 3 Jahren durch PeterPawn

@udo: Ist sogar mit einiger Wahrscheinlichkeit dieselbe Ursache. Der Lesezugriff auf die Adresse 0x55646f73 (Udos) ist ja ziemlich eindeutig. Die Annahme, daß nicht nur die 7490, sondern eher die Firmware ab 06.20 (bzw. ab Labor-06.10) generell betroffen ist, ist angesichts der üblichen AVM-Vorgehensweise sicherlich auch gerechtfertigt … aber es gibt wohl doch Unterschiede (s.u.).

Ich weiß zwar nicht, welche Änderungen Freetz da ansonsten noch so vornimmt, aber wenn der ctlmgr-Prozess abstürzt, sollte eigentlich nach einiger Zeit der Watchdog zubeißen und die Box neu starten. Wenn das nicht der Fall ist, wird vielleicht der "segmentation fault" an irgendeiner anderen Stelle im ctlmgr soweit abgefangen, daß nicht der gesamte Prozess, sondern nur die laufende Abfrage/Aktion abgebrochen wird.

Ansonsten ist der Neustart der Box beim ctlmgr-Absturz normalerweise auch nur eine mittelbare Folge … wenn ich JMC richtig verstanden habe, läßt er die Box auch nicht jedesmal wirklich neu starten. Er startet einfach von sich aus den 'ctlmgr' in einer Telnet-Session wieder neu und dann bleibt i.d.R. auch der Watchdog-initiierte Neustart aus.

Angesichts der bisherigen Testergebnisse würde ich ohnehin dafür plädieren, daß der FREETZMOUNT-Prozess komplett untersucht und an die geänderten Gegebenheiten der AVM-Firmware angepaßt wird. Ich mache das auch gerne (das Suchen nach Zusammenhängen in älteren Paketen ist zwar etwas mühselig, aber ich hatte da offenbar ohnehin falsche Vorstellungen zum Zusammenspiel von FREETZMOUNT und diverser Remove-Patches), das dauert aber ein wenig.

Merkwürdigerweise gibt es in der AVM-Firmware für die 7490 eine zusätzliche Library namens 'libmount.so', die in der Version für die 7390 nicht vorhanden ist. Ich versuche jetzt erst einmal, den Zweck dieser Lib zu verstehen (sie hat auf alle Fälle - nicht nur wegen des Namens, mehr wegen ihres Inhalts - etwas mit dem Mount-Prozess zu tun) und schaue dann (auch unter Berücksichtigung der von JMC noch zugesagten Testergebnisse zum Unterschied zwischen Mounten beim Start und nachträglich), was AVM da wo geändert haben könnte. Der Aufwand ist nur etwas höher und ich will mich nicht verzetteln mit anderen Sachen, die ich im Moment mache. Einen Workaround (auch um die Probleme von JMC beim Neustart) gäbe es ja …

Mein Vorschlag als zeitweise Lösung für Freetz mit 06.20 wäre, daß man die Verwendung von FREETZMOUNT mit dieser Version als "unstable" deklariert. Dann können die anderen Pakete (ohne zusätzliche Verwirrung beim Nutzer) ja trotzdem genutzt werden und auch wenn FREETZMOUNT einige Sachen zusätzlich bringt, ist es ja nicht lebenswichtig für Freetz an sich. Wenn es nur um das Mounten nach Label geht (bei gängigen Filesystemen, die von /sbin/blkid richtig erkannt werden), das ließe sich - zumindest vorübergehend - auch mit einem Einzeiler als Patch für udev-mount-sd erledigen und hat - bei mir auf originaler AVM-Version "schon immer" im Einsatz - wahrscheinlich keine Nebenwirkungen. Das war ja auch etwas verwirrend, da bei mir die Partitionen der HDD auch ausschließlich mit ihrem Label in Kleinbuchstaben gemountet werden und dabei kein Absturz auftritt - siehe comment 88.

Edit: Und schon geht das Verzetteln los ;)

Bei der 7490 wird offenbar (anders als bei der 7390) das 'util-linux-ng-2.17.2'-Paket anstelle der Busybox-Applets an einigen Stellen genutzt. Da ist zwar meines Wissens immer noch keine 'libmount.so' an sich dabei … die Binaries, die auf die libmount.so zugreifen (lsblk, mountpoint, swapon/swapoff, findmnt) dürften aber auf dem Paket basieren. Ich vermute mal ins Blaue, daß AVM da die Verwendung der mediadevmap anstelle von mtab/fstab irgendwie eingeführt hat/einführen will (als Abgrenzung zu den "üblichen" Mountpoints). Also heißt es wohl in den GPL-Sourcen weiter nach dem Sinn der libmount.so zu forschen, die sind verfügbar und sollten dann auch util-linux-ng abdecken.

Edit2: Offenbar versteht AVM unter den Bestimmungen der GPL zur *Nachvollziehbarkeit* von Änderungen (inkl. dem Bereitstellen notwendiger Skripte) etwas anderes als ich …

Es war mir schon etwas länger bewußt, daß in den AVM-Quellen in der Datei 'GPL-busybox.tar.gz' gar keine Busybox steckt, dazu hatte mir auch ein AVM-MA schon früher eine Antwort per E-Mail gegeben. Daß aber das dort hinterlegte 'util-linux-ng-2.17.2' auf der 7490 wohl auch gar nicht benutzt wird, macht die Sache noch etwas verwirrender. Es kommt wohl das Paket 'util-linux-ng-2.22.2' zum Einsatz (das hat auch eine libmount.so), das befindet sich dann auch in der Datei 'GPL-gcc.tar.gz' und wird in keinem Makefile auch nur mit einer Silbe erwähnt. Dafür hat man in 'GPL-gcc.tar.gz' (nur für die 06.20 der 7490 !!) dann die Auswahl zwischen drei verschiedenen gcc-Versionen (4.7.3, 4.7.4 und 4.8.1). Ich fühle mich fast dazu bemüßigt, bei AVM noch einmal nachzufragen, wie man denn nun aus ihrem Sammelsurium der verschiedensten OSS-Pakete in den verschiedensten Versionen genau die eine gültige Version für die 06.20 der 7490 bauen soll. Nach den Bestimmungen der GPL sollte das problemlos möglich sein. Der Weg, eigene Änderungen durch möglichst große Verwirrung zu kaschieren, dürfte wohl kaum dem Geiste der GPL entsprechen, vermutlich nicht einmal den Buchstaben …

Zuletzt geändert vor 3 Jahren von PeterPawn (vorher) (Diff)

comment:144 als Antwort auf: ↑ 143 Geändert vor 3 Jahren durch JMC

So, die Tests mit/ohne Stick sind oben ergänzt.

Replying to PeterPawn:

Ansonsten ist der Neustart der Box beim ctlmgr-Absturz normalerweise auch nur eine mittelbare Folge … wenn ich JMC richtig verstanden habe, läßt er die Box auch nicht jedesmal wirklich neu starten. Er startet einfach von sich aus den 'ctlmgr' in einer Telnet-Session wieder neu und dann bleibt i.d.R. auch der Watchdog-initiierte Neustart aus.

Richtig, das dauert mir sonst zulange ;)

comment:145 Geändert vor 3 Jahren durch PeterPawn

@JMC:

Danke für's Testen … ich würde das dann bis hier mal so zusammenfassen, daß FREETZMOUNT ein Teil der Ursache ist, aber nur dann, wenn auch ein Mount für ein Device stattfindet. Es ist also keine statische Änderung an einem AVM-File … erst bei der Ausführung von FREETZMOUNT-geändertem Code tritt das Problem auf.

Die "reinen" monitor-Ausgaben des udevd sind nach dem, was ich auf den ersten Blick erkennen konnte, identisch bei der Version mit oder ohne FREETZMOUNT - solange man nicht FREETZ_CUSTOM_UDEV_RULES=Y verwendet, ist das auch zu erwarten.

Leider hatte ich verdrängt, daß bei Freetz wohl auf der Konsole kein automatisches "setconsole" in der ersten Telnet-Session (pts0) ausgeführt wird. Eigentlich sollten die Skripte beim Mounten einige Ausgaben nach /dev/console schreiben, anhand der "Einstreuung" in die udevd-Ereignisse würde man dann etwas besser den zeitlichen Ablauf eines Mounts (mich interessiert ja eigentlich nur *mit* FREETZMOUNT, das andere kann ich - wenn auch mit anderen Geräten - selbst sehen) verfolgen können und vielleicht Unterschiede erkennen. Wäre es möglich, das noch einmal (ggf. auch nur _mit_ FREETZMOUNT) und einem vorhergehenden "setconsole" zu machen ?

Noch eine andere Frage im Nachgang zu den eingeschobenen Recherchen in den GPL-Quellen …

Es gibt ja im Freetz ein eigenes Paket für 'util-linux-ng' (FREETZ_PACKAGE_UTIL_LINUX_NG=Y). Ich glaube zwar nicht, daß die Ursache so simpel ist, aber die Information, ob Du das in Deinem Image verwendest, wäre vielleicht noch nützlich.

Bestimmt gibt es irgendwo in diesem Ticket Deine .config, ich will bloss nicht suchen (Asche auf mein Haupt) und gleichzeitig sicher sein, daß die Auskunft der *aktuelle* Stand ist. Wenn Du noch eine aktuelle .config im Ganzen hast, kann man da auch gleich noch nach einige andere potentielle Fragen klären, ohne Dich jedesmal zu behelligen.

comment:146 Antwort: Geändert vor 3 Jahren durch JMC

root@fritz:/var/mod/root# setconsole
root@fritz:/var/mod/root# udevadm --debug monitor
run_command: calling: monitor
monitor will print the received events for:
UDEV - the event which udev sends out after rule processing
KERNEL - the kernel uevent

KERNEL[107.814525] add      /devices/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-3 (usb)
KERNEL[107.817598] add      /devices/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-3/1-3:1.0 (usb)
UDEV  [107.849603] add      /devices/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-3 (usb)
KERNEL[108.426323] add      /module/scsi_mod (module)
UDEV  [108.427845] add      /module/scsi_mod (module)
KERNEL[108.441547] add      /class/scsi_host (class)
KERNEL[108.442667] add      /bus/scsi (bus)
KERNEL[108.447748] add      /class/scsi_device (class)
UDEV  [108.447965] add      /bus/scsi (bus)
UDEV  [108.448157] add      /class/scsi_host (class)
UDEV  [108.448343] add      /class/scsi_device (class)
KERNEL[108.515384] add      /module/sd_mod (module)
UDEV  [108.515677] add      /module/sd_mod (module)
KERNEL[108.516012] add      /class/scsi_disk (class)
UDEV  [108.516599] add      /class/scsi_disk (class)
KERNEL[108.517198] add      /bus/scsi/drivers/sd (drivers)
UDEV  [108.519670] add      /bus/scsi/drivers/sd (drivers)
KERNEL[108.605592] add      /module/usb_storage (module)
UDEV  [108.606990] add      /module/usb_storage (module)
KERNEL[108.608401] add      /devices/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-3/1-3:1.0/host0 (scsi)
KERNEL[108.609614] add      /devices/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-3/1-3:1.0/host0/scsi_host/host0 (scsi_host)
KERNEL[108.611849] add      /bus/usb/drivers/usb-storage (drivers)
UDEV  [108.613687] add      /bus/usb/drivers/usb-storage (drivers)
UDEV  [108.807031] add      /devices/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-3/1-3:1.0 (usb)
UDEV  [108.808140] add      /devices/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-3/1-3:1.0/host0 (scsi)
UDEV  [108.809103] add      /devices/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-3/1-3:1.0/host0/scsi_host/host0 (scsi_host)
KERNEL[113.607709] add      /devices/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-3/1-3:1.0/host0/target0:0:0 (scsi)
UDEV  [113.608837] add      /devices/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-3/1-3:1.0/host0/target0:0:0 (scsi)
KERNEL[113.609566] add      /devices/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-3/1-3:1.0/host0/target0:0:0/0:0:0:0 (scsi)
KERNEL[113.612496] add      /devices/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-3/1-3:1.0/host0/target0:0:0/0:0:0:0/scsi_disk/0:0:0:0 (scsi_disk)
KERNEL[113.615391] add      /devices/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-3/1-3:1.0/host0/target0:0:0/0:0:0:0/scsi_device/0:0:0:0 (scsi_device)
KERNEL[113.631709] change   /devices/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-3/1-3:1.0/host0/target0:0:0/0:0:0:0 (scsi)
UDEV  [113.643780] add      /devices/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-3/1-3:1.0/host0/target0:0:0/0:0:0:0 (scsi)
UDEV  [113.645172] add      /devices/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-3/1-3:1.0/host0/target0:0:0/0:0:0:0/scsi_disk/0:0:0:0 (scsi_disk)
UDEV  [113.646359] add      /devices/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-3/1-3:1.0/host0/target0:0:0/0:0:0:0/scsi_device/0:0:0:0 (scsi_device)
KERNEL[113.646789] add      /devices/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-3/1-3:1.0/host0/target0:0:0/0:0:0:0/block/sda (block)
UDEV  [113.647179] change   /devices/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-3/1-3:1.0/host0/target0:0:0/0:0:0:0 (scsi)
KERNEL[113.648233] add      /devices/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-3/1-3:1.0/host0/target0:0:0/0:0:0:0/block/sda/sda1 (block)
KERNEL[113.649866] add      /devices/virtual/bdi/8:0 (bdi)
UDEV  [113.657025] add      /devices/virtual/bdi/8:0 (bdi)
UDEV  [113.710319] add      /devices/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-3/1-3:1.0/host0/target0:0:0/0:0:0:0/block/sda (block)
UDEV  [113.772314] add      /devices/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-3/1-3:1.0/host0/target0:0:0/0:0:0:0/block/sda/sda1 (block)
KERNEL[114.304731] add      /module/nls_cp437 (module)
UDEV  [114.305903] add      /module/nls_cp437 (module)
KERNEL[114.324018] add      /module/nls_iso8859_1 (module)
UDEV  [114.325053] add      /module/nls_iso8859_1 (module)
FREETZMOUNT: [INFO] Partition UStor01 (/dev/sda1) was mounted successfully (vfat)
Jan  1 01:02:06 ctlmgr[1865]: [bt]  2b2f3fbc [2b2f3d1e] <0+0x2b2f3d1f>+0x29e (/usr/share/ctlmgr/libtamconf.so at 00002d1e)

Die ctlmgr Zeile hab ich bewirkt indem ich im Web-IF den crash herbeigeführt habe. Also ausser der einen Zeile hat sich nicht wirklich was getan im Output finde ich, oder?

Meine Config hänge ich jetzt gleich an.

Zuletzt geändert vor 3 Jahren von JMC (vorher) (Diff)

Geändert vor 3 Jahren durch JMC

aktuelle .config Testbox

comment:147 als Antwort auf: ↑ 146 Geändert vor 3 Jahren durch PeterPawn

Replying to JMC:

Also ausser der einen Zeile hat sich nicht wirklich was getan im Output finde ich, oder?

Wohl wahr, das sieht "im Original" (mit 1x swap + 2x ext3) wesentlich geschwätziger aus:

storage:unmounting /var/media/ftp/WDCWD16-00BEVE-11UYT0-03
storage:unmounting /var/media/ftp/WDCWD16-00BEVE-11UYT0-02

\u@\h:\w $ udevadm --debug monitor
run_command: calling: monitor
monitor will print the received events for:
UDEV - the event which udev sends out after rule processing
KERNEL - the kernel uevent

KERNEL[1412346906.331796] remove   /devices/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-4/1-4:1.0/host0/target0:0:0/0:0:0:0/scsi_device/0:0:0:0 (scsi_device)
KERNEL[1412346906.333256] remove   /devices/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-4/1-4:1.0/host0/target0:0:0/0:0:0:0/scsi_disk/0:0:0:0 (scsi_disk)
UDEV  [1412346906.333557] remove   /devices/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-4/1-4:1.0/host0/target0:0:0/0:0:0:0/scsi_device/0:0:0:0 (scsi_device)
KERNEL[1412346906.334159] remove   /devices/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-4/1-4:1.0/host0/target0:0:0/0:0:0:0/block/sda/sda3 (block)
KERNEL[1412346906.335614] remove   /devices/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-4/1-4:1.0/host0/target0:0:0/0:0:0:0/block/sda/sda2 (block)
UDEV  [1412346906.335923] remove   /devices/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-4/1-4:1.0/host0/target0:0:0/0:0:0:0/scsi_disk/0:0:0:0 (scsi_disk)
KERNEL[1412346906.338590] remove   /devices/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-4/1-4:1.0/host0/target0:0:0/0:0:0:0/block/sda/sda1 (block)
KERNEL[1412346906.363832] remove   /devices/virtual/bdi/8:0 (bdi)
KERNEL[1412346906.364312] remove   /devices/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-4/1-4:1.0/host0/target0:0:0/0:0:0:0/block/sda (block)
UDEV  [1412346906.367053] remove   /devices/virtual/bdi/8:0 (bdi)
KERNEL[1412346906.373434] remove   /devices/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-4/1-4:1.0/host0/target0:0:0/0:0:0:0 (scsi)
KERNEL[1412346906.383236] remove   /devices/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-4/1-4:1.0/host0/scsi_host/host0 (scsi_host)
KERNEL[1412346906.384013] remove   /devices/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-4/1-4:1.0/host0 (scsi)
UDEV  [1412346906.385295] remove   /devices/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-4/1-4:1.0/host0/scsi_host/host0 (scsi_host)
KERNEL[1412346906.386009] remove   /devices/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-4/1-4:1.0 (usb)
KERNEL[1412346906.396916] remove   /devices/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-4 (usb)
UDEV  [1412346906.405569] remove   /devices/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-4/1-4:1.0/host0/target0:0:0/0:0:0:0/block/sda/sda1 (block)
UDEV  [1412346906.437595] remove   /devices/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-4/1-4:1.0/host0/target0:0:0/0:0:0:0/block/sda/sda3 (block)
UDEV  [1412346906.447878] remove   /devices/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-4/1-4:1.0/host0/target0:0:0/0:0:0:0/block/sda/sda2 (block)
UDEV  [1412346906.566892] remove   /devices/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-4/1-4:1.0/host0/target0:0:0/0:0:0:0/block/sda (block)
UDEV  [1412346906.568108] remove   /devices/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-4/1-4:1.0/host0/target0:0:0/0:0:0:0 (scsi)
UDEV  [1412346906.574801] remove   /devices/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-4/1-4:1.0/host0 (scsi)
UDEV  [1412346906.576384] remove   /devices/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-4/1-4:1.0 (usb)
UDEV  [1412346906.857876] remove   /devices/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-4 (usb)
killall: ftpd: no process killed
killall: ftpd: no process killed
killall: ftpd: no process killed
killall: ftpd: no process killed
KERNEL[1412346916.408043] add      /devices/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-4 (usb)
KERNEL[1412346916.412465] add      /devices/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-4/1-4:1.0 (usb)
KERNEL[1412346916.423565] add      /devices/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-4/1-4:1.0/host1 (scsi)
KERNEL[1412346916.424862] add      /devices/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-4/1-4:1.0/host1/scsi_host/host1 (scsi_host)
UDEV  [1412346916.444403] add      /devices/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-4 (usb)
UDEV  [1412346916.800452] add      /devices/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-4/1-4:1.0 (usb)
UDEV  [1412346916.801655] add      /devices/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-4/1-4:1.0/host1 (scsi)
UDEV  [1412346916.802995] add      /devices/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-4/1-4:1.0/host1/scsi_host/host1 (scsi_host)
KERNEL[1412346921.461203] add      /devices/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-4/1-4:1.0/host1/target1:0:0 (scsi)
UDEV  [1412346921.462214] add      /devices/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-4/1-4:1.0/host1/target1:0:0 (scsi)
KERNEL[1412346921.472879] add      /devices/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-4/1-4:1.0/host1/target1:0:0/1:0:0:0 (scsi)
KERNEL[1412346921.473214] add      /devices/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-4/1-4:1.0/host1/target1:0:0/1:0:0:0/scsi_disk/1:0:0:0 (scsi_disk)
KERNEL[1412346921.473503] add      /devices/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-4/1-4:1.0/host1/target1:0:0/1:0:0:0/scsi_device/1:0:0:0 (scsi_device)
UDEV  [1412346921.493222] add      /devices/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-4/1-4:1.0/host1/target1:0:0/1:0:0:0 (scsi)
UDEV  [1412346921.493852] add      /devices/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-4/1-4:1.0/host1/target1:0:0/1:0:0:0/scsi_disk/1:0:0:0 (scsi_disk)
UDEV  [1412346921.494536] add      /devices/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-4/1-4:1.0/host1/target1:0:0/1:0:0:0/scsi_device/1:0:0:0 (scsi_device)
KERNEL[1412346921.528839] add      /devices/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-4/1-4:1.0/host1/target1:0:0/1:0:0:0/block/sdb (block)
KERNEL[1412346921.529258] add      /devices/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-4/1-4:1.0/host1/target1:0:0/1:0:0:0/block/sdb/sdb1 (block)
KERNEL[1412346921.530199] add      /devices/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-4/1-4:1.0/host1/target1:0:0/1:0:0:0/block/sdb/sdb2 (block)
KERNEL[1412346921.531228] add      /devices/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-4/1-4:1.0/host1/target1:0:0/1:0:0:0/block/sdb/sdb3 (block)
KERNEL[1412346921.532428] add      /devices/virtual/bdi/8:16 (bdi)
UDEV  [1412346921.534863] add      /devices/virtual/bdi/8:16 (bdi)
UDEV  [1412346921.726153] add      /devices/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-4/1-4:1.0/host1/target1:0:0/1:0:0:0/block/sdb (block)
UDEV  [1412346922.167517] add      /devices/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-4/1-4:1.0/host1/target1:0:0/1:0:0:0/block/sdb/sdb3 (block)
UDEV  [1412346922.206350] add      /devices/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-4/1-4:1.0/host1/target1:0:0/1:0:0:0/block/sdb/sdb1 (block)
UDEV  [1412346922.211835] add      /devices/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-4/1-4:1.0/host1/target1:0:0/1:0:0:0/block/sdb/sdb2 (block)
Mounting WDCWD16-00BEVE-11UYT0-03 to device /dev/sdb3...
MOUNT: use blkid to get device /dev/sdb3 data
MOUNT: filesystem type is: ext3
MOUNT:mount -t 'extX' /dev/sdb3 /var/media/ftp/WDCWD16-00BEVE-11UYT0-03
killall: ftpd: no process killed
KERNEL[1412346928.005412] add      /devices/virtual/bdi/0:14 (bdi)
UDEV  [1412346928.006607] add      /devices/virtual/bdi/0:14 (bdi)
Mounting WDCWD16-00BEVE-11UYT0-02 to device /dev/sdb2...
MOUNT: use blkid to get device /dev/sdb2 data
MOUNT: filesystem type is: ext3
MOUNT:mount -t 'extX' /dev/sdb2 /var/media/ftp/WDCWD16-00BEVE-11UYT0-02
killall: ftpd: no process killed
Mounting WDCWD16-00BEVE-11UYT0-01 to device /dev/sdb1...
MOUNT: use blkid to get device /dev/sdb1 data
MOUNT: filesystem type is: swap
MOUNT: try to add swap
mkswap: /dev/sdb1: warning: wiping old swap signature.
KERNEL[1412346933.272875] change   /devices/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-4/1-4:1.0/host1/target1:0:0/1:0:0:0/block/sdb/sdb1 (block)
MOUNT: swap added
UDEV  [1412346933.410031] change   /devices/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-4/1-4:1.0/host1/target1:0:0/1:0:0:0/block/sdb/sdb1 (block)

Was mich jetzt wirklich fertig macht, ist die Tatsache, daß auch mit originalem AVM-Image (der Prompt sieht nur so merkwürdig aus, weil das auch die originale Busybox ist) eigentlich alle Binaries, die die libmount.so benutzen auch sang- und klanglos mit einem "segmentation fault" die Segel streichen:

\u@\h:\w $ mountpoint /var/media/ftp/WDCWD16-00BEVE-11UYT0-02/FB7490/
Segmentation fault
\u@\h:\w $ lsblk
Segmentation fault
\u@\h:\w $ swapon --help

Usage:
 swapon [options] [<spec>]

Options:
 -a, --all              enable all swaps from /etc/fstab
 -d, --discard          discard freed pages before they are reused
 -e, --ifexists         silently skip devices that do not exist
 -f, --fixpgsz          reinitialize the swap space if necessary
 -p, --priority <prio>  specify the priority of the swap device
 -s, --summary          display summary about used swap devices
     --show[=<columns>] display summary in definable table
     --noheadings       don't print headings, use with --show
     --raw              use the raw output format, use with --show
     --bytes            display swap size in bytes in --show output
 -v, --verbose          verbose mode

 -h, --help     display this help and exit
 -V, --version  output version information and exit

The <spec> parameter:
 -L <label>             synonym for LABEL=<label>
 -U <uuid>              synonym for UUID=<uuid>
 LABEL=<label>          specifies device by swap area label
 UUID=<uuid>            specifies device by swap area UUID
 PARTLABEL=<label>      specifies device by partition label
 PARTUUID=<uuid>        specifies device by partition UUID
 <device>               name of device to be used
 <file>                 name of file to be used

Available columns (for --show):
 NAME  device file or partition path
 TYPE  type of the device
 SIZE  size of the swap area
 USED  bytes in use
 PRIO  swap priority

For more details see swapon(8).
\u@\h:\w $ swapon -s
Segmentation fault
\u@\h:\w $

Ich habe zwar auch nur minimalste Änderungen in der AVM-Firmware vorgenommen, aber ist das vollkommen *ohne jegliche* Änderung auch schon so ? Vielleicht hat ja jemand noch eine wirklich originale 7490 im Zugriff ? Auf einer Kundenbox will ich bei dem Thema nicht herumspielen … das wäre für mich die einzige Möglichkeit (außer Recover).

Ich würde da ja zu gerne mal mit dem gdb reinschauen, leider funktioniert der bei mir auf der 7490 aber auch nicht … und jetzt erst den zu reparieren, weitet das Thema noch mehr aus. AVM baut in den GPL-Sourcen auch irgendwo einen, mal sehen ob der "tut" …

Zuletzt geändert vor 3 Jahren von PeterPawn (vorher) (Diff)

comment:148 Geändert vor 3 Jahren durch JMC

Ich hab leider keine unmodifizierte 7490 im Zugriff, nur eine 7390, aber das bringt ja glaube ich nichts. Ich werd sonst heute Nachmittag/Abend mal recovern auf der Testbox und schauen was passiert.

comment:149 Geändert vor 3 Jahren durch PeterPawn

Ich werde im Gegenzug mal Deine Freetz-Konfiguration bauen und in der zweiten Partition installieren … das macht ja auf Dauer keinen Sinn per "stille Post" und dann kann ich unmittelbar testen. Aber erst muß ich noch etwas anderes zum Abschluß bringen, daher dauert das etwas … ich habe das Problem aber auf der ToDo-Liste und vergesse es nicht.

@Freetz-Maintainer:

Könnt Ihr Euch mit dem "Einschränken" des unstable-Status auf die Verwendung von FREETZMOUNT mit der 06.20 anfreunden oder braucht es dazu noch 1-2 Probanden, die das Problem durch Entfernen von FREETZMOUNT auch abstellen können oder ist es letztlich auch egal, ob die komplette 06.20 unstable ist oder nur beim Einsatz von FREETZMOUNT ?

comment:150 Geändert vor 3 Jahren durch er13

@Vermutung "das Problem läge ausschließlich an FreetzMount": Ich habe es jetzt die letzten Tage nicht intensiv verfolgen können. Ist es denn so? Verhält sich die Box stabil, wenn man FreetzMount abwählt?

@AVM-OpenSrc-Pakete: Meiner Ansicht nach hat AVM noch nie im vollen Umfang alles, was GPL verlangt, eingehalten. Es fehlen die richtigen uClibc / busybox .config's, es fehlen häufig auch die richtigen kernel .config's. Build-Anweisungen/-Scripte sind nicht vorhanden (was in welcher Reihenfolge, mit welchen Parametern/Umgebungsvariablen). Es liegen die falschen Sources bei (z.B. immer noch samba-3.0.x, obwohl die Firmware schon längst 3.3.x enthält). Zum Übersetzen verwendet AVM BuildRoot, die entsprechende BuildRoot .config ist aber nicht enthalten.

@util-linux: es wird die in BuildRoot enthaltene util-linux Version verwendet und nicht die separat liegende. Der Grund für die Verwendung von util-linux sind die mkswap, swapon & blkid Befehle (referenziert aus /etc/hotplug/udev-mount-sd, /etc/udev/rules.d/60-persistent-storage.rules & /bin/supportdata.usb). Alle anderen util-linux Binaries/Libraries landen nur deswegen in der Firmware, weil BuildRoot's util-linux Paket die Möglichkeit nicht bietet, nur die benötigten Files auszuwählen. swapon ist z.B. auch in der busybox von AVM enthalten, wird aber durch die util-linux-Version überschrieben. All die restlichen util-linux-Files werden von AVM gar nicht verwendet (zumindest ist das mein Stand - habe es vor einiger Zeit überprüft, kann allerdings sein, dass mir dabei was entgangen ist).

comment:151 Geändert vor 3 Jahren durch PeterPawn

@er13: Bisher gibt es die definitive Aussage von JMC dazu (mehrere Versuche, die nicht zu dem ansonsten gut reproduzierbaren Absturz des ctlmgr führten), von anderen kam in dieser Richtung noch kein Feedback. Allerdings hat ja Dein Patch für den Mountpoint offenbar auch bei einigen das Problem zumindest entschärft, wenn es auch nicht in jedem Falle vollkommen abgestellt wurde (s. JMC und die Abstürze nach dem "cold start" der USB-Devices).

Solange der zusätzliche Neustart bei den meisten wohl gar nicht auffällt (wer schaltet seine Box schon regelmäßig aus und wieder an), wird das wohl schon als Workaround ausreichen mit dem geänderten MP. Aber das ist - in meinen Augen - noch keine "saubere" Lösung, solange die echte Ursache nicht geklärt ist und ein "cold start" des USB-Speichers (verläßlich, zumindest bei JMC) zum Absturz führt.

Dann braucht es vielleicht doch noch einige Berichte, andererseits ist wohl auch der Eindruck nicht verkehrt, daß es "nicht so schlimm" ist und sich ein Großteil der Meldungen in diesem Ticket durch Downgrades/Workaround ohnehin - mindestens vorläufig - erledigt hat.

Solange der "unstable"-Status weitere Versuche bei einigen/vielen beeinflußt (http://www.ip-phone-forum.de/showthread.php?t=273481 als Beispiel), werden da wohl nur wenige Berichte - positiv oder negativ - nachkommen. Da sehe ich ein wenig ein Henne-Ei-Problem … deshalb der Vorschlag mit der Beschränkungm, der Workaround bezieht sich ja auch auf FREETZMOUNT.

@util-linux-ng: Die Suche habe ich auch nur "eingeschoben", weil mir die libmount.so irgendwie aufgefallen war (ist ja inzwischen geklärt, daß die zum Paket in der Version 2.22.2 gehört) … und bei den GPL-Sourcen bin ich dann wieder beruhigt, daß es nicht nur mein Unvermögen ist, was das vollkommen undurchschaubar macht.

Dann wird es wohl wirklich der Debugger richten müssen und das ist dann auch wieder gedeckt von der Lizenz und den gesetzlichen Ausnahmen im UrhG, solange AVM einem keine andere Chance läßt.

comment:152 Geändert vor 3 Jahren durch er13

In 12519:

FreetzMount:

@all users using "Partition label"-scheme: please reconfigure FreetzMount after updating to/flashing this revision

comment:153 Geändert vor 3 Jahren durch PeterPawn

@er13: Bisher gibt es die definitive Aussage von JMC dazu (mehrere Versuche, die nicht zu dem ansonsten gut reproduzierbaren Absturz des ctlmgr führten, wenn FREETZMOUNT nicht ausgewählt war), von anderen kam in dieser Richtung noch kein Feedback. Allerdings hat ja Dein Patch für den Mountpoint offenbar auch bei einigen das Problem zumindest entschärft, wenn es auch nicht in jedem Falle vollkommen abgestellt wurde (s. JMC und die Abstürze nach dem "cold start" der USB-Devices).

Ich bin inzwischen aber nicht einmal mehr ganz sicher, daß es wirklich an der Schreibweise des Mountpoints liegt und nicht doch vielmehr am Unterschied zwischen 'cold start' und 'warm start' des USB-Speichers (comment 132 von JMC). Wenn es mit der Schreibweise dann doch nichts zu tun hatte (das war ja nur die Vermutung mit dem fehlenden Match beim regexp), könnte man ja die neuen Alternativen für den MP-Namen drin lassen, aber den Standard wieder auf den alten Wert setzen. Was für mich nicht ins Bild paßt, ist comment 141 … da sollte ja eigentlich der MP-Patch mit drin sein und der Absturz tritt trotzdem auf … so wie bei JMC nach einem Kaltstart auch.

Solange der zusätzliche Neustart bei den meisten wenig bis gar nicht auffällt (wer schaltet seine Box schon regelmäßig aus und wieder an), wird das wohl bei vielen schon als Workaround ausreichen. Aber das ist - in meinen Augen - noch keine "saubere" Lösung, solange die echte Ursache nicht geklärt ist und ein "cold start" des USB-Speichers (verläßlich, zumindest bei JMC) zum Absturz führt. Es erklärt aber andererseits auch die eher geringe Zahl an Rückmeldungen zu diesem Problem. Wenn jemand das bei ersten Mal eher achselzuckend zur Kenntnis nimmt und es dann bis zum Ausschalten/Updaten nicht erneut auftritt, wird er es auch nicht melden.

Solange der "unstable"-Status weitere Versuche bei einigen/vielen beeinflußt (http://www.ip-phone-forum.de/showthread.php?t=273481 als Beispiel), werden da wohl nur wenige Berichte - positiv oder negativ - nachkommen. Da sehe ich ein wenig ein Henne-Ei-Problem … deshalb der Vorschlag mit der Beschränkungm, der Workaround/Patch ändert ja auch am FREETZMOUNT.

@util-linux-ng: Die Suche habe ich auch nur "eingeschoben", weil mir die libmount.so irgendwie aufgefallen war (ist ja inzwischen geklärt, daß die zum Paket in der Version 2.22.2 gehört) … und bei den GPL-Sourcen bin ich dann wieder beruhigt, daß es nicht nur mein Unvermögen ist, was das vollkommen undurchschaubar macht.

Dann wird es wohl wirklich der Debugger richten müssen und das ist dann auch wieder gedeckt von der Lizenz und den gesetzlichen Ausnahmen im UrhG, solange AVM einem keine andere Chance läßt.

comment:154 Geändert vor 3 Jahren durch er13

In 12522:

FreetzMount:

  • mark FreetzMount as being UNSTABLE when used with Fritz!OS 6.20
  • refs #2499

comment:155 Geändert vor 3 Jahren durch er13

In 12523:

6.2x firmware series:

  • remove UNSTABLE marker
  • refs #2499

comment:156 Geändert vor 3 Jahren durch er13

In 12524:

comment:157 Geändert vor 3 Jahren durch JMC

Da ich gerade erst ausm Büro komme (Migration *!§"$*) schau ich mal ob ich morgen die Lust hab zu recovern, sonst gibts in den nächsten Tagen Rückmeldung bzgl. unmodifizierter 7490.

comment:158 Geändert vor 3 Jahren durch qwertz123

Hi,

TL;DR: Entfernen von webdav scheint zu helfen??

Details / kleiner Einwurf/Beobachtung von mir:
Ich hab ne schwer modifizierte 7390, die das Problem bislang auch mit 6.20 bislang nicht hatte.
Da waren u.a. diverse removal-Patches an. Nun brauchte ich einige bislang deaktivierte Funktionen wieder (anderer Einsatzweck der Box) → habe alle removals entfernt.
Ergebnis: ctlmgr crash.

Im syslog stand was von segfault bei strcmp/libhtmltemplate.so drin und im /var/flash/crash.log war der faxd vertreten.
Watchdog war aus (rc.local), leider hilft das nur begrenzt weil der crash teilweise schon erfolgt, bevor freetzmount/external/rc.local durch ist, also musste ich da via ssh $box echo disable \>/dev/watchdog nachhelfen…

Da das kein Zustand ist (reboots enden in einer schleife) habe ich mir mal angeschaut was freetzmount macht und bin auf hotplug.d/storage gekommen, bzw. was dort drin gemacht wird und wie sich das mit meinen removals deckt - so lange die an waren, hatte ich ja kein Problem.

Ich hab da nur eine Überlappung mit webdav gefunden, und den removal patch wieder eingeschaltet → bislang kein Crash.

Keine Ahnung ob das bei der Eingrenzung weiterhilft, ich hab derzeit auch relativ wenig Ambitionen die Box komplett umzukrempeln. Das war ne ziemlich große Umstellung und es ist 'nen Haufen Peripherie dran, insofern bin ich erst einmal froh das es läuft und die Familie wieder telefonieren/surfen kann.

comment:159 Geändert vor 3 Jahren durch er13

In 12526:

libmodmount/do_mount_locked:

  • update device map before notifying other components about changes (by PeterPawn)
  • AVM does it in the same order
  • refs #2499, refs #2572

comment:160 Geändert vor 3 Jahren durch er13

In 12527:

libmodmount:

  • increase readability a bit by adding empty lines
  • add/tweak comments
  • refs #2499, refs #2572

comment:161 Geändert vor 3 Jahren durch er13

In 12528:

libmodmount:

  • move "restore umask" out of if/else
  • refs #2499, refs #2572

comment:162 Geändert vor 3 Jahren durch er13

Achtung: ich werde ein paar ungetestete Commits machen, die ich erst wenn ich mehr oder weniger durch bin, testen werde. Bitte bis zu meiner Freigabe kein "svn up" machen und nichts flashen ;-)

comment:163 Geändert vor 3 Jahren durch er13

In 12529:

libmodmount / find_mnt_name:

  • eliminate 2nd parameter as it's unused
  • refs #2499, refs #2572

comment:164 Geändert vor 3 Jahren durch er13

In 12530:

libmodmount / find_mnt_name:

  • eliminate unused return code
  • refs #2499, refs #2572

comment:165 Geändert vor 3 Jahren durch er13

In 12531:

libmodmount / do_mount_locked:

  • eliminate unnecessary while-loop
  • refs #2499, refs #2572

comment:166 Geändert vor 3 Jahren durch er13

In 12532:

libmodmount / do_mount_locked:

  • increase readability a bit by avoiding long if/else-branches
  • refs #2499, refs #2572

comment:167 Geändert vor 3 Jahren durch er13

In 12533:

libmodmount / do_mount_locked:

comment:168 Geändert vor 3 Jahren durch er13

Habe in r12531 doch einen kleinen Schönheitsfehler eingebaut:

FREETZMOUNT: Mounting device /dev/sda2 at /var/media/ftp/swap

Die Logausgabe sieht etwas komisch aus, ist aber ansonsten harmlos. Ansonsten scheint nach den letzten (erst jetzt getesteten) Commits alles genauso zu funktionieren wie bisher.

Achtung: die 6.20er Probleme bestehen weiterhin, diese wurden in den Commits oben noch nicht angegangen.

comment:169 Geändert vor 3 Jahren durch JMC

Bezüglich entfernen von webdav: Kann ich für mich nicht bestätigen. Werde die Box jetzt mal recovern und dann berichten was mit den binarys passiert beim Aufruf.

Edith sagt:

# mountpoint /var/media/ftp/CHIPSBNK-v3-3-8-8-01/
Segmentation fault
# lsblk
Segmentation fault

Ist frisch recovert und nur Telnet eingeschaltet.

Zuletzt geändert vor 3 Jahren von JMC (vorher) (Diff)

comment:170 Geändert vor 3 Jahren durch JMC

Ich hab gerade auf meinem ipad die Fon App benutzt und das hat die Box bzw den ctlmgr gecrasht (mit FREETZMOUNT auf UStor01)

root@fritz:/var/mod/root# cat /var/flash/crash.log
2014-10-06 18:22:59(1) [Segmentation fault] /usr/bin/avm/ctlmgr(2190) CRASHED at strcmp+0xc (/lib/libc.so.0 at 00038a2c) accessing 0+0x7553746e (/lib/libhtmltemplate.so.0 at 49c3046e)
SIGNO 11 ERRNO 0 CODE 1
Version: 06.20
Watchdog triggered 3 seconds ago
No bugmsg
ze: 00000000 at: 00000001 v0: 2ae5da20 v1: 0000006f
a0: 7fbfcfdf a1: 7553746f a2: 75537470 a3: 7fbfcfe0
t0: 00000000 t1: 5432c1e3 t2: 8071bae0 t3: 00000001
t4: 80000000 t5: 00000073 t6: 0000005b t7: 333d2f64
s0: 2b311be0 s1: 2b959b48 s2: 7fbfd408 s3: 00000000
s4: 00000000 s5: 2b67c90c s6: 7fbfd47c s7: 7fbfd488
t8: 00000000 t9: 2ae5da20 k0: 00000001 k1: 00000000
gp: 2b311be0 sp: 7fbfced8 fp: 7fbfd484 ra: 2b2f5cb9
FA 7553746e 0+0x7553746e (/lib/libhtmltemplate.so.0 at 49c3046e)
PC 2ae5da2c strcmp+0xc (/lib/libc.so.0 at 00038a2c)
RA 2b2f5cb8 0+0x2b2f5cb8 (/usr/share/ctlmgr/libtamconf.so at 00002cb8)
Code: 90830000  24870001  24a60001 <14600003> 90a20000  03e00008  00021023  00e02021  1062fff7
[bt]  2b2f5cb4 [2b2f5c06] <0+0x2b2f5c07>+0xae (/usr/share/ctlmgr/libtamconf.so at 00002c06)
[bt]  2b2f5fbc [2b2f5d1e] <0+0x2b2f5d1f>+0x29e (/usr/share/ctlmgr/libtamconf.so at 00002d1e)
root@fritz:/var/mod/root# 
Zuletzt geändert vor 3 Jahren von JMC (vorher) (Diff)

comment:171 Geändert vor 3 Jahren durch PeterPawn

Frische Box: Soviel dann zur QS beim Hersteller … :-(

Absturz: Hoffentlich aber mit FREETZMOUNT, oder ? Wenn ja, ist das insofern nicht verwunderlich, da ja auch über TR-064 irgendwann der ctlmgr ins Spiel kommen muß. Die Fon-App nutzt TR-064 zum Zugriff, HTTP nur beim Telefonbuch oder der Anrufliste (das merke ich mir nie) - wobei bei der Anrufliste dann wieder möglicherweise HTTP im Spiel wäre und die ist ja ein Kandidat für den USB-Zugriff (das TB eher nicht).

Ich habe mal versucht, das auf spezielle ctlmgr-Zugriffe herunterzubrechen, um es weiter einzukreisen (im Moment aber keine Zeit/kein Gerät zum Testen):

ctlusb:settings/device/count
usbdevices:settings/physmedium/list(name,vendor,serial,fw_version,conntype,capacity,status,usbspeed,model)
usbdevices:settings/physmediumcnt
usbdevices:settings/logvol/list(name,status,enable,phyref,filesystem,capacity,usedspace,readonly)
usbdevices:settings/logvolcnt
ctlusb:settings/storage-part/count

Wenn jemand weiß, wie er mit 'query.lua' die Box per HTTP befragen kann (steht in den ersten Zeilen der Datei, die heißt /usr/www/avm/query.lua), kann er ja mal schauen, ob bei einer dieser Aktionen der ctlmgr auch reproduzierbar abstürzt (die stammen aus 'usb_devices.lua').

comment:172 Geändert vor 3 Jahren durch JMC

Ja, der Absturz war auf einer Box mit FREETZMOUNT, ich denke ich werde auf der Produktiv-Box jetzt ohne FREETZMOUNT weitermachen und einen Symlink setzen der auf den Original-AVM-Benannten-Ordner geht. Testbox steht natürlich weiter mit FREETZMOUNT zur Verfügung um beim eingrenzen soweit mir möglich zu helfen.

Geändert vor 3 Jahren durch er13

ein klassisches Beispiel fürs Auseinanderlaufen eines Code-Clones ;-)

comment:173 Antwort: Geändert vor 3 Jahren durch PeterPawn

Ich blicke noch nicht so ganz durch, ob die diversen Änderungen im FREETZMOUNT jetzt auch alle in älterer Firmware (ich sage mal vor 05.50 nur als "Hausnummer") umgesetzt werden und welche Auswirkungen das dann dort hätte. 

Der "alte" Mechanismus mit "run_mount" als udev-Skript ist ja bis zu einem gewissen FW-Stand auch richtig. Wie weit zurück muß/soll denn die Kompatibilität mit älterer Firmware gewahrt bleiben ? Wie ist denn derzeit die Unterstützung von Freetz für Versionen vor dem webcm-Bug überhaupt geregelt/gewünscht/geplant ?

AVM hat ja für so ziemlich jedes Modell noch die Änderung nachgezogen, bei den ganz alten Geräten m.W. sogar für eine 04.8x oder so. Muß so etwas altes künftig auch im Trunk weiter unterstützt sein oder reicht es da zu sagen, dann muß man eben auf 1.2 oder 2.0 zurückgreifen ?

comment:174 als Antwort auf: ↑ 173 Geändert vor 3 Jahren durch hippie2000

Replying to PeterPawn:

AVM hat ja für so ziemlich jedes Modell noch die Änderung nachgezogen, bei den ganz alten Geräten m.W. sogar für eine 04.8x oder so. Muß so etwas altes künftig auch im Trunk weiter unterstützt sein oder reicht es da zu sagen, dann muß man eben auf 1.2 oder 2.0 zurückgreifen ?

Ich finde Freetz sollte irgendwann alle Modelle supporten statt welche herausfallen zu lassen.

Gefixed wurde jedes Modell das den Language Support in den Webserver einkompiliert hat. (config multi language).

Der Fix betrifft diese Modelle: http://pastebin.de/40982

Modelle vor Language Support waren nicht betroffen, sollten daher als intakt angesehen und in Freetz weiterhin supportet werden.

Meiner Meinung nach sollte die Grenze die Machbarkeit sein und nicht eine Firmwareversion. Die Machbarkeit endet beim derzeitigen Konzept bei Modellen die noch kein Eva hatten sondern den alten ADAM2. Aber auch das könnte man durch Wahl eines anderen Kompressionsverfahrens als LZMA umgehen.

Meiner Forschung und Einschätzung nach endet die Machbarkeit dann bei den beiden Modellen mit nur 2MB Flash.

comment:175 Geändert vor 3 Jahren durch er13

Sofern es keinen unheimlich großen Aufwand bedeutet, sollten alle älteren Versionen unterstützt werden. Einige der Änderungen (als Beispiel sei eben r12526 genannt) betrachte ich als Fehlerkorrekturen seitens AVM, die wir durchs Nachziehen dann indirekt auch in den älteren Firmware-Versionen korrigieren ;-)

Bei msgsend muss man glaube ich einige Fallunterscheidungen einführen.

Zuletzt geändert vor 3 Jahren von er13 (vorher) (Diff)

comment:176 Geändert vor 3 Jahren durch hippie2000

Mit Unterstützung muss nicht gemeint sein dass die olle Firmware supportet werden muss.

Für einige Altmodelle mit Kernel 2.4 geht das gar nicht. Da käme also nur ein brauchbarer Alien in Frage. Der W701V ist ja auch nur als Alien unterstützt, obwohl ja auch die olle tcom Firmware modbar wäre.

Ich finde wenn ein Modell mindestens in irgendeiner Form unterstützt wird genügt. Das hat auch Verluste, so gibt es einige Altmodelle deren USB-Controller nie in Kernel 2.6 portiert wurde. Die können maximal ein Alien ohne USB-Host werden…

Im Kernel 2.6 findet man zwar einen VLYNQ USB-Host Support, aber das hat nie jemand getestet (AVM vielleicht intern). Solche Limits kann man kaum umgehen, die sind aber Einzelfälle.

Viele Modelle lassen sich über gut konzipierte Aliens erschliessen, und das ist eh was der Nutzer wählt, da neuere Basisfirmware.

Im Prinzip braucht man irgendwann nur noch je SoC Generation eine Basisfirmware. Das klappt nicht immer gut wegen Limits beim RAM. Da muss dann im Alien sehr rabiat entfernt werden. Daher mein Gedanke einer Paketverwaltung für den AVM Teil statt Removes. Die komplexen Dependecies sind kaum in einzelnen Scripts einbaubar.

Im neuen Wiki werden die Dependencies maschinell ermittelt. Die Daten sind live exportierbar. Das würde das Remove System sehr viel effizienter machen und einige ultraknappe Modelle in neuere Firmware liften. Man könnte diese 2 Prinzipien auch Modell für Modell parallel betreiben (Revove vs. Package Manager) bis irgendwann alles erschlossen ist. Ohne Tests geht das natürlich nicht. Daher meine eskalierende Sammlung an Modellen. Die Menge der Firmwareversionen die gepflegt werden müssen könnte man damit sehr reduzieren.

comment:177 Geändert vor 3 Jahren durch PeterPawn

Die Frage entstand, da es eben bei AVM selbst diverse Änderungen in der Vorgehensweise gab/gibt (man braucht nur mal den Init-Prozess der 04.88 für die 7170 mit einem aktuellen System vergleichen) und dann besonders die diversen Remove-Patches (im Moment eben als "alles oder nichts" ausgelegt, z.B. beim TR-069) teilweise an den falschen Stellen patchen oder Sachen mit rausnehmen (bei TR-069 wohl - nur dem Lesen nach - auch TR-064), die man durchaus gebrauchen könnte (z.B. für die Apps). In einer 7390 (im Moment noch das zweitbeste Modell) ist es ohnehin schon eng genug, da nutzt externals auch nur in Maßen … und dann ist das entweder-oder (z.B. auch beim NAS und dem "default content" des yaffs2 im NAND) als finale Lösung nicht in jedem Falle geeignet. Selbst beim TR-069 kann man - auch wenn man es drinläßt - noch diversen Platz sparen, wenn man nur die Provider-Liste entsprechend kürzt.

Das wird aber im Ticket OT, wo kann man das am ehesten diskutieren ? Das IPPF halte ich nicht für sinnvoll, da würden (meine Meinung) mehr die wünschenswerten als die machbaren Wege favorisiert. Das Modell "Package Manager" finde ich spannend, wo wurde das schon mal angesprochen ?

comment:178 Geändert vor 3 Jahren durch er13

@hippie2000: bitte werwechsele nicht "Hardware/Box/Firmware unterstützen" mit "ein Paket unterstützt alle von Freetz unterstützten Boxen/Firmware-Versionen". Hier geht es um das zweite. Die korrekte Antwort lautet daher:

Sofern es keinen großen Aufwand bedeutet, wäre es wünschenswert, dass ein Paket (in diesem Fall FreetzMount) auch die älteren Firmware-Versionen unterstützt. Sollte der Aufwand aber mehr als gering sein, ist es für ein Paket durchaus legitim, eine (nicht notwendigerweise ältere) Firmware-Version nicht zu unterstützen. Dann gibt es halt ein "depends on" im menuconfig und das Paket ist für die Version gar nicht auswählbar.

comment:179 Antwort: Geändert vor 3 Jahren durch SpaceRat

Ich habe mit dem aktuellen freetz-trunk ein 7390-6.20-Image ohne FREETZMOUNT erstellt.
It compiles, first screen comes up …. aber das war's auch schon.

Ein beliebiger ctlmgr_ctl-Lesezugriff, z.B. …
ctlmgr_ctl r myfritzdevice settings/device0/dyndnslabel
… und die Box macht die Grätsche.

Da ich momentan die Box nicht einfach mal 'ne Stunde mit sich selbst und ihren Crashs beschäftigen kann, war ich froh, wenigstens problemlos aus sich selbst heraus ein Downgrade auf 6.04 machen zu können (Bei einem älteren freetz-trunk war es ein Heidenspaß, mit dem Update zwischen Neustart und erneuten Crash zu kommen) und habe ans Crash-Log nicht gedacht …


Auf jeden Fall scheint mir die 6.20 generell eher unbrauchbar zu sein:
Ich würde fast schätzen, daß sich AVM hier bei dem wahnhaften "Abdichten" verzettelt hat, denn ob ich die gesamte Config mit allcfgconv -c auslese oder die relevanten Werte gezielt mit ctlmgr_ctl r abfrage ist an sich unbedeutend, also wird wohl hinter beidem irgendein Müll stecken, der die Quadratur des Kreises (Ein System so "sicher" zu machen, daß selbst der User "root" nichts mehr machen kann, es gleichzeitig aber funktionsfähig zu halten.) ermöglichen soll.

comment:180 als Antwort auf: ↑ 179 ; Antwort: Geändert vor 3 Jahren durch PeterPawn

Replying to SpaceRat:

first screen comes up

Was heißt das genau ? Login-Screen ? Übersicht ?

Erfolgt der Absturz auch dann, wenn man das GUI gar nicht aufruft und nur den von Dir erwähnten Zugriff per Telnet/Skript probiert ?

Wenn ja, auch sehr unschön und suchenswert, aber - wenn ich nicht alles komplett falsch interpretiere - andere Baustelle. Hier ist wirklich der Zugriff auf das GUI (und in der Folge auf den ctlmgr) erforderlich für den Absturz und beileibe nicht jeder ctlmgr-Aufruf (dann würde  keine einzige GUI-Seite funktionieren) crasht hier.

Der Neustart erfolgt beim ctlmgr-Crash auch nicht immer unmittelbar, je nach Kontext kann etwas Zeit vergehen, bis der Watchdog den Neustart auslöst. Wenn in einer Reboot-Schleife das GUI für eine gewisse Zeit trotzdem benutzbar ist, kann ein Firmware-Update funktionieren, wenn es vor dem Auslösen des Watchdog bis zum - beim Update verwendeten - "disable" für den Watchdog kommt. Ansonsten kann man den Watchdog auch per Telnet-Session manuell abschalten, dann ist man - wenn das möglich ist - auch aus einer Reboot-Schleife (delayed) raus.

comment:181 als Antwort auf: ↑ 180 Geändert vor 3 Jahren durch SpaceRat

Replying to PeterPawn:

Replying to SpaceRat:

first screen comes up

Was heißt das genau ? Login-Screen ? Übersicht ?
Erfolgt der Absturz auch dann, wenn man das GUI gar nicht aufruft und nur den von Dir erwähnten Zugriff per Telnet/Skript probiert ?


Nun, was ich gemacht habe:
Ich habe eine neue gefreetzte Firmware auf Basis von 6.20 gebastelt, FREETZMOUNT dabei rausgelassen und diese vom vorhandenen Freetz aus aktualisiert.

Danach startete die Box normal durch und ich habe mich auf dem Web-UI angemeldet und dort mal etwas rumgeklitscht.
Nachdem das - im Gegensatz zum letzten Versuch vor dem "FREETZMOUNT weglassen"-Lösungsansatz - noch nicht zum Absturz geführt hatte, wollte ich die FritzBox an sich in den regulären Testbetrieb überführen.
Dazu brauche ich die Informationen, die mir
ctlmgr_ctl r myfritzdevice settings/device0/dyndnslabel
zur Verfügung stellt und deshalb habe ich es dann - also nachdem die FritzBox schon ein paar Minuten lief und ich auch mal auf der GUI gewesen war - auf der Shell (Per OpenSSH) aufgerufen.

Danach hat die FritzBox erst einmal nicht mehr reagiert und dann schlußendlich nach ein paar Gedenksekunden einen Neustart ausgeführt.

Der Neustart erfolgt beim ctlmgr-Crash auch nicht immer unmittelbar, je nach Kontext kann etwas Zeit vergehen, bis der Watchdog den Neustart auslöst.

Genau so fühlte es sich auch an.
Die ssh-Sitzung reagierte nicht mehr, aber bis zum Neustart vergingen noch etliche Sekunden.

Eine Boot-Loop war es auch nicht, die FritzBox crashte und startete erst wieder neu, als ich den Samba-Server mal neu gestartet habe.

Dazu muß man wissen, daß ich natürlich meinen Samba-Patch (http://freetz.org/ticket/2287) verwende, in dessen Scripten der Aufruf
ctlmgr_ctl w ctlusb settings/samba-server-enabled 1
bzw.
ctlmgr_ctl w ctlusb settings/samba-server-enabled 0
vorkommt …

Nun ist diese 7390 - wie schon beschrieben - im produktiven Einsatz und deshalb hatte es in diesem Moment Priorität für mich, die Kiste wieder zu stabilisieren, weshalb ich zu meiner Schande kein Crash-Log kopiert habe, sondern direkt wieder zurück auf die 6.04 gegangen bin.

Ich bin mir aber zu 99,99% sicher, daß diesen Crash auch jeder Andere - z.B. jemand mit einer 7390 Testbox im nicht-produktiven Einsatz - reproduzieren kann, indem er einfach mal auf der Shell irgendeinen Wert mit
ctlmgr_ctl r
ausliest oder mit
ctlmgr_ctl w
schreibt …

comment:182 Geändert vor 3 Jahren durch JMC

Wenn die SSH-Sitzung sofort nicht mehr reagiert ist das vergleichbar mit dem Absturz beim Fax-Problem. Bei dem von Peter erwähnten Crash kann man sich sogar nach ~20 Sekunden per Putty noch neu an der Box anmelden und den ctlmgr starten. Sieht m.M. nach - wie Peter schon gesagt hat - aber auch nach etwas anderem aus.

Beruhigen ist aber, dass ohne Freetzmount nichts crasht im Webmenu ;)

Edit:
Ich hab meine Produktivbox jetzt ohne FREETZMOUNT laufen, hier hatte ich aber das gleiche Verhalten: Nach dem Firmwareupdate ctlmgr Absturz per WebIF - ctlmgr gestartet, übers AVM Interface rebootet und alles ok. Das Problem nach dem Flashen scheint also auch ohne FREETZMOUNT da zu sein. Ich bin mir nichtmal sicher, ob das nicht auch schon in alten Firmware-Versionen auch so war, wie Peter schon geschrieben hatte schieben die meisten das vielleicht auf irgendwas und nach dem reboot gehts ja.

Zuletzt geändert vor 3 Jahren von JMC (vorher) (Diff)

comment:183 Geändert vor 3 Jahren durch CarstenSchuette

Also, ich glaube nicht, dass das ctlmgr-Problem auf der 7390 das gleiche Problem ist wie das mit den Mountpoints. Zumal der Zugriff mit den von SpaceRat beschriebenen ctlmgr-Befehlen bei mir mit FREETZMOUNT problemlos funktioniert (es passiert stumpf gar nichts).

Auch wundert mich, wie JMC auf einer frisch recoverten Box mountpoint oder lsblk aufrufen kann, auf meiner Box sind diese beiden Befehle im original AVM-Image gar nicht vorhanden.

comment:184 Geändert vor 3 Jahren durch JMC

Auf einer frisch recoverten 7490 mit 6.20 sind die bei dir nicht vorhanden?

Wie ich das machen konnte war recht einfach: Ich habe die Box recovert, da ich aus der Ferne auf die Box zugreife habe ich anschließend eine dummy Rufnummer und ein dummy Telefon eingerichtet, dann mit der Wählhilfe Telnet eingeschaltet, mich mit Telnet auf die Box verbunden und genau die Befehle eingetippt die oben im Code Block stehen. Funktioniert bei mir ohne Probleme. Was kommt denn auf einer frisch recoverten 7490 bei dir wenn du im Telnet probierst mountpoint einzugeben?

comment:185 Geändert vor 3 Jahren durch CarstenSchuette

Ja, du hast recht, ich war auf der falschen Box.
Auf einer 7490 kommt bei lsblk und mountpoint ebenfalls "Segmentation fault".

comment:186 Geändert vor 3 Jahren durch er13

Blöde Frage, wie kommt Ihr darauf mountpoint, lsblk, etc zu testen? Diese sind zwar in der AVM-Firmware enthalten, werden aber genauso wie findmnt, e2fsck gar nicht verwendet. Die sind nur deswegen da, weil BuildRoot sie alle im util-linux Paket mitliefert.

comment:187 Geändert vor 3 Jahren durch PeterPawn

Das ist meine Schuld, aber auch nur ein kleiner Ausflug und keine neue Richtung der Suche.

Bei der Suche nach der Ursache bin ich über die libmount.so gestolpert, in der Folge dann über die util-linux-ng und dort dann als erstes darauf, daß die ganzen aus diesem Paket gebauten Utilities bei mir in einem nur minimal modifizierten System schon von vorneherein nicht funktionieren. Das wunderte mich heftig (ich hatte der AVM-QS mehr zugetraut, ansonsten haben diese Tools einfach nichts im Image zu suchen) und ich stellte die Frage in den Raum, ob das auf einem *vollkommen unmodifizierten* System auch schon so ist. Das wird uns - wahrscheinlich - der Fehlerursache aber wohl doch nicht wirklich näher bringen … jedenfalls solange man die Ursache für diesen segv nicht kennt (bzw. wo da hingegriffen wird) und das kriege ich auf einer 7490 auch nicht heraus, da der gdb nicht will. Bliebe noch strace oder ltrace um festzustellen, ob das auch ein strcmp ist, habe ich im Moment aber auch nicht.

Insofern habe ich das Interesse an dieser Fragestellung nicht verloren, aber vertagt. ;)

JMC war dann so nett, das mal auf seiner Reserve-Box zu testen und auch da stürzen die schon ab. Damit ist das aber auch erst mal wieder erledigt.

Im Moment wäre ich mehr an den Ergebnissen der irgendwo vorher erwähnten ctlmgr-Abfragen interessiert um herauszufinden, ob sich das auf physikalische oder logische Datenträger eingrenzen läßt. Diese Zugriffe - glaube ich - als Gemeinsamkeit zwischen tamconf und telcfg extrahiert zu haben beim Enumerieren der Speicher (aus usb-devices.lua - oder so ähnlich) und das ist in meinen Augen immer noch die logischste Stelle.

Ansonsten fehlt mir im Moment einfach die Zeit für systematische Tests bei mir, da ich dazu meinen "Telefon"-Router benutzen muß, das geht nur mitten in der Nacht und da schlafe ich (entgegen meines sonstigen Rhythmus) zur Zeit eher. Das "duale" Booten zwischen AVM-06.20 (mit kleinen Modifikationen) und Freetz ohne jedesmal flashen zu müssen, habe ich zwar hinbekommen, aber das war's dann auch erst einmal.

comment:188 Geändert vor 3 Jahren durch SpaceRat

Gibt's in dieser Sache irgendwelche Neuigkeiten?

Ich würde schon gerne eine Firmware auf der Basis der 6.20 nutzen, aber momentan ist das nicht wirklich gangbar …

comment:189 Geändert vor 3 Jahren durch ralle

Schade das es hier so lange dauert interesiert mich auch

comment:190 Geändert vor 3 Jahren durch blackstar

Hallo
Bei mir tritt der Fehler inzwischen wieder auf :(
funktionierte mit trunk 12645 neu ausgecheckt bei Version 12662 → REBOOT bei Telefoniegeräten.
.config hatte ich nur erneut abgespeichert also weder was dazu noch weggenommen.
das einzigste war meines erachtens nach openvpn was aktualisiert wurde.
Gruß Black

comment:191 Antwort: Geändert vor 3 Jahren durch udo

Me too. Ich bin auf meiner 7390 daher wieder zurück auf trunk 12626. An der .config habe ich längere Zeit nicht gebastelt und beim "make oldconfig" immer nur die Defaults übernommen. Auffällig ist, dass nach dem Einspielen eines neueren Builds die Telefonie nie funktioniert. Und wie SpaceRat es bereits vermutet hatte, führt ein "ctlmgr_ctl r" zum Absturz.

comment:192 Geändert vor 3 Jahren durch PeterPawn

@udo:

'ctlmgr_ctl r' führt zum Absturz ? Das muß aber noch weitere Parameter haben, z.B. die "Section" der zu lesenden Einstellungen.

Ich habe schon in comment 171 versucht, das auf die Zugriffe auf

ctlusb:settings/device/count
usbdevices:settings/physmedium/list(name,vendor,serial,fw_version,conntype,capacity,status,usbspeed,model)
usbdevices:settings/physmediumcnt
usbdevices:settings/logvol/list(name,status,enable,phyref,filesystem,capacity,usedspace,readonly)
usbdevices:settings/logvolcnt
ctlusb:settings/storage-part/count

herunterzubrechen. Genauso gut kann es natürlich sein, daß es eine bestimmte "Art" von Einstellungen (ctlusb, usbdevices, myfritzdevice) insgesamt betrifft. Der Absturz bei wirklich beliebigen Abfragen mit ctlmgr_ctl (z.B. 'ctlmgr_ctl r box settings/hostname') ist imho nicht verbürgt … das wäre wirklich extrem unlogisch, da ja so ziemlich jede Abfrage von Statusvariablen und Einstellungen über den ctlmgr als zentrale Instanz läuft (wer will, kann die Protokollierung mit Option -m ja mal aktivieren, um da die Kommunikation bis zu einem Absturz mitzuschneiden - man muß eben nur den Restart durch den Watchdog verhindern) und dann jeder Aufruf des Webinterfaces sofort zum Absturz des ctlmgr führen müßte.

Ich habe im Moment keine Box frei, um das selbst zu testen und konnte das auch vorher auf einer 7490 mit unbekannten - aber offensichtlich nicht erfüllten - Rahmenbedingungen nicht nachstellen … daher warte ich immer noch auf jemanden, bei dem das Problem auf der Box reproduzierbar ist und der mit der query.lua (für die o.a. Abfragen) umgehen kann. Die einzelnen Werte (also die ohne "list" im Pfad) kann man ja auch direkt mit ctlmgr_ctl abfragen … wobei der Weg über query.lua dem vom AVM-GUI genommenen natürlich wesentlich näher ist und die Listenabfragen gehen ohnehin nur als mquery über die query.lua.

comment:193 als Antwort auf: ↑ 191 Geändert vor 3 Jahren durch make

In diesem Ticket geht es um Probleme der 7490. Tippfehler?

Ich bin auf meiner 7390 daher wieder zurück auf trunk 12626.

comment:194 Geändert vor 3 Jahren durch PeterPawn

Zu dem Zeitpunkt, als das Ticket eröffnet wurde, gab es die 06.20 für die 7390 vermutlich noch gar nicht. Das Problem zeigt sich - den bisherigen Meldungen zufolge - auch bei der 7390 und - vermutlich - irgendwann demnächst auch bei den ganzen neu erschienenen 06.20-Versionen für die anderen Modelle. Insofern wäre vmtl. eine Änderung des Titels sogar sinnvoll.

Zuletzt geändert vor 3 Jahren von PeterPawn (vorher) (Diff)

comment:195 Geändert vor 3 Jahren durch HarryT

I want to report that I to have the problems with the instable Fritzbox too.
I previously used a 7390 with Freetz and Fhem. After upgrading to 6.20 it became very instable and I thought it has a hardware problem, because even after going back to my previous 6.06 image it still was very unstable.

So I bought a 7490 with 6.20 and installed Fhem. This was stable including the usb-sticks, no problems. After I installed Freetz with 6.20 andFreetzmount it looks to be stable initiatly, but after some hours it became unstable. Then I removed the usb sticks and it became stable again. When the sticks where plugged-in again the box became unstable again immediatly.

Then I generated a Freetz image without freetzmount and loaded this. This runs for about 24 hours and looked stable. Then a sip call came in and the box had a very bad line quality and soon the box crashed. This was consequent for every call.

Downgrading to 6.06 with Freetz and then upgrading to the AVM 6.20 firmware seems to make it stable.
For the record:

  • the USB-stick labels used as mount points are all capitals
  • I don't use the fax feature
  • I don't use the answer machine
  • I use 3 sip accounts
  • dect is active

The last thing I tried was to recover the 7490 to 6.06 and then load my fritzbox settings (NOT the Freetz settings) saved from the 7390 6.06 version. To my surprise the 7490 was then again very unstable. Then I tried a Freetz version (without Freetzmount) with 6.06 and it was still unstable. Then I upgraded to the 6.20 version and it was stable again.

So very weird.

I guess:

  • freetzmount is not the reason for the instability but just triggers it, like a lot of other actions.
  • there is some problem with the avm-settings when restoring
  • not freetzmount causes instability but the use of freetz on a 6.20 ox 7390 & 7490, I guess it would be better to warn people for upgrading in combination with Freetz at all.

As I now have a 7390 available with the problems for testing purposes I can offer help if somebody has an idea how to solve this issue

I will search more the next days and maybe I can find something but it looks as if people with much more skills as I have tried already without success.

Questions:

  • Has anybody already described how to recover a 7490 to a situation in which the box with Fhem and Freetz runs stable?
  • Is it clear if it is possible at all to have it running stable with the current trunk vversion? Which version best to use?

I hope it is possible to see a solution for this problem.

PS My understanding of written German is perfect, but I can't write it.

Grusse

comment:196 Geändert vor 3 Jahren durch HarryT

Just to inform you of my findings.

After days of testing I could trace my problem back to the import of the saved fritzbox settings. Especcialy some of the VPN settings triggered the instabilty

What I did to solve my issue:

  • set the fritzbox to factory defaults
  • import the saved settings but use import settings from another fritzbox type
  • skip the settings which cause the problem. As said, my problem where (old) VPN settings which didn't cause any problems in the past with the older firmware.

I generated a new firmware with freetzmount from revision 12705. And my 7390 seems to run without problems yet. I will leave it running for another day and see what happens.

Off course I am not sure if my problem is/was the same as what others reportd in this topic.

{HT}

comment:197 Geändert vor 3 Jahren durch CarstenSchuette

Ich kann es leider gerade nicht testen, aber es gibt jetzt eine 06.21er-Labor.
Treten diese Abstürze und Reboots mit der Laborversion immer noch auf?

comment:198 Geändert vor 3 Jahren durch PeterPawn

Man kann ja anhand der Crash-Logs davon ausgehen, daß die Abstürze des ctlmgr auf Variablenabfragen aus Lua-Seiten zurückzuführen sind (sie erfolgen ja schon beim ausschließlich lesenden Zugriff des Nutzers und sollten daher imho nicht auf das Ändern irgendwelcher Einstellungen zurückzuführen sein). Da der ctlmgr sowohl für den HTTP-Server als auch für die Variablenabfragen zuständig ist, kann man bei seinem Absturz bei einer Abfrage auch kein Traceback mit einer Angabe der Anweisung, die am Ende den Fehler verursacht, erwarten. Also muß man versuchen, das auf anderem Wege einzugrenzen, z.B. durch einzelne Abfragen, so daß sich die zum Absturz führende identifizieren läßt (per GUI mit query.lua) oder durch Abfrage von Lua-Variablen der Box auf der Kommandozeile, wo man den Fehler dann unabhängig vom Absturz des Webservers vielleicht doch noch sehen kann.

Da ich bei mir den Fehler nicht reproduzieren kann und offenbar niemand sich mit dem HTTP-Aufruf der query.lua auskennt, um die Kommandos aus usb_devices.lua einzeln zu testen, hänge ich mal ein Lua-Skript an, mit dem sich diese Variablen von der Kommandozeile aus abfragen lassen. Inzwischen sind ja m.W. nicht mehr alle Variablen auch mit ctlmgr_ctl abfragbar (schon gar nicht als Liste), diese Einschränkung sollte mit dem Skript nicht bestehen.

Das tar-File enthält zwei Dateien, eine ist das ausführbare Skript (queries.lua), das von STDIN einzelne Zeilen der Form "varname=query" liest, wobei "varname" der Name einer Shell-Variablen ist und "query" eine Abfrage von Variablen, wie man sie auch in jeder Lua-Seite des AVM-GUI finden kann. Das Ergebnis der Abfrage wird dann nach dem Variablennamen auf STDOUT ausgegeben, so daß man diese Zeilen als Shell-Variablenzuweisung weiterverarbeiten könnte. Bei Multiqueries sieht das noch etwas anders aus, der Aufbau der Variablen ist aber selbsterklärend.

Die zweite (test_usb) enthält einige Variablendefinitionen, die von AVM in usb_devices.lua benutzt werden, um die physikalischen Datenträger und die Partitionen auf diesen zu enumerieren - da würde ich im Moment die Quelle des Fehlers suchen wollen.

Ich würde also jemanden mit dem reproduzierbaren Fehler bitten, die Abfragen mal mit "./queries.lua < test_usb" ausführen zu lassen und zu schauen, ob dabei der ctlmgr auch abstürzt. Die "normale" Ausgabe (eine HDD mit 2 Partitionen am USB) würde z.B. so aussehen:

root@FB7490:~ $ ./queries.lua < test_usb
DEVICES="1"
PHYS_1_index="physmedium0"
PHYS_1_name="sys"
PHYS_1_vendor="WDC WD16"
PHYS_1_serial="0"
PHYS_1_fw_version="01.0"
PHYS_1_conntype="USB 2.0"
PHYS_1_capacity="155414663168"
PHYS_1_status="Online"
PHYS_1_usbspeed="480"
PHYS_1_model="00BEVE-11UYT0"
PHYS_count=1
PHYSCNT="1"
VOLS_1_index="logvol0"
VOLS_1_name="data"
VOLS_1_status="Online"
VOLS_1_enable="1"
VOLS_1_phyref="1"
VOLS_1_filesystem="ext3"
VOLS_1_capacity="121594040320"
VOLS_1_usedspace="19141115904"
VOLS_1_readonly="0"
VOLS_2_index="logvol1"
VOLS_2_name="system"
VOLS_2_status="Online"
VOLS_2_enable="1"
VOLS_2_phyref="1"
VOLS_2_filesystem="ext3"
VOLS_2_capacity="33820622848"
VOLS_2_usedspace="981565440"
VOLS_2_readonly="0"
VOLS_count=2
VOLSCNT="2"
PARTS="2"
root@FB7490:~ $

Wenn das problemlos funktioniert, muß man m.E. im Module "foncalls.lua" (und in der Folge in der C-Library libcallloglua.so) den Fehler suchen, was in der Library etwas problematisch werden dürfte. Dabei gehe ich immer davon aus, daß der Absturz beim Aufruf der "Telefonie" im GUI erfolgt, was in der Folge in die Abarbeitung der "foncalls_list.lua" mündet. Wenn das schon nicht stimmen sollte, bitte ich um entsprechende Rückmeldungen …

Eine mögliche Alternative wäre es, wenn jemand vor dem Aufruf der GUI-Seite, die zum Absturz führt, den ctlmgr mit "ctlmgr -s" beendet, ihn mit Protokollierung neu startet ("ctlmgr -m") und nach dem Absturz des ctlmgr diesen dann wieder ohne "-m" neu startet (damit der Watchdog die Box nicht neu bootet, während man das Ergebnis noch auswertet). Anschließend müßte sich aus der Datei /var/tmp/ctlmgrmsg.log auslesen lassen, welche Datenabfrage zum Absturz der vorherigen Instanz des ctlmgr geführt hat (als Kommunikation zwischen luacgi und ctlmgr).

Geändert vor 3 Jahren durch PeterPawn

tar-File enthält keine Verzeichnisse !

comment:199 Antwort: Geändert vor 3 Jahren durch JMC

Also ich hab meine Testbox wieder in einen Zustand gebracht der das Problem wieder auftreten lässt:

root@fritz:/var/media/ftp/uStor01# ./queries.lua < test_usb
DEVICES="1"
PHYS_1_index="physmedium0"
PHYS_1_name="uSto"
PHYS_1_vendor="CHIPSBNK"
PHYS_1_serial="0714330009AE8410"
PHYS_1_fw_version="5.00"
PHYS_1_conntype="USB 2.0"
PHYS_1_capacity="2088435712"
PHYS_1_status="Online"
PHYS_1_usbspeed="480"
PHYS_1_model="v3.3.8.8"
PHYS_count=1
PHYSCNT="1"
VOLS_1_index="logvol0"
VOLS_1_name="uStor01"
VOLS_1_status="Online"
VOLS_1_enable="1"
VOLS_1_phyref="1"
VOLS_1_filesystem="fat"
VOLS_1_capacity="2088435712"
VOLS_1_usedspace="39845888"
VOLS_1_readonly="0"
VOLS_count=1
VOLSCNT="1"
PARTS="1"
root@fritz:/var/media/ftp/uStor01#

Anbei dann mal ein auszug aus meiner ctlmgrmsg.log (das sind die letzten Zeilen, falls mehr benötigt wird kurz bescheid geben)

<1501.767268>ctlmgr:msg from luacgi4903: "<message><to>tam</to><from>luacgi4903</from><sequence>168</sequence><sid>82ff713d015dee76</sid><transaction><type>query</type><key>settings/TAM/list(Active,Name,Display,MSNBitmap)</key><error>0</error></transaction></message>"
<1501.776702>ctlmgr:msg OUT: "<message><to>luacgi4903</to><from>tam</from><sequence>222</sequence><transaction><type>response</type><key>settings/TAM/list(Active,Name,Display,MSNBitmap)</key><sequence>168</sequence><error>0</error><values><r><v>TAM0</v><v>1</v><v>Anrufbeantworter</v><v>1</v><v>1</v></r><r><v>TAM1</v><v>0</v><v></v><v>0</v><v>0</v></r><r><v>TAM2</v><v>0</v><v></v><v>0</v><v>0</v></r><r><v>TAM3</v><v>0</v><v></v><v>0</v><v>0</v></r><r><v>TAM4</v><v>0</v><v></v><v>0</v><v>0</v></r><r><v>TAM5</v><v>0</v><v>Anrufbeantworter</v><v>0</v><v>0</v></r><r><v>TAM6</v><v>0</v><v></v><v>0</v><v>0</v></r><r><v>TAM7</v><v>0</v><v></v><v>0</v><v>0</v></r><r><v>TAM8</v><v>0</v><v></v><v>0</v><v>0</v></r><r><v>TAM9</v><v>0</v><v></v><v>0</v><v>0</v></r></values></transaction></message>"
<1501.783018>ctlmgr:msg from luacgi4903: "<message><to>tam</to><from>luacgi4903</from><sequence>169</sequence><sid>82ff713d015dee76</sid><transaction><type>query</type><key>settings/MSN0</key><error>0</error></transaction></message>"
<1501.783933>ctlmgr:msg OUT: "<message><to>luacgi4903</to><from>tam</from><sequence>223</sequence><transaction><type>response</type><key>settings/MSN0</key><sequence>169</sequence><error>0</error><values><r><v>123457</v></r></values></transaction></message>"
<1501.785520>ctlmgr:msg from luacgi4903: "<message><to>tam</to><from>luacgi4903</from><sequence>170</sequence><sid>82ff713d015dee76</sid><transaction><type>query</type><key>settings/MSN1</key><error>0</error></transaction></message>"
<1501.786310>ctlmgr:msg OUT: "<message><to>luacgi4903</to><from>tam</from><sequence>224</sequence><transaction><type>response</type><key>settings/MSN1</key><sequence>170</sequence><error>0</error><values><r><v></v></r></values></transaction></message>"
<1501.788069>ctlmgr:msg from luacgi4903: "<message><to>tam</to><from>luacgi4903</from><sequence>171</sequence><sid>82ff713d015dee76</sid><transaction><type>query</type><key>settings/MSN2</key><error>0</error></transaction></message>"
<1501.789186>ctlmgr:msg OUT: "<message><to>luacgi4903</to><from>tam</from><sequence>225</sequence><transaction><type>response</type><key>settings/MSN2</key><sequence>171</sequence><error>0</error><values><r><v></v></r></values></transaction></message>"
<1501.790814>ctlmgr:msg from luacgi4903: "<message><to>tam</to><from>luacgi4903</from><sequence>172</sequence><sid>82ff713d015dee76</sid><transaction><type>query</type><key>settings/MSN3</key><error>0</error></transaction></message>"
<1501.791685>ctlmgr:msg OUT: "<message><to>luacgi4903</to><from>tam</from><sequence>226</sequence><transaction><type>response</type><key>settings/MSN3</key><sequence>172</sequence><error>0</error><values><r><v></v></r></values></transaction></message>"
<1501.793636>ctlmgr:msg from luacgi4903: "<message><to>tam</to><from>luacgi4903</from><sequence>173</sequence><sid>82ff713d015dee76</sid><transaction><type>query</type><key>settings/MSN4</key><error>0</error></transaction></message>"
<1501.794441>ctlmgr:msg OUT: "<message><to>luacgi4903</to><from>tam</from><sequence>227</sequence><transaction><type>response</type><key>settings/MSN4</key><sequence>173</sequence><error>0</error><values><r><v></v></r></values></transaction></message>"
<1501.796241>ctlmgr:msg from luacgi4903: "<message><to>tam</to><from>luacgi4903</from><sequence>174</sequence><sid>82ff713d015dee76</sid><transaction><type>query</type><key>settings/MSN5</key><error>0</error></transaction></message>"
<1501.797043>ctlmgr:msg OUT: "<message><to>luacgi4903</to><from>tam</from><sequence>228</sequence><transaction><type>response</type><key>settings/MSN5</key><sequence>174</sequence><error>0</error><values><r><v></v></r></values></transaction></message>"
<1501.798687>ctlmgr:msg from luacgi4903: "<message><to>tam</to><from>luacgi4903</from><sequence>175</sequence><sid>82ff713d015dee76</sid><transaction><type>query</type><key>settings/MSN6</key><error>0</error></transaction></message>"
<1501.799508>ctlmgr:msg OUT: "<message><to>luacgi4903</to><from>tam</from><sequence>229</sequence><transaction><type>response</type><key>settings/MSN6</key><sequence>175</sequence><error>0</error><values><r><v></v></r></values></transaction></message>"
<1501.801300>ctlmgr:msg from luacgi4903: "<message><to>tam</to><from>luacgi4903</from><sequence>176</sequence><sid>82ff713d015dee76</sid><transaction><type>query</type><key>settings/MSN7</key><error>0</error></transaction></message>"
<1501.802111>ctlmgr:msg OUT: "<message><to>luacgi4903</to><from>tam</from><sequence>230</sequence><transaction><type>response</type><key>settings/MSN7</key><sequence>176</sequence><error>0</error><values><r><v></v></r></values></transaction></message>"
<1501.804137>ctlmgr:msg from luacgi4903: "<message><to>tam</to><from>luacgi4903</from><sequence>177</sequence><sid>82ff713d015dee76</sid><transaction><type>query</type><key>settings/MSN8</key><error>0</error></transaction></message>"
<1501.804963>ctlmgr:msg OUT: "<message><to>luacgi4903</to><from>tam</from><sequence>231</sequence><transaction><type>response</type><key>settings/MSN8</key><sequence>177</sequence><error>0</error><values><r><v></v></r></values></transaction></message>"
<1501.806524>ctlmgr:msg from luacgi4903: "<message><to>tam</to><from>luacgi4903</from><sequence>178</sequence><sid>82ff713d015dee76</sid><transaction><type>query</type><key>settings/MSN9</key><error>0</error></transaction></message>"
<1501.807345>ctlmgr:msg OUT: "<message><to>luacgi4903</to><from>tam</from><sequence>232</sequence><transaction><type>response</type><key>settings/MSN9</key><sequence>178</sequence><error>0</error><values><r><v></v></r></values></transaction></message>"
<1501.808947>ctlmgr:msg from luacgi4903: "<message><to>tam</to><from>luacgi4903</from><sequence>179</sequence><sid>82ff713d015dee76</sid><transaction><type>query</type><key>settings/UseStick</key><error>0</error></transaction></message>"

Edit:
Auch bei 06.21 bleibt es bei mir so, dass nach Poweron/Firmwareupdate beim ersten mal ctlmgr abschmiert wenn man auf Telefoniegeräte/Rufnummern klickt. Nach einem erneuten Reboot ist es ok. Da habe ich auch mal mit ctlmgr -m getestet, da gehts aber noch weiter dann:

<210.719465>ctlmgr:msg from luacgi3820: "<message><to>tam</to><from>luacgi3820</from><sequence>179</sequence><sid>f569a89af0b0f1fa</sid><transaction><type>query</type><key>settings/UseStick</key><error>0</error></transaction></message>"
<210.721691>ctlmgr:msg OUT: "<message><to>luacgi3820</to><from>tam</from><sequence>227</sequence><transaction><type>response</type><key>settings/UseStick</key><sequence>179</sequence><error>0</error><values><r><v>2</v></r></values></transaction></message>"
<210.724162>ctlmgr:msg from luacgi3820: "<message><to>telcfg</to><from>luacgi3820</from><sequence>180</sequence><sid>f569a89af0b0f1fa</sid><transaction><type>query</type><key>settings/FaxMailActive</key><error>0</error></transaction></message>"
<210.725004>ctlmgr:msg OUT: "<message><to>luacgi3820</to><from>telcfg</from><sequence>228</sequence><transaction><type>response</type><key>settings/FaxMailActive</key><sequence>180</sequence><error>0</error><values><r><v></v></r></values></transaction></message>"
<210.734043>ctlmgr:msg from luacgi3820: "<message><to>box</to><from>luacgi3820</from><sequence>181</sequence><sid>f569a89af0b0f1fa</sid><transaction><type>query</type><key>status/localtime</key><error>0</error></transaction></message>"
[...]

Scheint also tatsächlich das UseStick der Knackpunkt zu sein?

Zuletzt geändert vor 3 Jahren von JMC (vorher) (Diff)

comment:200 als Antwort auf: ↑ 199 Geändert vor 3 Jahren durch PeterPawn

Replying to JMC:

Scheint also tatsächlich das UseStick der Knackpunkt zu sein?

Zumindest bei der 06.20 kommt ja offenbar auf die Abfrage von "tam:settings/UseStick" keine Antwort mehr zurück. Das Routing dieser Abfragen läuft alles über den ctlmgr, der seinerseits die Libraries für die verschiedenen Einstellungen aus /usr/share/ctlmgr lädt und so per Library erweiterbar wird.

Vielleicht kannst Du das ja noch einmal direkt mit einem "ctlmgr_ctl r tam settings/UseStick" oder auch durch ein

echo "USESTICK=tam:settings/UseStick" | ./queries.lua

ganz gezielt ohne jedes Lametta testen ?

Bei der 06.21 verstehe ich die Testbedingungen oder auch die Ergebnisse nicht so ganz (abgesehen davon, daß da endlich mal die beiden verbrieften Absturzstellen (telcfg und tam) direkt hintereinander auftauchen in der ctlmgr-Kommunikation). Stürzt die 06.21 nun unter identischen Voraussetzungen auch nach dem "initialen Absturz" genauso ab ? Das Protokoll würde das Überleben nahelegen …

Den ersten Absturz hatten wir, wenn ich es richtig verstanden habe, ja schon auf den "Kaltstart" für die USB-Geräte reduziert - wenn nicht, bitte noch einmal mit nachträglichem Anstecken des USB-Speichers verifizieren, auch wenn ich in Erinnerung habe, daß Du das nur vor Ort machen kannst, wo Du Dich nicht immer befindest.

comment:201 Geändert vor 3 Jahren durch JMC

root@fritz:/var/mod/root# ps w | grep ctlmgr
 4110 root     15444 S    /usr/bin/avm/ctlmgr
 4193 root      1332 S    {busybox} grep ctlmgr
root@fritz:/var/mod/root# echo "USESTICK=tam:settings/UseStick" | /var/media/ftp/UStor01/queries.lua
USESTICK="***no result***"
root@fritz:/var/mod/root# ps w | grep ctlmgr
 4404 root      1332 S    {busybox} grep ctlmgr

Die Abfrage dauert sehr lange (mit Sicherheit 15+ Sekunden) und wie zu sehen ist ist anschließend der ctlmgr weg. Das ist der Stand bei einem Kaltstart mit 06.21, das letzte Log in meinem vorherigen Post ist aus einem Warmstart und zeigt wie es danach weitergehen würde.

Nach einem Warmstart sieht es so aus:

root@fritz:/var/mod/root# echo "USESTICK=tam:settings/UseStick" | /var/media/ftp/UStor01/queries.lua
USESTICK="2"

comment:202 Antwort: Geändert vor 3 Jahren durch PeterPawn

Dann würde ich mal sagen, AVM hat ein Problem, was offenbar nur bei Freetz auftrat, in der 06.21-Laborversion beseitigt.

Bleibt am Ende noch die Frage übrig, was das nun eigentlich war und ob die ganzen Kopfstände in Freetz zumindest teilweise wieder rückgängig gemacht werden könnten. Auch wenn das Anpassen der Mount-/Dismount-Sequenz an das AVM-Vorgehen bei neueren Boxen (die eben auch zwei unabhängige USB-Slots haben können) sicherlich nicht sinnlos ist … das "Abschießen" von Diensten, die auf einem zweiten USB-Speicher weiterlaufen könnten, sollte dadurch deutlich seltener notwendig werden. Die Änderung der Schreibweise (auch wenn sie die Symptome linderte) braucht es ja vielleicht nicht mehr …

Zweite Frage ist dann, ob und wann es diese Möglichkeit auch für die 7390 und die kleineren Modelle geben wird … und was man im Freetz solange (oder anstelle dessen, falls sie gar nicht in absehbarer Zeit kommt) machen sollte.

Das Witzigste an der Sache ist aber für mich, daß die betreffenden Plugin-Libraries für den ctlmgr (libtamconf.so) bei beiden Versionen identisch sind … dann läge die Ursache des Fehler am Ende gar nicht in diesen Libraries - unabhängig davon, was die Backtraces da behauptet haben -, sondern diese würden ihrerseits schon mit falschen Parametern aufgerufen werden und die BTs gehen dann nicht weit genug zurück. Das ist alles schon sehr merkwürdig …

comment:203 Geändert vor 3 Jahren durch JMC

Ich glaube nicht, dass das Problem mit 06.21 einfach gelöst ist. In aktuellen Freetz Versionen sind ja die Freetzmount Änderungen eingebaut die dafür sorgen, dass das Problem nicht mehr auftritt. Das ist mit 06.20 genauso, ich habe kein erneutes downgrade gemacht weil es ja auch darum ging, ob das Problem mit der neuen Labor weg ist.

Ich werde nachher auf 06.20 downgraden und berichte dann ob ich das auch dort nachstellen bzw. nicht nachstellen kann (sprich: Nachstellen vor Freetzmount Änderungen, dort rechne ich mit dem gleichen Ergebnis. Nachstellen nach Freetzmount Änderungen, dort rechne ich damit, dass es genauso wie bei 06.21 ist)

Edit:
Blöd gelaufen, ich hab jetzt Probleme meine Box mit einem ganz alten 06.20er Image dazu zu bringen zu rebooten (ausser nach Kaltstart/Firmwareupdate) - das ist natürlich sehr kontraproduktiv…

Zuletzt geändert vor 3 Jahren von JMC (vorher) (Diff)

comment:204 Geändert vor 3 Jahren durch PeterPawn

Änderungen am FREETZMOUNT:

Da habe ich meinerseits gar nicht in das CS 12519 hineingesehen und ganz einfach die Beschreibung mißverstanden. Ich dachte, daß im FREETZMOUNT wieder das "uStor01" Standard wäre, es ist aber nur von "Label" auf "festen Präfix" wieder zurück geändert, uppercase am Beginn ist wohl noch drin.

Dann haben ja auch die anderen Nutzer, die z.B. für die 7490i von ähnlichen Problemen berichten (da allerdings mit Reboot-Schleife und ohne Fehlerprotokolle, so daß die Einschätzung, ob es sich auch um eine ähnliche Ursache handelt, schlicht unmöglich ist), bei sich bei der Verwendung von FREETZMOUNT einen großen Anfangsbuchstaben im Pfad. Das relativiert einige Überlegungen …

Mit "Nachstellen" meinst Du das Herunterbrechen auf den einen Aufruf des ctlmgr für die Abfrage von "UseStick" ? Wenn Du das wirklich mit beiden Versionen an diesem einen Aufruf festmachen kannst und mir netterweise auch noch von den beiden Abstürzen dann das dazugehörige crash.log anhängst, dann macht es langsam wirklich Sinn, vom Absturzpunkt an mal rückwärts mit einem Debugger durch den Code zu steppen. Bisher ist das einfach viel zu viel auf einmal und der ctlmgr mag es überhaupt nicht, wenn man ihm mit einem Debugger zuleibe rückt (jedenfalls nicht, solange der Watchdog die Box neu starten darf).

Ich habe auch noch eine weitere Bitte zu einer Überlegung, die zwar etwas mystisch klingt, aber die man vielleicht auch definitiv ausschließen sollte: Der ctlmgr wird ja bei Freetz (allerdings ist das von FREETZMOUNT unabhängig und da schleift dann auch die Logik schon ein wenig - jedoch wohl auch nicht schlimmer als bei der Auswertung des Patterns nach Groß-/Kleinschreibung) nicht direkt gestartet, sondern über den Umweg eines Helper-Skripts, das eine eigene Library vor die libc lädt (allerdings nur für das Umbenennen von Dateien und das spielt hier dummerweise wahrscheinlich auch wieder keine Rolle, deshalb ist die Theorie eben auch eher esoterisch). Das läßt sich (ohne gravierende Auswirkungen, solange man keine neuen User im Freetz hinzufügt und nur nach dem, was ich dazu bisher gesehen habe - zu den Auswirkungen können die Autoren sicherlich am ehesten etwas sagen) mit einem einzigen Copy-Kommando in der fwmod.custom wieder rückgängig machen, indem man einfach das Binary wieder von /usr/bin/avm/ctlmgr nach /usr/bin/ctlmgr zurückkopiert (und ein Image mit FREETZMOUNT erstellt). Ich habe - wie gesagt - keine logische Begründung … nur das dumpfe Gefühl, daß sich die libctlmgr.so eben in den DynLink-Prozess genau der libc.so einklinkt und dort eine Funktion (zugegenermaßen aber eben eine andere) ersetzt. Wenn jetzt irgendwo in den DynLib-Funktionen beim lazy-Linken eine Stub nicht richtig aufgelöst wird - woher dieses Problem auch immer plötzlich auftauchen mag, ich war sogar schon auf dem Trip, es könnte an dem Doppelprozessor und einer Race-Condition liegen - dann könnte das auch eine zumindest denkbare Ursache sein und um das einfach auszuschließen, wäre ein Test ohne libctlmgr.so imho der einfachste Weg. Stürzt die Box dann genauso ab, kann man diese Überlegungen beruhigt beiseite legen … allerdings kostet Dich das einen weiteren Versuch mit einem nochmals abgewandelten Image.

comment:205 Geändert vor 3 Jahren durch JMC

Das mit den Reboot-Schleifen und ohne Fehlerprotokolle hatte ich ja auch als ich noch den Faxempfang auf dem Stick eingerichtet hatte. Nachdem ich das deaktiviert hatte war das bei mir verschwunden… Vielleicht trifft das ja bei den anderen auch zu?

Nachstellen meinte ich in dem Fall generell den crash bzw. das UseStick ja. Leider ist meine Testumgebung mittlerweile so "fest", dass ich nur noch beim Kaltstart/Firmwareupdate einen ctlmgr Crash hinbekomme. Nich mehr nach säteren reboots - auch mit der derzeit letzten Version die ich da habe r12451 nicht. Und diese Version hat anfangs definitiv Probleme gehabt.

Ich bin durchaus bereit noch einiges zu flashen und zu tun um zu helfen das Problem einzukreisen oder helfen es zu finden. Wenn du sagst ohne libctlmgr.so mit abgewandeltem Image - was soll ich tun?

comment:206 als Antwort auf: ↑ 202 Geändert vor 3 Jahren durch make

Die 6.21 Beta ist seit heute auch für die 7390 verfügbar. Allerdings gehört meine 7390 nicht zu denjenigen, bei denen das Reboot-Problem nach der Umstellung auf den führenden Grossbuchstaben noch reproduziert werden kann. Macht es trotzdem Sinn, das Upgrade einzuspielen und dein Skript auszuführen?

Zweite Frage ist dann, ob und wann es diese Möglichkeit auch für die 7390 und die kleineren Modelle geben wird … und was man im Freetz solange (oder anstelle dessen, falls sie gar nicht in absehbarer Zeit kommt) machen sollte.

comment:207 Geändert vor 3 Jahren durch PeterPawn

Ja, habe ich dann kurz nach dem Absenden des Ticket-Kommentars auch gleich gesehen, da war sie noch "frisch". Das überraschte mich auf der einen Seite, läßt aber imho auch den Schluß zu, daß für AVM die Umstellung der Boxen auf 06.20 letztlich durch ist und da wohl nicht mehr so viele neue Versionen für die bisher nicht versorgten Modelle kommen werden (und einige - selbst mit VR9 - fehlen da imho schon noch).

Allerdings gehört meine 7390 nicht zu denjenigen, bei denen das Reboot-Problem nach der Umstellung auf den führenden Grossbuchstaben noch reproduziert werden kann.

Kann ich das jetzt wirklich so interpretieren, daß bei Dir auch die Umstellung auf den Großbuchstaben als Workaround funktioniert hat ? Bisher fehlten zwar weitere - eindeutig zuzuordnende - negative Meldungen zu diesem Thema/Ticket, aber eben auch die positiven Rückmeldungen, daß der Workaround funktioniert.

Macht es trotzdem Sinn, das Upgrade einzuspielen und dein Skript auszuführen?

Denke ich dann eher nicht … außer Du willst es anstelle von "ctlmgr_ctl r" irgendwo anders benutzen, weil es auch Listen (auch teilweise, was AVM selbst nur einmal benutzt) abfragen kann ;-) Ich habe das irgendwo auch noch zum Setzen von Variablen (cmtable), falls es jemand brauchen kann - auch "ctlmgr_ctl w" hat ja seine Beschränkungen.

@JMC

Ich bin nicht so richtig sicher, ob der Test ohne libctlmgr.so sinnvoll ist, wenn das Problem nicht mehr eindeutig zu reproduzieren ist. Beim zweiten Anlauf ist das Problem ja ohnehin verschwunden, wenn ich Dich richtig verstehe (also auch bei der direkten Abfrage von "UseStick", mit originalem FREETZMOUNT-Mountpoint (uStor01) und Nachrichten auf dem Stick). Also könnte der Test nur noch eine Aussage zum "Kaltstart" erbringen … wenn der sich auf einen "Kaltstart" der ganzen Box und nicht nur der USB-Geräte bezieht (das wäre der Test mit dem Abziehen und Anstecken gewesen, der aber ja nun nicht mehr funktioniert, wenn der Absturz nicht zuverlässig auftritt), bringt das wahrscheinlich weniger. Bei einem Neustart der Box durch PoR sind die Abläufe ja ohnehin etwas anders (deshalb hilft der wohl auch bei einigen Problemen, die ansonsten unerklärlich sind).

Ich wüßte zu gerne, warum ich diesen Fehler auf "Teufel komm raus" nicht reproduzieren kann … ich habe inzwischen schon vieles versucht, allerdings mehr bei der Test-7390, was ja aber eigentlich auch funktionieren müßte.

Wenn Du die Idee mit dem Auslassen der libctlmgr.so trotzdem wirklich mal testen willst (Ralf oder oliver können sicherlich noch etwas dazu sagen, welche anderen Auswirkungen das hat - ich habe nur den geblockten Rename-Zugriff auf /var/tmp/passwd.tmp gesehen und keine Ahnung, was in "modusers update" anstelle dessen gemacht wird), dann bräuchtest Du wohl nur für die Dauer des 'make' das File 'patches/scripts/105-add_ctlmgr-wrapper.sh' entfernen (oder umbenennen, die Endung ".sh" müßte weg). Aber wie schon geschrieben … es ist mehr Bauchgefühl als klar begründbarer Verdacht (es ist halt "die Gegend") - auch wenn es imho nicht vollkommen an den Haaren herbeigezogen ist.

@er13:

Wenn allerdings wirklich die Umstellung auf den Großbuchstaben künftig erhalten bleiben soll(te), dann muß man wohl noch einmal durch den gesamten Trunk gehen und irgendetwas für/gegen die Standard-Einstellungen vieler Pakete machen, da steht wohl auch häufig das /var/media/ftp/uStor01 direkt drin. Was hältst Du von einem (zugegebenermaßen auch nicht ganz sauberen) Workaround, bei dem parallel zum Mountpoint mit dem großen Anfangsbuchstaben noch ein Symlink auf den anderen Namen angelegt wird, damit die vielen Pakete nicht angefaßt werden müssen und sich gleichzeitig die Auswirkungen bei der Migration von älteren Images für die Nutzer in Grenzen halten ?

comment:208 Antworten: Geändert vor 3 Jahren durch CarstenSchuette

Vielleicht hilft euch die Info, dass ich den faxd-Crash beim Boot der Box oder eben beim Aktivieren des Fax-Dienstes über das WebUI mit der 6.20er nachvollziehen kann, in dem ich beim Faxdienst angebe, dass die eingehenden Faxe auf dem USB-Stick gespeichert werden sollen.

Ich brauche im Moment eine stabile Box, daher kann ich die 6.21er aktuell nicht selbst testen.

Zuletzt geändert vor 3 Jahren von CarstenSchuette (vorher) (Diff)

comment:209 als Antwort auf: ↑ 208 ; Antwort: Geändert vor 3 Jahren durch PeterPawn

Replying to CarstenSchuette:

Vielleicht hilft euch die Info, dass ich den faxd-Crash beim Boot der Box oder eben beim Aktivieren des Fax-Dienstes über das WebUI mit der 6.20er nachvollziehen kann, in dem ich beim Faxdienst angebe, dass die eingehenden Faxe auf dem USB-Stick gespeichert werden sollen. Ich brauche im Moment eine stabile Box, daher kann ich die 6.21er aktuell nicht selbst testen.

Wenn das dann reproduzierbar ist, keine Reboot-Schleife auslöst und beim Crash in a1 auch die ersten vier Zeichen des Mountpoints stehen (wie in comment 30), wäre das ein "schöner Fehler". Auch dabei müßte man dann aber ganz genau unterscheiden, wann der Absturz wirklich erfolgt (beim Abfragen, beim Setzen oder beim Benutzen der Einstellung). Bei den Anrufen hat das JMC dann bis zu einem einzelnen Zugriff auf eine bestimmte Variable in der libtamconf.so heruntergebrochen, bevor es bei ihm jetzt plötzlich leider weg ist. Wenn das beim faxd auch möglich ist, hätte man einen zweiten Anhaltspunkt. Allerdings würde mich das dann wirklich langsam verrückt machen, denn die Einstellung für den faxd, auf USB-Speicher zuzugreifen, führt ja bei JMC wohl zur Reboot-Schleife und da stellt sich dann wieder die Frage, warum das bei Dir anders wäre - wenn es derselbe Fehler ist.

Die im comment 198 (letzter Absatz) beschriebene Kommandofolge, um den konkreten Zugriff zu ermitteln, bei dem die Box dann abstürzt, kann man auf den faxd letztlich wahrscheinlich genauso anwenden. Auch der faxd dürfte für den Zugriff auf Einstellungen auf den ctlmgr zurückgreifen … da sollte sich auch etwas in der ctlmgrmsg.log finden. Kann man einen einzelnen Zugriff isolieren, kann man es auch gezielt testen.

comment:210 als Antwort auf: ↑ 209 ; Antwort: Geändert vor 3 Jahren durch CarstenSchuette

Replying to PeterPawn:

Wenn das dann reproduzierbar ist, keine Reboot-Schleife auslöst und beim Crash in a1 auch die ersten vier Zeichen des Mountpoints stehen (wie in comment 30), wäre das ein "schöner Fehler".

Mein crashlog steht im comment 18, und ja, es stehen die ersten vier Zeichen des Mountpoints in der Adresse. Wie gesagt, das war und ist bei mir mit der 06.20er nachvollziehbar, sobald ich dem Faxdienst sage, er soll die eingehenden Faxe auf dem USB-Stick speichern.

Auch dabei müßte man dann aber ganz genau unterscheiden, wann der Absturz wirklich erfolgt (beim Abfragen, beim Setzen oder beim Benutzen der Einstellung).

Der Crash erfolgt beim Setzen der Einstellung und reißt das WebIF mit. Die Einstellung wird nicht übernommen, das heißt nach einem Boot der Box scheint wieder alles in Ordnung zu sein. Nur, dass eben die Einstellungen des Faxdienstes nicht übernommen wurden.

führt ja bei JMC wohl zur Reboot-Schleife und da stellt sich dann wieder die Frage, warum das bei Dir anders wäre

Ich finde das eigentlich ganz logisch:

Wenn man aber eine alte Config mit einer Vorgänger-Firmware nimmt, in der der Faxdienst entsprechend konfiguriert ist, und dann die Firmware auf eine 06.20er-Version mit Freetz aktualisiert, dann tritt die Bootloop auf, weil der faxd beim Booten der Box crasht und die Box mitreißt.

Übernimmt man die Einstellungen nur selektiv in die 06.20er, läuft das so lange, bis man die Telefoniegeräte mit übernimmt, denn da stecken wieder die Faxdienst-Einstellungen mit dem USB-Speicherort drin. Darum konnten einige hier die Box mit einer sauberen 06.20er-Installation und übernommener Konfiguration ohne Faxdienst-Einstellungen wieder zum Leben erwecken.

Und ich würde mal behaupten, alle, die diese Probleme nicht hatten, nutzen entweder nicht den integrierten Faxdienst oder haben ihn so eingestellt, dass er eingehende Faxe nicht auf dem USB-Stick speichert.

Zuletzt geändert vor 3 Jahren von CarstenSchuette (vorher) (Diff)

comment:211 als Antwort auf: ↑ 208 Geändert vor 3 Jahren durch make

Guter Hinweis, Carsten! In dem Moment in dem ich das Speichern von eingehenden Faxnachrichten auf dem Stick einschalte (ist bei mir normalerweise deaktiviert), ist das Web-UI futsch. Mein crash.log (FB 7390, 06.21-29345) sieht folgendermassen aus:

# cat /var/flash/crash.log
2014-11-11 08:16:28(1) [Segmentation fault] /usr/bin/avm/ctlmgr(1361) CRASHED at strcmp+0xc (/lib/libc.so.0 at 00038a2c) accessing 0+0x5553746e (/lib/libz.so.1 at 29ce346e)
SIGNO 11 ERRNO 0 CODE 1
Version: 06.21-29345
Watchdog triggered 7 seconds ago
No bugmsg
ze: 00000000 at: 00000001 v0: 2ae62a20 v1: 00000046
a0: 2b0cd52b a1: 5553746f a2: 55537470 a3: 2b0cd52c
t0: 00000000 t1: 00000000 t2: 0000005b t3: ffffff80
t4: 00000063 t5: 00000073 t6: 0000005b t7: 632f6275
s0: 2b0d4c30 s1: 2b89ca40 s2: 2b6a08f0 s3: 2b52ebc0
s4: 2b516030 s5: 2b6a03e0 s6: 2b7284c8 s7: 2b5160e0
t8: 00000000 t9: 2ae62a20 k0: 00000001 k1: 00000000
gp: 2b0d4c30 sp: 7feaeb40 fp: 2b6a0240 ra: 2b08d53d
FA 5553746e 0+0x5553746e (/lib/libz.so.1 at 29ce346e)
PC 2ae62a2c strcmp+0xc (/lib/libc.so.0 at 00038a2c)
RA 2b08d53c 0+0x2b08d53c (/usr/share/ctlmgr/libtelcfg.so at 0000353c)
Code: 90830000  24870001  24a60001 <14600003> 90a20000  03e00008  00021023  00e02021  1062fff7
[bt]  2b08d538 [2b08d48a] <0+0x2b08d48b>+0xae (/usr/share/ctlmgr/libtelcfg.so at 0000348a)
[bt]  2b09a26c [2b09a1ae] <0+0x2b09a1af>+0xbe (/usr/share/ctlmgr/libtelcfg.so at 000101ae)
Signal Segmentation fault while doing crashdump (2)
2014-11-11 08:16:28(2) [Segmentation fault] /usr/bin/avm/ctlmgr(1361) CRASHED at 0+0x2ad50cd8 (/lib/libavmcsock.so.2 at 00051cd8) accessing 0+0x2b611ffc (/lib/libphonebook.so at 000dfffc)
SIGNO 11 ERRNO 0 CODE 2
ze: 00000000 at: 2b89d05b v0: ffff0000 v1: 2b612008
a0: 3c1c0000 a1: ffff8000 a2: 27bd8000 a3: 279c0000
t0: 00000000 t1: 00000000 t2: 00000000 t3: 00000000
t4: 00000080 t5: 7f000001 t6: 0041257c t7: 0399e021
s0: ffff0000 s1: 2ad4f3a0 s2: 00000000 s3: 7feaed28
s4: 2b09a1af s5: 000064f7 s6: 2b6a0ca0 s7: 00000000
t8: 00000000 t9: 2ae899d4 k0: 00000001 k1: 00000000
gp: 2ad820a0 sp: 7feae0e0 fp: 2b6a0240 ra: 2ad511b4
FA 2b611ffc 0+0x2b611ffc (/lib/libphonebook.so at 000dfffc)
PC 2ad50cd8 0+0x2ad50cd8 (/lib/libavmcsock.so.2 at 00051cd8)
RA 2ad511b4 0+0x2ad511b4 (/lib/libavmcsock.so.2 at 000521b4)
Code: 2474fff8  10000019  01708025 <8c6bfff4> 004b5824  1564000f  00000000  1547000d  00000000
[bt]  2ad511ac [2ad50a14] <0+0x2ad50a14>+0x798 (/lib/libavmcsock.so.2 at 00051a14)
[bt]  2ad50000 [2ad4f65c] <0+0x2ad4f65c>+0x9a4 (/lib/libavmcsock.so.2 at 0005065c)
[bt]  !7feae820 rtsignal trampoline on stack
[bt]  2ae62a24 mempcpy+0x444 (/lib/libc.so.0 at 000385e0)

a1: 5553746f → 'USto' a2: 55537470 → 'UStp'
accessing 0+0x5553746e → 'UStn'

Vielleicht hilft euch die Info, dass ich den faxd-Crash beim Boot der Box oder eben beim Aktivieren des Fax-Dienstes über das WebUI mit der 6.20er nachvollziehen kann, in dem ich beim Faxdienst angebe, dass die eingehenden Faxe auf dem USB-Stick gespeichert werden sollen.

Zuletzt geändert vor 3 Jahren von make (vorher) (Diff)

comment:212 Geändert vor 3 Jahren durch JMC

Ich denke das Ticket ist einfach viel zu lang, denn das mit dem Fax speichern auf den USB-Stick hatten wir vor gefühlten 2 Monaten schon. Es geht leider einfach zuviel verloren scheinbar.

@PeterPawn:
Test ohne libctlmgr.so mache ich im laufe des Tages mal und Berichte dann, im schlimmsten fall steht dann ein recover an wenn mehr in Mitleidenschaft gezogen sein sollte. Nicht wild bei der Testbox

comment:213 als Antwort auf: ↑ 210 Geändert vor 3 Jahren durch PeterPawn

Replying to CarstenSchuette:

Ich finde das eigentlich ganz logisch:

So ist das ja auch wieder logisch … und auch genau der Fehler, mit dem Du die Kommunikation des ctlmgr einfach mal mitschneiden solltest.

Wir haben uns nur deshalb mißverstanden, weil Du etwas von einem "faxd-Crash" geschrieben hast und den hatten wir hier eben auch schon (comment 34 30). Wenn es bei Dir wie in comment 18 - genauso wie bei make in 211 - der ctlmgr ist, der da den Geist aufgibt, sind wir m.E. an der richtigen Stelle. Trotzdem kann ich den Fehler bei mir nicht reproduzieren, weder mit einer pre-06.20-Config mit aktiviertem Faxempfang auf USB-Stick (eigentlich Platte, aber das sollte hoffentlich nichts machen, ich habe keine andere) nach dem Update, noch beim nachträglichen Aktivieren des Faxempfangs. Die Beschreibung dieses Fehlers hatten wir von JMC ja schon mal (eben mit der erwähnten Reboot-Schleife), deshalb hatte ich das auch schon bei mir getestet.

@JMC:

Ich sage mal, wir haben eben kein anderes Ticket. Ich sehe weniger die Länge (die Anzahl der Kommentare) als das Problem an, als vielmehr die zeitliche Streckung und die Ungewißheit, wo der Workaround funktioniert und wo nicht. Es begann mit einer Labor-Version für die 7490 und zog sich über diverse Symptome bis zum heutigen Stand (06.20 auf mehreren Modellen) hin. Vielleicht - nur meine Meinung - sollte man wirklich einfach das Ticket schließen und die Meldungen der Leute mit immer noch aktuellen Problemen dazu noch einmal mit den heutigen Fehlern in einem neuen aufnehmen.

Was mir ehrlich gesagt vollkommen fehlt, sind Fehlermeldungen für andere Modelle mit existierender 06.20 … wenn sich das auf Modelle mit S0-Bus (CONFIG_CAPI_NT=y ???) beschränkt - bisher meines Wissens eben nur bei 7490 und 7390 aufgetreten -, wäre das ja auch ein Hinweis. Daß es irgendetwas mit der Konfiguration von Faxempfang und Anrufbeantworter im Zusammenhang mit der Speicherung auf dem USB-Speicher zu tun hat, wissen wir ja schon seit ca. 8 Wochen … wir kriegen es bloß nicht systematisiert und auf die wirkliche Ursache eingegrenzt, weil offensichtlich viele Randbedingungen dort hineinspielen. Ich würde auch behaupten, daß viele Deine Voraussetzung für den reproduzierbaren Absturz mit der existierenden Nachricht auf dem AB gar nicht richtig verstanden haben (comment 89, Abs. 1 … ich hoffe mal, ich habe das nicht meinerseits mißverstanden) und u.U. bei ihnen nur deshalb der Fehler verschwunden ist, weil keine alten Nachrichten auf dem AB sind.

Zuletzt geändert vor 3 Jahren von PeterPawn (vorher) (Diff)

comment:214 Antwort: Geändert vor 3 Jahren durch make

Nur mal so ins Blaue hinein geraten: Könnte das Problem vielleicht mittelbar damit zusammen hängen, ob auf dem USB-Device ein bestimmter Filesystem-Typ vorhanden ist oder nicht? Auf meinem wären derzeit vFAT, ext2 und eine aktivierte swap-Partition. Ist die Swap-Partition vielleicht die gesuchte Randbedingung?

comment:215 Antworten: Geändert vor 3 Jahren durch PeterPawn

@make: Wir raten ja alle nur fleißig … die Frage des Dateisystems an sich hatten wir in 88/89 schon mal, vielleicht haben wir sie ja auch zu früh verworfen. Die Frage bei der swap-Partition wäre dann aber (ich habe auch eine drauf, die wird sogar unter original Firmware verwendet), ob deren Vorhandensein das Auftreten des Fehlers verhindert. Wenn bei Dir (mit swap-Part.) der Absturz trotzdem erfolgt, bin ich etwas unentschieden, dort zu suchen …

Aber Du kannst ja offenbar den Fehler von CarstenSchuette und JMC bei Dir auch reproduzieren. Wenn Du die Kommunikation des ctlmgr mitschneiden läßt (cmt. 198, letzter Absatz), was steht denn dann in den letzten Zeilen der ctlmgrmsg.log ?

@all: Mir ist aber im Zusammenhang mit meinem vorherigen Kommentar zum ISDN noch etwas aufgefallen, was ich den bisherigen Kommentaren nicht eindeutig entnehmen kann. Neben der reinen ISDN-Möglichkeit in der Box (da gibt es viele potentielle Nutzer) könnte ja auch noch die reale Verwendung der ISDN-Funktionen eine Rolle spielen.

Um nun nicht jeden mit dem Fehler einzeln um die Angabe seiner Konfiguration zu bitten - das macht das Ticket nur noch länger -, wüßte ich nur gerne, ob das auch bei jemandem auftritt, der in seiner Konfiguration garantiert keine ISDN-Funktionen benutzt. Dazu gehört nicht nur, daß der S0 weder intern noch extern angeschlossen ist, sondern eben auch, daß der Telefonieteil (mit der leider binären Konfigurationsdatei) definitiv nicht auf "möglicher ISDN-Anschluß" (also Festnetzanschluß mit mehreren Rufnummern) eingerichtet wurde und auch keine derartige Konfiguration importiert wurde. Mir ist bewußt, daß das eine recht hohe Hürde für eine Aussage ist, weil man u.U. die Box neu konfigurieren muß … aber wenn es niemanden gibt, der diese Eingangsvoraussetzungen erfüllt, kann man die ja immer noch herunterschrauben.

Ich werde mal im Anschluß versuchen, eine Zusammenstellung an ctlmgr-Abfragen zu finden, mit denen man sich sicher sein kann (im Rahmen meiner Annahmen zur AVM-Konfiguration), ob "die Box denkt, sie wäre ISDN" oder nicht … vielleicht läßt sich damit dann ein Ansatz finden.

Der Zusammenhang zwischen ISDN und USB ist sicherlich auf den ersten Blick auch nicht vollkommen einleuchtend, aber da braucht bei AVM in der Firmware bloß eine einzige Abfrage als Weiche vorhanden sein, damit komplette Code-Teile anders abgearbeitet werden. Die Vermeidung von Redundanzen im Code ist nicht unbedingt eine Priorität oder Stärke, wenn man von sichtbaren AVM-Änderungen in OSS-Quellen oder in sichtbaren Firmware-Teilen ausgeht und was einmal funktioniert, wird sicherlich ohne Not nicht wieder angefaßt und optimiert.

comment:216 als Antwort auf: ↑ 215 ; Antwort: Geändert vor 3 Jahren durch isar03

Hallo liebe Experten,

ich bin zwar nur Nutzer und kein Entwickler, aber bei mir trat dieses Problem unter folgenden Bedingungen auf (FB 7490 auf 6.10 und 6.20):

  • Festplatte am USB port (nur FAT32)
  • kein Fax eingerichtet
  • 1 AB eingerichtet, Speicherung aber intern (NICHT) auf USB
  • Freetz mit (nur) Telefonsparbuch

Das Problem trat in der 6.10 erstmals auf, NACHDEM ich meinen ISDN Anschluß auf einen Telekom IP Anschluß umgerüstet habe:

  • Nutzung Festnetz abgeschaltet
  • 3 IP Rufnummern konfiguriert
  • 2 neue Telefoniegeräte (DECT jetzt direkt mit FB) eingerichtet

Nach dem Neustart der Box führt jeder Klick auf ein Submenü von "Telefonie" zu einen "Freeze" und wenige Minuten später zum Reboot.

Vielleicht hilft das ja weiter?

Replying to PeterPawn:

@make: Wir raten ja alle nur fleißig … die Frage des Dateisystems an sich hatten wir in 88/89 schon mal, vielleicht haben wir sie ja auch zu früh verworfen. Die Frage bei der swap-Partition wäre dann aber (ich habe auch eine drauf, die wird sogar unter original Firmware verwendet), ob deren Vorhandensein das Auftreten des Fehlers verhindert. Wenn bei Dir (mit swap-Part.) der Absturz trotzdem erfolgt, bin ich etwas unentschieden, dort zu suchen …

Aber Du kannst ja offenbar den Fehler von CarstenSchuette und JMC bei Dir auch reproduzieren. Wenn Du die Kommunikation des ctlmgr mitschneiden läßt (cmt. 198, letzter Absatz), was steht denn dann in den letzten Zeilen der ctlmgrmsg.log ?

@all: Mir ist aber im Zusammenhang mit meinem vorherigen Kommentar zum ISDN noch etwas aufgefallen, was ich den bisherigen Kommentaren nicht eindeutig entnehmen kann. Neben der reinen ISDN-Möglichkeit in der Box (da gibt es viele potentielle Nutzer) könnte ja auch noch die reale Verwendung der ISDN-Funktionen eine Rolle spielen.

Um nun nicht jeden mit dem Fehler einzeln um die Angabe seiner Konfiguration zu bitten - das macht das Ticket nur noch länger -, wüßte ich nur gerne, ob das auch bei jemandem auftritt, der in seiner Konfiguration garantiert keine ISDN-Funktionen benutzt. Dazu gehört nicht nur, daß der S0 weder intern noch extern angeschlossen ist, sondern eben auch, daß der Telefonieteil (mit der leider binären Konfigurationsdatei) definitiv nicht auf "möglicher ISDN-Anschluß" (also Festnetzanschluß mit mehreren Rufnummern) eingerichtet wurde und auch keine derartige Konfiguration importiert wurde. Mir ist bewußt, daß das eine recht hohe Hürde für eine Aussage ist, weil man u.U. die Box neu konfigurieren muß … aber wenn es niemanden gibt, der diese Eingangsvoraussetzungen erfüllt, kann man die ja immer noch herunterschrauben.

Ich werde mal im Anschluß versuchen, eine Zusammenstellung an ctlmgr-Abfragen zu finden, mit denen man sich sicher sein kann (im Rahmen meiner Annahmen zur AVM-Konfiguration), ob "die Box denkt, sie wäre ISDN" oder nicht … vielleicht läßt sich damit dann ein Ansatz finden.

Der Zusammenhang zwischen ISDN und USB ist sicherlich auf den ersten Blick auch nicht vollkommen einleuchtend, aber da braucht bei AVM in der Firmware bloß eine einzige Abfrage als Weiche vorhanden sein, damit komplette Code-Teile anders abgearbeitet werden. Die Vermeidung von Redundanzen im Code ist nicht unbedingt eine Priorität oder Stärke, wenn man von sichtbaren AVM-Änderungen in OSS-Quellen oder in sichtbaren Firmware-Teilen ausgeht und was einmal funktioniert, wird sicherlich ohne Not nicht wieder angefaßt und optimiert.

comment:217 als Antwort auf: ↑ 215 Geändert vor 3 Jahren durch JMC

Replying to PeterPawn:

Um nun nicht jeden mit dem Fehler einzeln um die Angabe seiner Konfiguration zu bitten - das macht das Ticket nur noch länger -, wüßte ich nur gerne, ob das auch bei jemandem auftritt, der in seiner Konfiguration garantiert keine ISDN-Funktionen benutzt. Dazu gehört nicht nur, daß der S0 weder intern noch extern angeschlossen ist, sondern eben auch, daß der Telefonieteil (mit der leider binären Konfigurationsdatei) definitiv nicht auf "möglicher ISDN-Anschluß" (also Festnetzanschluß mit mehreren Rufnummern) eingerichtet wurde und auch keine derartige Konfiguration importiert wurde. Mir ist bewußt, daß das eine recht hohe Hürde für eine Aussage ist, weil man u.U. die Box neu konfigurieren muß … aber wenn es niemanden gibt, der diese Eingangsvoraussetzungen erfüllt, kann man die ja immer noch herunterschrauben.

Bei mir wurde die Ursprungsbox mal mit ISDN betrieben, dann aber auf einen reinen IP-Anschluss gewechselt und entsprechend ist die Box und auch die Testbox konfiguriert. Ich weiß nicht ob da evtl. noch "Reste" vorhanden sind, sehen tue ich aber nur die IP-Only Config.

comment:218 als Antwort auf: ↑ 216 ; Antwort: Geändert vor 3 Jahren durch PeterPawn

Replying to isar03:

NACHDEM ich meinen ISDN Anschluß auf einen Telekom IP Anschluß umgerüstet habe: - Nutzung Festnetz abgeschaltet

Danke für die konkrete Beschreibung. Fragen:

  1. "abgeschaltet" meint "Haken raus" bei "Festnetz aktiv" ? Das wäre dann (meine Meinung) intern (in den Einstellungen) immer noch ein ISDN-Anschluß, eben nur ohne aktives Festnetz. Die Antwort erübrigt sich, wenn meine Annahme stimmt … nur wenn ich falsch liege, bitte meine falsche Annahme korrigieren.
  1. Ist das Fehlerbild fix und reproduzierbar … und zwar in diesem Moment und Du könntest (und würdest) etwas testen ?

jeder Klick auf ein Submenü von "Telefonie"

  1. Ist das wirklich erst bei einem Submenü (dann würde der erste Klick auf "Telefonie" ja noch problemlos laufen, bei dem aber auch schon die Anrufliste (foncalls_list.lua) rechts angezeigt wird, was bei JMC zum Absturz führte) der Fall oder habe ich das mißverstanden ?

Freetz mit (nur) Telefonsparbuch

  1. Meint das mit oder ohne FREETZMOUNT ?

Wenn Du auf 2. mit "ja" für beide Teile antworten würdest, auch an Dich die Bitte folgende Tests (Telnetzugang erforderlich, ansonsten nicht sinnvoll) auszuführen:

  1. mit dem Skript zwischen 198 und 199 den Test
echo "ABC=tam:settings/UseStick" | sh ./queries.lua

ausführen. Kommt da nicht innerhalb von max. 3 Sekunden eine Reaktion der Art 'ABC="…"', ist der ctlmgr abgestürzt und Du kannst ihn mit einem einfachen 'ctlmgr' neu starten und damit den Reboot vermeiden. Dann wüßten wir aber ein ganz konkretes Kommando, mit dem man bei Dir einen Absturz auslösen kann.

  1. Wenn 1. einen reproduzierbaren Fehler ergibt, bitte mal den Festnetzanschluß wieder aktivieren, alle event. noch vorhandenen Festnetznummern löschen und dann eine neue Festnetznummer einrichten. Theoretisch sollte die Box dann mit der Frage "Eine oder mehrere Festnetzrufnummern ?" reagieren und bei der Auswahl "eine" dann wirklich auf "analog" umschalten. Anschließend den Festnetzanschluß meinetwegen auch wieder deaktivieren (obwohl auch ein Test mit aktivem Festnetz nicht uninteressant wäre) und den Test aus 1. noch einmal ausführen.
  1. Wenn 2. auch zum Fehler führt, kannst Du dann mal einfach die Festplatte sicher entfernen lassen und ca. 1 Minute später (etwas Zeit lassen, damit alle Prozesse vom Dismount wissen) noch einmal 1. testen ? Die Frage ist, ob das Vorhandensein der Platte ausreicht (auch ohne Speicherung von AB-Nachrichten darauf, das hatten wir auch schon einmal weiter oben), um den Absturz auszulösen.

BTW: "Nur Nutzer" gibt es nicht … jeder, der in seinem Leben schon mal eine Zeile Code für andere geschrieben hat, weiß konkrete Fehlermeldungen zu schätzen; ohne sie wäre die Fehlersuche gar nicht möglich. Lieber 5 konkrete Fehlermeldungen von "Nur-Nutzern" als eine nach dem Motto: "Ich weiß nur, daß es eben nicht geht, aber hey … ich programmiere auch.". my 2 cents

@JMC:

Den oben beschriebenen Test mit der Umstellung auf analog könntest Du ja auch machen … wenn Dein "Kaltstart-Absturz" verschwindet, wäre das ja auch ein Indiz (allerdings bin ich nur bedingt optimistisch).

comment:219 als Antwort auf: ↑ 218 Geändert vor 3 Jahren durch isar03

Replying to PeterPawn:

  1. "abgeschaltet" meint "Haken raus" bei "Festnetz aktiv" : JA
  1. Ich habe Freetz derzeit (deswegen) deinstalliert und brauche die Box "live" für 3 Mietparteien - sorry testen kann ich leider nicht.

jeder Klick auf ein Submenü von "Telefonie":

Unsicher, vielleicht auch schon bei Click auf "Telefonie"


  1. Meint das mit oder ohne FREETZMOUNT?:

Sagt mir zu wenig. Ich habe Freetz nach dieser Anleitung http://freetz.org/wiki/help/howtos/common/newbie ohne ein konkretes Modul gebaut und geflasht. Danach TSB installiert.

comment:220 als Antwort auf: ↑ 215 Geändert vor 3 Jahren durch make

Meine 7390 hängt an einem ISDN-Anschluss, auf der internen Seite sind schon länger keine ISDN-Geräte (mehr) vorhanden oder konfiguriert.

Hier der Auszug aus dem ctlmgr-logfile beim Übernehmen der aktivierten Option "auf dem USB-Speicher ablegen":

<6544.727428>ctlmgr:msg from luacgi11032: "<message><to>telcfg</to><from>luacgi11032</from><sequence>70</sequence><sid>fd312c2cfe818979</sid><transaction><type>query</type><key>settings/FaxKennung</key><error>0</error></transaction></message>"
<6544.728702>ctlmgr:msg OUT: "<message><to>luacgi11032</to><from>telcfg</from><sequence>187</sequence><transaction><type>response</type><key>settings/FaxKennung</key><sequence>70</sequence><error>0</error><values><r><v>0049xxxxxx</v></r></values></transaction></message>"
<6544.731552>ctlmgr:msg from luacgi11032: "<message><to>ctlusb</to><from>luacgi11032</from><sequence>71</sequence><sid>fd312c2cfe818979</sid><transaction><type>query</type><key>settings/storage-part/count</key><error>0</error></transaction></message>"
<6544.734954>ctlmgr:msg OUT: "<message><to>luacgi11032</to><from>ctlusb</from><sequence>188</sequence><transaction><type>response</type><key>settings/storage-part/count</key><sequence>71</sequence><error>0</error><values><r><v>3</v></r></values></transaction></message>"
<6544.737173>ctlmgr:msg from luacgi11032: "<message><to>connection0</to><from>luacgi11032</from><sequence>72</sequence><sid>fd312c2cfe818979</sid><transaction><type>query</type><key>status/connect</key><error>0</error></transaction></message>"
<6544.738191>ctlmgr:msg OUT: "<message><to>luacgi11032</to><from>connection0</from><sequence>189</sequence><transaction><type>response</type><key>status/connect</key><sequence>72</sequence><error>0</error><values><r><v>5</v></r></values></transaction></message>"
<6544.740530>ctlmgr:msg from luacgi11032: "<message><to>box</to><from>luacgi11032</from><sequence>73</sequence><sid>fd312c2cfe818979</sid><transaction><type>query</type><key>status/localtime</key><error>0</error></transaction></message>"
<6544.741682>ctlmgr:msg OUT: "<message><to>luacgi11032</to><from>box</from><sequence>190</sequence><transaction><type>response</type><key>status/localtime</key><sequence>73</sequence><error>0</error><values><r><v>11:15:17 11.11.2014</v></r></values></transaction></message>"
<6544.743545>ctlmgr:msg from luacgi11032: "<message><to>emailnotify</to><from>luacgi11032</from><sequence>74</sequence><sid>fd312c2cfe818979</sid><transaction><type>query</type><key>settings/enabled</key><error>0</error></transaction></message>"
<6544.744684>ctlmgr:msg OUT: "<message><to>luacgi11032</to><from>emailnotify</from><sequence>191</sequence><transaction><type>response</type><key>settings/enabled</key><sequence>74</sequence><error>0</error><values><r><v>1</v></r></values></transaction></message>"
<6544.746633>ctlmgr:msg from luacgi11032: "<message><to>emailnotify</to><from>luacgi11032</from><sequence>75</sequence><sid>fd312c2cfe818979</sid><transaction><type>query</type><key>settings/From</key><error>0</error></transaction></message>"
<6544.747707>ctlmgr:msg OUT: "<message><to>luacgi11032</to><from>emailnotify</from><sequence>192</sequence><transaction><type>response</type><key>settings/From</key><sequence>75</sequence><error>0</error><values><r><v>a@b.com</v></r></values></transaction></message>"
<6544.750058>ctlmgr:msg from luacgi11032: "<message><to>box</to><from>luacgi11032</from><sequence>76</sequence><sid>fd312c2cfe818979</sid><transaction><type>query</type><key>settings/hostname</key><error>0</error></transaction></message>"
<6544.751136>ctlmgr:msg OUT: "<message><to>luacgi11032</to><from>box</from><sequence>193</sequence><transaction><type>response</type><key>settings/hostname</key><sequence>76</sequence><error>0</error><values><r><v>xxx</v></r></values></transaction></message>"
<6544.753212>ctlmgr:msg from luacgi11032: "<message><to>emailnotify</to><from>luacgi11032</from><sequence>77</sequence><sid>fd312c2cfe818979</sid><transaction><type>query</type><key>settings/passwd</key><error>0</error></transaction></message>"
<6544.754196>ctlmgr:msg OUT: "<message><to>luacgi11032</to><from>emailnotify</from><sequence>194</sequence><transaction><type>response</type><key>settings/passwd</key><sequence>77</sequence><error>0</error><values><r><v>****</v></r></values></transaction></message>"
<6544.756461>ctlmgr:msg from luacgi11032: "<message><to>emailnotify</to><from>luacgi11032</from><sequence>78</sequence><sid>fd312c2cfe818979</sid><transaction><type>query</type><key>settings/accountname</key><error>0</error></transaction></message>"
<6544.757588>ctlmgr:msg OUT: "<message><to>luacgi11032</to><from>emailnotify</from><sequence>195</sequence><transaction><type>response</type><key>settings/accountname</key><sequence>78</sequence><error>0</error><values><r><v>a@b.com</v></r></values></transaction></message>"
<6544.759513>ctlmgr:msg from luacgi11032: "<message><to>connection0</to><from>luacgi11032</from><sequence>79</sequence><sid>fd312c2cfe818979</sid><transaction><type>query</type><key>settings/username</key><error>0</error></transaction></message>"
<6544.760694>ctlmgr:msg OUT: "<message><to>luacgi11032</to><from>connection0</from><sequence>196</sequence><transaction><type>response</type><key>settings/username</key><sequence>79</sequence><error>0</error><values><r><v>fooobar</v></r></values></transaction></message>"
<6544.762606>ctlmgr:msg from luacgi11032: "<message><to>emailnotify</to><from>luacgi11032</from><sequence>80</sequence><sid>fd312c2cfe818979</sid><transaction><type>query</type><key>settings/starttls</key><error>0</error></transaction></message>"
<6544.763653>ctlmgr:msg OUT: "<message><to>luacgi11032</to><from>emailnotify</from><sequence>197</sequence><transaction><type>response</type><key>settings/starttls</key><sequence>80</sequence><error>0</error><values><r><v>1</v></r></values></transaction></message>"
<6544.765893>ctlmgr:msg from luacgi11032: "<message><to>emailnotify</to><from>luacgi11032</from><sequence>81</sequence><sid>fd312c2cfe818979</sid><transaction><type>query</type><key>settings/SMTPServer</key><error>0</error></transaction></message>"
<6544.766970>ctlmgr:msg OUT: "<message><to>luacgi11032</to><from>emailnotify</from><sequence>198</sequence><transaction><type>response</type><key>settings/SMTPServer</key><sequence>81</sequence><error>0</error><values><r><v>x.y.de:465</v></r></values></transaction></message>"
<6544.773904>ctlmgr:msg from luacgi11032: "<message><to>manager</to><from>luacgi11032</from><sequence>82</sequence><sid>fd312c2cfe818979</sid><transaction><type>group_begin</type><group>cgi_group</group><error>0</error></transaction></message>"
<6544.774977>ctlmgr:msg from luacgi11032: "<message><to>telcfg</to><from>luacgi11032</from><sequence>83</sequence><transaction><type>set</type><key>settings/FaxMailAddress0</key><group>cgi_group</group><error>0</error><values><r><v>x@y.z</v></r></values></transaction></message>"
<6544.785589>ctlmgr:msg from luacgi11032: "<message><to>telcfg</to><from>luacgi11032</from><sequence>84</sequence><transaction><type>set</type><key>settings/FaxKennung</key><group>cgi_group</group><error>0</error><values><r><v>0049xxxxxx</v></r></values></transaction></message>"
<6544.786893>ctlmgr:msg from luacgi11032: "<message><to>telcfg</to><from>luacgi11032</from><sequence>85</sequence><transaction><type>set</type><key>settings/FaxMailActive</key><group>cgi_group</group><error>0</error><values><r><v>3</v></r></values></transaction></message>"

@make: Wir raten ja alle nur fleißig … die Frage des Dateisystems an sich hatten wir in 88/89 schon mal, vielleicht haben wir sie ja auch zu früh verworfen. Die Frage bei der swap-Partition wäre dann aber (ich habe auch eine drauf, die wird sogar unter original Firmware verwendet), ob deren Vorhandensein das Auftreten des Fehlers verhindert. Wenn bei Dir (mit swap-Part.) der Absturz trotzdem erfolgt, bin ich etwas unentschieden, dort zu suchen … Aber Du kannst ja offenbar den Fehler von CarstenSchuette und JMC bei Dir auch reproduzieren. Wenn Du die Kommunikation des ctlmgr mitschneiden läßt (cmt. 198, letzter Absatz), was steht denn dann in den letzten Zeilen der ctlmgrmsg.log ? @all: Mir ist aber im Zusammenhang mit meinem vorherigen Kommentar zum ISDN noch etwas aufgefallen, was ich den bisherigen Kommentaren nicht eindeutig entnehmen kann. Neben der reinen ISDN-Möglichkeit in der Box (da gibt es viele potentielle Nutzer) könnte ja auch noch die reale Verwendung der ISDN-Funktionen eine Rolle spielen.

Was mit allerdings noch aufgefallen ist, ist dass es einen Fehler bei der Anzeige des Ablage-Pfades für die Faxnachrichten gibt. Angezeigt wird mir…

Pfad: \\FRITZ\\faxbox

… wobei erstens "FRITZ" schon falsch ist, da meine Fritzbox einen anderen Host- und Netbios-Namen hat und zweitens auch der eigentliche Pfad fehlt (\\) oder die Backslashes fälschlicherweise verdoppelt sind. Hier gibt es vielleicht einen Zusammenhang zum rausgepatchen AVM-Samba-Server (bei mir läuft Samba 3.0.37).

comment:221 Geändert vor 3 Jahren durch PeterPawn

Merci … allerdings höre ich jetzt auf, mich bei jedem Tester zu bedanken, irgendwann wirkt das auch albern. Meinen generellen Dank an alle, die ihre Zeit dafür opfern, habe ich schon abgesondert. Also möge es mir niemand übel nehmen, wenn ich nur noch auf technische Aspekte eingehe.

  1. Damit haben wir wieder eine weitere Box mit aktivem oder ehemaligem ISDN-Anschluß, macht drei bisher.
  1. Die betreffende Einstellung finde ich schon "putzig", da hätte ich jetzt per se auch keinen Zusammenhang zur USB-Speicherung hergestellt. Wenn das fix ist, sollte auch ein
ctlmgr_ctl w telcfg settings/FaxMailActive 3

genau denselben Fehler hervorrufen. Bei mir liefert eine Abfrage des Wertes auch genau diese "3":

root@FB7490:~ $ ctlmgr_ctl r telcfg settings/FaxMailActive
3

Wo genau das in den Tiefen der Firmware dann etwas mit dem USB-Speicher zu tun hat, liegt zwar - für mich jedenfalls - im Dunklen, aber das muß uns ja auch nicht im Einzelnen interessieren. Ein stabiler und reproduzierbarer Fehler ist notwendig … ansonsten sind alle Versuche zum Ein-/Ausschluß von Randbedinungen nur willkürlich. Und um nicht jedesmal die kompletten Einstellungen bei neuen Meldungen abzufragen, braucht es m.E. einen konkreten Befehl, der entweder zum Crash führt oder auch nicht … bei nicht, ist es eine andere Baustelle.

Das mit dem Pfad in der HTML-Anzeige würde ich nicht überbewerten, der ist nicht dynamisch aus irgendwelchen Einstellungen generiert, sondern steht so direkt in der htmltext_de.db drin (Offset 0xb1a3b bei 7490/06.20), von wo er dann im Lua-Module fon_devices_html.lua in Zeile 1122 (function get_save_path) gelesen wird. Dieser Pfad wird aber von der Lua-Seite nicht zum Setzen irgendwelcher Einstellungen verwendet.

In den Binaries steht dann wieder der richtige Pfad drin, im faxd z.B.:

/var/InternerSpeicher
/FRITZ
/faxbox
/var/media/ftp/
[...]
/FRITZ/faxbox

Bleibt also am Ende auch an Dich die Frage (angesichts des externen ISDN-Anschlusses sicherlich eher obsolet), ob bei analogem Anschluß das Problem nicht auftritt. Der Test ohne libctlmgr.so sollte auch bei einem einzelnen ausreichen (JMC will ihn ja im Laufe des Tages mal machen) … insofern würde ich jetzt Deinen Fehler als +1 nehmen (gerne noch mit der Ansage, ob die Reduktion auf die ctlmgr-Einstellung als Test für diesen Fall funktioniert) und wüßte aber im Moment auch nicht unmittelbar, wo man dann weiter testen/suchen sollte.Von den Faxmail-Einstellungen möchte ich mich jedenfalls nicht bis zum USB-Speicher durch den Debugger quälen, der Weg von dort ist imho weiter als von "UseStick" aus.

@isar03:

Nach diesem hier ist die Standardeinstellung für FREETZMOUNT "ein", damit ist dann FREETZMOUNT im Image wohl enthalten. Das mit der fehlenden Test-Möglichkeit ist schade, aber alle auf einmal macht ja auch nicht viel Sinn. In jedem Falle würde ich Dein Problem als zu diesem Ticket gehörend ansehen und den Fehlercounter (inkl. des Zählers für "ehemals ISDN") inkrementieren. Wenn wir eine Lösung finden, wärst Du ja dann auch ein potentieller Indikator für deren Funktionieren …

comment:222 Antwort: Geändert vor 3 Jahren durch make

Also, ctlmgr_ctl w telcfg settings/FaxMailActive 3 hat in der Tat den sofortigen Crash zur Folge. Tests an Analog-Anschlüssen kann ich nicht vornehmen, mangels Verfügbarkeit. Mein Hinweis auf die Pfade und die Partitionen hängt mit meiner Annahme zusammen, dass das Enumerieren oder Lokalisieren des Verzeichnisses zur Speicherung der (Anrufbeantworten|Fax)-Nachrichten nicht (mehr) (richtig) funktioniert. Ich hatte in der Vergangenheit schon beobachtet, dass das FRITZ-Parent-Verzeichnis auf verschiedenen Partitionen auftaucht, wobei für mich kein klares Muster erkennbar war. Möglicherweise war der Trigger hier jeweils ein Firmwareupgrade.
Andere Idee - wenn wir jetzt so einen eindeutigen Trigger wie FaxMailActive haben, könnte man dann nicht mit gdb auf der Box mal genauer nachschauen, wie die Abläufe sind? Der eigentliche Auslöser für den Crash ist ja immer das Verwenden (Dereferenzieren) eines Strings als Pointer (soweit ich das sehe handelt es sich hier immer um einen konkreten Mountpoint. Wenn man, s.o., den Partitions-Präfix in Freetz kürzer macht (zB Us), kann man im crash.log (Register a1) auch sehen, dass beispielsweise Us04 als Pointer dereferenziert wird, was natürlich keinen Sinn macht.

comment:223 als Antwort auf: ↑ 222 ; Antwort: Geändert vor 3 Jahren durch PeterPawn

Replying to make:

Mein Hinweis auf die Pfade und die Partitionen hängt mit meiner Annahme zusammen, dass das Enumerieren oder Lokalisieren des Verzeichnisses zur Speicherung der (Anrufbeantworten|Fax)-Nachrichten nicht (mehr) (richtig) funktioniert.

Da stimme ich Dir in vollem Umfang zu, daher auch die mit dem ursprünglichen Skript (test_usb) abgefragten ctlmgr-Einstellungen. Aber der beim Fax angezeigte Pfad ist in diesem Falle eben wirklich (zumindest nach meiner Überzeugung) eine Sackgasse, da der nur aus drei möglichen festen Texten bestehen kann (s. das erwähnte fon_devices_html.lua).

Ich hatte in der Vergangenheit schon beobachtet, dass das FRITZ-Parent-Verzeichnis auf verschiedenen Partitionen auftaucht, wobei für mich kein klares Muster erkennbar war.

Neue Firmware sollte auf jedem beschreibbaren USB-Datenträger ein solches FRITZ-Verzeichnis anlegen, da im darin befindlichen mediabox-Unterverzeichnis die sqlite3-Datenbank mit dem Index für dieses Volume gespeichert wird und ohne Index gibt es im FRITZNAS keine Anzeige dieses Datenträgers.

könnte man dann nicht mit gdb auf der Box mal genauer nachschauen, wie die Abläufe sind?

Halte ich auch für eine gute Idee … beim Weg von den Fax-Einstellungen bis an die richtige Stelle sehe ich aber das eher düster.

Sämtlichen AVM-Binaries fehlen die Symbole, das einzige, was man im Debugger noch hat, sind die exportierten. Da macht das Steppen bis zur fraglichen Stelle einfach keinen Spaß … bei mir kommt dann noch der fehlende Absturz und einige Probleme, den gdb (7.8) auf einer 7490 überhaupt zum Arbeiten mit Breakpoints zu bewegen, dazu. An conditional breakpoints (halte bei 0x1234 an, wenn a1=xy ist) ist da mal gar nicht zu denken … :-(

Wenn also jemand mit dem Fehler und einem funktionierenden gdb einen Stack-Trace an der Absturzstelle erzeugen kann, den man auch weiter als die 2 BTs im crash.log zurückverfolgen kann, dann kämen wir vermutlich auch etwas weiter bei der Analyse. Den Weg bis zu einem Absturz ohne vernünftigen Debugger und conditional BPs zu tracen (es ist immerhin strcmp, was da ziemlich flott am Beginn abstürzt), ist imho aussichtslos, dafür wird die Funktion einfach zu oft benutzt (ist nur eine Vermutung, aber eine begründete, oder ?) … und Alternativen wie ltrace funktionieren (bei mir) auf der 7490 auch nicht bzw. deren Einsatz verbietet sich von selbst bei einer Komponente wie dem ctlmgr, wo der Aufruf der fraglichen libc-Funktion ja erst einige Libs später erfolgt.

Da erschien/erscheint mir der Weg von einer Abfrage von "UseStick" bis zur Enumeration von USB-Volumes einfach logischer, deshalb auch die intensiveren Bemühungen mit JMC, das mal auf einen konkreten Aufruf einzugrenzen. Jetzt ist das gelungen … und nun ist der Absturz weg. Was soll man da nun machen ? Das Debuggen "ins Blaue hinein", bis man mal bei strcmp ankommt, ist bei der zu vermutenden Häufigkeit imho nicht machbar, den fehlerhaften Aufruf kann man eben auch nur als solchen erkennen, wenn der Fehler auf der eigenen Box überhaupt auftritt. Deshalb bleibt es (für mich persönlich jedenfalls) Priorität, die genauen Rahmenbedingungen zu ermitteln, damit man den Fehler auf einer beliebigen Box nachstellen und dann auch mit dem Debugger suchen kann.

comment:224 als Antwort auf: ↑ 223 Geändert vor 3 Jahren durch er13

Replying to PeterPawn:

Deshalb bleibt es (für mich persönlich jedenfalls) Priorität, die genauen Rahmenbedingungen zu ermitteln, damit man den Fehler auf einer beliebigen Box nachstellen und dann auch mit dem Debugger suchen kann.

Sehe ich genauso.

comment:225 als Antwort auf: ↑ 214 Geändert vor 3 Jahren durch CarstenSchuette

Replying to make:

Nur mal so ins Blaue hinein geraten: Könnte das Problem vielleicht mittelbar damit zusammen hängen, ob auf dem USB-Device ein bestimmter Filesystem-Typ vorhanden ist oder nicht? Auf meinem wären derzeit vFAT, ext2 und eine aktivierte swap-Partition. Ist die Swap-Partition vielleicht die gesuchte Randbedingung?

Gemäß comment:199 getestet:

root@fritz:/var/mod/root# echo "USESTICK=tam:settings/UseStick" | ./queries.lua
USESTICK="1"

Gemäß comment:222 getestet. Das Lesen des Wertes liefert bei mir übrigens eine 5:

root@fritz:/var/mod/root# ctlmgr_ctl r telcfg settings/FaxMailActive
5

Anschließend setzen auf 3…

root@fritz:/var/mod/root# ctlmgr_ctl w telcfg settings/FaxMailActive 3
root@fritz:/var/mod/root# 

…es passiert ein paar Sekunden nichts, dann ist der root-Prompt wieder da.
Anschließend liefert das Lesen des Wertes aber kein Ergebnis mehr:

root@fritz:/var/mod/root# ctlmgr_ctl r telcfg settings/FaxMailActive
root@fritz:/var/mod/root# ctlmgr_ctl r telcfg settings/FaxMailActive
root@fritz:/var/mod/root# ctlmgr_ctl r telcfg settings/FaxMailActive
root@fritz:/var/mod/root# ctlmgr_ctl r telcfg settings/FaxMailActive

Und noch ein paar Sekunden später bootet dann die Box → ctlmgr offenbar gecrasht.
Nach dem Reboot sagt das crash.log:

2014-11-11 22:50:30(1) [Segmentation fault] /usr/bin/avm/ctlmgr(1529) CRASHED at strcmp+0xc (/lib/libc.so.0 at 00038a0c) accessing 0+0x5553746e (/lib/libz.so.1 at 29c3646e)
SIGNO 11 ERRNO 0 CODE 1
Version: 06.21-29325
Watchdog triggered 9 seconds ago
No bugmsg
ze: 00000000 at: 00000001 v0: 2ae5da00 v1: 00000046
a0: 2b0c752b a1: 5553746f a2: 55537470 a3: 2b0c752c
t0: 00000000 t1: 00000000 t2: 0000005b t3: ffffff80
t4: 00000063 t5: 00000073 t6: 0000005b t7: 622f3030
s0: 2b0cec30 s1: 2b92e780 s2: 2b813970 s3: 2b5769c0
s4: 2b3edd28 s5: 2b813b30 s6: 2b825ac8 s7: 2b3eddd8
t8: 00000000 t9: 2ae5da00 k0: 00000001 k1: 00000000
gp: 2b0cec30 sp: 7fa5c7e0 fp: 2b813350 ra: 2b08753d
FA 5553746e 0+0x5553746e (/lib/libz.so.1 at 29c3646e)
PC 2ae5da0c strcmp+0xc (/lib/libc.so.0 at 00038a0c)
RA 2b08753c 0+0x2b08753c (/usr/share/ctlmgr/libtelcfg.so at 0000353c)
Code: 90830000  24870001  24a60001 <14600003> 90a20000  03e00008  00021023  00e02021  1062fff7 
[bt]  2b087538 [2b08748a] <0+0x2b08748b>+0xae (/usr/share/ctlmgr/libtelcfg.so at 0000348a)
[bt]  2b09426c [2b0941ae] <0+0x2b0941af>+0xbe (/usr/share/ctlmgr/libtelcfg.so at 000101ae)
Signal Segmentation fault while doing crashdump (2)
2014-11-11 22:50:30(2) [Segmentation fault] /usr/bin/avm/ctlmgr(1529) CRASHED at 0+0x2ad4c5f8 (/lib/libavmcsock.so.2 at 000515f8) accessing 0+0x2b78bffc (/usr/share/ctlmgr/libtr069.so at 001b2ffc)
SIGNO 11 ERRNO 0 CODE 2
ze: 00000000 at: 181020aa v0: ffff0000 v1: 2b78c008
a0: 3c1c0000 a1: ffff8000 a2: 27bd8000 a3: 279c0000
t0: 00000000 t1: 00000000 t2: 00000000 t3: 00000000
t4: 00000000 t5: 7f000001 t6: 004125a0 t7: 0399e021
s0: fffffef0 s1: 2ad4ad00 s2: 00000000 s3: 7fa5c9c8
s4: 2b0941af s5: 000064f7 s6: 2b813ca0 s7: 00000000
t8: 00000105 t9: 2ae848d4 k0: 00000001 k1: 00000000
gp: 2ad7d0a0 sp: 7fa5bd80 fp: 2b813350 ra: 2ad4cad8
FA 2b78bffc 0+0x2b78bffc (/usr/share/ctlmgr/libtr069.so at 001b2ffc)
PC 2ad4c5f8 0+0x2ad4c5f8 (/lib/libavmcsock.so.2 at 000515f8)
RA 2ad4cad8 0+0x2ad4cad8 (/lib/libavmcsock.so.2 at 00051ad8)
Code: 10000027  24630008  004a5024 <5544000b> 8c6bfff4  55670009  8c6bfff4  8c6b0000  01656024 
[bt]  2ad4cad0 [2ad4c364] <0+0x2ad4c364>+0x76c (/lib/libavmcsock.so.2 at 00051364)
[bt]  2ad4b950 [2ad4afb4] <0+0x2ad4afb4>+0x99c (/lib/libavmcsock.so.2 at 0004ffb4)
[bt]  !7fa5c4c0 rtsignal trampoline on stack
[bt]  2ae5da04 mempcpy+0x444 (/lib/libc.so.0 at 000385c0)

Zum Thema Partitionen und Filesystem auf dem Stick:

root@fritz:/var/mod/root# df /dev/sda1
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/sda1             15617008     39064  15577944   0% /var/media/ftp/UStor01

root@fritz:/var/mod/root# blkid
/dev/sda1: UUID="A83A-ADA4" TYPE="vfat"

comment:226 Geändert vor 3 Jahren durch CarstenSchuette

Zu comment:225 sei noch ergänzt, dass ich die o.g. Tests mit der 06.21 durchgeführt habe. Das Problem besteht also weiterhin.

Zuletzt geändert vor 3 Jahren von CarstenSchuette (vorher) (Diff)

comment:227 Antwort: Geändert vor 3 Jahren durch SpaceRat

Ich möchte nochmal daran erinnern, daß sich ein Crash auch mit
ctlmgr_ctl r myfritzdevice settings/device0/dyndnslabel
oder
ctlmgr_ctl w ctlusb settings/samba-server-enabled 1
bzw.
ctlmgr_ctl w ctlusb settings/samba-server-enabled 0
provozieren läßt und das hat ja nun mit Fax/Telefon herzlich wenig zu tun.

Die Vermutung, daß was im Wrapper faul ist, halte ich da schon für wahrscheinlicher.

Leider kann ich im Moment nicht mehr testen, weil die 7390 einfach laufen muß.
Ich kann erst weiter mitstochern, wenn die 6.20 oder 6.21 auf der 7270v2 angekommen ist, die läuft nebenher.

Aber wenn ich mal wild und laienhaft raten darf:
AVM hat ja die Möglichkeit entfernt, mittels allcfgconv die Config samt entschlüsselter Passworte auszulesen.
Dieser Schritt alleine macht aber keinen Sinn, wenn ich an dieselben Informationen auch durch gezielte Abfragen via ctlmgr komme.
Umgekehrt braucht die Box an verschiedenen Stellen diese Daten, also wäre es doch nicht völlig abwegig, anzunehmen, daß es irgendwo ein Problem mit der Quadratur des Kreises gibt, überall als root zu arbeiten und doch nicht alles machen zu dürfen …

comment:228 Geändert vor 3 Jahren durch PeterPawn

@SpaceRat: Ohne Deine Fehlermeldung mißachten zu wollen, bisher bist Du - jedenfalls hier im Ticket - der Einzige, der diesen Zusammenhang herstellen konnte. Die These, daß jeder beliebige ctlmgr-Zugriff zum Absturz führt (comment 181 am Ende), ist imho inzwischen eindeutig widerlegt.

Da Du im Moment (nach eigener Aussage) das nicht durch erneuten Test bestätigen kannst, weil Du die Box dazu nicht hast und es ansonsten hier noch niemand am Samba-Server (oder einer MyFRITZ!-Freigabe wie beim ersten ctlmgr_ctl-Kommando) festmachen konnte, würde ich dabei eine andere Fehlerursache (hier wird derzeit ein Absturz des ctlmgr-Prozesses nach einem Stringvergleich (strcmp), bei dem als zweiter Operand ein falscher Pointer übergeben wird, "bearbeitet") für wahrscheinlicher halten.

Da jeder Speichervorgang auf der Seite storage/settings.lua das von Dir zitierte (De-)Aktivieren des Samba-Servers auslöst (Zeile 237 ff.) - unabhängig vom vorherigen Wert, also auch 1→1 und 0→0 - läßt sich das auch mit dem GUI sehr leicht überprüfen. Wenn mehrere Meldungen dazu kommen sollten, ist es ein weiterer Indikator/Trigger, wenn nicht, dann eher ein isoliertes Problem.
Daß ein Zusammenhang mit USB-Speicher besteht, ist imho inzwischen hinreichend nachgewiesen; der Weg vom Fax/Telefon dorthin wäre theoretisch auch nicht länger, als der vom Samba-Server aus.


Zu den Kennwörtern (die These tauchte ja auch schon in comment 181 mal auf):

Verschlüsselte Kennwörter lassen sich über ctlmgr_ctl (und auch über box.query im Lua, was vermutlich in libcmquery.so mündet) weder im Klartext noch als konkretes Chiffrat abfragen (der WLAN-Key ist eine Ausnahme, wo man wohl Absicht unterstellen kann und configexport_passwd eine weitere, die am Ende eine galoppierende Sicherheitslücke ist - für mich jedenfalls), es werden ansonsten grundsätzlich nur (vier) Sterne ausgegeben. Das ist mit Benutzernamen schon anders, deshalb ist auch der Austausch von Benutzernamen und Kennwörtern eine Angriffsmöglichkeit auf diese Verschlüsselung, aber es geht ja ohnehin noch einfacher. Das Maskieren mit den Sternen ist mit einiger Wahrscheinlichkeit auch schon in der internen Kommunikation der Fall, jedenfalls wird in der ctlmgrmsg.log auch schon kein Kennwort protokolliert. Auch wenn das natürlich eine Vorkehrung seitens der Protokollierung sein könnte (das Handling der Abfragen inkl. der Protokollierung erfolgt in libcm.so), so gibt es in der zuständigen Library aber die Sterne als String nicht, damit liegt imho die Vermutung nahe, daß die Daten den ctlmgr gar nicht verlassen (dort gibt es die Sterne). Wenn man sich andere Komponenten ansieht, wo man davon ausgehen muß, daß sie Kennwörter im Klartext benötigen (z.B. mailer oder ddnsd), dann trifft man dort m.W. immer auf die libar7cfg.so (oder eine andere "zuständige" Lib), woraus ich dort jeweils einen direkten eigenen Zugriff auf die Konfigurationsdateien ableiten würde.
Auch solche internen Sachen wie das User-Login und andere Authentifizierungen werden vom Lua-CGI einfach an den ctlmgr delegiert, da gibt es kein Lesen von Kennwörtern zum Vergleich mit irgendwelchen Eingaben.

Ich persönlich (nur meine eigene Meinung, um das noch einmal klar herauszustellen) sehe da auch keinen mittelbaren Zusammenhang zwischen verschlüsselten Daten und dem Fehler … zumal er ja offensichtlich (jemand andere Erfahrungen ?) mit der originalen AVM-Firmware noch nicht aufgetreten ist und die steht vor genau demselben Problem bei der Verschlüsselung, dort greift Freetz m.W. auch nicht in die originale Firmware ein (/var/tmp/passwd mal außen vor).


Der Test ohne den Wrapper (ist ja mehr Bauchgefühl) steht noch aus … bestimmt erbarmt sich mal jemand.

@all: Ich plädiere dafür, daß mal jemand mit dem Fehler einen Thread im IPPF aufmacht. Weitergehende Reaktionen/Antworten (also mehr als: Das ist es nicht. Punkt.) sind im Ticket sicher eher unschön, ich weiß aber keine andere Möglichkeit der Diskussion, wenn PN nicht geht. Deshalb der Vorschlag zum "Umzug", außerdem bekommen wir dann vielleicht doch mehr Feedback, weil mehr Leute darauf aufmerksam werden (meint in erster Linie den "Kaltstart-Absturz" und ist nur meine These).

comment:229 als Antwort auf: ↑ 227 ; Antwort: Geändert vor 3 Jahren durch make

Also, auf meiner 7390 führt KEINER dieser Befehle unter 06.21-29345 zu Problemen geschweige denn zu Reboots.

ctlmgr_ctl r myfritzdevice settings/device0/dyndnslabel
oder
ctlmgr_ctl w ctlusb settings/samba-server-enabled 1
bzw.
ctlmgr_ctl w ctlusb settings/samba-server-enabled 0

Bitte die erforderlichen Randbedingungen mit in den Kommentar schreiben und/oder darauf hinweisen, dass sie existieren, aber unklar sind. Sonst drehen wir hier uns endlos im Kreis. Danke.

Zuletzt geändert vor 3 Jahren von make (vorher) (Diff)

comment:230 als Antwort auf: ↑ 229 Geändert vor 3 Jahren durch HarryT

Auf meine 7490 FRITZ!OS 06.21-freetz-devel-12721 BETA ebenfalls kein Reboot mit dieser Befehle.

Hinzu gefugt: Etwa 15 minuten spater hatte ich ein reboot. Aber die box ist im moment sehr instabiel. Glaub nicht dass es etwas damit so tun hat.

Replying to make:

Also, auf meiner 7390 führt KEINER dieser Befehle unter 06.21-29345 zu Problemen geschweige denn zu Reboots.

ctlmgr_ctl r myfritzdevice settings/device0/dyndnslabel
oder
ctlmgr_ctl w ctlusb settings/samba-server-enabled 1
bzw.
ctlmgr_ctl w ctlusb settings/samba-server-enabled 0

Bitte die erforderlichen Randbedingungen mit in den Kommentar schreiben und/oder darauf hinweisen, dass sie existieren, aber unklar sind. Sonst drehen wir hier uns endlos im Kreis. Danke.

Zuletzt geändert vor 3 Jahren von HarryT (vorher) (Diff)

comment:231 Geändert vor 3 Jahren durch HarryT

@ Peter Pawn

Der Test ohne den Wrapper (ist ja mehr Bauchgefühl) steht noch aus … bestimmt erbarmt sich mal jemand.

Du meinst: "dann bräuchtest Du wohl nur für die Dauer des 'make' das File 'patches/scripts/105-add_ctlmgr-wrapper.sh' entfernen (oder umbenennen, die Endung ".sh" müßte weg). " ??

Dan die firmware laden und was solte man dan sehn?

{HT}

comment:232 Antwort: Geändert vor 3 Jahren durch PeterPawn

I'd think, I've read somewhere else you'd prefer to use english … if I'm wrong, we can continue in german later.

The 'fwmod' script looks for files with extension .sh to be executed during firmware build. If you rename the file to remove the .sh-extension (you could append some other characters for example) and start building another image with 'make', the wrapper script for ctlmgr will not be included into the new image. This new image file has to be flashed at last …

The idea behind that test are some thoughts regarding the dynamic linking while loading a library (the libctlmgr.so library modifies the process for one special function of libc.so). If there's a technique named "lazy binding" is used, the real location of a called function will not be determined until the first call of this function is executed. My gut instinct says, there could be a problem saving caller's parameters while performing the bind process and therefore I'd like to know for sure, that it's not a problem with the modified linker process due to preloading of libctlmgr.so.

It's meaningless to do that test without a persistent error. But if you can reproduce the error while using the ctlmgr wrapper script and it vanishes without the wrapper … that could be worth further investigations. If the error occurs even without the ctlmgr wrapper script, that's not the cause of the problems and we can forget the idea.

comment:233 Antwort: Geändert vor 3 Jahren durch make

Der Wrappper wird es wohl nicht sein. Ich habe folgendes gemacht:

  • usbroot eingeschaltet
  • watchdog disabled
  • Absturz des ctlmgr mit faxmailactive 3 ausgelöst
  • Das Wrapperskript ctlmgr durch das AVM-Binary ersetzt und neu gestartet
  • Erneut Absturz des ctlmgr mit faxmailactive 3 ausgelöst

Oder mache ich da jetzt einen Denkfehler?

comment:234 als Antwort auf: ↑ 232 Geändert vor 3 Jahren durch HarryT

Replying to PeterPawn:

I'd think, I've read somewhere else you'd prefer to use english … if I'm wrong, we can continue in german later.

For writing. Reading and understanding German is no problem.

The 'fwmod' script looks for files with extension .sh to be executed during firmware build. If you rename the file to remove the .sh-extension (you could append some other characters for example) and start building another image with 'make', the wrapper script for ctlmgr will not be included into the new image. This new image file has to be flashed at last …

The idea behind that test are some thoughts regarding the dynamic linking while loading a library (the libctlmgr.so library modifies the process for one special function of libc.so). If there's a technique named "lazy binding" is used, the real location of a called function will not be determined until the first call of this function is executed. My gut instinct says, there could be a problem saving caller's parameters while performing the bind process and therefore I'd like to know for sure, that it's not a problem with the modified linker process due to preloading of libctlmgr.so.

Ok, I renamed the patch and running make now.

It's meaningless to do that test without a persistent error. But if you can reproduce the error while using the ctlmgr wrapper script and it vanishes without the wrapper … that could be worth further investigations. If the error occurs even without the ctlmgr wrapper script, that's not the cause of the problems and we can forget the idea.

:-( I would love to have a persistent error which I can prevoke at the moment I want. That would make things a lot easier. At the moment my (test) 7490 box goes down sometimes when I use it. It looks as if this started after my changes yesterday. Maybe I can find a clue in that.
First I will load the new firmware and see what happens.

comment:235 als Antwort auf: ↑ 233 ; Antwort: Geändert vor 3 Jahren durch PeterPawn

Replying to make:

Oder mache ich da jetzt einen Denkfehler?

Imho nicht, wenn der Absturz dann in /usr/bin/ctlmgr und nicht in /usr/bin/avm/ctlmgr erfolgte …

Allerdings ist das Einführen einer weiteren Variablen (usbroot) natürlich eine (neue) Unwägbarkeit … aber es war ohnehin nur eine diffuse Vermutung mit dem LD_PRELOAD und keinesfalls mit allzu viel Hoffnung meinerseits verknüpft.

Hast Du zufällig einen gdb (6.8) im Image ? Vielleicht lohnt es sich ja doch, den gdb nachdem sich die Box ge"settled" hat, einfach mal an den ctlmgr-Prozess zu attachen (Watchdog disablen) und dann das ctlmgr_ctl aufzurufen … bei Dir ist der Fehler ja offenbar gut zu reproduzieren.

Ansonsten warte ich persönlich immer noch auf den ersten Kommentar, daß das Problem auch auf einer Box ohne genutzte ISDN-Funktionen (weder intern noch extern und auch ohne "Rudimente" von ISDN-Konfigurationen nach Umstellung auf IP) aufgetreten ist.

Wenn ich das halbwegs richtig verstehe, ist ein Indiz für die "angenommene externe Identität" der FRITZBox die Zeile

[   14.530000] [piglet]bitfile for autodetect '/lib/modules/bitfile_isdn.bit'
[   16.120000] [piglet]-> TE-Mode

in dmesg, wo bei analogem Modus etwas von "POTS-Mode" stehen sollte. Eine einzelne Variable, die Auskunft über diese Einstellung gibt, habe ich bisher noch nicht identifiziert.

Da bei der Initialisierung des Kernel-Modules zum Laden des "piglets" in das FPGA (in /ect/init.d/S11-piglet) auch keine direkte Einstellung abgefragt wird, sondern ein Int32 aus telefon_misc:

piglet_bitfilemode=`/bin/testvalue /var/flash/telefon_misc 4 2638`

, bin ich nicht einmal sicher, ob es eine einzelne Einstellung überhaupt gibt, die man da abfragen könnte, insofern ist wahrscheinlich dmesg mit grep das Mittel der Wahl. Was da intern wirklich abgeht bei der Initialisierung des FPGA für die verschiedenen Konfigurationen, kann man nur raten, denn in den Kernel-Quellen ist Piglet_noemif nur ein Dummy.

comment:236 Antwort: Geändert vor 3 Jahren durch HarryT

Ok

I renamed the patches/scripts/105-add_ctlmgr-wrapper.sh patch and made a "make clean" and "make". Loaded the new firmware and then playing around with the fax settings I have a GUI crash when I try to save these settings. So it seems I can confirm the findings of "make".

My firmware: FRITZ!OS 06.21-freetz-devel-12721M BETA

As answer to the latest post of Peter Pawn, I never had ISDN and never configured it. The current situation is on a box freshly recovered this week and for sure nothing set for ISDN.

A finding I have and not read about in this threat is the noise on the phone line. It seems to have a correlation with the instability. I am not sure, but when I only use the AVM firmware the line quality is good. In the situation where the box is instable with the Freetz firmware I have noise on the line. I am not sure yet what the situation is if I have no Freetz settings at all.

A bit of topic, but very usefull for testing:
a) Is there a way to remove ALL settings in Freetz? I am looking for an easy way to get Freetz in the situation as if it is loaded after a firmware recovery with the AVM tool.

b) I am not sure if the factory settings of AVM indeed leave the Fritzbox in a situation as if it is recovered. Does anybody know?

comment:237 als Antwort auf: ↑ 235 Geändert vor 3 Jahren durch make

Imho nicht, wenn der Absturz dann in /usr/bin/ctlmgr und nicht in /usr/bin/avm/ctlmgr erfolgte …

So war es. Ich kann aber auch einfach mal die LD_PRELOAD-Zeile in /usr/bin/ctlmgr auskommentieren, aber einen Unterschied sollte das ja nicht machen.

Hast Du zufällig einen gdb (6.8) im Image ? Vielleicht lohnt es sich ja doch, den gdb nachdem sich die Box ge"settled" hat, einfach mal an den ctlmgr-Prozess zu attachen (Watchdog disablen) und dann das ctlmgr_ctl aufzurufen … bei Dir ist der Fehler ja offenbar gut zu reproduzieren.

Daran hatte ich auch schon gedacht. Mit gdb 7.8 war die disassembly "unbefriedigend" (jede Menge nicht disassemblierte Opcodes mitten in den Funktionen), mit 7.8.1 scheint es noch schlechter zu funktionieren. Ich werde bei Gelegenheit mal die von dir erwähnte Version probieren.
Mein Eindruck ist aber, dass der gdb-build die Mips-Spezialitäten der 7390 nicht bzw nicht vollständig kennt. Objdump sollte das prinzipiell können, wenn entsprechend übersetzt, allerdings weiss ich nicht, woher ich ein funktionierendes objdump nehmen könnte. Bevor das nicht repariert ist, macht gdb wohl eher wenig Sinn.

comment:238 als Antwort auf: ↑ 236 ; Antwort: Geändert vor 3 Jahren durch PeterPawn

Replying to HarryT:

As answer to the latest post of Peter Pawn, I never had ISDN and never configured it. The current situation is on a box freshly recovered this week and for sure nothing set for ISDN.

Could you try to locate the "piglet" entries shown above please (dmesg | grep piglet) ?

If you've never configured the external phone line settings of the box, it's still possible the default settings are used and I'm unsure, which technology is assumed there.

Is there a way to remove ALL settings in Freetz? I am looking for an easy way to get Freetz in the situation as if it is loaded after a firmware recovery with the AVM tool.

Afaik an "echo -n >/var/flash/freetz" should do the job, shouldn't it ?

I am not sure if the factory settings of AVM indeed leave the Fritzbox in a situation as if it is recovered. Does anybody know?

A factory reset selectively clears settings files with minor id > 100 only (a downgrade does the same), the freetz file uses id 60. That's why it survives even a factory reset. Usually the recovery process wipes out everything at TFFS settings storage, so in this case the freetz settings are cleared too.

comment:239 als Antwort auf: ↑ 238 Geändert vor 3 Jahren durch HarryT

Replying to PeterPawn:

Replying to HarryT:

As answer to the latest post of Peter Pawn, I never had ISDN and never configured it. The current situation is on a box freshly recovered this week and for sure nothing set for ISDN.

Could you try to locate the "piglet" entries shown above please (dmesg | grep piglet) ?

[ 9.540000] [piglet]use settings for 185(7 gpios from hw_config)

[ 14.780000] [piglet]bitfile for autodetect '/lib/modules/bitfile_isdn.bit'

[ 14.780000] [piglet] try to preload in progress-context: /lib/modules/bitfile_isdn.bit

[ 15.850000] [piglet] bitfile 72761 bytes done

[ 15.860000] [piglet] "wyatt_earp_unload_xilinx" not loaded

[ 20.960000] [piglet] use preload[0] /lib/modules/bitfile_pots.bit

[ 22.030000] [piglet] bitfile 72761 bytes done

[ 22.040000] [piglet]→ POTS-Mode

[ 22.140000] [piglet]TDM: FS: 8005 Hz CLK: 2046220 Hz

Zuletzt geändert vor 3 Jahren von HarryT (vorher) (Diff)

comment:240 Geändert vor 3 Jahren durch PeterPawn

@HarryT:

Thanks … but it's too bad. You've destroyed my whole hope with a single strike.

Damit hat sich die These mit ISDN vs. analog dann wohl auch zerschlagen.
Was mich dann aber wirklich stinkig macht, ist die fehlende Antwort auf die Frage, warum es mit 7360/7362SL/3490 usw. bisher nicht gemeldet wurde.

Die NAND-Idee kann man dann auch getrost fallen lassen, da der bei 7362SL zumindest genauso vorhanden ist (die andere Größe halte ich für unwesentlich).

Wobei das "hat sich erledigt" ja auch nur für die Suche nach der Erklärung gilt, warum es sich nicht auf jeder beliebigen Box reproduzieren läßt. Als Unterscheidung zwischen Modellen mit und ohne Problem ist die in der Box angelegte ISDN-Unterstützung ja immer noch gut … auch hier aber nur bis zur ersten Meldung von einer Box mit CONFIG_CAPI_NT=n und CONFIG_CAPI_TE=n.

comment:241 Antwort: Geändert vor 3 Jahren durch HarryT

Is there another usefull test? Otherwise I will go back to firmware 6.0 I try to build a production box.

BTW I think I had on interesting situation this weekend.

  • A complete fresh 7490 box, no freetz settings and no fritz settings.
  • As it seems using the fax-settings is the easiest way to crash the box I just filled my IP phonenumbers and the fax settings (to usb)and that already made the box instable.

If it is usefull I can repeat this test to confirm my findings.


comment:242 als Antwort auf: ↑ 241 ; Antwort: Geändert vor 3 Jahren durch PeterPawn

Replying to HarryT:

A complete fresh 7490 box, no freetz settings and no fritz settings.

That's curious … but you've used an own image, haven't you ?

If this happens with the original firmware too, it would be very amazing and the first advice of such behaviour (here - no clue of AVM's own state of knowledge).

If it's a modified firmware image without the suspected FREETZMOUNT patches, please attach the .config file used to build it (or add an advice, where to find it in an earlier comment if it's unchanged).

If it's really a blank box, it beats me why we can't reconstruct the same situation with any other box in the wild. What's the right setup to do that … we have the same problem across different devices (7390 and 7490) and across different origins (therefore it's not a layer8 error). Together with your report it's not a "settings zombie" too. Why can't we find a "trigger button" to push ?

With your configuration we could have a chance to track it down a little bit further again and publishing the .config file saves you from being barraged with questions.

To get a stable system for production use today, you'd better use an older base indeed.

Is there another usefull test?

There're still some ideas, how somebody could try to track down the cause, but it's only poking about in the fog and I'm embarrassed to give advice only, 'cause I'm unable to check it by myself.
One interesting question I reflect upon is building an image with CAPI values set to "no". Imho there's a chance to get a better knowledge of the cause, if we know for sure, it's something related to the ability to use ISDN (no devices beside 7390/7490 are reported yet).
It seems to be impossible to deny loading the piglet completely without loosing every phone/fax related function, but downgraded models have to do the same job with the same code base and there should be an environment setting to "switch off ISDN support". Afaik that's done with the CONFIG_CAPI_NT/CONFIG_CAPI_TE settings for internal/external support and it could be worth a check. I don't think, that it will reveal the real cause … but it could be another small step for a man, but a giant leap for (no, not the mankind) clearer understanding of another (possibly) determining factor.

To explain my assumption (and my insistence to know it for sure), why the issue is recognized for ISDN capable devices only, I'd use the following pseudo code:

IF (ISDN is available/possible) THEN

action A
action B
action C

ELSE

action B

ENDIF

The structure of the code above would make it difficult to summarize 'action B' for both cases and without occassion nobody would bother to change that code.

The fact, that there's not even a single report for other models (related to the same issue), leads me to believe that it's related to a unique feature of 7390/7490 only and the ISDN support is the only one I can see there. And the suspected code parts (or better the meanwhile known crash triggers) are all together related to phone/fax settings for sure … my opinion.

comment:243 Geändert vor 3 Jahren durch PeterPawn

Mal was ganz anderes … kann es sein, daß die Maßnahmen zur Spam-Abwehr etwas zu extrem verschärft wurden ? Für den vorhergehenden Kommentar wurde eine Spam-Wahrscheinlichkeit von 98,81% ermittelt. Nun muß ja sicherlich nicht jeder sich für das interessieren, was ich da in schlechtem Englisch von mir gebe, aber >98% stimmen mich schon nachdenklich.

Oder liegt es am Ende wirklich am Englischen ?

An meinen Ausschweifungen wird es sicherlich nicht liegen, auch wenn ich mich dafür gerne noch einmal bei allen Lesern entschuldige. Um es etwas abzuwandeln: "Hier schreibe ich, ich kann nicht anders, Freetz helfe mir, AVMen."

comment:244 als Antwort auf: ↑ 242 ; Antwort: Geändert vor 3 Jahren durch HarryT

Replying to PeterPawn:

Replying to HarryT:

A complete fresh 7490 box, no freetz settings and no fritz settings.

That's curious … but you've used an own image, haven't you ?

It is a Freetz image


If this happens with the original firmware too, it would be very amazing and the first advice of such behaviour (here - no clue of AVM's own state of knowledge).

:-) the original firmware runs fine. Even with fhem installed.

If it's a modified firmware image without the suspected FREETZMOUNT patches, please attach the .config file used to build it (or add an advice, where to find it in an earlier comment if it's unchanged).

It is WITH Freetzmount, and I didn't publish my .config yet. I will build without Freetzmount and look if I can make it instable. As far as I remember I had a situation without Freetzmount and crashes but at that moment with lots of other stuff. If I can create an instable situation without Freetzmount and only the firmware, I could publish the .config and a simple instruction how to crash it. I guess that could help a lot.

If it's really a blank box, it beats me why we can't reconstruct the same situation with any other box in the wild.

I will repeat my test to see if I can reproduce my results.

What's the right setup to do that … we have the same problem across different devices (7390 and 7490) and across different origins (therefore it's not a layer8 error).

Together with your report it's not a "settings zombie" too. Why can't we find a "trigger button" to push ?

:-((

To get a stable system for production use today, you'd better use an older base indeed.

I know. I have my old 7390 running again with 6.04. I bought the 7490 because I thought my 7390 had hardware problems. :-( And now I have an excellent test box :-)


Is there another usefull test?

There're still some ideas, how somebody could try to track down the cause, but it's only poking about in the fog and I'm embarrassed to give advice only, 'cause I'm unable to check it by myself.
One interesting question I reflect upon is building an image with CAPI values set to "no". Imho there's a chance to get a better knowledge of the cause, if we know for sure, it's something related to the ability to use ISDN (no devices beside 7390/7490 are reported yet).
It seems to be impossible to deny loading the piglet completely without loosing every phone/fax related function, but downgraded models have to do the same job with the same code base and there should be an environment setting to "switch off ISDN support". Afaik that's done with the CONFIG_CAPI_NT/CONFIG_CAPI_TE settings for internal/external support and it could be worth a check.

It is for testings so no problems when there is no phone/fax on the box. The only problems is that I don't have a good way to let it crash as I now do this by installing the fax. But I have the impression that fhem helps a lot with the crashing so I can try several things with that.
If anybody can explain to me how to exclude ISDN I will give it a try the next days.

The fact, that there's not even a single report for other models (related to the same issue), leads me to believe that it's related to a unique feature of 7390/7490 only and the ISDN support is the only one I can see there.

Is it know if many people use freetz on a another box as the 7390/7490? Maybe I am able to test this with a 7360 next week.

And the suspected code parts (or better the meanwhile known crash triggers) are all together related to phone/fax settings for sure … my opinion.

I still wonder if other people also have constistent noise on the phoneline when they have an instable box. That might be a very quick check for a possible instable system, and leads to the conclusion it has something to do with the instability.

Zuletzt geändert vor 3 Jahren von HarryT (vorher) (Diff)

comment:245 als Antwort auf: ↑ 244 ; Antwort: Geändert vor 3 Jahren durch PeterPawn

Replying to HarryT:

It is for testings so no problems when there is no phone/fax on the box. The only problems is that I don't have a good way to let it crash as I now do this by installing the fax. But I have the impression that fhem helps a lot with the crashing so I can try several things with that. If anybody can explain to me how to exclude ISDN I will give it a try the next days.

Disabling the ISDN support does not imply that there's no more phone/fax support for POTS/DECT.

I was a little bit stupid … to disable ISDN support it should be sufficient to write it to /var/flash/featovl.cfg. The two commands

echo CONFIG_CAPI_NT=n >>/var/flash/featovl.cfg
echo CONFIG_CAPI_TE=n >>/var/flash/featovl.cfg

would be all that is needed. There's a small chance to enter a reboot loop … but usually the content of featovl.cfg is only used to overrule some fixed firmware settings from /etc/init.d/rc.conf. One additional point is: the display of firmware versions becomes corrupted, because the rc.conf file is sourced from /etc/version too and any settings from featovl.cfg will be written (as log) to stdout and clobber the displayed firmware version.

To reenable ISDN support, write an empty line to the featovl.cfg file without appending. Your original featovl.cfg should be empty too.

comment:246 als Antwort auf: ↑ 245 Geändert vor 3 Jahren durch HarryT

A short update. I had only very limited time tonight.

I succesfully edited featovl.cfg and the fritzbox come up afterwards. I was not able to trigger a crash, but the noise in the telephone line is available and makes the use of the telephone impossible. So I suspect I get a crash when working with it.

I hope to have time to do more test tomorrow.

Zuletzt geändert vor 3 Jahren von HarryT (vorher) (Diff)

comment:247 Geändert vor 3 Jahren durch HarryT

Just a very long shot. Might it be that the toolset on which the firmware is generated is the key?
I have problems with a 7390 (international converted to german) and a german 7490 box and others don't have problems at all. So maybe the way I generate the firmware is the key.

I use openSUSE 13.1 for the build.

Zuletzt geändert vor 3 Jahren von HarryT (vorher) (Diff)

comment:248 Antwort: Geändert vor 3 Jahren durch HarryT

Today the box with

echo CONFIG_CAPI_NT=n >>/var/flash/featovl.cfg

echo CONFIG_CAPI_TE=n >>/var/flash/featovl.cfg

reboots constant. Maybe the difference is that it was disconnect over night from the power.

As I believe the noise on the phoneline making a connection impossible is the first sign of trouble.

When I bring my box back to the original 6.20 it is ok. I didn't enter a single setting after the recovery
An image generated on Freetz-Linux and Freetzmount gives the noise on te phoneline
An image generated on openSUSE without Freetzmount gives also the noise on the phoneline.

Again the last situations where after the recovery and I did NOT set any setting at all. No external telephone line or internet was connected.

I must admit I have no ideas anymore how I can trace the problem.

I hope my findings where usefull.

comment:249 als Antwort auf: ↑ 248 ; Antwort: Geändert vor 3 Jahren durch PeterPawn

Replying to HarryT:

As I believe the noise on the phoneline making a connection impossible is the first sign of trouble. 

I've problems to believe, the noise is related to the crash in conjunction with the USB problems here.

Why ? There were multiple reports regarding the crash, but nobody else wasted any words on a noisy phone line. Therefore I'd say, you run into another problem too.

If my memory serves me right, there were some reports about trouble building images with openSuSE in the past. But that's something where I'm 404 and you'd better not rely on me.

Reading some of your statements above, I'd think you're using Freetz's remove patches to make room at the flash of the 7390. If I had to guess, I'd say, you've transfered an earlier 7390 configuration to the 7490 build process (I did that too) without regard to the available space there. If you disable every unneeded remove patch for the 7490 (the root filesystem for such a device could grow far more than 40 MB), I'm optimistic about your ability to build an usable Freetz image for the (german) 7490 even with 06.20 as base. I would use the Freetz-linux system (or another Ubuntu system), but that's only a guess and I'm unable to justify my opinion … perhaps 'cause most people use (afaik) such one.

I hope my findings where usefull.

Every test is useful. Your test without ISDN support was - imho - a good hint, especially after your inability to crash it immediately like you could do before. I hope, there will be another reader who can verify that finding.

One last thought about the noise from your phone … if you remove a needed codec or something else with a patch, which was not crafted for the 7490 (imho every remove patch is meaningless there, only replace patches for duplicate services like DNS or DHCP are needed) and even not for the special firmware version, there's a needless chance you run into trouble. The noise played is a dial tone with a wrong format in my opinion and you could avoid it, if you do not remove any file from the original image. It's worth a shot …

comment:250 als Antwort auf: ↑ 249 Geändert vor 3 Jahren durch HarryT

Replying to PeterPawn:

Replying to HarryT:

As I believe the noise on the phoneline making a connection impossible is the first sign of trouble. 

I've problems to believe, the noise is related to the crash in conjunction with the USB problems here.

Why ? There were multiple reports regarding the crash, but nobody else wasted any words on a noisy phone line. Therefore I'd say, you run into another problem too.

Right. But on the other hand, I myself only found this after extensive testing. Picking up the phone is not the first thing you do after flashing the firmware. But indeed if noboddy can confirm this it looks something special for me.

If my memory serves me right, there were some reports about trouble building images with openSuSE in the past. But that's something where I'm 404 and you'd better not rely on me.

Maybe, but I use openSUSE for years now to build Freetz images. No problems with that intill yet.But here also, t would be nice to hear if other users use openSUSE with or without problems.

Reading some of your statements above, I'd think you're using Freetz's remove patches to make room at the flash of the 7390. If I had to guess, I'd say, you've transfered an earlier 7390 configuration to the 7490 build process (I did that too) without regard to the available space there.

Right. But I used a lot of external processing on my 7390 and this is switched of for my 7490.Besides I also tried removing the .config and start again. But I am not sure if I did a make clean then.

If you disable every unneeded remove patch for the 7490 (the root filesystem for such a device could grow far more than 40 MB), I'm optimistic about your ability to build an usable Freetz image for the (german) 7490 even with 06.20 as base. I would use the Freetz-linux system (or another Ubuntu system), but that's only a guess and I'm unable to justify my opinion … perhaps 'cause most people use (afaik) such one.

I did yesterday one of my tests with an image build on Freetz-linux and a new .config with all default settings on a freshly recoverd box. → noise on the line.

One last thought about the noise from your phone … if you remove a needed codec or something else with a patch, which was not crafted for the 7490 (imho every remove patch is meaningless there, only replace patches for duplicate services like DNS or DHCP are needed) and even not for the special firmware version, there's a needless chance you run into trouble. The noise played is a dial tone with a wrong format in my opinion and you could avoid it, if you do not remove any file from the original image. It's worth a shot …

Hmmm. I will try a fresh almost default .config with remove patches disabled and see what happens. Both on openSUSE and Ubuntu.

Geändert vor 3 Jahren durch HarryT

.config on Mint default settings for 7490

comment:251 Antwort: Geändert vor 3 Jahren durch HarryT

I just generated a new build on a fresh Mint 64 bits installation with a new and default .config file. I attached the config file.

  • I generated the freetz image on a fresh Mint (Ubuntu) OS
  • I recoverd the fritzbox before loading the image.
  • Loaded the freetz firmware
  • After the fritzbox come up, I entered the GUI
  • tried to do some Fax settings and the GUI crashed
  • after some minutes the fritzbox reboots

I didn't enter a single settings!
If it helps to have my firmware build, I can make it available. I guess it is somehow possible to send me a PM message.

@PeterPawn: Indeed the terrible noise is gone and it is still unstable.

I still don't understand why it seems to work by other people. The only difference I can think off yet is that I build on a 64 bit environment.

comment:252 als Antwort auf: ↑ 251 Geändert vor 3 Jahren durch PeterPawn

Replying to HarryT:

If it helps to have my firmware build, I can make it available. I guess it is somehow possible to send me a PM message.

If it's the version for 7390, I'd like to get it, to use it for further investigations. If it's 7490 only, it's still interesting, but currently I've no free 7490 to verify anything with it.

But it's not as easy as you think - I'd say better: I've no idea, how to write you a personal message here. If you own an account at IPPF too, I could use it … but I'm unsure, if this account is yours:http://www.ip-phone-forum.de/member.php?u=111136

comment:253 Geändert vor 3 Jahren durch HarryT

It is a 7490 image. Anyway, I tried yesterday to make a build without freetzmount and that runs stable and no noise on the line. Today I generated a new build with all the stuff I need. (destroyed the correct build because I did a make distclean :-( ) And now noise on the line again. Grrr. But at least for 10 minutes it runs stable and I was no able to crash it. So I can build parts to find out when the noise on the line starts. So lots of work for the next days. But I still wonder if noboddy else has this noise on the line. Or is everybody stopped with testing?

Its is http://www.ip-phone-forum.de/member.php?u=362568

comment:254 Geändert vor 3 Jahren durch Conan179

Dürfte ich mal Fragen, ob das Problem immer noch gibt? ich würde, wen möglich, meiner 7272 auf die 06.20 updaten, ohne das es einen Neustart gibt, wen ich Das Telefongeräte Menü öffne.

comment:255 Geändert vor 3 Jahren durch PeterPawn

Ja, prinzipiell besteht das Problem noch.

Du könntest hier die Lorbeeren ernten, wenn Du der erste bist, der es auf einer 7272 einfach mal probiert und davon berichtet. Bisher gibt es nur Meldungen für 7390 und 7490, da die 7272 ja auch internes und externes ISDN hat, ist es interessant zu erfahren, ob sie betroffen ist.

Andere Modelle ohne ISDN-Funktionen (7362, 7360, 3xxx) sind bisher jedenfalls auch noch nicht auffällig geworden. Solange bei Dir der Workaround im FREETZMOUNT funktioniert (das ist bei einigen ja auch der Fall), solange riskierst Du ja nichts. Spätestens ohne USB-Speicher sollte sich jede FRITZBox von dem hier diskutierten Fehler umgehend erholen, einen Absturz ohne vorhandenen USB-Speicher hatten wir imho noch nicht.

comment:256 Antwort: Geändert vor 3 Jahren durch meowClown

Nur zur Info, die 7360 hat das Problem auch. Ich habe es mit freetz stable und trunk versucht. Sobakd ich zum Beispiel auf Weckruf in der FritzBox-Oberfläche klicke, bricht die Verbindung ab und die Box macht einen Neustart.

comment:257 Antwort: Geändert vor 3 Jahren durch Conan179

@PeterPawn Die 7272 ist betroffen in der Labor phase hab ich es aus probiert und die 7272 hat neustarts gemacht, wen ich in das Menü für Telefonie Geräte geklickt habe, hab es auch hier als Ticket geschrieben http://freetz.org/ticket/2566

comment:258 als Antwort auf: ↑ 257 Geändert vor 3 Jahren durch PeterPawn

Ok, dann also ein weiteres Modell … wobei ich nicht richtig verstehe, ob Du das aus aktuellen Erkenntnissen schließt oder aus den in 2566 beschriebenen Problemen. Da das dort mit "replace kernel" los geht und mit irgendeinem Patch für das Erstellen der Kernel-Symbole endet, wird zwischendrin für mich absolut nicht mehr deutlich, was die konkreten Rahmenbedingungen waren.

Der augenfälligste Unterschied zwischen Deinem ctlmgr-Absturz und den hier im Ticket isolierten Problemen ist, daß bei Dir schon der erste Operand für den Stringvergleich eine ungültige Adresse war (AGED in a0). Damit ist sicherlich ein grober Zusammenhang mit den hier diskutierten Problemen nicht von der Hand zu weisen, aber es muß irgendeine Rahmenbedingung existieren, die bei Dir schon zu einem falschen ersten Operanden führt.

Auch wenn es viel Arbeit ist, würde ich ein Basis-Image mit Freetz bauen und damit erst einmal testen. Da gleich ein "replace kernel" o.ä. zu versuchen (das ist ja auch in Verbindung mit VoIP-Funktionen imho noch etwas verdächtig in einem anderen Ticket), kann gut gehen, verstellt aber bei einem Fehler den Blick auf die Ursachen, wie man an 2566 ziemlich gut sehen kann.

Wenn das Basis-Image sich auf einer "leeren" Box mit einer der o.a. Abfragen zum Absturz bringen läßt (und der FREETZMOUNT-Workaround - der bei Deinem Ticket verwendet wurde oder auch nicht, ich blicke nicht so richtig durch - nichts bringt), dann kannst Du vielleicht helfen, eine Firmware zu finden, die auf wirklich jeder Box abstürzt und somit eine bessere Lokalisierung des Fehlers ermöglichen.

comment:259 als Antwort auf: ↑ 256 Geändert vor 3 Jahren durch PeterPawn

Replying to meowClown:

Nur zur Info, die 7360 hat das Problem auch. Ich habe es mit freetz stable und trunk versucht. Sobakd ich zum Beispiel auf Weckruf in der FritzBox -Oberfläche klicke, bricht die Verbindung ab und die Box macht einen Neustart.

Auch wenn das eher nebenbei und schon ziemlich unbestimmt ist, erstmal danke für die Info.

Leider wirft das mehr Fragen auf, als es beantwortet.

Da wir hier mit hoher Wahrscheinlichkeit einen Zusammenhang zur 06.20 unterstellen, leuchtet es mir nicht auf Anhieb ein, wie Du das mit "freetz stable" versucht haben willst. Nicht, daß es nicht prinzipiell auch denkbar wäre, aber bitte erläutere, wie Du dabei vorgegangen bist.

Auch die anderen Informationen/Tests/Schlußfolgerungen - also wie Du festgestellt hast, daß bei Deinem Problem ein Zusammenhang zu den anderen Berichten in diesem Ticket besteht - wären hilfreich.

Schon wenn es Dir gelingt, bis zum "Weckruf"-Link auf der linken Seite des FRITZBox-GUI (also im Menü) vorzudringen, wärst Du ja eigentlich einen Schritt weiter, als viele andere hier, wenn das Problem auftritt. Wenn Du den "Weckruf n"-Link unter "Komfortfunktionen" in der Übersichtsseite meinst, hättest Du das ja sicherlich anders formuliert. Wobei auch auf der Weckruf-Seite durchaus eine "enumeration of fon devices" erfolgen könnte (für die SELECT-Box mit dem Geräten), da könnte die "fon_devices.lua" ohne weiteres wieder im Spiel sein.

Auch die anderen Rahmenbedingungen (FREETZMOUNT ja/nein, USB-Speicher ja/nein, Nachrichten auf dem AB ja/nein, kurz so ziemlich jede Information zu dem, was wir bisher hier schon diskutiert/verdächtigt haben) wären hilfreich. Es gibt so viele andere Möglichkeiten, warum das bei Dir nicht funktionieren könnte, da mußt Du ja irgendwelche Anhaltspunkte haben, die Dich zu Deiner Aussage veranlaßten.

Weiter oben steht auch, wie man den ctlmgr zur Preisgabe der Absturzstelle (bzw. der auslösenden Abfrage) bewegen kann, spätestens damit kann man dann feststellen, ob da ein Zusammenhang bestehen könnte oder nicht. Auch ein Crash-Log wäre hilfreich, der Verweis auf den abgestürzten ctlmgr-Prozess im Zusammenhang mit vier Zeichen des Mountpoint-Namens in a1 beim Absturz wären schon ein starkes Indiz.

Zuletzt geändert vor 3 Jahren von PeterPawn (vorher) (Diff)

comment:260 Geändert vor 3 Jahren durch make

Ich hab, nach vielen ergebnislosen Experimenten, möglicherweise einen Fortschritt gemacht. Auf der 7390 ist es wohl so, das FREETZMOUNT das Problem höchstens triggert, aber nichts ursächlich damit zu tun hat.

Da der Verzicht auf FREETZMOUNT leider ausser viel Arbeit keine positiven Effekte nach sich gezogen hat, habe ich mal eine Firmware gebaut, die mit der originalen uclibc läuft ("Keep AVM uClibc"). Diese Firmware habe ich als Ausgangsbasis für ein USB-RootFS genommen. Nach dem Booten zeigt sich als erstes, das viele Dienste gar nicht erst starten (zB openSSH), ABER es ist nicht mehr möglich, die Box via telnet mit "ctlmgr_ctl w telcfg settings/FaxMailActive 3" zum Reboot zu zwingen… Statt dessen wird der Befehl genauso klaglos ausgeführt wie mit einer reinen AVM Firmware.

(Ich muss mir das morgen nochmal etwas genauer anschauen, da ich bei der Firmware noch einige zusätzliche Settings verändert habe…)

Zuletzt geändert vor 3 Jahren von make (vorher) (Diff)

comment:261 Antwort: Geändert vor 3 Jahren durch PeterPawn

@make:
Ist da etwas genaueres bei herausgekommen ? Auch wenn die Rahmenbedingungen mit USB-Root sicherlich nicht denen bei anderen entsprechen und wir (bzw. ich) auf der Suche nach dem genauen Gegenteil sind (also nicht das Vermeiden, sondern das Ergründen von Triggern), kann das natürlich durchaus auch an der Lib liegen. Ich kriege jedenfalls beim Vermischen der AVM-uClibc mit der Freetz-Variante bei meinen "Nicht-Freetz"-Modifikationen auch oft genug Probleme, i.d.R. auch in Form von SIGSEGV - meist halt ohne Dump. Insofern halte ich das Suchen an dieser Stelle auch für eine mögliche Herangehensweise, aber ich sehe den Weg zur Lösung nicht so richtig. Ein Workaround, bei dem die AVM-Lib erhalten bleibt, dürfte ja nur lokal zum faxd/ctlmgr arbeiten, ansonsten funktioniert der Rest nicht mehr. Wenn Du nur für den Start von faxd/ctlmgr die AVM-Lib (per PRELOAD oder LIBRARY_PATH) setzt, ist der Fehler dann auch weg ?

Ansonsten bin ich noch auf ein - meines Wissens bisher auch nicht dokumentiertes - File im Zusammenhang mit der Behandlung des USB-Speichers durch die AVM-Firmware gestoßen, allerdings bei der Analyse des Inhalts und der Zugriffe darauf bisher nur bis zur libctlusb.so vorangekommen. Der Name "/var/.SHMUSBDEVICES" legt imho eher eine Art IPC nahe, aber dann ist es mit der Idee auch schon wieder vorbei, wozu die nun wieder gut sein mag.

Bei der gesamten Wühlerei durch die USB-Geschichten in der Firmware ist mir noch eine weitere potentielle Ursache aufgefallen, die man zwischen den Boxen, wo der Fehler auftritt und denen, wo man ihn partout nicht hervorrufen kann, abgleichen könnte.
Die Benutzerverwaltung erlaubt ja inzwischen die Zuordnung von Benutzerrechten für bestimmte NAS-Pfade. Nachdem diese NAS-Pfade i.d.R. ein Parent-Directory des von der Firmware für die Speicherung von Anrufen/Faxen verwendeten FRITZ-Verzeichnisses beinhalten und die abstürzenden Funktionen dort Zugriffsrechte testen könnten, würde ich alle Leute mit abstürzenden Boxen noch einmal darum bitte, die Zugriffsrechte des angemeldeten Benutzers auf das FRITZ-Verzeichnis auf dem USB-Speicher explizit zu prüfen und ggf. vielleicht sogar einmal den Zugriff ausdrücklich zu erlauben, wenn dort nur allgemein "alle Speicher" ausgewählt ist. 2-3 Meldungen, ob es mit oder ohne Berechtigungen exakt derselbe Fehler ist, würden schon reichen. Danke

comment:262 Geändert vor 3 Jahren durch make

Ich habe mich in den letzten Tagen nochmal durch den ganzen Thread gelesen und dabei feststellen müssen, dass ja das ein oder andere längst bekannt ist.
Ich konnte in den letzten Tagen funktionierende Firmwares sowohl mit als auch ohne FREETZMOUNT bauen, genau so wie es mir möglich war, Freetz-Firmwares sowohl mit wie auch ohne FREETZMOUNT zum Absturz zu bringen. Insofern leider wenig Erkenntnisgewinn. Ich hab noch zwei, drei Ideen, denen ich mal nachgehen will.

  • ich hatte den Eindruck, dass beim Wechsel von "mit FREETZMOUNT" zu "ohne FREETZMOUNT" (und andersrum) gerne mal die Faxeinstellungen "kaputt" gehen (mit nachfolgenden Boot-Loops). Nachdem ich dann von Hand auf FaxMailActive 1 umgeschaltet habe, hörte das ständige Rebooten auf.
  • mir ist aufgefallen, dass ich in einigen Settings (FritzNas-Berechtigungen?) noch Pfade zu einem uStor0x-Verzeichnis hatte, das es natürlich nicht mehr gibt.
  • Mindestens einmal hatte ich den Effekt, dass nach dem Löschen aller FRITZ/fritz-Ordner auf dem Stick und im internen Speicher gar nichts mehr ging. Anrufbeantworterspeicher voll, Reboots bei FaxMailActive 3. Dabei ist mir aufgefallen, was ja auch schon thematisiert war, das die Partition, auf der Anrufbeantworter, Fax usw. ihre Daten ablegen, bei mehreren Partitionen von der Mount-Reihenfolge abhängt. Die Mount-Reihenfolge wiederum scheint mir zufällig zu sein, meine 4 Partitionen auf dem Stick werden nach jedem Reboot in einer anderen Reihenfolge gemounted (mit FREETZMOUNT, ohne hab ich das noch nicht überprüft). Vielleicht sind die Datenbanken unterhalb des Fritz-Verzeichnisses irgendwie korrupt und je nachdem in welcher Reihenfolge gemountet wird, spielt das eine Rolle oder nicht?

Im Moment läuft bei mir alles ohne Probleme, ich kann machen was ich will — die Box stürzt nicht mehr ab (auch nicht bei FaxMailActive 3). Ich bau jetzt erstmal eine neue FW mit eigener Toolchain, für den Fall dass ich irgendwann wieder Probleme habe. Wenn du noch Ideen hast…

comment:263 als Antwort auf: ↑ 261 Geändert vor 3 Jahren durch HarryT

Replying to PeterPawn:

Bei der gesamten Wühlerei durch die USB-Geschichten in der Firmware ist mir noch eine weitere potentielle Ursache aufgefallen, die man zwischen den Boxen, wo der Fehler auftritt und denen, wo man ihn partout nicht hervorrufen kann, abgleichen könnte.
Die Benutzerverwaltung erlaubt ja inzwischen die Zuordnung von Benutzerrechten für bestimmte NAS-Pfade. Nachdem diese NAS-Pfade i.d.R. ein Parent-Directory des von der Firmware für die Speicherung von Anrufen/Faxen verwendeten FRITZ-Verzeichnisses beinhalten und die abstürzenden Funktionen dort Zugriffsrechte testen könnten, würde ich alle Leute mit abstürzenden Boxen noch einmal darum bitte, die Zugriffsrechte des angemeldeten Benutzers auf das FRITZ-Verzeichnis auf dem USB-Speicher explizit zu prüfen und ggf. vielleicht sogar einmal den Zugriff ausdrücklich zu erlauben, wenn dort nur allgemein "alle Speicher" ausgewählt ist. 2-3 Meldungen, ob es mit oder ohne Berechtigungen exakt derselbe Fehler ist, würden schon reichen. Danke

Not the test you asked for, but I used a FAT USB-stick during my test, so rights can't be the problem I guess.
Or are my thoughts wrong?

comment:264 Geändert vor 3 Jahren durch PeterPawn

It's really not a problem with filesystems and "normal" access control. If you restrict user's access to NAS directories, an additional entry will be added to usb.cfg:

usbhost {
        readonly = no;
        password = "";
        autoprov_enabled = no;
        ftp_internet_enabled = no;
        aura_enabled = no;
        aura_config = 0;
        ftp_server_enabled = yes;
        samba_server_enabled = yes;
        samba_server_workgroup = "WORKGROUP";
        samba_server_server_string = "HOSTNAME";
        users_enabled = yes;
        acl_directories {
                path = "/data/Storage";
                access {
                        UserID = 10;
                        local_read = yes;
                        local_write = yes;
                        internet_read = no;
                        internet_write = no;
                }
        }
        spindown_enabled = no;
        spindown_time = 600;
        usbhost_version = 1;
        internet_secured_only = no;
        fritznas_share = "SHARENAME";
        usb3port_config = 0;
}

Some parts of AVM's firmware honor such a restriction while calculating an effective access list. My idea was, that there could be an undetected error and only FRITZBox owners with "paranoid" security settings (e.g. the used account does not have any access to the NAS directories 'cause it's denied) run into the error or quite the opposite and only users without special settings are affected.

It's one more time nothing I could justify … only another try to reflect about the possible causes of the very different behaviour.

comment:265 Geändert vor 3 Jahren durch wl_michael

Hallo ich habe die komplette FRITZBox zurückgesetzt und dann nach und nach angefangen die Elemente neu zu installieren. Dabei ist mir aufgefallen dass alles funktioniert bis zu ich die Onlinefestplatte einbinde. Sobald ich diese einrichte stürzt das Telefonmenü sofort ab und es beginnen die reboots.
Wenn ich die Onlinefestplatte wieder deaktiviere geht alles wieder ganz normal .
Ich habe dann davfs2 von freetz installiert.
Wenn ich jetzt eine Onlinefestplatte zsb Mydrive einhänge ohne Zertifikat funktioniert alles problemlos. Sobald ich aber die der Telekom einhänge mit Zertifikat beginnen sofort wieder die Abstürze und reboots.
Meine Box läuft somit stabil solange ich nicht ein Zertifikat bei der online Festplatte verwende.
Vielleicht hilft das ja jemanden weiter. Ich bin zu wenig Experte um genau zu wissen an welcher Schraube ich noch drehen kann. Daher hoffe ich auf weitere Rückmeldungen

comment:266 Geändert vor 2 Jahren durch CarstenSchuette

Gibt's dazu eigentlich mittlerweile was Neues oder eine Idee?
Meine 7490 crasht nämlich neuerdings auch beim Klick auf die Telefoniegeräte….

Übrigens ist das Problem bei mir mit FREETZMOUNT in Verbindung zu bringen. Ein Image ohne FREETZMOUNT läuft einwandfrei, sobald FREETZMOUNT aktiv ist, treten die Probleme auf.

Zum Thema Onlinespeicher, das ist hier mit dem 1&1-Onlinespeicher wie von wl_michael beschrieben nachvollziehbar. Sobald der Onlinespeicher eingebunden ist, treten die Crashs auf. Ohne Onlinespeicher scheint die Box stabil zu sein. Dabei ist es unerheblich, ob ich davfs2 oder den AVM-Onlinespeicher verwende. Macht irgendwie auch Sinn, denn der Onlinespeicher greift ja auf das USB-Medium zu.

Allerdings ist der Crash des faxd unabhängig vom Onlinespeicher immer noch da. Sobald der faxd so eingestellt wurde, dass der USB-Speicher zur Ablage der Faxe verwendet werden soll, crasht der faxd. Entweder beim Speichern der Einstellungen aus dem WebIF, oder - wenn diese Einstellung da ist - beim Booten der Box (Bootloop). Das hatte ich ja vor ein paar Wochen schon mal so beschrieben.

Fazit: Sieht so aus, als wenn ein grundsätzliches Problem beim Zugriff auf den USB-Speicher besteht, und zwar nicht auf das Volume selbst, sondern wenn versucht wird, festzustellen, welche USB-Speicher es gibt.

Hier nochmal ein crashlog, das auftritt, wenn ich versuche, dem Faxdienst das Speichern auf dem USB-Speicher zu konfigurieren. in a1 steht "USto" und in den libhtmltemplate-Aufruf wird als Parameter 0x5553746e übergeben, was UStn, was besagtem a1-Wert -1 entspricht. Nicht wirklich sinnvoll, oder? Mal ins Blaue geschossen: Da wird unmittelbar vor dem Crash eine Funktion aufgerufen (aus FREETZMOUNT oder davon neu hinzugefügten/verbogenen Libs), die einen Pointer auf den String "UStor01" zurückgeben sollte. Statt dessen gibt sie aber den Inhalt des Strings zurück, eben "USto", und das ist als Pointer natürlich Humbug.

Kann man das irgendwie tracen und in eine Datei schreiben, welche Lib-Funktionen aufgerufen werden?

2015-01-06 09:04:53(1) [Segmentation fault] /usr/bin/avm/ctlmgr(1486) CRASHED at strcmp+0xc (/lib/libc.so.0 at 00038b9c) accessing 0+0x5553746e (/lib/libhtmltemplate.so.0 at 29c9546e)
SIGNO 11 ERRNO 0 CODE 1
Version: 06.23
Watchdog triggered 1 seconds ago
No bugmsg
ze: 00000000 at: 00000001 v0: 2ae5db90 v1: 00000046
a0: 2b0c552b a1: 5553746f a2: 55537470 a3: 2b0c552c
t0: 00000000 t1: 00000000 t2: 0000005b t3: ffffff80
t4: 00000063 t5: 00000073 t6: 0000005b t7: 622f3030
s0: 2b0ccc30 s1: 2b90bd18 s2: 2b813960 s3: 2b5773c0
s4: 2b557728 s5: 2b813c60 s6: 2b8b7550 s7: 2b5577d8
t8: 00000000 t9: 2ae5db90 k0: 00000001 k1: 00000000
gp: 2b0ccc30 sp: 7fc5a070 fp: 2b813260 ra: 2b08553d
FA 5553746e 0+0x5553746e (/lib/libhtmltemplate.so.0 at 29c9546e)
PC 2ae5db9c strcmp+0xc (/lib/libc.so.0 at 00038b9c)
RA 2b08553c 0+0x2b08553c (/usr/share/ctlmgr/libtelcfg.so at 0000353c)
Code: 90830000  24870001  24a60001 <14600003> 90a20000  03e00008  00021023  00e02021  1062fff7 
[bt]  2b085538 [2b08548a] <0+0x2b08548b>+0xae (/usr/share/ctlmgr/libtelcfg.so at 0000348a)
[bt]  2b09226c [2b0921ae] <0+0x2b0921af>+0xbe (/usr/share/ctlmgr/libtelcfg.so at 000101ae)
Signal Segmentation fault while doing crashdump (2)
2015-01-06 09:04:53(2) [Segmentation fault] /usr/bin/avm/ctlmgr(1486) CRASHED at 0+0x2ad4c5f8 (/lib/libavmcsock.so.2 at 000515f8) accessing 0+0x2b78bffc (/usr/share/ctlmgr/libtr069.so at 001b2ffc)
SIGNO 11 ERRNO 0 CODE 2
ze: 00000000 at: 181020b5 v0: ffff0000 v1: 2b78c008
a0: 3c1c0000 a1: ffff8000 a2: 27bd8000 a3: 279c0000
t0: 00000000 t1: 00000000 t2: 00000000 t3: 00000000
t4: 00000000 t5: 7f000001 t6: 004125a0 t7: 0399e021
s0: fffffef0 s1: 2ad4ad00 s2: 00000000 s3: 7fc5a258
s4: 2b0921af s5: 000064f7 s6: 2b813ca0 s7: 00000000
t8: 00000102 t9: 2ae84bf4 k0: 00000001 k1: 00000000
gp: 2ad7d0a0 sp: 7fc59610 fp: 2b813260 ra: 2ad4cad8
FA 2b78bffc 0+0x2b78bffc (/usr/share/ctlmgr/libtr069.so at 001b2ffc)
PC 2ad4c5f8 0+0x2ad4c5f8 (/lib/libavmcsock.so.2 at 000515f8)
RA 2ad4cad8 0+0x2ad4cad8 (/lib/libavmcsock.so.2 at 00051ad8)
Code: 10000027  24630008  004a5024 <5544000b> 8c6bfff4  55670009  8c6bfff4  8c6b0000  01656024 
[bt]  2ad4cad0 [2ad4c364] <0+0x2ad4c364>+0x76c (/lib/libavmcsock.so.2 at 00051364)
[bt]  2ad4b950 [2ad4afb4] <0+0x2ad4afb4>+0x99c (/lib/libavmcsock.so.2 at 0004ffb4)
[bt]  !7fc59d50 rtsignal trampoline on stack
[bt]  2ae5db94 mempcpy+0x444 (/lib/libc.so.0 at 00038750)
Zuletzt geändert vor 2 Jahren von CarstenSchuette (vorher) (Diff)

comment:267 Geändert vor 2 Jahren durch dirkh

Das Befolgen des Vorschlages des Recover und des Aufspielen eines Minimal Freetz ohne Patches aus

http://freetz.org/ticket/2480#comment:6

führte bei mir trotzdem zum Crash. Es hat nur geholfen, die USB Festplatte abzuziehen und nach dem Hochfahren ranzustecken.

Nach ein wenig Probieren habe ich herausgefunden wie das Telefonie AVM Webinterface wieder mit gesteckter Festplatte nach dem Reboot funktioniert. Ich musste den Online-Speicher abschalten und den USB Anschlusstyp der Festplatte von USB 2.0 auf USB 3.0 stellen. Dann funktioniert ein Image mit und ohne FREETZ_MOUNT Patch.

comment:268 Geändert vor 2 Jahren durch blackstar

kann es soweit bestätigen das ich den Absturz reproduzierbar
ohne FREETZMOUNT auch habe.
http://www.ip-phone-forum.de/showthread.php?t=275861&page=2
gruß Blackstar

comment:269 Geändert vor 2 Jahren durch er13

In 12858:

Fritz!OS 6.20:

  • revert r12522 / r12523 - make once again the whole support for Fritz!OS-6.20 in Freetz as unstable
  • refs #2499

comment:270 Geändert vor 2 Jahren durch er13

Hallo zusammen,

das Ticket ist mittlerweile 6 Monate alt. Wir haben eine Unmenge an Fehlerberichten und auch eine Unmenge an Workarounds, die aber alle nur eines gemeinsam haben, dass sie (zugegebenermaßen etwas überspitzt ausgedrückt) nichts gemeinsam haben. Bei einem reicht es die FAX-Nachrichten auf dem USB-Träger abzuspeichern, um den Fehler zu provozieren, bei dem anderen muss zusätzlich der Online-Speicher(davfs) angebunden sein. Bei einem hilft der Freetzmount-Großbuchstabe-Trick, bei dem anderen muss der Anschlusstyp von USB2 auf USB3 umkonfiguriert werden, usw. Also, viele unterschiedliche Voraussetzungen und auch unterschiedliche Workarounds (wenn welche gefunden werden).

All das ist für mich ein Zeichen dafür, dass es sich um einen Memory-Corruption-Fehler (Stack/Heap) handelt. Meinem Gefühl nach ist es auch nicht auszuschließen, der Fehler befände sich in dem closed-source Code von AVM. Irgendeine Anpassung in Freetz führt nur dazu, dass der Fehler viel leichter provoziert werden kann.

Mein Verdacht ist die uClibc. Entweder wird diese mit einer inkompatiblen (zu der von AVM genutzten) .config gebaut oder wir haben einen uClibc-Patch, der entweder an sich fehlerhaft ist oder eben dazu führt, dass der (vermutete) AVM-Fehler viel leichter provoziert werden kann.

Ich habe mir zwar schon mehrfach alle uClibc-0.9.33.x Patches angeschaut, konnte jedoch bisher keinen Patch als fehlerhaft bzw. als besonders verdächtig identifizieren. Mit irgendwas sollten wir aber starten…

@alle, die mehr oder weniger deterministisch den Fehler provozieren/nachstellen können: würdet Ihr bitte mit einem frischen Checkout starten, in diesem den 190-nptl_no_stack_cache.openwrt.patch entfernen, dann Eure .config (mit der Ihr den Fehler nachstellen könnt) reinkopieren, menuconfig aufrufen und dann die Option "Toolchain options/Toolchains" auf "Build own toolchains" umstellen. Dann bauen, flashen und schauen, ob und, wenn ja, wie sich das Verhalten des Systems geändert hat. Danke!

Grüße,
Gene

comment:271 Antwort: Geändert vor 2 Jahren durch blackstar

Hallo
der Fehler tritt bei mir ohne FREETZMOUNT im zusammenhang mit Onlinespeicher auf (HTTPS)
http://www.ip-phone-forum.de/showthread.php?t=275861&page=2&p=2063457#post2063457
auch ohne den 190-nptl_no_stack_cache.openwrt.patch​ auf.
Box 7390 Labor Firmware
Blackstar

Geändert vor 2 Jahren durch blackstar

7390 ohne FREETZMOUNT ohne OpenWRT Patch Absturz bei genutzem Onlinespeicher

comment:272 Antwort: Geändert vor 2 Jahren durch er13

Mir fällt gerade ein, dass es eigentlich relativ einfach ist, zu testen, ob es ab uClibc liegt oder nicht. Man muss nur

  • das originale AVM-Image nehmen, dieses entpacken
  • die uClibc-Dateien aus der Freetz-Toolchain reinkopieren
  • modifizierte Firmware wieder packen, flashen, testen.
  1. diesen Artikel für detailliertere Beschreibung.

Damit erhält man ein Image, in dem nur eine einzige Komponente anders ist - die uClibc, sonst nichts.

Mag jemand von Euch bitte so ein Image erstellen und flashen (Freetz ist dann natürlich vorübegehend weg, sofern Ihr kein Recover benutzt/benutzen müsst, bleiben die Freetz-Einstellungen erhalten). Lässt sich der Fehler mit so einem Image nachstellen? Danke!

comment:273 als Antwort auf: ↑ 272 ; Antwort: Geändert vor 2 Jahren durch schalli

Replying to er13:

Mir fällt gerade ein, dass es eigentlich relativ einfach ist, zu testen, ob es ab uClibc liegt oder nicht. Man muss nur

  • das originale AVM-Image nehmen, dieses entpacken
  • die uClibc-Dateien aus der Freetz-Toolchain reinkopieren
  • modifizierte Firmware wieder packen, flashen, testen.
  1. diesen Artikel für detailliertere Beschreibung.

Damit erhält man ein Image, in dem nur eine einzige Komponente anders ist - die uClibc, sonst nichts.

Mag jemand von Euch bitte so ein Image erstellen und flashen (Freetz ist dann natürlich vorübegehend weg, sofern Ihr kein Recover benutzt/benutzen müsst, bleiben die Freetz-Einstellungen erhalten). Lässt sich der Fehler mit so einem Image nachstellen? Danke!

Hallo,
ich leide auch unter spontanen Reboots der Box und kann das Problem mit dem ctlmgr reproduzieren.
Ich würde mich bereiterklären, das Original-Image mit ersetzter uClibc auszuprobieren, wenn du mir verräts, welche Dateien ersetzt werden müssen.
Aber hat nicht CarstenSchuette in http://freetz.org/ticket/2499?replyto=272#comment:39 bereits bestätigt, dass es mit der Original uClibc funktioniert?

Grüße

schalli

comment:274 als Antwort auf: ↑ 273 Geändert vor 2 Jahren durch CarstenSchuette

Replying to schalli:

Aber hat nicht CarstenSchuette in http://freetz.org/ticket/2499?replyto=272#comment:39 bereits bestätigt, dass es mit der Original uClibc funktioniert?

Das war anders herum. Es gibt in freetz eine Option, um die AVM-uClibc beizubehalten und nicht durch die selbst gebaute zu ersetzen. Der hier geforderte Test ist anders herum, nimm ein Original-AVM-Image und tauschen darin nur die uClibc gegen die von freetz gebaute Version aus.

comment:275 Geändert vor 2 Jahren durch bjo81

Hallo,

ich habe gerade 12864 mit 6.20 auf meine 7320 geflashed, keine Probleme bei den Telefonieeinstellungen bisher. AB und Fax sind aktiv, allerdings nur mit interner Speicherung, USB-Stick ist nicht vorhanden. Freetzmount ist abgeschaltet.

comment:276 Antwort: Geändert vor 2 Jahren durch RoiDanton

Hallo zusammen,

ich habe mich auch mal an das Upgrade von 6.05 und einer älteren Freetz Trunk gewagt, also Freetz Trunk sowie die 6.23. Dachte, ich versuche es einfach mal. Zur Sicherheit habe ich mir auch ein Image mit der 6.05 gemacht, ansonsten exakt gleich.

Tja, zuerst dachte ich, ich kann hier etwas anderes vermelden, denn nach dem Upgrade war alles in bester Ordnung. Konnte jeden einzelnen Menüpunkt der Telefonie, genauer gesagt jeden einzelnen Menüpunkt der Fritz- und der Freetzoberfläche durchklicken, alles gut.

Dann rief hier jemand an, der uns nicht erreichte. Seither hing die Box mehr oder weniger in einem Bootloop. Gerade genug Zeit, das o.g. 6.05 Image zu installieren, das war aber knapp und klappte erst nach dem dritten Mal als ich sagte, er solle die AVM-Dienste beenden beim flashen…

Tjo, nicht so geil, da muss ich wohl noch etwas Geduld haben.

Viele Grüße,
Martin

comment:277 als Antwort auf: ↑ 276 ; Antwort: Geändert vor 2 Jahren durch PeterPawn

Replying to RoiDanton:

Dann rief hier jemand an, der uns nicht erreichte. 

Ich will nicht weiter auf der Geschichte herumreiten, wenn er13 jetzt versucht, die Erkenntnisse zu straffen … aber die Nachfrage kann ich mir dann auch nicht verkneifen.

War das am Ende ein verpaßter Anruf oder wurde der vom Anrufbeantworter angenommen und wenn das zweite der Fall ist, wurde dann auch eine Nachricht aufgezeichnet oder hat der Anrufer vorher wieder aufgelegt ? Ich frage deshalb, weil das eben drei verschiedene Zustände in der Anrufliste sind und ich in jedem Falle bereit bin zu beschwören, daß eine Abfrage von "UseStick", wie sie bei der Anzeige der Anrufliste ja bewiesenermaßen vorkommt, auch einen Zugriff auf den Datenträger auslöst, denn ansonsten dürfte eine "schlafende HDD" eigentlich nicht hochfahren und das macht sie bei mir definitiv - unabhängig davon, ob AB-Nachrichten dort abgelegt werden oder nicht bzw. ob welche vorhanden sind oder nicht.

Wenn das wirklich ein "memory/stack corruption"-Problem ist, spielt ja u.U. auch die Abfolge von internen Aufrufen eine entscheidende Rolle (wenn niemand auf die "schlechten Adressen" zugreift, geht das vielleicht häufig auch glimpflich aus).

Die Frage/Bitte, ob Du das versuchen könntest zu reproduzieren, kann ich mir sicherlich sparen, oder ? Wenn Du die Box brauchst, will ich Dir das auch nicht zumuten.

comment:278 Geändert vor 2 Jahren durch Conan179

Mir ist Folgendes Aufgefallen. Wen die SD karte an meiner 7272 hängt, fat32 ist, läuft die mein 06.20 trunk ohne neustarts, aber wen die karte im NTFS/ETX2/ETX3/EXT4 formatiert ist startet sie nach dem boot, nach wenigen minuten nach dem start neu.
Den online speicher von 1und1 hab ich ausgemacht.

comment:279 Geändert vor 2 Jahren durch blackstar

hallo
heute Trunk 12876 ausgecheckt build own uclibs ausgewählt.
die Box ist eine schwarze 1&1.
die Box arbeitet durch der Fehler tritt nicht mehr auf auch bei verbundenem Onlinespeicher.
der reproduzierbare Fehler nicht mehr auf.
Telefoniegeräte etc alles nutzbar
(Uptime bisher 3h)

Zuletzt geändert vor 2 Jahren von blackstar (vorher) (Diff)

Geändert vor 2 Jahren durch blackstar

Funktioniert (?)

comment:280 Geändert vor 2 Jahren durch wl_michael

Hallo blackstar,
Wenn ich es richtig in deiner config sehe benutzt du nicht die neuste Firmware sondern eine ältere FIRMWARE LABOR. Mit der geht das alles auch ohne Probleme.
Außerdem hast du eine 7390.
Auf meiner 7490 mit neuster Firmware 6.23 läuft freetz gar nicht mehr. Egal was ich einstelle, es kommt immer wieder zu den reboots. Anfangs ging es noch den webdav abzuschalten, aber das hilft auch nicht mehr.
Wo findet man denn den Schalter "build own uclibs"? Habe diesen nirgends gefunden.
Ist echt schade das freetz auf der 7490 nicht mehr nutzbar ist. Vielleicht findet jemand einen passenden Hinwies und kann ihn hier einstellen.

comment:281 Antwort: Geändert vor 2 Jahren durch KingTutt

Inzwischen ist dieses Ticket lang und unübersichtlich geworden. Irgendwie müsste man da mal aufräumen, damit eingrenzbar wird, was geht und was nicht.
Ich selbst nutze die 7490 mit FW 112.06.23 seit dem 25 Dezember 2014 mit 7490_06.23-freetz-devel-12829.de_20141225-142939 ohne irgendwelche Probleme. Allerdings habe ich weder das Fax konfiguriert, noch Freetzmount in meinem Image.

Ich hänge die config mal als funktionierende Referenz an.

Geändert vor 2 Jahren durch KingTutt

comment:282 als Antwort auf: ↑ 281 Geändert vor 2 Jahren durch PeterPawn

Replying to KingTutt:

Ich hänge die config mal als funktionierende Referenz an.

Angesichts der Feststellung, daß das Ticket schon unübersichtlich genug ist, sollte man meines Erachtens davon Abstand nehmen, weitere Kommentare dieser Art anzuhängen. Es ist nicht böse gemeint, aber es gibt genug Boxen, wo die 06.2x auch auf 7490/7390 mit Freetz-Image läuft und das Problem war bisher eher das Finden einer reproduzierbar fehlerhaften Installation als die Zusammenstellung der vielen funktionierenden. Weniger als 30 Leute (ich zähle nicht extra nach), die die hier beschriebenen Probleme mit der 06.2x auf 7490 haben (teilweise auch nur hatten), sind wohl glücklicherweise immer noch eher der geringere Anteil der Freetz-Nutzer mit 06.2x-Firmware. Auch die anderen Boxen sind ja noch massenweise in freier Wildbahn vertreten und ausweislich geänderter Signaturen im IPPF gibt es inzwischen wohl auch genug Installationen aller möglichen Modelle mit 06.20-Firmware, um ein generelles und nicht zu lösendes Problem ausschließen zu können.

Das heißt nicht, daß man das Problem nicht suchen sollte, wenn man eine Idee hat, wie man es finden kann. Aber nachdem inzwischen die 06.20-Firmware generell ausgerollt ist und es wohl keine weiteren Veröffentlichungen für bisher nicht versorgte Modelle geben wird, dürften immer mehr Leute auf Freetz-Images mit 06.2x-Basis angelangen. Wenn die alle Probleme haben sollten, müßte man - nur meine Meinung - mehr im IPPF davon lesen. Damit behaupte ich einfach mal, es handelt sich um ein Problem, das nur unter sehr seltenen Rahmenbedingungen auftritt … dafür spricht eben auch, daß es uns einfach nicht gelingen will, das Problem dauerhaft reproduzierbar (und übertragbar) nachzustellen und es bei einigen hier, die ebenfalls Freetz mit 06.20 verwend(et)en, noch nie auftrat.

Wenn Du also einen Beitrag zur Abarbeitung dieses Tickets leisten möchtest, könntest Du ja mal das Fax entsprechend konfigurieren. Wenn dann Deine Box auch abstürzt (im Gegensatz zu jetzt), hat man schon mal einen Faktor verifiziert. Wenn man dann noch sagen kann, daß definitiv die Fax-Funktion die Schuld an den Abstürzen trägt (das konnten wir bisher ja eben noch nicht eingrenzen), dann könnte man die "unstable"-Warnung auf die konkreten Umstände begrenzen. Aber die Feststellung "Bei mir läuft's …" trägt leider nicht wirklich zu neuen Erkenntnissen bei, denn Du bist eben nicht der Einzige, bei dem es läuft. Deshalb macht die Meldung zum Ergebnis der Änderung bzgl. der Fax-Funktion auch nur dann Sinn, wenn Du damit den Fehler reproduzierbar triggern kannst (wobei es m.E. ohnehin Konsens ist, daß die Fax-Funktion ein möglicher Auslöser ist, aber wohl eher nicht der einzige benötigte).

comment:283 als Antwort auf: ↑ 277 ; Antwort: Geändert vor 2 Jahren durch RoiDanton

Hoffe, dass der Beitrag eher sinnvoll ist und nicht noch mehr das Ticket zumüllt, es gab ja schon Beschwerden. Aber ich möchte mal auf die Nachfrage reagieren, wenn auch spät - Mailnotifications sind wohl nicht die Stärke vom Trac…

Replying to PeterPawn:

Replying to RoiDanton:

Dann rief hier jemand an, der uns nicht erreichte. 

Ich will nicht weiter auf der Geschichte herumreiten, wenn er13 jetzt versucht, die Erkenntnisse zu straffen … aber die Nachfrage kann ich mir dann auch nicht verkneifen.

War das am Ende ein verpaßter Anruf oder wurde der vom Anrufbeantworter angenommen und wenn das zweite der Fall ist, wurde dann auch eine Nachricht aufgezeichnet oder hat der Anrufer vorher wieder aufgelegt ? Ich frage deshalb, weil das eben drei verschiedene Zustände in der Anrufliste sind und ich in jedem Falle bereit bin zu beschwören, daß eine Abfrage von "UseStick", wie sie bei der Anzeige der Anrufliste ja bewiesenermaßen vorkommt, auch einen Zugriff auf den Datenträger auslöst, denn ansonsten dürfte eine "schlafende HDD" eigentlich nicht hochfahren und das macht sie bei mir definitiv - unabhängig davon, ob AB-Nachrichten dort abgelegt werden oder nicht bzw. ob welche vorhanden sind oder nicht.

Also es kam definitiv kein Klingeln, von daher auch keinen Spruch auf dem AB. Und auch keinen Eintrag im Anruf Log. Die Box muss sich recht schnell und vollständig weggeschossen haben.

comment:284 als Antwort auf: ↑ 283 ; Antwort: Geändert vor 2 Jahren durch PeterPawn

Replying to RoiDanton:

Hoffe, dass der Beitrag eher sinnvoll ist und nicht noch mehr das Ticket zumüllt, es gab ja schon Beschwerden.

Ich hab' hier gar nichts zu sagen, es war nur meine Meinung und die Feststellung/Bitte, daß es nicht noch jede funktionierende Konfiguration ins Ticket schaffen muß.

Also es kam definitiv kein Klingeln, von daher auch keinen Spruch auf dem AB. Und auch keinen Eintrag im Anruf Log. Die Box muss sich recht schnell und vollständig weggeschossen haben.

Das wäre meines Wissen die erste Feststellung (in diesem Ticket), daß eine FRITZBox durch den reinen Anruf abgeschossen wurde. Das würde ich - auch nur geraten - eher einem anderen Problem zuschreiben. Andererseits ist es ja auch komisch, wenn ein eingehender Anruf es nicht mehr schafft, etwas in der Box zu ändern und dann trotzdem nach dem Absturz ein Boot-Loop auftritt - da muß er ja noch irgendetwas ggü. dem vorherigen Zustand geändert haben (nach meinem Verständnis), warum sollte sich das Verhalten der Box sonst ändern.

comment:285 als Antwort auf: ↑ 284 Geändert vor 2 Jahren durch RoiDanton

Replying to PeterPawn:

Replying to RoiDanton:

Also es kam definitiv kein Klingeln, von daher auch keinen Spruch auf dem AB. Und auch keinen Eintrag im Anruf Log. Die Box muss sich recht schnell und vollständig weggeschossen haben.

Das wäre meines Wissen die erste Feststellung (in diesem Ticket), daß eine FRITZBox durch den reinen Anruf abgeschossen wurde. Das würde ich - auch nur geraten - eher einem anderen Problem zuschreiben. Andererseits ist es ja auch komisch, wenn ein eingehender Anruf es nicht mehr schafft, etwas in der Box zu ändern und dann trotzdem nach dem Absturz ein Boot-Loop auftritt - da muß er ja noch irgendetwas ggü. dem vorherigen Zustand geändert haben (nach meinem Verständnis), warum sollte sich das Verhalten der Box sonst ändern.

Ich fand das auch sehr seltsam und hatte hier noch nicht von so einem Fall gelesen, von daher habe ich hier reingeschrieben. Gerade dieser Boot-Loop hat mich doch gar sehr erschreckt. Und ja, irgendwas muss ja passiert sein, sonst kommt es ja nicht dazu.

Klar, ich müsste das nun intensiv prüfen, ob es wirklich so war. Man kann ein Klingeln ja auch mal überhören. Nachdem sich aber im fraglichen Zeitraum 2 Erwachsene mit 3 Telefonen in der WoOhnung aufgehalten haben, kann das an sich nicht überhört worden sein. Der Anrufer kann freilich wenig dazu beitragen, da er auf jeden Fall keinen Anrufbeantworter gehört hat.

Geändert vor 2 Jahren durch jampr

Absturz bei Klick auf Telefoniegeräte

comment:286 Geändert vor 2 Jahren durch jampr

Rev 12884. Mit angehängtem USB3-Stick und Fax an FON1. Vorher sauberes recover gemacht.

comment:287 Geändert vor 2 Jahren durch udo

Für mich und meine 7390 ist das Problem gelöst. Wenn ich Problem mit der Telefonie bekomme, dann mache ich einfach ein "make distclean" und kompiliere neu. Im Detail:

Wenn ich nach einem "svn update; make oldconfig; make" die neu erzeugte Firmware einspiele, dann funktioniert die Box in der Regel nicht. In der "Übersicht" fehlt der grüne Punkt neben der "Telefonie". Ein abermaliger Reboot der FritzBox hilft auch nicht. Aber nach einem "make distclean", einem Restore der alten .config und einem "make oldconfig; make" bekomme ich stets eine funktionierende neue Firmware.

comment:288 Geändert vor 2 Jahren durch CarstenSchuette

@udo: Das ist keine Problemlösung. Sondern ein Workaround.

comment:289 Geändert vor 2 Jahren durch wl_michael

Meine 7490 läuft seit 17 Stunden mit Faxserver und Freetz Webdav.
Weiter oben im Artikel hatte ich gelesen das dass Problem gar nicht von freetz kommt, sonder das eventuell ein Firmwarefehler von AVM verstärkt wird. Es war auch so das meine Box ohne freetz abgestürzt ist. Nur halt nicht ständig und im Dauer Reboot.
Habe gestern gesehen das es eine neue Labor-Version gibt 06.25. Die habe ich dann auch gleich verwendet und sieh da, es ist mir nicht mehr möglich die Box zum Absturz zu bringen.

comment:290 Geändert vor 2 Jahren durch make

@wl_michael: Kann ich so nicht bestätigen. Eine 7390 mit rev29836 (aktueller als die 7490 Labor-FW) rebootet wie gehabt, wenn FreetzMount in der FW ist und ein USB-Stick an der Box hängt.

comment:291 Geändert vor 2 Jahren durch wl_michael

@make: Prüfe mal was du für eine Firmware hast. Ist bei mir die 6.25 Labor. So viel ich weis gibt es diese gar nicht für die 7390. Das was du angibst ist der freetz level und sagt nichts über die verwendete Firmware.. Meine Box hat jetzt 1Tag und 7Stunden und läuft ohne Probleme.

Zuletzt geändert vor 2 Jahren von wl_michael (vorher) (Diff)

comment:292 Geändert vor 2 Jahren durch dirkh

Clean rebuild funktioniert auch bei mir nicht. Mit einem Update vor 2 Wochen funktioniert bei mir kein Workaround, die 7490 re-bootet beim Start, außer ich entferne die USB-Platte zum Start und stecke sie später ran. Dann kann ich auch die Telefon-Web Seite benutzen. Ich glaube es gibt eine Abhängigkeit in der Startreihenfolge, womit etwas falsch oder garnicht initalisiert wird und dann beim Zugriff auf die USB-Platte kommt es dann zum Crash.

comment:293 Geändert vor 2 Jahren durch PeterPawn

Probleme mit dem Start des USB-Subsystems habe ich in der Tat auch mit einer 7390 und 06.20 gefunden, aber die waren auch nicht reproduzierbar und zeigten sich sporadisch in einem nicht geladenen usb_storage.ko-Module. Warum das nicht geladen wurde (ebenfalls nur dann, wenn das USB-Gerät bereits beim Start angeschlossen war und niemals, wenn es nachträglich erst eingebunden wurde), habe ich leider auch nie ermitteln können. Aber daraus resultierte eben bei mir niemals ein ctlmgr-Crash, es standen halt keine USB-Geräte zur Verfügung, bis die Treiber manuell geladen wurden.

Wobei mir da irgendwie wieder in Erinnerung gerät, daß es doch tatsächlich mal eine Stelle im Freetz gab, wo der AVM-Tippfehler (underscore vs. dash/hyphen in usb?storage) in der /etc/hotplug/storage in der "start"-Behandlung

start)
passeeren
touch /var/STORAGE_STARTING
if ! lsmod | grep -q usb_storage ; then
modprobe sd_mod
modprobe usb-storage
if ! test -d $FTPDIR; then
mkdir -p $FTPDIR
## be sure only root is allowed to write to $FTPDIR
chmod 755 $FTPDIR
fi
touch $DEVMAP
#tune write behaviour
echo 2 > /proc/sys/vm/laptop_mode
echo 100 > /proc/sys/vm/dirty_expire_centisecs
echo 100 > /proc/sys/vm/dirty_writeback_centisecs
local SPINDOWN_SECONDS=0
local SPINDOWN_ALLOWED="`echo usbhost.spindown_enabled|usbcfgctl -s`"
if [ "$SPINDOWN_ALLOWED" = "yes" ] ; then
SPINDOWN_SECONDS="`echo usbhost.spindown_time|usbcfgctl -s`"
fi
hd_spindown_control "$SPINDOWN_SECONDS"
fi
vrijgeven
;;

korrigiert wurde. Wenn das tatsächlich immer noch so sein sollte (@Gene: Du oder ich, wer guckt nach? Parallel ist Unfug.) und AVM aus irgendeinem merkwürdigen Grund (eine logische Erklärung hätte ich auch nicht) von diesem Fehler profitiert, weil dann eben die Treiber immer geladen werden, dann könnte das tatsächlich einen Unterschied machen, den wir bei der Analyse des geänderten Mount-Vorgangs vor fast 6 Monaten nicht berücksichtigt haben - so unwahrscheinlich das für mich auf den ersten Blick auch wirken mag.

comment:294 als Antwort auf: ↑ 1 Geändert vor 2 Jahren durch maniac_on_moon

Moin,

das Verhalten beim laden der Module kommt mir seltsam vor.

Wer hat bei den laufenden Boxen ein "Replace Kernel" gebaut?
Der kann dann auch mehr als 50 Module laden.

Gruß
maniac_on_moon

comment:295 Geändert vor 2 Jahren durch dirkh

Falls es einen Zusammenhang mit diesem Problem gibt. Ich hatte vor einem Jahr beim Umstieg auf die 06.05 und auch 06.20 ein Re-boot Problem als ich zusätzlich USB Kernelmodul zum Bauen ausgewählt hatte, wie
FREETZ_MODULE_usb_storage=y
Bei der 7390 oder anderen Boxen hatte ich das Problem nicht, aber da man ja keine Kernel Module separate auswählen muss, bin ich diesem Problem nicht weiter nachgegangen. Eine Konfig hätte ich auch noch dazu.

comment:296 Antwort: Geändert vor 2 Jahren durch tchelovek

Gibt es hier etwas Neues ?

Gemeldet ist das Problem seit 7 Monaten, Priorität = Normal.

Im Menuconfig gibt es einen Hinweis, daß Freetz für Produktiveinsatz nicht geeignet ist.

Gibt es eine Alt-Version von Freetz, die man für die Produktion einsetzen kann ?

comment:297 Geändert vor 2 Jahren durch Whoopie

@tchelovek: Ich weiss, Forderungen stellen ist einfacher als selbst Probleme lösen. Daher schlage ich vor, dass Du Dich in die Thematik einarbeitest und bis Ende der Woche eine Lösung präsentierst.

comment:298 Geändert vor 2 Jahren durch wl_michael

Hallo,
ich möchte nochmals darauf hinweisen das bei mir das Problem mit FRITZ!OS 06.25 Labor behoben ist. Wenn jemand das auch mit dieser Firmware probiert hat, bitte eine Rückinfo dazu geben. Meine 7490 läuft seit dem Update vor 7 Tagen ohne eine Absturz.

Geändert vor 2 Jahren durch wl_michael

Freetz-Info

comment:299 Geändert vor 2 Jahren durch PeterPawn

bis Ende der Woche eine Lösung präsentierst.

So weit muß es ja noch nicht einmal gehen … ich wäre schon mit einer stabil abstürzenden Konfiguration, die sich auf andere Boxen (und damit auch auf meine - am liebsten auf die 7390) übertragen läßt, zufrieden. Dann suche ich auch gerne mit … ansonsten einfach keine Chance.

@tchelovek:

Was brächte es denn (außer einem besseren Gefühl bei Dir), wenn die Priorität eine andere wäre? Wenn Du Dir das Ticket wenigstens durchgelesen hättest, würdest Du wissen, daß es längst nicht bei jedem auftritt. Es steht Dir also frei, es bei Dir selbst zu probieren und - solltest Du davon tatsächlich betroffen sein - Deinen Teil zur Aufklärung beizutragen, wenn es nicht einen Punkt betrifft, der hier schon zig-mal hoch und runter diskutiert wurde. Wenn Du nicht betroffen bist, kannst Du das gesamte Ticket getrost ignorieren.

@wl_michael:

Bitte aber wirklich nur von denjenigen, die vorher auch die Abstürze zu verzeichnen hatten. Wir haben - ich sage jetzt mal definitiv, obwohl ich es nicht belegen kann - mehr funktionierende als abstürzende Boxen und da muß wirklich nicht jeder mit einer funktionierenden Konfiguration sich an einer Umfrage beteiligen. Ich habe den Absturz noch nie hinbekommen, damit wäre mein Test z.B. nicht beweiskräftig.

comment:300 Geändert vor 2 Jahren durch wl_michael

@PeterPawn, meine Box stürzte im Minutentakt ab. Somit gehöre ich zu den denjenigen. Für mich hat sich das Problem mit FRITZ!OS 06.25 Labor behoben. Was anderes habe ich hier noch nicht gelesen. Sollte es noch welche geben die das Problem auch mit FRITZ!OS 06.25 Labor haben dann bitte hier schreiben. Ansonsten kann das Ticket geschlossen werden.
PS: Kann sein das es die Firmware FRITZ!OS 06.25 Labor nur für die 7490 gibt. Ursprünglich war das Ticket auch für diese Box. Die anderen müssen sich dann noch etwas gedulden bis es auch für diese Boxen eine entsprechende Firmware gibt.

Zuletzt geändert vor 2 Jahren von wl_michael (vorher) (Diff)

comment:301 Antwort: Geändert vor 2 Jahren durch schalli

Also meine beiden Boxen stürzen mit der LABOR-Version nicht mehr ab.

FritzBox 7490 mit 6.25 (FRITZ!OS 06.25-29805 PHONE) und
FritzBox 7390 mit 6.23 (FRITZ!OS 06.23-29836 DSL)

Beide Boxen hatten vorher die beschriebenen Probleme, dass bei Klick auf Telefonie "ctl_mgr" abgestürzt ist und die Box dann nach ein paar Minuten neu startete.

An der 7490 hängt ein USB-Stick, an der 7390 nicht.
Weitere Infos gerne auf Nachfrage, bin auch bereit, ein paar Configs auf ein oder zwei Boxen durchzutesten..

comment:302 Geändert vor 2 Jahren durch make

@schalli: Schliess mal einen USB-Stick an die 7390 an, stell den AB oder FAX auf Speicherung auf dem Stick um und spiel ein Image mit FREETZMOUNT ein. Bei mir reicht das, dass die Box reproduzierbar abstürzt — mit der von dir erwähnten FW-Version.

Die 7390er FW ist definitiv noch nicht gefixt, aber ein USB-Stick/externe FP ist wohl zwingend erforderlich um das Problem überhaupt zu triggern.

comment:303 als Antwort auf: ↑ 296 ; Antwort: Geändert vor 2 Jahren durch dirkh

Replying to tchelovek:

Gibt es hier etwas Neues ? Gemeldet ist das Problem seit 7 Monaten, Priorität = Normal. Im Menuconfig gibt es einen Hinweis, daß Freetz für Produktiveinsatz nicht geeignet ist. Gibt es eine Alt-Version von Freetz, die man für die Produktion einsetzen kann ?

Die 06.05 sollte nicht das Problem haben, desweiteren könnte man folgende Betrachtung anstellen.

Folgende Bibliotheken benutzen die libhtmltemplate.so.0, die doch der Grund für die Crashes sind:
build/original/filesystem/lib/libemailservice.so.0.0.0
build/original/filesystem/lib/libfaxsend.so.1.0.0
build/original/filesystem/lib/libmailbuilder.so.0.0.0
Der avm/ctlmgr, der immer abstürzt benutzt nicht selber die libhtmltemplate Bibliothek.
Damit sollte doch einzugrenzen sein, dass der Fax-Dienst bzw. alle Dienste, die die E-Mail Funktion benutzen in Verbindung mit extenen USB-Trägern zum Problem führen kann.

Könnte man daraus nicht eine Empfehlung ableiten unter welchen Bedingungen man die neue Firmware doch benutzen kann??

comment:304 als Antwort auf: ↑ 303 Geändert vor 2 Jahren durch PeterPawn

Replying to dirkh:

Folgende Bibliotheken benutzen die libhtmltemplate.so.0, die doch der Grund für die Crashes sind: ![…] Könnte man daraus nicht eine Empfehlung ableiten unter welchen Bedingungen man die neue Firmware doch benutzen kann??

Meiner Meinung nach hat der Absturz nichts mit der libhtmltemplate.so zu tun. Diese taucht nur so oft auf, weil der in a1 stehende Beginn des Mount-Path für das Volume bei vielen übereinstimmt (uSto) und an dieser Adresse sich zufällig gerade die libhtmltemplate.so im Speicher befindet. Bei einem abweichenden Mount-Path wird der Fehler im Dump auch an einer anderen Stelle "vermutet" (s. z.B. comment 137, 211, 225).

comment:305 als Antwort auf: ↑ 301 ; Antwort: Geändert vor 2 Jahren durch Matthy

Replying to schalli:

Also meine beiden Boxen stürzen mit der LABOR-Version nicht mehr ab.

FritzBox 7490 mit 6.25 (FRITZ!OS 06.25-29805 PHONE)

Interessant! Das kann ich bestätigen! Meine 7490, die zuvor mit der 6.2x das Problem hatte, hat mit der 6.25er Labor mit der gleichen freetz-Config das Problem nicht mehr. 2 USB-Sticks hängen dran und Faxfunktion ist auch aktiviert.

Zuletzt geändert vor 2 Jahren von Matthy (vorher) (Diff)

comment:306 als Antwort auf: ↑ 305 Geändert vor 2 Jahren durch mrspeccy

Replying to Matthy:

Replying to schalli:

Also meine beiden Boxen stürzen mit der LABOR-Version nicht mehr ab.

FritzBox 7490 mit 6.25 (FRITZ!OS 06.25-29805 PHONE)

Interessant! Das kann ich bestätigen! Meine 7490, die zuvor mit der 6.2x das Problem hatte, hat mit der 6.25er Labor mit der gleichen freetz-Config das Problem nicht mehr. 2 USB-Sticks hängen dran und Faxfunktion ist auch aktiviert.

Das kann ich auch bestätigen. Faxfunktion + USB-Stick → Abstürze mit 6.20 und 6.23, mit 6.25-29805 hingegen nicht mehr.

comment:307 Geändert vor 2 Jahren durch schalli

Meine 7390 stürzt mit USB-Stick dran nicht ab.

Muss ich FREETZMOUNT irgendwo aktivieren, oder ist das standardmäßig an?

comment:308 Geändert vor 2 Jahren durch Whoopie

@schalli: FREETZMOUNT wird genutzt, sobald Du es ins Image aufnimmst. Ich habe übrigens auch ein 7390, und meine Box stürzt mit angeschlossenem USB-Stick reproduzierbar ab.

comment:309 Geändert vor 2 Jahren durch er13

  • Komponente von webinterface nach unknown geändert
  • Priorität von normal nach high geändert

comment:310 Geändert vor 2 Jahren durch RoiDanton

So, habe auch die Labor Firmware mit dem neuesten freetz-trunk verheiratet und ein Update auf meiner 7490 gemacht. An der Konfiguration habe ich nichts geändert.

Fritzbox scheint auch stabil zu laufen - im Gegensatz zu den Versuchen davor, siehe oben hier im Ticket. Habe alle Menüpunkte durchgeklickt und mich auch angerufen und auf den Anrufbeantworter (der auf USB speichert) gesprochen. Hat alles geklappt.

comment:311 Antwort: Geändert vor 2 Jahren durch frank_m24

Kann schon jemand was zur 06.24 sagen?

comment:312 Geändert vor 2 Jahren durch schalli

Also ich bin jetzt wieder auf die stable 6.05 gegangen, weil die FB 7490 auch mit der 6.23 LABOR beim Faxen widerholt abgestürzt ist.

comment:313 als Antwort auf: ↑ 311 Geändert vor 2 Jahren durch elmicha

Replying to frank_m24:

Kann schon jemand was zur 06.24 sagen?

Mit FREETZMOUNT gibt's diesen Absturz, ohne FREETZMOUNT ist alles ok.

comment:314 Geändert vor 2 Jahren durch er13

In 12979:

  • replace uClibc also in filesystem_core
  • refs #2499

comment:315 Antwort: Geändert vor 2 Jahren durch er13

Könnte bitte jemand mit dem Problem auf einer 7490 testen, ob r12979 irgendeinen Einfluss auf das Problem hat? Danke!

comment:316 Geändert vor 2 Jahren durch er13

In 12983:

fwmod:

  • remove unnecessary/incorrect double quotes
  • refs r12979, refs #2499

comment:317 Geändert vor 2 Jahren durch CarstenSchuette

Kann ich heute Abend machen.

comment:318 Geändert vor 2 Jahren durch CarstenSchuette

Sollte es so einfach gewesen sein?

Ich habe die Befehle aus comment:225 hier wiederholt und meine Box läuft jetzt durch. Bisher war es bei mir so, dass die Box nach root@fritz:/var/mod/root# ctlmgr_ctl w telcfg settings/FaxMailActive 3 gecrasht ist. Das geht jetzt. Der Faxdienst speichert seine Faxe jetzt sauber auf dem per FREETZMOUNT eingebundenen USB-Stick ab, der Anrufbeantworter auch.

Zuletzt geändert vor 2 Jahren von CarstenSchuette (vorher) (Diff)

comment:319 Antwort: Geändert vor 2 Jahren durch er13

Und wie schaut es im AVM-WebIf unter Telefonie aus? Kannst Du alle Seiten anklicken bzw. Parameter verstellen ohne dass die Box abstürzt?

Wegen "so einfach": ich würde mich richtig freuen, wenn es am Ende "so einfach" sein wird. An sich ist diese Inkonsistenz (unterschiedliche libc-Versionen im filesystem_root und im filesystem) schon eine sehr plausible Erklärung für das nicht-deterministische im Ticket dokumentierte Verhalten (bei einem führt die Reihenfolge zum Absturz, bei dem anderen eine andere, bei einem hilft der Trick, bei dem anderen der andere). Es wurde halt bisher die AVM-Version von libuClibc und ld_uClibc gemischt mit den Freetz-Versionen von allen anderen uClibc-Libraries (libpthread, libdl, libm, libutil, usw) verwendet. Der Fehler betrifft übrigens genauso 5.5x und 6.0x. Aber da scheinen unsere Abweichung zu AVM in der uClibc .config geringer zu sein als bei 6.2x.

So richtig glauben, dass es allein daran liegt, tue ich allerdings nicht. Das Problem wurde ja auch (angeblich) auf der 7390 beobachtet und diese hat nur ein Dateisystem. Wie Peter schon mal vermutet hat, könnten es eine Kombination von mehreren Problemen sein. Aber warten wir ab, was die anderen User berichten. Dein positives Feedback ist ja schon da (Danke übrigens fürs Testen), vielleicht motiviert es mehr Leute zu testen.

comment:320 als Antwort auf: ↑ 319 Geändert vor 2 Jahren durch CarstenSchuette

Replying to er13:

Und wie schaut es im AVM-WebIf unter Telefonie aus? Kannst Du alle Seiten anklicken bzw. Parameter verstellen ohne dass die Box abstürzt?

Ja. Gerade alles einmal durchgeklickt und ein bisschen rumgeändert. Sieht gut aus. Aber das sollten sicherheitshalber mal noch ein paar weitere Leute testen. Mein Fazit ist auf jeden Fall positiv, weitere Tests lohnen sich :)

comment:321 Geändert vor 2 Jahren durch make

@er13: Wie - "angeblich"? Ich kann den Absturz auf meiner 7390 immer noch ohne Anstrengungen nachstellen. Mit FreetzMount immer, aber - wie ich in meinem crash.log heute morgen gesehen habe - der Fehler tritt auch ohne FreetzMount auf, nur viel seltener.

Ne, da ist noch irgendwas richtig braun, und so wichtig die Änderung für die 7490 bestimmt ist, den Fehler auf der 7390 behebt sie nicht, kann sie nicht beheben.

comment:322 Geändert vor 2 Jahren durch CarstenSchuette

Die Crashs auf der 7390 sehen auch irgendwie anders aus wie auf der 7490. Bei der 7490 steht der Text "USto" im Register, bei den crashs der 7390, die hier dokumentiert sind, ist der Wert aber 0+0x48444400 ("HDD", wenn ich mich nicht verrechnet habe).

Vielleicht trotzdem einfach nochnmal testen, zwischendurch hat sich ja auch an der uClibc und sonstwo eine Menge getan.

Zuletzt geändert vor 2 Jahren von CarstenSchuette (vorher) (Diff)

comment:323 Geändert vor 2 Jahren durch make

Carsten, da muss ich dich korrigieren: In den Registern steht einfach der Anfang des Mountpoint-Namens. Wenn der MountPoint-Prefix auf HDD gesetzt ist, klar, dann steht da HDD. Normal ist USto oder Hersteller-Device-Name.
Die Register bei mir sind zB beim Crash a0: 6572436f a1: 53616e44 — mit Mount-Prefix "SanDisk-CruzerContour". Aktuell stürzt mir der faxd ab, bis vor kurzem war es noch die Anrufbeantworter-Variante. Nach meiner Erfahrung kann sich das durchaus von Boot zu Boot oder Flash zu Flash ändern.
Freu dich, dass deine Box läuft, aber rechne besser nicht damit, dass es so bleibt.

2015-03-02 19:03:36 [Segmentation fault]
faxd[2464] crashed at 2acd4b90 (/lib/libc.so.0: strcmp + 0x0) accessing 0x6572436f
Version: 06.23-29836
at: 00000000 v0: 2acd4b90 v1: 53616e44
a0: 6572436f a1: 53616e44 a2: 0041f0b0 a3: 7fbc88a0
t0: 00000000 t1: 00000000 t2: 0000005b t3: ffffff80
t4: 00000063 t5: 00000073 t6: 0000005b t7: 6e446973
s0: 0041f0b0 s1: 2aab6200 s2: 7fbc9550 s3: 2acd3df0
s4: 80000001 s5: 2aab80b0 s6: 2ad3f000 s7: 2ad3f000
t8: 00000000 t9: 2acd4b90
gp: 0041f0b0 sp: 7fbc8ae0 fp: 7fa3f8a0 ra: 00402cf7
[bt] Code: 03e00008 00601021 <90830000> 24870001
[bt] 00402cf2 [/usr/bin/faxd at 2cf3]
[bt] 0040356a [/usr/bin/faxd at 356a]
[bt] 00403ac0 [/usr/bin/faxd at 3ac0]
[bt] 00403d38 [/usr/bin/faxd at 3d38]
[bt] 00404536 [/usr/bin/faxd at 4536] fax_machine + 0x202
[bt] 004025bc [/usr/bin/faxd at 25bc] main + 0x99c
2015-03-02 19:10:35 [Segmentation fault]
faxd[2472] crashed at 2acd4b90 (/lib/libc.so.0: strcmp + 0x0) accessing 0x6572436f
Version: 06.23-29836
at: 00000000 v0: 2acd4b90 v1: 53616e44
a0: 6572436f a1: 53616e44 a2: 0041f0b0 a3: 7ff02be0
t0: 00000000 t1: 00000000 t2: 0000005b t3: ffffff80
t4: 00000063 t5: 00000073 t6: 0000005b t7: 6e446973
s0: 0041f0b0 s1: 2aab6200 s2: 7ff03890 s3: 2acd3df0
s4: 80000001 s5: 2aab80b0 s6: 2ad3f000 s7: 2ad3f000
t8: 00000000 t9: 2acd4b90
gp: 0041f0b0 sp: 7ff02e20 fp: 7ffa5bb0 ra: 00402cf7
[bt] Code: 03e00008 00601021 <90830000> 24870001
[bt] 00402cf2 [/usr/bin/faxd at 2cf3]
[bt] 0040356a [/usr/bin/faxd at 356a]
[bt] 00403ac0 [/usr/bin/faxd at 3ac0]
[bt] 00403d38 [/usr/bin/faxd at 3d38]
[bt] 00404536 [/usr/bin/faxd at 4536] fax_machine + 0x202
[bt] 004025bc [/usr/bin/faxd at 25bc] main + 0x99c

comment:324 Geändert vor 2 Jahren durch CarstenSchuette

Make, hast du eine 7390 oder 7490?
Ich frage das, was bei dir steht 06.23-29836 als Version, ich baue aber eine 06.25-29912

Firmware: 113.06.25 rev29912 PHONE
Freetz: devel-12983M
Zuletzt geändert vor 2 Jahren von CarstenSchuette (vorher) (Diff)

comment:325 Geändert vor 2 Jahren durch make

7390 — AVM kommt ja nicht rüber mit einer neuen Labor, deswegen noch 6.23.xx. Was neueres gibt es da nicht.

comment:326 Geändert vor 2 Jahren durch er13

@Carsten: verstehe ich es richtig, waren Deine Tests alle mit 7490.06.25Labor? Könntest Du es eventuell mit 06.24release testen? Es wurde doch berichtet, dass der Fehler mit der Labor-FW gar nicht bis deutlich schwieriger zu erzwingen ist. Danke!

@make: wegen angeblich - keine Angst, ich habe es doch in Klammern geschrieben ;-)

comment:327 Geändert vor 2 Jahren durch CarstenSchuette

Ja, stimmt, mit der 06.24 crasht auch meine Box. Die gleiche Config läuft aber mit der 06.25-labor (USB-Stick abziehen verhindert die Bootloop).

1970-01-01 01:00:52 [Segmentation fault]
faxd[2192] crashed at 2acd382c (/lib/libc.so.0: strcmp + 0xc) accessing 0x5553746f
Version: 06.24
at: 00000001 v0: 2acd3820 v1: 00000046
a0: 0041750b a1: 5553746f a2: 55537470 a3: 0041750c
t0: 00000000 t1: 00000034 t2: 8071cac0 t3: 00000001
t4: 80000000 t5: 00000073 t6: 0000005b t7: 323d2f64
s0: 0041f0b0 s1: 2aab6000 s2: 7fa6e6e0 s3: 2acd2e80
s4: 80000001 s5: 2aab80b0 s6: 2ad3b000 s7: 2ad3b000
t8: 00000000 t9: 2acd3820
gp: 0041f0b0 sp: 7fa6e2b8 fp: 7f932140 ra: 00402cf7
[bt] Code: 24870001 24a60001 <14600003> 90a20000
[bt] 00402cf2 [/usr/bin/faxd at 2cf3]
[bt] 0040356a [/usr/bin/faxd at 356a]
[bt] 00403ac0 [/usr/bin/faxd at 3ac0]
[bt] 00402536 [/usr/bin/faxd at 2536] main + 0x916

comment:328 als Antwort auf: ↑ 315 Geändert vor 2 Jahren durch osvit

Replying to er13:

Könnte bitte jemand mit dem Problem auf einer 7490 testen, ob r12979 irgendeinen Einfluss auf das Problem hat? Danke!

Meiner 7390 mit letzter Labor stürzt wie vorher ab.

comment:329 Geändert vor 2 Jahren durch er13

In 12989:

  • create uclibc-testing branch
  • refs #2547, refs #2499

comment:330 Geändert vor 2 Jahren durch er13

In 12990:

uClibc:

  • disable/rename/regroup some patches (WIP)
  • refs #2547, refs #2499

comment:331 Geändert vor 2 Jahren durch er13

In 12991:

uClibc:

  • reenable/rename/regroup some patches (WIP)
  • refs #2547, refs #2499

comment:332 Geändert vor 2 Jahren durch er13

In 12992:

uClibc:

  • reenable another set of patches
  • refs #2547, refs #2499

comment:333 als Antwort auf: ↑ 271 Geändert vor 2 Jahren durch er13

Replying to blackstar:

der Fehler tritt bei mir ohne FREETZMOUNT im zusammenhang mit Onlinespeicher auf auch ohne den 190-nptl_no_stack_cache.openwrt.patch​ auf.

Meine Tests zeigen, dass das in #2547 gemeldete Problem eindeutig auf 190-nptl_no_stack_cache.openwrt.patch zurückzuführen ist. Ich hatte diesen Patch bereits in comment:270 verdächtigt. Du, blackstar, hast jedoch gemeldet, dass das Problem auch nach dem Entfernen von 190-nptl_no_stack_cache.openwrt.patch weiterhin besteht, was mich jetzt angesichts von #2547 etwas verwirrt. Könntest Du bitte bestätigen, dass Du alle Anweisungen aus comment:270 bzgl. dessen, wie der Test durchzuführen ist, auch wirklich befolgt hast (ich zitiere):

  • mit einem frischen Checkout starten
  • den 190-nptl_no_stack_cache.openwrt.patch​ entfernen
  • .config (mit der Ihr den Fehler nachstellen könnt) reinkopieren
  • menuconfig aufrufen und dann die Option "Toolchain options/Toolchains" auf "Build own toolchains" umstellen

Hast Du diese wirklich so 1-zu-1 befolgt oder hast Du eventuell den letzten Schritt vergessen/ausgelassen?

@alle: könnte bitte noch jemand, der das Problem reproduzierbar auf einer 7490 nachstellen kann, den "lösche 190-nptl_no_stack_cache.openwrt.patch​"-Test bitte mit 7490.06.24release wiederholen und hier berichten. Danke!

Edit: zum Testen kann man nun auch den uclibc-testing branch verwenden, wichtige Voraussetzung für den richtigen Test wäre, dass dabei eine selbstgebaute Toolchain mit default Toolchain-Einstellungen (i.e. gcc/binutils-Version) verwendet wird.

Zuletzt geändert vor 2 Jahren von er13 (vorher) (Diff)

comment:334 Geändert vor 2 Jahren durch er13

In 12993:

uClibc:

  • reenable another set of patches
  • refs #2547, refs #2499

comment:335 Geändert vor 2 Jahren durch er13

In 12995:

uClibc:

  • reenable NPTL-related patches
  • refs #2547, refs #2499

comment:336 Geändert vor 2 Jahren durch make

Kurze Rückmeldung:
Eine 7390 mit 06.23-29836, freetz-trunk, FREETZ_MOUNT, eigener Toolchain, binutils-2.22 und ohne 190-nptl_no_stack_cache.openwrt.patch​ stürzt bei mir immer noch wie gehabt ab. Bitte kurze Info, falls .config oder crash.log benötigt werden.

comment:337 Geändert vor 2 Jahren durch er13

@make: könntest Du den uclibc-testing branch bitte auschecken und folgendes testen:

  • folgende Patches unter uclibc/0.9.33.2 löschen:
    • 150-vasprintf_size_reduce.openwrt.patch
    • alle, deren Nummer ≥ 890 ist bis auf die folgenden drei: 950-dup3_support_part*.upstream.patch (2 Stück) und 994-explicit-no-as-needed.freetz.patch
  • Zeilen 57 bis 62 (beides inklusive) in uclibc.mk auskommentieren
  • Deine .config, mit der sich der Fehler nachstellen/provozieren lässt, reinkopieren
  • menuconfig aufrufen, auf selbstgebaute Toolchain umstellen, kernel-/target-binutils auf 2.22 umstellen
  • für 6.23release (i.e. 7390.6.23 rev29808) bauen und testen

Danke!

Ich kriege den Fehler aus diesem Ticket auf meiner Box nicht nachgestellt, also muss einer von Euch das, was ich in #2547 gemacht habe, hier machen.

comment:338 Antwort: Geändert vor 2 Jahren durch make

@er13: In der von dir vorgeschlagenen Konfiguration kann ich den Fehler nicht mehr reproduzieren. Habe zur Sicherheit mehrere leicht modifizierte FWs geflasht, die Box mehrfach neu gestartet, bis jetzt keine Probleme. Auch Änderungen an den Anrufbeantworter- und Fax-Optionen machen keine Probleme. Wie sieht der nächste Schritt aus?

Zuletzt geändert vor 2 Jahren von make (vorher) (Diff)

comment:339 als Antwort auf: ↑ 338 Geändert vor 2 Jahren durch er13

Replying to make:

Wie sieht der nächste Schritt aus?

Zunächst mal Danke fürs Testen! Ich hoffe Du bringst für die nächsten Schritte viel Zeit und Geduld mit ;-) Diese sehen nämlich wie folgt aus:

  • häppchenweise die entfernten Patches wieder hinzufügen
  • nach jedem Häppchen das Ganze from scratch neu bauen, flashen und testen

Da Du in der aktuellen Konfiguration den Fehler nicht mehr nachgestellt bekommst (klopf x 3 auf Holz), ist die Wahrscheinlichkeit hoch, dass es an einem der uClibc-Patches liegt. Durch schrittweise hinzufügen werden wir es erst auf ein bestimmtes Häppchen und anschließend auf einen konkreten Patch aus diesem einschränken können. Ich hätte folgenden Vorschlag für die einzelnen Häppchen:

Häppchen1 (mein Hauptverdächtiger derzeit, daher ein einziger Patch in dem ganzen Häppchen):

150-vasprintf_size_reduce.openwrt.patch

Häppchen2 (ls 89* 90*):

890-SYMBOL_PREFIX.upstream.patch
890-undefined_sys_symbols.upstream.patch
900-dlsym_rtld_next_fix.upstream.patch
900-libdl_tls_symbols.uclibcml.patch
901-dlopen_static.upstream.patch
901-dlopen.upstream.patch
902-dlclose_fix.alpinelinux.patch
902-dlsym_lookup_failure.alpinelinux.patch

Häppchen3 (ls 91* 92* 93*):

910-res_mkquery_unsafe_res_options_access.upstream.patch
910-res_query.upstream.patch
910-res_state_after_res_init.upstream.patch
910-res_thread_res_func_order.upstream.patch
910-res_thread_safe_res_init_1.upstream.patch
910-res_thread_safe_res_init_2.upstream.patch
911-gethostbyaddr_r__corrupted_addr_list.alpinelinux.patch
913-resolver_non_fqdn_lookups.part1.uclibcml.patch
913-resolver_non_fqdn_lookups.part2.uclibcml.patch
920-rpc_authnone_marshal.upstream.patch
920-rpc_non_nptl.upstream.patch
930-backtrace.upstream.patch
931-backtrace_makefile_typos.freetz.patch
932-backtrace-1.uclibcml.patch
932-backtrace-2.uclibcml.patch
932-backtrace-3.uclibcml.patch

Häppchen4 (ls 95*):

950-eventfd1_proper_implementation.upstream.patch
950-eventfd2_arch_specific_defines.upstream.patch
950-eventfd3_omit_prototype_if_not_available.freetz.patch
950-fallocate.part1.upstream.patch
950-fallocate.part2.upstream.patch
950-fallocate.part3.upstream.patch
950-scanf_m_flag.upstream.patch
950-scanf_wide.upstream.patch

Häppchen5 (ls 96*):

960-atexit_memleak.upstream.patch
960-libc-elf-explicitly-include-uClibc_page.h-to-make-PA.upstream.patch
960-linuxthreads.old_pthread_weak.upstream.patch
960-mips64_relocation_fixes-1.upstream.patch
960-mips64_relocation_fixes-2.openwrt.patch
960-nice.upstream.patch
960-pread_pwrite_part1.upstream.patch
960-pread_pwrite_part2.upstream.patch
960-pread_pwrite_part3.upstream.patch
960-pread_pwrite_part4.upstream.patch
960-pread_pwrite_part5.upstream.patch
960-pread_pwrite_part6.upstream.patch
960-syscall_error_registers_part1.upstream.patch
960-syscall_error_registers_part2.upstream.patch
960-syscall_mmap2_call_fix.upstream.patch

Häppchen6 (ls 97*):

970.600-mips64_abi_selection.part1.openwrt.patch
970.600-mips64_abi_selection.part2.openwrt.patch
970.610-mips64_syscall_fix.openwrt.patch
970.614-mips64_fix_setjmp_longjmp.openwrt.patch
970.615-mips_fix_sigev_pad_size.openwrt.patch
970.616-mips_fix_stat_time.openwrt.patch
970.617-mips_fix_setjmp_ptrsize.openwrt.patch
970.618-mips64_fix_syscall_error.openwrt.patch
970.619-mips64_fix_sysdep_cancel.openwrt.patch

Häppchen7 (ls 98*):

980-nptl_getpid.upstream.patch
980-nptl_pthread_exit.upstream.patch
980-nptl_remove_duplicate_vfork_in_libpthread.uclibcml.patch
980-nptl-sh-fix-race-condition-in-lll_wait_tid.upstream.patch
980-nptl_SIGCANCEL.upstream.patch

Bei diesem letzten soll die Änderung in uclibc.mk (s. comment:337) wieder rückgängig gemacht werden.

Du kannst natürlich auch statt schrittweise (i.e. Häppchen für Häppchen) auch die binäre Suche anwenden. Dann hast Du nach spätestens 3 Mal komplett neu bauen es auf ein bestimmtes Häppchen eingeschränkt.

comment:340 Geändert vor 2 Jahren durch make

Ok, ich schau mal, wie weit ich morgen damit komme.

comment:341 Geändert vor 2 Jahren durch er13

Hmm, das Ticket wurde vor 8 Monaten erstellt, 150-vasprintf_size_reduce.openwrt.patch habe ich aber erst vor 6 in r12410 hinzugefügt. Könnte natürlich sein, dass es eine Kombination von 150-vasprintf_size_reduce.openwrt.patch und 190-nptl_no_stack_cache.openwrt.patch​ ist… das glaube ich aber nicht wirklich…

@make: Mach' bitte die binäre Suche, dann musst Du im schlimmsten Fall nur 3 Mal bauen.

comment:342 Geändert vor 2 Jahren durch make

Ergebnisse bisher (alles vorläufig und ohne komplett neu auszuchecken):

mit binutils-2.22, ohne uclibc.mk:57-62 :
[1-4 ohne 190-nptl_no_stack*] -> Bootloop
[1-2 plus 91{1,3}*] -> ok
[1-3] -> ok
[1-4 ohne 950-scanf_m_flag.upstream.patch und ohne 950-scanf_wide.upstream.patch] -> ok
[1-4 ohne 950-scanf_wide.upstream.patch] -> Bootloop
[1-7 ohne 950-scanf_wide.upstream.patch] -> Bootloop
[1-7 ohne 950-scanf_m_flag.upstream.patch] -> ok

mit binutils-2.23.2:
[1-7 ohne 950-scanf_m_flag.upstream.patch] -> ok

Demnach scheint also (mindestens) 950-scanf_m_flag.upstream.patch problematisch zu sein.

EDIT: Bin mit den beiden scanf-Patches etwas durcheinander geraten, sorry.

Zuletzt geändert vor 2 Jahren von make (vorher) (Diff)

comment:343 Geändert vor 2 Jahren durch er13

Verstehe ich es richtig: der fen Fehler verursachende Patch befindet sich im Häppchen 4?

Versuch mal bitte alles aus 1-4 ohne 190-nptl_no_stack und ohne die beiden 950-scanf*. Danke!

comment:344 Geändert vor 2 Jahren durch make

Ich bau gerade 1-4 ausser 950-scanf*. 190-nptl ist allerdings mit dabei. Da das wegen der ganzen mitausgewählten Pakete immer eine halbe Ewigkeit dauert, will ich jetzt nicht abbrechen. Ich ergänze das Ergebnis dann oben im Kommentar.

Zuletzt geändert vor 2 Jahren von make (vorher) (Diff)

comment:345 Geändert vor 2 Jahren durch make

So, für heute bin ich durch. Ergebnisse im Detail unter comment:342.

comment:346 Geändert vor 2 Jahren durch er13

@make: Danke Dir! Ich habe den Spass am vergangenen WE inkl. Mo. machen dürfen (s. #2547) und weiß, welcher Aufwand sich dahinter verbirgt! Danke!

comment:347 Geändert vor 2 Jahren durch make

Gerne, haben wir ja hoffentlich alles was von. Falls da noch mehr zu tun ist, einfach hier ins Ticket schreiben…

comment:348 Geändert vor 2 Jahren durch er13

Hmm, wenn ich mir die Commit-History so anschaue…

Das ist der Upstream-Commit, der dem 950-scanf_m_flag entspricht.

Danach gab's diesen Commit, in dem behauptet wird, dass der 1.te "would cause a segfault if it was used for 'c' or '[' conversions" - stimmt wir haben einen Segfault.

Danach gab's aber den Revert von dem 2.ten, weil dieser wiederum "breaks badly (e.g. busybox netstat)".

Danach gab's wiederum diesen Commit, der dem 950-scanf_wide entspricht und zwar ein Problem löst, aber eben nicht das Problem, von dem in dem 2.ten Commit gesprochen wurde, somit ist dieses weiterhin ungelöst und es ist scheinbar genau das Problem, das zu dem Segfault aus diesem Ticket führt.

Hätte mir die Commit-Messages genauer lesen sollen.

Interessant, beide Patches sind in dem buildroot-master (und dem letzten buildroot-Release) enthalten: scanf_m_flag und scanf_wide. Mal abwarten, wann AVM auf diesen umsteigt ;-)

comment:349 Geändert vor 2 Jahren durch er13

In 13002:

uClibc:

  • disable scanf-related patches as these seem to be the cause for the segfaults reported in #2499
  • adjust the .config accordingly
  • refs #2499

comment:350 Geändert vor 2 Jahren durch CarstenSchuette

Für mich mal eben, ihr redet immer von 950-scan-Patches. Bei mir haben die die Nummer 990. Wie kommt's?

comment:351 Antwort: Geändert vor 2 Jahren durch make

Verstehe ich das richtig:
Die beiden scanf-Patches gibt es seit 22 Monaten als 990-scanf im Trunk, das Problem aus diesem Ticket ist aber erst seit ca einem dreiviertel Jahr akut. Also müsste der Fehler demnach schon seit ~2 Jahren latent in allen Freetz-Images vorhanden sein, wurde aber erst durch eine FW-Änderung im Bereich [6.05 - 6.20] von AVM getriggert. Beispielsweise durch den Aufruf einer Funktion aus der scanf-Familie mit "%m[". Entsprechende Treffer gäbe es zB in den Binaries von faxd, libtamconf.so und libtelcfg.so, was ja eigentlich auch ganz gut passen würde.

comment:352 Geändert vor 2 Jahren durch er13

In 13004:

uClibc:

  • remove disabled patches from repository
  • refs #2499

comment:353 als Antwort auf: ↑ 351 ; Antwort: Geändert vor 2 Jahren durch er13

Replying to make:

der Fehler … wurde aber erst durch eine FW-Änderung im Bereich [6.05 - 6.20] von AVM getriggert. Beispielsweise durch den Aufruf einer Funktion aus der scanf-Familie mit "%m[". Entsprechende Treffer gäbe es zB in den Binaries von faxd, libtamconf.so und libtelcfg.so, was ja eigentlich auch ganz gut passen würde.

Hmm, eigentlich dürfte uclibc-Version, die AVM mitliefert, %m[ nicht unterstützen, denn sonst müsste das opensrc-Paket von AVM die entsprechenden Patches enthalten, was aber nicht der Fall ist. Andererseits taucht %m[ in der Tat a) auf; b) erst seit 6.20 in den von Dir aufgezählten Dateien. Der Kontext ist übrigens

/var/media/devmap
%*[^:]:%m[^0x0A]0x0A (mit 0x0A ist newline gemeint)

Was erklären würde, warum das Abschalten von Freetz-Mount bei manchen "geholfen" hat - AVM hat das Format von /var/media/devmap in 6.20 etwas angepasst, in Freetz-Mount sind diese Anpassungen aber (noch) nicht enthalten (wegen der Kompatibilität zu den älteren Firmwares).

Nach diesen Erkenntnissen stellt sich die Frage, was tun? AVM scheint es zu verwenden, unsere uClibc-Version unterstützt das Flag aber nicht. Hoffen, dass AVM-Routinen damit zurecht kommen oder sollen wir einen Testcase für das Problem ableiten und dann uns doch um den uClibc-Fix bemühen?

p.s. Und AVM nervt - irgendwas als Opensrc-Paket zu veröffentlichen, was nicht wirklich dem entspricht, was verwendet wird. Ich kann das für manche Kernel-Sources-Versionen nachweisen, jetzt scheint es auch für uClibc der Fall zu sein. Irgendwann platzt mir der Kragen, die kriegen eine Klage wegen GPL-Verletzung zugeschickt.

@Carsten: wir sind in dem uclibc-testing branch unterweges. Ich habe in diesem die Patches neu geordnet/gruppiert. Die zusammengehörenden Patches sind jetzt (etwas mehr) beieinander.

Zuletzt geändert vor 2 Jahren von er13 (vorher) (Diff)

comment:354 Geändert vor 2 Jahren durch er13

@alle: make hat schon enorm viel getestet, könnte bitte noch jemand testen und bestätigen, dass mit den letzten Anpassungen das Problem nicht mehr auftritt? Dafür bitte

  • den uclibc-testing branch verwenden (was problematische Patches angeht, so sind diese in diesem Branch schon alle entfernt)
  • die .config reinkopieren, mit der das Problem reproduzierbar auftritt
  • menuconfig aufrufen und auf "Toolchain selber bauen" umstellen

Danke!

Wenn es weitere positiven Rückmeldungen gibt, werde ich die Download-Toolchain updaten. Bis dahin würde ich mir aber den Aufwand gerne sparen wollen.

comment:355 als Antwort auf: ↑ 353 ; Antwort: Geändert vor 2 Jahren durch make

Hmm, eigentlich dürfte uclibc-Version, die AVM mitliefert, %m[ nicht unterstützen, denn sonst müsste das opensrc-Paket von AVM die entsprechenden Patches enthalten, was aber nicht der Fall ist.

Wenn du dir das Original-Binary von AVM anschaust, dann wird %m[ in der Tat nicht unterstützt: In dem Binary findest du das #define SPEC_CHARS als String (Fileoffset: 0x96710), was ja praktischerweise alle gültigen Zeichen im Formatstring enthält. Demnach kann die AVM-uClibc überhaupt nichts mit %m[ anfangen, jedenfalls nicht in der 7390.06.23-Version. Oder was übersehe ich da?

Zuletzt geändert vor 2 Jahren von make (vorher) (Diff)

comment:356 als Antwort auf: ↑ 355 Geändert vor 2 Jahren durch er13

Replying to make:

In dem Binary findest du das #define SPEC_CHARS als String (Fileoffset: 0x96710). Demnach kann die AVM-uClibc überhaupt nichts mit %m[ anfangen, jedenfalls nicht in der 7390.06.23-Version.

Nice catch! Und auch nicht in der 7490.06.24. Demnach ziehe ich meinen Vorwurf der GPL-Verletzung zurück. Es gibt eine viel einfachere Erklärung - AVM testet nicht bzw. nicht ausreichend - schreibt den Code, der %m[ verwendet, prüft aber nicht, ob die verwendete libc-Bibliothek es unterstützt.

Und wenn man nach %m[ in 7490_Labor.113.06.25-29912 greppt, dann findet man den String nicht mehr (also hat AVM endlich getestet und erkannt, dass uClibc es nicht unterstützt). In 7390_LabDSL.84.06.23-29836 ist der String weiterhin in denselben drei Binaries enthalten. Das passt sehr gut mit den Berichten zusammen, wonach bei einigen nach dem Update auf die letzte Labor-FW der Fehler nicht mehr auftritt (das sind die 7490-User) und bei einigen (das sind dann die 7390-User) der Fehler auch nach dem Update auf die letzte Labor nach wie vor da ist.

comment:357 Geändert vor 2 Jahren durch make

Eine deprimierende, aber leider stimmige Interpretation des Entwicklungsprozesses bei AVM. Möchte man ja eigentlich gar nicht weiter darüber nachdenken, was da an vergleichbaren Problemen im closed source Teil schlummern könnte.

Die Antwort auf deine Frage, was tun wäre ist also, auf den Bugfix von AVM in den kommenden Firmware-Versionen zu warten? Was ist mit den Firmware-Versionen [06.05 - 06.23] - reicht es für die wirklich aus, nur den uclibc-Patch rauszunehmen?
Die %m-Semantik sichert dem Aufrufer zu, den korrespondierenden Pointer auf den von scanf allozierten Buffer korrekt zu setzen (was nach dem Entfernen des Patches nicht passieren würde). Und das es für den Caller nicht notwendig ist, die Adresse eines _initialisierten_ Pointers zu übergeben. Durch das Entfernen des scanf-Patches müsste fscanf auf %m[ mit errno=ERROR_EINVAL reagieren, oder? Bleibt also die Frage, ob im AVM-Code darauf getestet wird oder ob "der Entwickler" davon ausgeht, dass scanf schon funktionieren wird und den Hersteller-Produkt-Namen korrekt aus den devmap-Zeilen extrahieren kann.
Im letzteren Fall tauschen wir den Absturz durch die fehlerhafte uclibc-Implementierung gegen einen Zugriff auf einen nicht oder mit 0 initialisierten Pointer aus, der zudem später noch mit free freigegeben wird.

Das ist jetzt einiges an Spekulation, aber so ganz wohl fühle ich mich damit nicht. Hast du die Möglichkeit, im Assembler-Code zu prüfen, ob AVM den return-Wert von scanf checkt?

comment:358 Geändert vor 2 Jahren durch er13

Auf Basis Deines SPEC_CHARS-Catches wissen wir, in der AVM-Version von uClibc wird %m[ nicht unterstützt. Wenn wir die beiden scanf-Patches entfernen (der zweite behebt einen Fehler, der mir dem ersten erst reinkam), dann bringen wir die Freetz-uClibc-Version in Bezug auf die *scanf-Funktionen auf denselben Stand wie die AVM-Version. Da es mit der AVM-Version keinen Absturz gibt, wird AVM den return-Wert von *scanf vermutlich schon checken. Das Problem an dem Code ist, dass der *scanf-Aufruf wohl nie matcht und der Code "danach" (der für den Fall, dass es matcht) nie ausgeführt wird. Dieser Fehler bleibt mit unserer Anpassung bestehen, aber ich habe nicht vor durch irgendwelche Tricks in der uClibc Fehler von AVM in dem closed-Source binary auszubessern. Mir würde "Patches entfernt, User bestätigen läuft" reichen.

p.s. Mit Assembler bzw. dem Disassemblieren kennt sich meiner Einschätzung nach Ralf am allerbesten aus.

comment:359 Antwort: Geändert vor 2 Jahren durch er13

In 13005:

[uclibc-testing branch]:

  • update uClibc-0.9.33.x based download toolchains
  • refs #1939, refs #2499, refs #2547

comment:360 Geändert vor 2 Jahren durch er13

In 13007:

[trunk]:

Note: all users of uClibc-0.9.33.2 based toolchain (both download and self-built) should backup their .config, call "make distclean", restore their .config and build everything anew, i.e. no autoupdate or whatever…

comment:361 Geändert vor 2 Jahren durch Whoopie

RESPEKT!!! Meine 7390 stürzt nicht mehr ab. DANKE!!!

comment:362 Geändert vor 2 Jahren durch osvit

Danke! Bei mir läuft jetzt auch alles ohne Abstürze!

comment:363 Geändert vor 2 Jahren durch er13

Es wird wohl das längste Ticket mit dem kürzesten Namen sein: der %m[-Bug ;-)

p.s. an dieser Stelle nochmal ein großes Dankeschön an make für seinen Einsatz und den Test-Marathon.

comment:364 Geändert vor 2 Jahren durch make

Danke, danke, aber leider habe ich in comment:260 die Gelegenheit verpasst, die richtigen Schlussfolgerungen schon viel früher zu ziehen. Also …

Die Blumen gebühren eindeutig allen, die hier über 8 Monate kontinuierlich mit Ideen, Thesen, Wissen, unzähligen crashlogs und ihrer Zeit zur Lösung beigetragen haben. Abgesehen von den unzähligen Das-kann-doch-garnicht-sein-Momenten hat mir persönlich dieses Ticket viele Gelegenheiten geboten, einiges aus den Kommentaren, insbesondere von er13 und denen von PeterPawn zu lernen. Vielen Dank von mir dafür!

Zuletzt geändert vor 2 Jahren von make (vorher) (Diff)

comment:365 Geändert vor 2 Jahren durch CarstenSchuette

Juchu….. Lüppt! Saubere Arbeit!
Dann könnte jetzt ja eigentlich auch der Hinweis aus dem menuconfig raus, dass FREETZ "unstable" mit den neueren Firmwares ist?

Zuletzt geändert vor 2 Jahren von CarstenSchuette (vorher) (Diff)

comment:366 Geändert vor 2 Jahren durch PeterPawn

Glückwunsch, daß Ihr die Lösung gefiunden habt.

Ich ärgere mich allerdings maßlos, daß die bereits in Comment:88als verdächtig eingestufte Zeichenkette von mir nicht als Template für scanf erkannt wurde … dabei programmiere ich selbst seit Jahr(zehnt)en in C/C++.

Aber das Feature mit der Speicherzuweisung eines passenden Puffers durch scanf kannte ich tatsächlich nicht. Man lernt eben nie aus, wobei es schon witzig ist, wenn ein seit 2008 im POSIX-Standard vorhandenes Feature offenbar nur sehr unvollständig und fehlerhaft in der µClibc ankommt (oder interpretiere ich die Auswirkungen der Patches da nur falsch?).

comment:367 Geändert vor 2 Jahren durch make

Ja, schon ärgerlich, im Nachhinein festzustellen, wie nah man dem Kern des Problems schon viel früher gekommen ist…

Aber was kann man daraus lernen? Ich frage mich zB ob scanf im Callstack aufgetaucht wäre, wenn das Problem mal mit einer debug-uclibc getriggert worden wäre?

comment:368 Geändert vor 2 Jahren durch er13

In 13012:

FreetzMount:

  • remove workaround added in r12487, it's not necessary anymore - please update your configurations accordingly - the 1st character of the mount point won't be upper-cased anymore
  • refs #2499, refs #2572

comment:369 Geändert vor 2 Jahren durch er13

In 13013:

6.2x:

  • remove "Freetz support is UNSTABLE"-warning, support for Fritz!OS 6.20 is considered to be stable now ("replace kernel" is however still experimental/unstable)
  • refs #2499

comment:370 Geändert vor 2 Jahren durch er13

In 13014:

menuconfig:

  • make Fritz!OS 6.2x the default firmware version
  • refs #2499

comment:371 Geändert vor 2 Jahren durch er13

In 13015:

FreetzMount:

comment:372 Geändert vor 2 Jahren durch er13

  • Lösung auf fixed gesetzt
  • Status von new nach closed geändert

comment:373 als Antwort auf: ↑ 359 Geändert vor 2 Jahren durch dirkh

Replying to er13:

In 13005:

[uclibc-testing branch]:

  • update uClibc-0.9.33.x based download toolchains
  • refs #1939, refs #2499, refs #2547

Hi,
wenn jemand die Toolchain updated, könnte jemand vorher den toolchain.patch von http://freetz.org/ticket/2650#comment:11 integrieren.
Gibt es eigentlich einen Grund warum die target-utils, d.h. der native Target Compiler nicht Teil der Toolchain ist?

Danke und Gruß

comment:374 Geändert vor 2 Jahren durch er13

In upstream wurde ein Patch aufgenommen, der nun den Segfault bei der %m[-Conversion behebt, indem er diese korrekt (bzw. überhaupt) umsetzt.

Hinweis: Hilfe zur Verwendung von Tickets finden Sie in TracTickets.