7590 mit Labor 7.24 / Release 7.25 bootet nicht mehr

[MasterRoCcO]

Ich habe mir ein Image für die 7590 mit der Labor gebaut und Box fährt nicht mehr hoch.

[fda77]

Untrustedd entfernen oder watchdog deaktivieren

-> #28

[MasterRoCcO]

Es geht hier um die 7.24 FW und es ist egal ob watchdog an oder aus ist sie Bootet nicht mehr. Sie blinkt nur und nichts geht mehr. Es ist ein sauberes Freetz-ng nichts drin nichts geändert nunr watchdog an und aus gemacht zum testen

[fda77]

Wenn es keinerlei Logs gibt ist es schwer zu sagen wo es hängt.
7490 läuft jedenfalls mit Labot

[PrinzVonBillAir]

Ich habe es gerade mal bei mir getestet.
Hier meine config, welche bei 07.21 funktioniert (siehe Bild), bei 07.24 Labor jedoch nicht. Als Pakete ausgewählt: dnsmasq und WOL, Pakete abgewählt: dropbear und authkeys.
Wie beim Threadersteller auch, bleibt die Box während dem Booten hängen und ist nicht erreichbar und nur mittels FS-Wechsel wieder gangbar zu machen.

config.txt

[MasterRoCcO]

Danke @PrinzVonBillAir fürs testen, aber wie sagt fda es ist ein duplicate. Seit der FW 7.19 kann man die 7490 nicht mehr mit der 7590 vergleichen. Musl sei dank

[fda77]

7490:
Wer die nutzt sollte bei AVM um aktuelle Sourcen per eMail betteln! Da kommt vermutlich irgendwas wie "ach, warten sie doch bis zum Release" blah etc zurück. Dies dankend ablehnen und darauf bestehen! Wenn der AVM keine Lust hat aktuellen Quellcode zu veröffentlichen, sollen er seine Labors auch behalten

unresolved symbol avm_pa_dev_register in file /lib/modules/3.10.107/kernel/drivers/dsld/kdsldmod.ko
WARNING: Unresolved symbols detected, not all AVM-features may work.
No current sources by AVM? Error in kernel's .config?

7590:
Am besten lötet jemand ne serielle console an seine Box, dann sieht man genau was das Problem ist

• ich würde disable-watchdog auf jeden Fall aktivieren
• dann einmal mit und einmal ohne remove-untrustedd testen
• keine dnsmasq im image, dies belegt port 53 (DNS) was Probleme mit dem multid verusachen kann

Wenn ein Image nicht bootet, kann man danach über den Bootloader die alte Firmware wieder aktivieren oder über den Bootloader ein gutes Image flashen. ABER KEIN RECOVERY. Mit Glück findet man dann in den crash/debug Logs noch alte Meldungen

[berndy2001]

Ist mir auf er 7590 auch kürzlich aufgefallen, bin dann wieder zurückgestiegen.
"Disable AVM watchdog" war gewählt; "remove-untrustedd" war nicht gewählt. Kein Dnsmasq.

Habe mich dann nicht mehr näher damit beschäftigt, im Sinne von frischem Checkout und Minimal-Image.

[fda77]

Eine Idee von @PeterPawn: Evtl verbraucht Freetz zuviel "Zufälligkeit" weshalb der untrustedd nicht richtig läuft. Zum überprüfen:

• 7590 mit recovery zurücksetzen
• kein Backup zurückspielen!!
• Grundlegende Konfiguration
• Freetz mit Labor über Bootloader einspielen, untrustedd nicht entfernt, watchdog kann drin bleiben

[cnbr]

Da meine 7590 heute beim Starten mit der Labor 7.24 hing, habe ich mal über die serielle Console ein Log gezogen und anschließend wieder die vorher funktionsfähige Partition aktiviert.
Aufgefallen ist, die Log stoppt ca 7 Sekunden nach Boot im Bereich random: init: uninitialized urandom read (4 bytes read)
Eine Meldung random: crng init done kommt nach ca 32 Sekunden, bei der funktionierenden 7.21 kommt die schon ca. 0,5 Sekunden später. Nach Eingabe von Enter an der Console wird ab und an Waiting for entropy ausgegeben. Nach über 2 Mit Wartezeit ohne weitere Ereignisse habe ich dann abgebrochen und das funktionsfähige Image wieder aktiviert.
Logs von der 7.24 und der funktionsfähigen 7.21 sind mit dabei, vielleicht hilft es ja bei der Diagnose.
boot_7590_07.24.all-rev84707_labor_freetz-ng-17597.log
boot_7590_07.21.all_freetz-ng-17273.log
Bei der 7.21 werden zu dem Zeitpunkt die Module eip123 und eip123_hw geladen, die ja wohl Verschlüsselung und lt. @PeterPawn den Zufallszahlengenerator betreffen

[fda77]

Danke!!
Auszüge aus deinen Logs:

[    0.000000] [fw-info] Version 07.24-84707

[    6.536963] [announce_root] filesystem (/dev/mtdblock6) will be used as root device
[    6.554939] VFS: Mounted root (squashfs filesystem) readonly on device 31:6.
[    6.566991] devtmpfs: mounted
[    6.569711] Freeing unused kernel: 372k freed
[    6.572907] This architecture does not have kernel memory protection.
[    7.014812] random: init: uninitialized urandom read (4 bytes read)
[    7.304165] random: 1: uninitialized urandom read (4 bytes read)
[    7.498423] random: head: uninitialized urandom read (4 bytes read)

[   10.345035] [0]system-load  49% loadavg 0.8 0.2 0.1 - pgstat: sum=217155 free=102303 slab=1837 alloc=770/s fault=105/s (sleep 1)
[   32.588305] 	
[   32.590312] random: 7 urandom warning(s) missed due to ratelimiting
[   50.688115] start slab_allocator-trace now  (use cat /proc/slab_allocators)

�[32m[INFO]�[0m Waiting for entropy
�[32m[INFO]�[0m Waiting for entropy

[    0.000000] [fw-info] Version 07.21

[    6.419887] [announce_root] filesystem (/dev/mtdblock5) will be used as root device
[    6.440305] VFS: Mounted root (squashfs filesystem) readonly on device 31:5.
[    6.453108] devtmpfs: mounted
[    6.455746] Freeing unused kernel: 388k freed
[    6.459032] This architecture does not have kernel memory protection.
[    6.899343] random: init: uninitialized urandom read (4 bytes read)
[    7.036616] random: 1: uninitialized urandom read (4 bytes read)
[    7.228091] random: head: uninitialized urandom read (4 bytes read)

[    7.465082] eip123_hw: loading out-of-tree module taints kernel.
[    7.469743] eip123_hw: module license 'Proprietary' taints kernel.
[    7.475929] Disabling lock debugging due to kernel taint
[    7.481658] [module-mem] give 0x4000 bytes at 884a8000 to module 'eip123_hw' (0x98a000 bytes left)
[    7.492344] [module-mem] give 0x2000 bytes at 884ac000 to module 'eip123' (0x988000 bytes left)
[    7.500970] eip123 1e000000.eip123: Detected hardware version 2.2.2
[    7.506069] eip123 1e000000.eip123: my_id=3 master_id=0 num_mailboxes=4 mailbox_size=256
[    7.514125] eip123 1e000000.eip123: Linked mailbox number 1
[    7.544405] eip123 1e000000.eip123: Sysinfo: FWVersion=2.4.2 HWVersion=2.2.2 MemorySize=32768 HostId=3 Identity=0 NVMAnomaly=0 NVMAnomalyLocation=0
[    7.776456] eip123 1e000000.eip123: eip123_hw init successful
[    7.809166] random: crng init done
[    7.811109] random: 7 urandom warning(s) missed due to ratelimiting
[    7.836475] eip123 1e000000.eip123: Device responded with error_src=0x0 error=0x1 opcode=0x1c
[    7.843608] eip123 1e000000.eip123: Could not find rootkey in OTP

Die eip*ko gibt es in der Labor auch, "modinfo" von diesen Dateien

filename:       lib/modules/4.9.198/extra/eip123_hw.ko
description:    Hardware access functions for the eip123 driver.
author:         Alexander Theißen <a.theissen@avm.de>
license:        Proprietary
depends:
vermagic:       4.9.198 SMP mod_unload MIPS32_R2 32BIT

filename:       lib/modules/4.9.198/extra/eip123.ko
description:    Driver for the eip123 crypto chip.
author:         Alexander Theißen <a.theissen@avm.de>
license:        GPL v2
alias:          of:N*T*Cverimatrix,eip123C*
alias:          of:N*T*Cverimatrix,eip123
depends:
vermagic:       4.9.198 SMP mod_unload MIPS32_R2 32BIT

filename:       lib/modules/4.9.198/extra/eip97.ko
description:    Cryptographic accelerator driver for EIP97
author:         Robert Hering <r.hering@avm.de>
license:        GPL
alias:          of:N*T*Clantiq,crypto-xrx500C*
alias:          of:N*T*Clantiq,crypto-xrx500
depends:
vermagic:       4.9.198 SMP mod_unload MIPS32_R2 32BIT
parm:           eip97_desc_num:uint

Es könnte also so sein wie PeterPawn schrieb, dass zuwenig Zufälligkeit vorhanden ist. So früh dürften Daemons von Freetz damit noch nichts zu tun haben. Könnte auch ein Fehler in der busybox-config sein. Oder was mit einem "dev" bzw "tty", ob das für das hw-crypto überhaupt genutzt wird weiss ich aber nicht..
Kannst du noch ein Log von der Labor-ohne-Freetz machen? PeterPawn vermutet dass so nötige Dateien generiert werden können und danach evtl die Labor auch mit Freetz starten kann.
Die "Waiting for entropy" kommen aus diesem AVM-Script, als Konsequenz dass die eip* Module wohl nicht geladen werden https://www.ip-phone-forum.de/threads/305167/post-2351216

[cnbr]

Log von der 07.24-84940 ist anbei, der Bereich um random sieht nun etwas anders aus, random: init: fehlt z.B. vermutlich wird der Zufallsgenerator nun anders initialisiert,

[    6.515359] devtmpfs: mounted
[    6.518067] Freeing unused kernel: 372k freed
[    6.521281] This architecture does not have kernel memory protection.
[    7.809150] eip123_hw: loading out-of-tree module taints kernel.
[    7.813925] eip123_hw: module license 'Proprietary' taints kernel.
[    7.819921] Disabling lock debugging due to kernel taint
[    7.825731] [module-mem] give 0x4000 bytes at 884a8000 to module 'eip123_hw' (0x9ac000 bytes left)
[    7.836712] [module-mem] give 0x2000 bytes at 884ac000 to module 'eip123' (0x9aa000 bytes left)
[    7.845266] eip123 1e000000.eip123: Detected hardware version 2.2.2
[    7.850278] eip123 1e000000.eip123: my_id=3 master_id=0 num_mailboxes=4 mailbox_size=256
[    7.858335] eip123 1e000000.eip123: Linked mailbox number 1
[    7.888905] eip123 1e000000.eip123: Sysinfo: FWVersion=2.4.2 HWVersion=2.2.2 MemorySize=32768 HostId=3 Identity=0 NVMAnomaly=0 NVMAnomalyLocation=0
[    7.924883] eip123 1e000000.eip123: Device responded with error_src=0x2 error=0x2 opcode=0x11
[    8.232884] eip123 1e000000.eip123: eip123_hw init successful
[    8.265309] random: crng init done
[    8.292899] eip123 1e000000.eip123: Device responded with error_src=0x0 error=0x1 opcode=0x1c
[    8.299988] eip123 1e000000.eip123: Could not find rootkey in OTP
[    8.581626] [module-mem] give 0x33000 bytes at 884ae000 to module 'led_module' (0x977000 bytes left)

boot_FRITZ.Box_7590-07.24-84940-Labor.log

[fda77]

Danke. Die Busybox .config der 7590 7.21 von AVM hat noch ein paar mehr Optionen aktiviert als Freetz.

+       select FREETZ_BUSYBOX_STACK_OPTIMIZATION_386
+       select FREETZ_BUSYBOX_FEATURE_EDITING_WINCH
+       select FREETZ_BUSYBOX_FEATURE_UNZIP_CDF
+       select FREETZ_BUSYBOX_FACTOR
+       select FREETZ_BUSYBOX_FEATURE_XARGS_SUPPORT_ARGS_FILE
+       select FREETZ_BUSYBOX_FEATURE_WAIT_FOR_INIT
+       select FREETZ_BUSYBOX_FEATURE_INIT_QUIET
+       select FREETZ_BUSYBOX_FEATURE_INIT_MODIFY_CMDLINE
+       select FREETZ_BUSYBOX_FEATURE_NOLOGIN
+       select FREETZ_BUSYBOX_FEATURE_SECURETTY
+       select FREETZ_BUSYBOX_FEATURE_HEXDUMP_REVERSE
+       select FREETZ_BUSYBOX_XXD
+       select FREETZ_BUSYBOX_FEATURE_VOLUMEID_EXFAT
+       select FREETZ_BUSYBOX_FEATURE_VOLUMEID_F2FS
+       select FREETZ_BUSYBOX_FEATURE_WGET_HTTPS
+       select FREETZ_BUSYBOX_ASH_BASH_NOT_FOUND_HOOK
+       select FREETZ_BUSYBOX_FEATURE_SH_READ_FRAC
+       select FREETZ_BUSYBOX_FEATURE_SH_HISTFILESIZE

Die Module werden also mit der Labor+Freetz nicht mehr geladen, was mit der 7.21+freetz oder Labor+AVM funktioniert
Diese Zeilen erscheinene mit als auch ohne Freetz, also "normal" und deuten auf keinen Fehler hin

[    7.836475] eip123 1e000000.eip123: Device responded with error_src=0x0 error=0x1 opcode=0x1c
[    7.843608] eip123 1e000000.eip123: Could not find rootkey in OTP

[fda77]

@cnbr 9762e59 könnte helfen

[cnbr]

Leider nicht wirklich, keine Veränderung feststellbar, hängt leider weiterhin.
Auszug von der serielle Console, komplette Log im Anhang.

[    6.473972] [announce_root] filesystem (/dev/mtdblock6) will be used as root device
[    6.491883] VFS: Mounted root (squashfs filesystem) readonly on device 31:6.
[    6.503890] devtmpfs: mounted
[    6.506586] Freeing unused kernel: 372k freed
[    6.509810] This architecture does not have kernel memory protection.
[    6.966097] random: init: uninitialized urandom read (4 bytes read)
[    7.253298] random: 1: uninitialized urandom read (4 bytes read)
[    7.446095] random: head: uninitialized urandom read (4 bytes read)
[    9.865868] [0]system-load  52% loadavg 0.8 0.2 0.1 - pgstat: sum=217254 free=102369 slab=1791 alloc=782/s fault=106/s (sleep 0)
[   32.564816] random: crng init done
[   32.566816] random: 7 urandom warning(s) missed due to ratelimiting
[   50.676629] start slab_allocator-trace now  (use cat /proc/slab_allocators)

�[32m[INFO]�[0m Waiting for entropy
�[32m[INFO]�[0m Waiting for entropy
�[32m[INFO]�[0m Waiting for entropy

boot_7590_07.24.all-rev84707_labor_freetz-ng-17605.log

[fda77]

Mist .. und danke fürs testen
@PeterPawn Hast du noch Ideen?

[fda77]

Die anderen Zeilen in der Datei verändern doch auch indirekt die post_install
Das ganze war lange vor ng, ich hab jetzt kein Ticket gefunden, vielleicht war das auch im Forum.
Ich glaube AVM hatte da gewisse Dect-Events ins Syslog geschrieben, und mit was anderem ausgelesen. Evtl ein spezieller printk-Dingens-Modus. Und durch Freetz/ gab es da irgend welche Problem. Aber so genau weiss ich das alles nicht mehr

[PeterPawn]

Die anderen Zeilen in der Datei verändern doch auch indirekt die post_install

Wo genau?

Die ändern die var/install und erst die schreibt bei ihrer Ausführung im Rahmen eines Updates dann weitere Daten in die var/post_install ... aber auch da nur in die bereits aus der var.tar extrahierte Datei und nicht in das "template" (das es mittlerweile sogar noch zusätzlich gibt bei AVM in der var.tar - hatten wir letztens irgendwo anders schon) im Tarball.

[fda77]

Ist doch so okay, hat ja so bislang funktioniert. Für die 7390 gab es eh kein Fritzos 7+ mehr.
Normalerweis entlädt man für einen Reboot eh keine Module...

[PeterPawn]

Das ist vermutlich der Unterschied zwischen "So ist es richtig." und "Pascht scho' irgendwie." - einen plausiblen Grund, warum man das nicht in einer gesonderten Datei patchen sollte, habe ich jedenfalls nicht gefunden/gelesen.

Aber wie so oft ... lassen wir das Thema einfach bleiben, denn schließlich macht AVM das ja schon falsch, wenn sie sich dazu versteigen, die DECT-LKMs zu entladen - wobei vermutlich auch nur dort die Leute zu finden sind, die genau sagen können, was beim Entladen dieser LKMs eigentlich passieren sollte.

Das kann ja bis hin zur Signalisierung an die DECT-Geräte, daß die Basis ab jetzt nicht mehr verfügbar ist, gehen - ich verstehe halt nicht, warum man bei Änderungen immer so weit wie möglich von der originalen Firmware "wegkommen" wollte, anstatt so dicht wie möglich dranzubleiben.

Je geringer die Unterschiede (weil man nur das ändert, was tatsächlich erforderlich ist, um ein Ziel zu erreichen und nicht einfach "auf Verdacht" noch alles mögliche andere), um so geringer auch die Wahrscheinlichkeit für zusätzliche Probleme, die sich daraus ergeben können - und "unerklärliche Phänomene", von denen nur Freetz (oder sogar nur Freetz-NG) betroffen ist (auch wenn Freetz sicherlich nur ältere Versionen unterstützt, gibt es ja noch andere Optionen der Modifikation und von denen hört man zumindest nicht, daß die ähnliche Probleme machen), gibt es ja nun genug.

Wenn man dann bei der Fehlersuche und der dabei erfolgenden Suche nach möglichen Unterschieden weniger Punkte abzuklappern hat, ist das sicherlich auch von Vorteil.

[fda77]

Ist ja jetzt nur noch für die alten Geräte bei denen es auftrat, dass sollte auf jeden fall geändert werden.
Ansonsten benutze ich für die Verzeichnisse config/ und patches/ tatsächlich meist grep. Die Sortierung dort erschliesst sich mir nicht so ganz, aber wenn man was ändert und die Sortierung durcheinander wirft passt nachher irgendwas bestimmt nicht mehr

Busybox: Du meintest vor kurzem es wäre ganz gut genau die Version von AVM zu nehmen. Also man kann problemlos viel Versionen der Busybox aufnehmen (in ng). Das gibt aber eine unmenge an Symbolen im menuconfig, sieh make/busybox/. Ich habe die Befürchtung dass es irgend wann für kconfig zu viele werden.
Ausserdem werden vermutlich viele bei Problemmeldungen die genutzte Version nicht angeben was die Fehlersuche erschwert

[PeterPawn]

Hinsichtlich der BusyBox hast Du mich vermutlich auch falsch verstanden - gegen deren Ersetzen ist wenig einzuwenden, solange sie minimal dieselben Funktionen bietet, wie die von AVM und sich im Verhalten nur so weit unterscheidet, daß es nicht zum Problem wird (Stichwort LKM-Kommandos). Deine Änderungen an dieser Stelle, wenn es um die Frage geht, welche Optionen denn bei der Freetz-BusyBox minimal zu aktivieren sind, sind ja vollkommen in Ordnung in meinen Augen. Ich weiß zwar nicht mehr, ob Du dafür auch das "generate.sh" für die BB angepaßt hattest, aber das Vorgehen war mir schon immer suspekt und für reibungslosen Austausch brauchte es schon immer eine "handgemachte" BusyBox-Konfiguration bei mir.

Die war ja auch der wesentliche Punkt (weil sie viel Zeit in Anspruch nimmt), warum ich bei mir eine Möglichkeit brauchte, die .config für verschiedene Modelle und Versionen nachnutzen zu können, ohne jedesmal BusyBox und (wenige) Pakete neu konfigurieren zu müssen. Aber zurück zur BusyBox...

Speziell die Optimierungen (Applets bevorzugen, NOFORK, etc.) können aber zu abweichendem Verhalten und ggf. zum Aufruf eines falschen Kommandos führen, wobei auch bei AVM mittlerweile an vielen Stellen immer öfter der Aufruf mit absoluten Pfaden zu finden ist, was zwar zum Problem wird, wenn man da etwas ersetzen/einschmuggeln will, aber die Sicherheit, daß man tatsächlich das gewünschte Kommando findet, deutlich erhöht - zumindest solange das Dateisystem unverändert ist. Ein Austausch nur über das Ausnutzen der Suchreihenfolge (explizit in PATH oder implizit) ist damit verhindert.

Irgendwann muß man auch einsehen, daß die AVM-Firmware deutlich komplexer geworden ist im Laufe der Jahre und daß eine Änderung durch Austausch/Löschen jedes beliebigen Teils/Kommandos immer öfter zu unerwarteten Seiteneffekten führt - hier will ich mal an die XFRM-Funktionen von "iptables" erinnern, die ja bei den GRX-Boxen (oder sogar bei allen Modellen) zum nächsten Problem führten, als AVM die VPN-Implementierung überarbeitete.

Man muß daher m.E. bei jeder wirklich neuen Version (und in den Labor-Versionen ändert sich das eben noch ständig bzw. es besteht die Chance dafür) erst einmal ergründen, was sich gegenüber dem Vorgänger geändert hat und welche Auswirkungen das auf das eigene Projekt haben könnte. Einfach nur die Versionsnummer der Vorlage zu erhöhen und dabei dann darauf zu vertrauen, daß das schon weiterhin alles passen würde, führt mich wieder zu der (bisher nicht wirklich beantworteten) Frage, wo genau Du Dein Freetz-NG denn nun sehen willst - die Signale sind da (zumindest für mich) immer noch widersprüchlich, auch wenn ich Dein erstes Tag tatsächlich gesehen habe.

Aber glaubst Du tatsächlich selbst, daß irgendjemand ein altes Tag (mit zusätzlichen Kommandos/Optionen, die es dafür braucht) auschecken und benutzen würde? Und was wäre Deine Reaktion auf einen Fehlerbericht, der sich nur auf die alte Version am Tag (täck, nicht taag) bezieht?

Das ist eben wieder ein gewaltiger Unterschied zwischen Tags und Branches ... ich kann einen Commit zur Fehlerkorrektur problemlos auch auf zwei Branches anwenden (solange sie sich nicht gerade an dieser Stelle auch noch unterscheiden) und habe das Problem damit in beiden Zweigen gelöst. Insofern hast Du (für mich) bisher nur den halben Weg zurückgelegt beim Versuch, eine "nutzerfreundliche Version" anzubieten, bei welcher der potentielle Interessent davon ausgehen kann, daß die tatsächlich auch (auf einer hinreichenden Anzahl von Installationen) getestet ist.

Und anders als Du (gerade wieder bei der 6591 zu sehen, iirc) bin ich nicht der Ansicht, daß bereits ein einzelner erfolgreicher Anwender ausreichend sein sollte, um irgendwo ein "funktioniert"-Schild draufzupappen. Das FRITZ!OS ist mittlerweile ein so komplexes Gebilde (vergleichen mit den allermeisten anderen OS für SOHO-Router, wobei es inzwischen auch andere Geräte gibt, die beim Funktionsumfang - auch mit mehr OSS-Benutzung - deutlich aufholen), daß ein Einzelner gar nicht alle Teile davon benutzen KANN - manches schließt sich ja auch gegenseitig aus, wie IP-Client und VPN/DynDNS/etc.

Ich versuche mir gerade vorzustellen, wie das wäre, wenn AVM nach dem ersten Kunden, der kein Problem in der neuen Labor-Version hatte, das Zeug gleich als Release unter die Leute bringen würde. Und dort kapriziert man sich immer nur auf eine (nämlich die letzte aktuelle) Version und hat gar nicht den Ehrgeiz, auch noch die Geräte aus dem 30-jährigen Krieg zu unterstützen ... was das Ganze für AVM noch einmal deutlich leichter macht.

Da sieht also schon AVM mit einem ganzen Programmierer-/Tester-Team sich gezwungen, gewisse Grenzen zu ziehen ... und das alles jetzt als Einzelner (mit ein paar "Freiwilligen", die auch nicht immer ganz freiwillig als Tester herhalten sollen/müssen) weiterhin im Griff zu behalten (während bei AVM die Entwicklung immer weiter fortschreitet), ist halt schon sehr ambitioniert und man KANN unmöglich auf allen Hochzeiten gleichzeitig tanzen. Da muß man sich mal für eine Veranstaltung entscheiden - sonst bleibt das (in meinen Augen zumindest) immer nur Stückwerk.

Und ich bin auch tatsächlich der Ansicht, daß Du ohne eine solche grundsätzliche Entscheidung und "offizielle" Positionierung für Freetz-NG nur sehr wenige (ernsthafte) Mitstreiter finden wirst - dann bleibt es bei einer (durchaus wachsenden) Zahl an "Benutzern", die dann aber erwarten (werden), daß Du Dich um ihre Probleme mit Deinem Fork auch kümmerst. Das machst Du in letzter Zeit auch deutlich besser - aber irgendwann wirst Du auf diesem Weg an einer Grenze ankommen, wo das nicht länger zu stemmen ist und wenn Du bis dahin keine Mitstreiter gefunden hast (oder sich die Struktur des Projekts geändert/angepaßt hat), wird Freetz-NG wohl genauso leise sterben, wie das für das ursprüngliche Projekt der Fall war/ist.

Ich bin jedenfalls schon dabei, die (ohnehin wenigen) Pakete für meine eigenen Projekte nur noch mit einer eigenen Toolchain (die noch nicht das Stadium erreicht hat, daß ich sie veröffentlichen wollte) und mit musl als C-Library zu erzeugen - die waren/sind bei mir ja ohnehin fast alle statisch gelinkt (daher ja auch ein paar Patches für Freetz-Pakete, die das überhaupt erst ermöglichten) und genau dafür ist ja musl mal gedacht gewesen, so daß dabei sogar kleinere Binaries entstehen, als mit der uClibc(-ng). Obendrein wird ja auch bei OpenWRT inzwischen musl verwendet, so daß man auch nicht jeden einzelnen Patch für Pakete (bzw. Upstream-Projekte) selbst erstellen muß.

Bei musl gibt es nicht viel zu konfigurieren ... und überlege Dir mal, wieviel einfacher schon die Freetz-Toolchain (also C-Compiler und -Library für Cross-Build und fürs Target-System) gestrickt sein könnte, wenn es da nur noch eine C-Library gäbe und man nur noch die neueren FRITZ!OS-Versionen (jenseits der 06.5x, wo bei AVM der Wechsel auf einen 3er-Kernel stattfand) berücksichtigen wollte.

Aber das ist hier halt auch alles "off-topic" und hat mit dem konkreten Problem, warum die 7590 mit 07.24 offenbar beim Warten auf ausreichende Entropie stehenbleibt, nur wenig zu tun. Was damit aber zu tun hat, ist die Frage, wie weit Freetz(-NG) jetzt dem Benutzer seinerseits "Hilfen" beim Eingrenzen/Nachverfolgen solcher Probleme anbieten sollte ... und auch da hast Du mit dem Erweitern (und Persistieren) der Protokolle ja durchaus Fortschritte gemacht. Nur reicht das offensichtlich nicht immer aus, um einen Fehler zu finden ... und man muß/sollte dann dem Benutzer auch mehr Hilfestellung geben (können), wie genau er sein System modifizieren muß, damit da zusätzliche Informationen erzeugt werden, die man zur Lösung des Problems benötigt.

Und hier beißen sich dann tatsächlich meine Theorien hinsichtlich des "so wenige Änderungen, wie erforderlich" und "ausreichende Möglichkeiten der Ablaufverfolgung" - die sind offensichtlich nicht ohne weiteres unter einen Hut zu bringen. Damit sollte/muß man sich Gedanken machen, mit den "Developer-Einstellungen" eben nicht nur die Auswahl bestimmter Symbole in der Konfiguration zu beschränken, sondern auch zusätzliche Änderungen an der Firmware vorzunehmen, die genau für solche tiefergehenden Fehlersuchen auch benötigt werden (und zwar immer wieder, das ist ja auch nicht jedes Mal die Neuerfindung des Rades) und die man dann eben nur in solche "Debug-Versionen" einbauen läßt.

Damit hat man dann wieder zwei Fliegen mit einer Klappe geschlagen - die "Benutzer-Änderungen" werden auf das Notwendige reduziert und die Debug-Versionen liefern "auf Knopfdruck" genug Infos, daß man nicht immer erst "Dann bau doch mal das und das dort ein." empfehlen muß, was offensichtlich den größten Teil der Benutzer auch überfordert.

Ich persönlich finde es jedenfalls deutlich dringender, solche "Debug-Hilfen" in die Freetz-Modifikationen einzubauen, als sich um die Unterstützung von Boxen zu kümmern, die noch gar nicht in ausreichender Zahl auf dem Markt sind, als daß deren Besitzer sich schon in größerer Zahl für Modifikationen daran interessieren würden und wo mangels Gerätschaften (mit eigenem Zugriff, denn vieles ist auch nur schwer zu vermitteln beim "Erkunden" neuer Geräte) vieles nur "geraten" ist. Zwar muß man sich auch um solche neuen Geräte irgendwann mal kümmern, aber man muß auch mal Prioritäten setzen und da gäbe es (in meinen Augen) noch genug Baustellen in Freetz-NG, die deutlich mehr Aufmerksamkeit bräuchten, als die Unterstützung des neuen Image-Formats von AVM.

Denn ein wenig wirkt auch Freetz-NG bei der Unterstützung der neuen Versionen noch wie "Vaporware" ... Hauptsache, es steht schon irgendwo, daß 07.2x und 07.24-Labor bereits unterstützt werden. Wie gut das dann tatsächlich funktioniert und wieviele Probleme oder Fragen da weiterhin offen/ungelöst sind, interessiert dann die "Marketing-Abteilung" gar nicht mehr - das erinnert ein wenig an AVM und das "DNS over TLS", was zwar auch "implementiert" ist, aber noch so viele Probleme bereitet, daß viele Benutzer (zumindest diejenigen, die die Ursache verstehen und sich nicht einfach durch einen Neustart behelfen, weil sie gar nichts anderes können) das lieber wieder abschalten.

Aber wir sollten das tatsächlich eher nach "Discussions" verlagern - ich mache mir mal vorsichtshalber eine Kopie der Seite.

[fda77]

Mit der Busybox ist das so eine Sache wie man an f2f5e84 sieht. Plötzlich fehlt das letzte ' das sich hinter der Klammer der Variable befindet. Ich hab die 1.32.0 zwar 6 Monate bei mir laufen gehabt, das fiel mir aber nicht auf. Evtl kam es erst durch 1.32.1.
Die von AVM genutzten Optionen werden noch nicht ausgewertet (die ganzen neuen Dateien in make/busybox/avm/), das ist nur manuell durch selects oder bei strings in der generate.sh.
Der Tag war halt vor größeren Änderungen an busybox und uclibc. Als etwas in richtung stable und der branch mach neues was noch Problem machen kann (war bei busybox ja so)

Die 2 Issues heute hab ich nur gelöscht weil durch die Umwandlung in eine Diskussion diese kopiert wurden, und der Status automatisch auf "locked" gesetzt wurde. Das half der Übersicht in den Issues nicht wirklich.
Eigen Diskussionen wären schon gut. Man kann hier Posts als off-topic markieren, die sind dann eingeklappt und werden erst nach einem klick angezeigt. Das wäre für dieses Issue ganz gut :)

Die Toolchain ist doch einfach, weil nämlich nur uclib verwendet wird! Was AVM verwendet ist egal bei den neueren FOS! Also so wie du vorgeschlagen hast. Dazu auch nur noch die neueren single-lib version (Für Nutzer von vorkompilierten Binaries ist das halt etwas stressig...)

[PeterPawn]

Also so wie du vorgeschlagen hast.

Eben nicht ganz so ... während musl ja genau dafür auch (mit-)entwickelt wurde, statisch gelinkt zu werden (https://musl.libc.org/about.html):

Due to lack of heavy internal coupling between libc components, static linking with musl pulls in very little code that the application isn't actually using. Minimal static-linked binaries can be under 10 kB of code, even with threads, and even useful programs can be under 50 kB.

ist das bei der uClibc nicht der Fall und die ganzen Optionen zur Konfiguration, machen die Benutzung der uClibc[-ng] auch nicht gerade einfacher und konsistenter.

Verglichen mit der uClibc[-ng] (und die wurde schon für "embedded devices" entwickelt), ist musl dann eben noch einmal effektiver - hier: https://elinux.org/images/e/eb/Transitioning_From_uclibc_to_musl_for_Embedded_Development.pdf findest Du ein Paper, was uClibc und musl miteinander vergleicht.

Es gab ja auch gute Gründe, warum OpenWRT vor mehr als fünf Jahren zu musl als Standard gewechselt hat: https://lists.openwrt.org/pipermail/openwrt-devel/2015-June/007680.html - letztlich hat AVM das jetzt (nach einem Ausflug zur glibc) auch nur nachvollzogen und ich hoffe mal (bzw. ich wage die These), daß das für künftige Systeme der präferierte Weg sein wird.

Die glibc ist einfach deutlich umfangreicher und für Geräte wie die FRITZ!Boxen praktisch Overkill und die uClibc ist im Original ziemlich alt, während die uClibc-ng im Embedded-Umfeld (sicherlich auch, weil es da musl schon gab und die Vorteile - siehe das oben verlinkte Paper - auf der Hand liegen) nie so richtig in die Puschen kam.

Wenn man dann noch die Idee hinter dem Flatpak-Format (https://flatpak.org/) berücksichtigt (das ja auch "beim Containern" :-) zunehmend eine Rolle spielt), dann kommt man noch eher zur Notwendigkeit von Komponenten (oder eben speziell der C-Library), die ein effektives statisches Linken unterstützen, damit die erzeugten "Flat-Paks" (auch wenn eine FRITZ!Box sicherlich kein Desktop-System ist) auf die notwendige Größe beschränkt werden können.

Alles das, was in Freetz in den Abhängigkeiten der Pakete von anderen bzw. von bestimmten Libraries steckt, hat sich automatisch überlebt, wenn man tatsächlich zu solchen "containerisierten Apps" (für einen DNS-/DHCP-Server, für einen SSH-Server, für ein VPN, etc. - die OS für die NAS von QNAP oder Synology machen vor, wie das geht) käme und das wäre dann (wenn es selbst alles mitbringt, was man dafür braucht) auch noch unabhängig von der Version des FRITZ!OS, auf der es laufen soll (solange die Architektur stimmt und es sich irgendwie in das FRITZ!OS integrieren kann).

Das ist sicherlich auch nichts, was man von heute auf morgen auf die Beine stellen kann ... aber es ist nun mal die Zukunft (mal abgesehen davon, daß man das dann tatsächlich auch wieder viel mehr (potentiellen) Benutzern zugänglich machen kann) und nur, weil es diese Architekturideen und die dafür notwendigen Werkzeuge vor 15 Jahren noch nicht gab, als Freetz aus der Taufe gehoben wurde, kann das Rezept für die heutige Weiterentwicklung ja nicht "Vorwärts in die Vergangenheit" heißen - auch ein Windows 95/98 (oder XP, wenn wir zeitlich besser liegen wollen zur "Geburt" von Freetz) mußte irgendwann mal etwas Neuerem weichen.

Entweder man sieht Freetz als die "gute alte Zeit" an, die man nicht missen möchte und die man mit (sehr) viel Aufwand am Leben erhält oder man sieht es (im derzeitigen Zustand/Aufbau) nur als Übergangslösung, bis etwas Moderneres zur Verfügung steht. Und damit komme ich schon wieder auf die "Positionierung" von Freetz-NG zu sprechen ... irgendwann kommt man einfach nicht mehr umhin, sich ein paar Gedanken darüber zu machen, wo man sich (in Relation zu anderen Optionen) in der Software-Landschaft sehen will und welche Perspektiven man (noch) sieht.

Einer "Übergangslösung" mag man noch so manche unsaubere Problemlösung nachsehen, weil es ja eine Perspektive für deren Ablösung gibt - von einer "Dauerlösung" werden die meisten aber etwas mehr erwarten. Das schließt dann auch wieder den Bogen zu Reboots und Watchdogs und AVM-Diensten mit bisher unbekanntem Zweck, die man einfach abschaltet und dann so tut, als gäbe es jetzt gar kein Problem mehr, obwohl man noch gar nicht weiß, was mit dieser Abschaltung (bzw. es ist ja im Moment wohl sogar das komplette Entfernen der dazu notwendigen Dateien) alles an Seiteneffekten verbunden ist. Bei AVM ist man ja nun auch nicht vollkommen blöd und entwickelt irgendwelche Services, die heute und in Zukunft niemand braucht - da sollte dann etwas mehr "Untersuchung", was der überhaupt machen soll, schon drin sein.

Und ein Watchdog hat ja genau die Aufgabe, zu verhindern daß das System oder ein einzelner Service auf diesem System einfach "stehenbleibt", ohne daß es jemand bemerkt und entsprechende Aktionen einleitet. Es muß ja auch irgendeinen Grund geben, warum der Watchdog hier tatsächlich auslöst - da jetzt einfach alle Watchdogs abzuschalten, hat irgendwie Ähnlichkeit mit dem Überbrücken einer (elektrischen) Sicherung, nur weil die immer wieder durchbrennt, anstatt einfach mal nach der Ursache dafür zu suchen.

[fda77]

Du kannst dich gern um musl kümmern. Ich brauche es nicht, wogegen gelink wird ist egal solang es funktioniert. Für modfs klappt es mit dem statischen linken so wie es aktuell ist halt nicht so gut. Vergiss nicht dass auch dl-toolchains für alle erlaubten Kombinationen nötig sind

[cnbr]

Mit der nun verfügbaren 7.25 habe ich es versucht, leider keine Änderung gegenüber der Labor. Hängt wieder in dem Teil um random: init. Log vom Booten ist in Anhang.
7590_07.25.all_freetz-ng-17993M_boot.log

Source der 7.25 hatte ich nachgefragt, wurde schon bereitgestellt.

[fda77]

Schade, ich hab gehofft mit der Release läuft es wieder.
Also immer noch die [INFO] Waiting for entropy wie schon in #120 (comment)
Die Änderungen an kernel und busybox sind nicht so spektakulär

busybox

--- make/busybox/avm/07.21-7590--busybox.config.grx5	2020-12-30 05:54:39.053657734 +0100
+++ make/busybox/avm/07.25-7590--busybox.config.grx5	2021-02-22 14:14:27.000000000 +0100
-CONFIG_INSMOD=y
-CONFIG_LSMOD=y
-CONFIG_FEATURE_LSMOD_PRETTY_2_6_OUTPUT=y
-CONFIG_MODPROBE=y
-CONFIG_FEATURE_MODPROBE_BLACKLIST=y
-CONFIG_RMMOD=y
-CONFIG_FEATURE_CMDLINE_MODULE_OPTIONS=y
-CONFIG_FEATURE_CHECK_TAINTED_MODULE=y
-CONFIG_FEATURE_MODUTILS_ALIAS=y
-CONFIG_FEATURE_MODUTILS_SYMBOLS=y
-CONFIG_DEFAULT_MODULES_DIR="/lib/modules"
+CONFIG_DEFAULT_MODULES_DIR=""
-CONFIG_DEFAULT_DEPMOD_FILE="modules.dep"
+CONFIG_DEFAULT_DEPMOD_FILE=""

kernel

--- make/linux/configs/avm/config-grx5-7590_07.20	2020-11-01 06:20:37.129906111 +0100
+++ make/linux/configs/avm/config-grx5-7590_07.25	2021-02-16 18:58:32.000000000 +0100
+CONFIG_AVM_PA_SCH_TACK=m
+CONFIG_BLK_DEV_LOOP=m
+CONFIG_BLK_DEV_LOOP_MIN_COUNT=8
+CONFIG_AVM_WATCHDOG_SHIM=y
+CONFIG_WATCHDOG_CORE=y
+CONFIG_GRX500_IAP_WDT=y
+CONFIG_AVM_GRX500_IAP_WDT_NMI=y
+CONFIG_AVM_WATCHDOG_SHIM_SUPPORT=y
+CONFIG_NFS_FS=m
+CONFIG_NFS_V2=m
+CONFIG_NFS_V3=m
+CONFIG_GRACE_PERIOD=m
+CONFIG_LOCKD=m
+CONFIG_LOCKD_V4=y
+CONFIG_NFS_COMMON=y
+CONFIG_SUNRPC=m

Komplett:
busybox.diff.txt
kernel.diff.txt

[fda77]

@PeterPawn liest du noch mit?
Ich hab mir das mit dem HOME mal angeschaut.
Das Verzeichnis /mod/root wird hier gesetzt: https://github.com/Freetz-NG/freetz-ng/blob/master/fwmod#L1098
mod -> var/mod ist ein Link im Dateisystem
/var/mod wird durch das entpacken der var.tar erstellt: https://github.com/Freetz-NG/freetz-ng/blob/master/fwmod#L1085
Daher sollte es das Verzeichnis auch immer geben

@cnbr Du kannst mal versuchen in https://github.com/Freetz-NG/freetz-ng/blob/master/fwmod#L1098 das "/mod/root" durch "/" zu ersetzen
Und wenn es nicht hilft den ganzen Bereich rauswerfen
von https://github.com/Freetz-NG/freetz-ng/blob/master/fwmod#L1084
bis https://github.com/Freetz-NG/freetz-ng/blob/master/fwmod#L1122
(ich find es sehr suspekt dass die 4 .dummy Dateien von AVM gelöscht werden)

Dieser eip137 hat übrigens auch eine "root of trust" Funktion: https://www.chipestimate.com/log.php?from=%2FINSIDE-Secure-Corporation%2FEIP-123%2Fdatasheet%2Fip%2F30754&logerr=1
Vielleicht hilft es auch mal eins oder alle Kernelmodule zu löschen

• build/original/filesystem/lib/modules/4.9.198/extra/eip123_hw.ko
• build/original/filesystem/lib/modules/4.9.198/extra/eip123.ko
• build/original/filesystem/lib/modules/4.9.198/extra/eip97.ko

Die Header/Sourcen dazu gibts in der hwcrypto-Datei im Sourcenpaket von avm

[PeterPawn]

Ja, ab und an lese ich noch mit.

Aber ich habe den Überblick verloren - trifft das nun für alle 7590 mit 07.25 (bzw. der Labor davor) zu oder auch wieder nur für einige?

Ich hätte Ideen, wie man das Problem weiter einkreisen könnte und wo vielleicht die Ursachen für die (unterstellte) unterschiedliche Benutzung von Entropie liegen könnten - aber das ist eigentlich eine längere Geschichte (wenn, will ich sie halt auch so erzählen, daß sie Sinn macht) und mir fehlt im Moment die Zeit dafür.

Ich habe das aber weiterhin auf dem Zettel ... wobei ich noch einmal daran erinnern will, daß die ursprüngliche Annahme, es könnte mit der Crypto-Hardware und Freetz-NG ein Problem geben, gar nicht an dieser Stelle auftauchte (hier ist es wegen der Meldungen in der SerCon ja deutlich), sondern das noch im Kontext des Abschaltens aller AVM-Watchdogs bzw. der Deaktivierung des untrustedd (als weniger drastischer Workaround) als "Gemeinsamkeit" der Boxen mit solchen Problemen als These in den Raum gestellt wurde (iirc war das auch in einem IPPF-Thread).

Ein weiterer Fakt ist es meines Wissens auch, daß dieses Problem offenbar durch Änderungen hervorgerufen wird (wenn es sich nicht doch auf nur wenige Einzelfälle beschränkt, womit wir wieder bei der "Systematik" und dem verlorenen Überblick wären), die für Freetz-NG spezifisch sind (ggf. auch für Freetz wären, aber das wissen wir nicht, weil Freetz 07.2x nicht unterstützt) und es bei anderen Modifikationen (z.B. hier: https://www.ip-phone-forum.de/threads/busybox-mit-telnet-in-fritz-os-7-2x.307385/post-2400543) bisher wohl noch keine Probleme gab.

Daher würde ich hier tatsächlich erst einmal den umgekehrten Weg nehmen (weil es einfacher zu realisieren ist) und Stück für Stück Komponenten aus Freetz in ein "von Hand" modifiziertes Image einbauen, bis das Problem auftritt. Beginnen würde ich mit einer (statisch gelinkten) BusyBox - damit könnte man feststellen, ob die abweichende Version der BusyBox oder die C-Library der BusyBox (aus Freetz-NG) generell daran schuld ist (dann tritt das Problem auch mit dieser BusyBox auf) oder ob es am Ende der dynamische Loader der uClibc-ng ist (AVM nutzt ja musl - ein weiterer Unterschied und m.W. nutzen dann auch die AVM-Bestandteile die BusyBox von Freetz[-NG] und damit die andere C-Library zumindest an einigen Stellen), der da zuviel Entropie "verbraucht" (das könnte z.B. dann der Fall sein, wenn ASLR verwendet werden sollte - ich weiß aber nicht sicher, ob das der Fall ist und müßte mich erst durch die Quellen/Beschreibungen wühlen).

Jedenfalls erscheint es mir (auch angesichts der Stelle, wo das Problem auftritt, denn das ist schon sehr, sehr früh in der Initialisierung des Systems) sinnvoller, nach und nach Änderungen dazuzunehmen, bis das Problem auftaucht, als Stück für Stück Freetz-Änderungen zu entfernen, bis es irgendwann verschwunden ist.

Der Vorschlag, die Routine zum "Warten auf Entropie" mal anzupassen und genauere Infos auszugeben, bleibt davon unberührt ... es wäre nämlich weiterhin interessant zu wissen, ob es (a) überhaupt einen Zuwachs an Entropie gibt oder ob der Hardware-RNG gar nicht arbeitet oder (b) erzeugte Entropie gleich wieder von irgendeinem Prozess "verbraucht" wird, weil da jemand permanent (und mit falscher Implementierung) an /dev/[u]random nuckelt und es daher nie bis zu den erwarteten 112 Byte (bzw. 896 Bit) als "Entropie-Vorrat" kommt, die in der rc.hwcrypto erwartet werden.

[fda77]

Ich hab von keiner 7590 gelesen die erfolgreich bootete, daher gehe ich von allen 7590 mit 7.25 aus. Mein 7490 läuft problemlos mit der neuesten Labor
Stück für Stück Freetz deaktivieren hab ich auch schon überlegt und mir das Verzeichnis https://github.com/Freetz-NG/freetz-ng/tree/master/patches/scripts angeschaut. Da sind schon ein paar suspekte Dinge drin, zb
https://github.com/Freetz-NG/freetz-ng/blob/master/patches/scripts/108-patch_multid-wait.sh
Ursprünglicher commit von 2007: https://trac.boxmatrix.info/freetz-ng/browser/freetz-ng/trunk/patches/110-multid-wait.patch?rev=1415 Vielleicht braucht man den gar nicht mehr ^^

Die AVM Busybox half nicht wie hier zu sehen: #120 (comment)

@cnbr Kannst du dir die Entropie ausgeben lassen wie in #120 (comment)

[cnbr]

Probiere ich die Tage aus, #120 (comment) und auch das mit Entropie und die weitern Tipps von PeterPawn. Welche Module geladen sind könnte auch interessant sein.
Da dann während der Versuche ohne Internet und Telefon der WAF im Haus schlecht wäre, muss ich noch eine Ersatzbox besorgen.

Ob es relevant ist, kann ich nicht beurteilen, bei den Sourcen von AVM ist mir aufgefallen, in der 7.25 kommt Kernel 4.9.198 zum Einsatz, im tar.gz ist linux-headers-4.9.160.

[fda77]

linux-headers-4.9.160.

die sind mir auch aufgefallen, aber egal da

• man für grx5 / 7590 eh keinen replace-kernel auswählen kann
• im Minimalimage keine Kernelmodule eingebaut und geladen werden

[fda77]

Es war doch was mit Busybox. Wenn man sich das Diff oben anschaut sieht man dass modprobe usw nicht mehr enthalten sind. Wenn man sich die Logs oben anschaut sieht man dass manche Module nicht geladen werden. Wenn man ins Image schaut sieht man dass dort nun ein gewisses kmod dies übernimmt (ka was das besser kann). Und wenn man sich das make Log anschaut sieht man dass dort 3 modules*bin Dateien gelöscht werden. kmod mag diese aber!
Also einfach die Schleife https://github.com/Freetz-NG/freetz-ng/blob/master/fwmod#L1442 löschen

Was nicht geht: modprobe von freetz-modulen. die sind nur in der .deb und nicht in der .deb.bin. Vorerst entwerder modprobe-busybox nehmen oder mit insmod den kompletten Pfad (in der richtigen Reihenfolge) aufrufen
Ob man man die .bin erzeugen kann weiss ich nicht, da die avm Module lokal nie gebaut werden. Die .deb wird von Freetz mit https://github.com/Freetz-NG/freetz-ng/blob/master/tools/depmod.pl erstellt

EDIT Da ich fakeroott kaputt gemacht habe, vorerst pseudo verwenden!

a82b193 3d17b82 dd5d730

[freetz-ng-mod]

So meine 7590 lauft nun mit fw 7.25 ohne reboot. Uptime: 6 min

Was mich aber nun sehr wundert ist das ich eine Mail bekommen habe von der Box.

Änderungsnotiz
Diese E-Mail wurde Ihnen von Ihrer FRITZ!Box 7590 (UI) [7590-client] gesendet. Sie enthält Informationen über Änderungen in Ihrer FRITZ!Box oder Ereignisse in Ihrem Heimnetz. | Diese E-Mail wurde Ihnen von Ihrer FRITZ!Box 7590 (UI) [7590-client] gesendet. Sie enthält Informationen über Änderungen in Ihrer FRITZ!Box oder Ereignisse in Ihrem Heimnetz.
Diese E-Mail wurde Ihnen von Ihrer FRITZ!Box 7590 (UI) [7590-client] gesendet. Sie enthält Informationen über Änderungen in Ihrer FRITZ!Box oder Ereignisse in Ihrem Heimnetz.

Der FRITZ!Box-Benutzer "fritz5432" wurde nach dem Update automatisch angelegt. Dieser FRITZ!Box-Benutzer nutzt das FRITZ!Box-Kennwort. Sie können sich weiterhin wie gewohnt mit Ihrem FRITZ!Box-Kennwort an Ihrer FRITZ!Box anmelden.

EDIT: Die Box bleibt zwar online aber nun verliert sie ca alle 2 min die LAN Verbindung, Und die Box Blinkt
Uptime: 20 min

EDIT1: So habe die Box nun mal neu gestartet per Reboot auf der freetz Seite nun mal schauen was passiert

EDIT2: Box ist nun seit über 1h online ohne LAN probs nun

[fda77]

Meine läuft jetzt seit 1 Tag ohne Probleme.
Also ausser denen die AVM mal wieder verursacht hat, wie sich dass sich hinter einem Hybrid Router keine Telekom VOIP Nummern mehr registrieren lassen. Andere Anbieter gehen nach wie vor. Das wurde auch schon an anderer Stelle berichtet

[cnbr]

Bei mir läuft auch nun seit heute morgen auch, den Patch für den Watchdog hatte ich noch deaktiviert, macht scheinbar keine Probleme.

[fda77]

watchdog und untrustedd braucht man nicht mehr, auch mit 7.2x.
Das Problem war dass avm nun kmod ab fos 7.25 verwendet statt BusyBox. Und diese nutzt die modules*bin die Freetz aber immer löschte. Busybox hat die bislang ignoriert. Mit den *bin im image funktioniert kmod, aber auch Busybox (durch kmod-remove).
Ab fos 7.2x gibt es dann noch die libkmod.so. Die "strings" zeigen zwar modules* aber keine *bin. Dennoch funktioniert die 7.2x mit den *bin im image ohne watchdog+untrustedd patches