Fritzbox 6490 Cable Bootloop

[PeterPawn]

Zumindest hat sich ja mit dem Verhindern des Wartens auf den ARM-Core das Timing sehr, sehr deutlich verschoben ... es hat also definitiv eine Auswirkung.

Was ich hier jetzt wieder nicht mehr verstehe ... eigentlich müßte der Watchdog für den Init-Prozess (der nach dem mir vorliegenden Image für die 06.85 auf beiden Cores jeweils 120 Sekunden für "init-start" in "S05-watchdog" setzt) bereits nach 2 Minuten (plus ein paar Sekunden, weil erst irgendwo nach Sekunde 30 die "S05-watchdog" abgearbeitet wird) die Box neu starten ... da sind 4 Minuten schon recht lang - auch wenn früher von AVM dort gerne mal 240 Sekunden gesetzt wurden (bei anderen Modellen/Versionen). Das läßt ja fast vermuten, daß beide Systeme tatsächlich durch ihre "rc.tail.sh" laufen, wo der Watchdog mit "init-done" dann entschärft wird.

Meine Interpretation der LEDs wäre jetzt jedenfalls die, daß irgendeine Synchronisation vor der "S50-lan-sync" ebenfalls ausfällt (auch wenn es da - zumindest als Skript - nur noch eine gibt, die nach dem Zurücksetzen auf Werkseinstellungen oder Recovery wirksam würde - mit dem Tag "FWINFO_up" in der "S01-head") und dadurch das WLAN wenige (zwei) Sekunden früher gestartet wird ... wobei das schon im Rahmen der Meßungenauigkeit liegen dürfte.

Das langsamere Blinken der Power-LED signalisiert ja normalerweise den Start der Initialisierung und dürfte dann einsetzen, wenn das "led_module"-LKM geladen wurde - der Übergang zum "Doppelblinken" zeigt i.d.R. an, daß die Box auf der WAN-Seite am Synchronisieren ist. Ich kann mir auch gut vorstellen, daß das hier gar nichts mit dem tatsächlichen Status auf dem ARM-Core zu tun hat ... vor dem dortigen "S50-lan-sync" würde in "S45-docsis" ja das eCM gestartet und damit kann man wohl beim Erreichen von "S50-lan-sync" auf dem ARM-Core davon ausgehen, daß es auch läuft und - bis es "bereit" ist - sich dann halt auf der Synchronisationssuche befindet. Das würde zumindest das doppelte Blinken ab Sekunde 55 erklären - es ist also denkbar, daß es nur eine Spekulation des ATOM-Cores ist.

Rein theoretisch müßte man doch in dieser Zeit (das LAN wird (vom "dsld") direkt nach dem WLAN gestartet und steht damit kurz nach dem Beginn des Blinkens der WLAN-LED zur Verfügung) in das Menu der Box kommen können, denn auch der "ctlmgr" wird noch vor dem WLAN gestartet.

Hier kann man jetzt vieles versuchen ... vom Umstellen auf "LAN1" (wobei ich nicht weiß, was auf dem ARM-Core vermutlich falsch läuft - auch wenn mein Verdacht in Richtung ARM-Core immer ausgeprägter wird) mit der Hoffnung, daß dann vom ARM kein Reboot kommt, bis zum Versuch, die Werkseinstellungen zu laden (wobei ich mir davon eher weniger verspreche, weil das (wenn man es alles richtig gemacht hat) ja von Hand schon einige Male geschehen ist) oder mit ein wenig Glück und Geschwindigkeit gelingt es ja vielleicht sogar, die Support-Daten abzurufen - man kann die Anmeldung und den Abruf ja auch automatisieren, wenn man von Hand dazu zu lange brauchen würde.

Was weißt Du denn sonst noch von der Box? Hat die bereits ab Werk neue Zertifikate oder wurden die erst nachträglich über "cm_dl_cert" aktualisiert? Das ist u.a. deshalb entscheidend, weil davon abhängt, ob man die "config-space"-Partition einfach löschen kann oder nicht - die Kalibrierungsdaten holt sich die Box schon wieder aus dem Urlader, aber beim Zertifikat geht das nur dann gut, wenn das bereits beim Finalisieren in der Box hinterlegt wurde.

Ob eine Box ohne Zertifikate im Bootloader mit neuer Firmware nicht irgendwann mal die Segel streicht, wenn ihr jemand diese Partition löscht (was hier m.E. bereits zuvor geschehen ist oder es gab einen Fehler im JFFS2, der jetzt dazu führt, daß auch das "Retten" der Zertifikate nicht mehr funktioniert, was ja eine funktionierende Dateisystemstruktur braucht bzw. bei neuer Firmware wird gar nicht mehr versucht, die Partition neu zu formatieren), habe ich noch gar nicht genauer angesehen.

Eigentlich sollte eine Box mit einem Bootloader in Version 1.3272 die Zertifikate lange im Bootloader haben ... aber es gibt ja leider auch immer wieder Leute, die hier irgendwelche "Transplantationen" versuchen oder eben auch mal die "config-space" löschen lassen - ob nun absichtlich oder versehentlich, sei mal dahingestellt.

In jedem Falle muß man jetzt erst einmal ermitteln, wo die Box ihr Problem hat - die Zeit bis zum Reboot sollte dafür ausreichen. Allerdings könnte das mit der originalen Firmware tatsächlich etwas schwierig werden (ein Shell-Zugang ist bei so einer Suche schon extrem hilfreich) und vielleicht sollte man mal darüber nachdenken, ob man sich die Firmware für den ATOM-Core hier nicht doch etwas anpaßt - von dort kann man dann auch mal den Blick auf den ARM-Core wagen, was da tatsächlich läuft und was nicht.

EDIT: Ich habe gerade oben noch einmal nachgelesen ... da schreibst Du, Du hättest "firmware_info" um ",recoverd=2" ergänzt - das ist doch hoffentlich nur ein Tippfehler oder hast Du das tatsächlich genau so geschrieben? Dann wären die ganzen Aktionen, die am "Recover_was_here" hängen, gar nicht erst ausgeführt worden und die Unterschiede im Timing würden nur darauf beruhen, daß die Standardeinstellungen im TFFS erst einmal hergestellt wurden in "S12-defaults", weil die davon abhängig sind, ob sie existieren und nicht davon, was da in "firmware_info" steht.

Wobei ich gerade mal gesehen habe, daß AVM bei der 6490 (141.06.85) tatsächlich Vorkehrungen getroffen hat, damit eine MTD-Partition mit dem Namen "nand-swap" als Swap-Device eingebunden wird ... das muß dann aber ein Modell mit einem deutlich größeren NAND-Flash sein, denn die 6490 hat ja gar keinen (nur SPI + eMMC) und die 6590 m.W. auch nicht (nur den doppelten eMMC-Speicher). Da das Suchen nach diesem Partition-Namen aber über "/proc/mtd" erfolgt, dürfte das keine Partition auf dem "mmc"-Treiber (Major 179) sein, denn die werden dort eigentlich nicht eingeschlossen. Mal schauen, was die 6591 an Überraschungen in dieser Hinsicht bereithält ...

 

[f666]

Falls die Zertifikate im Bootloader sind, müsste ein "retr CONF" (oder "retr CONFIG", weiß ich gerade nicht) diese liefern.
In der Datei nach der gz Signatur suchen, auftrennen, entpacken und mit OpenSSL reinschauen.

 

[PeterPawn]

Die zweite Variante ist die richtige: https://www.ip-phone-forum.de/threa...e-firmware-update.286994/page-10#post-2175794 - nachdem es endlich mal jemand anderes wieder hervorgekramt hat (ich wollte absichtlich nicht weiter darauf eingehen und habe das Thema nach diesem einen Beitrag aus dem August 2016 mit Vorbedacht ruhen lassen), kann man ja vielleicht auch mal ein kleines Skript basteln, welches das Vorhandensein der neuen Zertifikate im Bootloader automatisch ermittelt ... das wäre ja auch zum "Identifizieren" von Geräten, bei denen sich der Aufwand noch lohnt, durchaus nützlich.

Dazu muß man nicht mal direkt in das Zertifikat schauen ... schon die Existenz des passenden Payloads (neben WLAN-, DECT- und DOCSIS-Kalibrierung, die andere IDs haben) zeigt an, daß die Zertifikate bereits bei der Produktion hinterlegt wurden im Bootloader.

 

[ice012345]

Rein theoretisch müßte man doch in dieser Zeit (das LAN wird (vom "dsld") direkt nach dem WLAN gestartet und steht damit kurz nach dem Beginn des Blinkens der WLAN-LED zur Verfügung) in das Menu der Box kommen können, denn auch der "ctlmgr" wird noch vor dem WLAN gestartet.

Ja hatte ich ja schon geschrieben, wenn ich schnell genug die 192.168.178.1 aktuallisiere komme ich machmal rein. Das klappt aber nicht immer, trotz das ich die Netzwerkkarte manuell auf 192.168.178.20, subnetz 255.255.255.0, gateway 192.168.178.1 eingestellt habe.

EDIT: Ich habe gerade oben noch einmal nachgelesen ... da schreibst Du, Du hättest "firmware_info" um ",recoverd=2" ergänzt - das ist doch hoffentlich nur ein Tippfehler oder hast Du das tatsächlich genau so geschrieben? Dann wären die ganzen Aktionen, die am "Recover_was_here" hängen, gar nicht erst ausgeführt worden und die Unterschiede im Timing würden nur darauf beruhen, daß die Standardeinstellungen im TFFS erst einmal hergestellt wurden in "S12-defaults", weil die davon abhängig sind, ob sie existieren und nicht davon, was da in "firmware_info" steht.

Ja ist eine Tipfehler. Ich habe "quote SETENV firmware_info 141.06.85,recovered=2" getippt.

Was weißt Du denn sonst noch von der Box? Hat die bereits ab Werk neue Zertifikate oder wurden die erst nachträglich über "cm_dl_cert" aktualisiert? Das ist u.a. deshalb entscheidend, weil davon abhängt, ob man die "config-space"-Partition einfach löschen kann oder nicht - die Kalibrierungsdaten holt sich die Box schon wieder aus dem Urlader, aber beim Zertifikat geht das nur dann gut, wenn das bereits beim Finalisieren in der Box hinterlegt wurde.

Die Box hat J383 Seriennummer und ist neu.
Ausgeliefert mit auf linux_fs_start 0 die firmware_version kdg und firmware_info 141.06.50. linux_fs_start 1 war leer.

 

[PeterPawn]

Ja hatte ich ja schon geschrieben, wenn ich schnell genug die 192.168.178.1 aktuallisiere komme ich machmal rein. Das klappt aber nicht immer, trotz das ich die Netzwerkkarte manuell auf 192.168.178.20, subnetz 255.255.255.0, gateway 192.168.178.1 eingestellt habe.

Das hattest Du aber bereits für den Fall beschrieben, daß die Box nach 75 oder 90 Sekunden neu startet ... wenn das jetzt bis zu vier Minuten dauert, hast Du ja weit mehr als die doppelte Zeit zur Verfügung und es dürfte gar kein Problem mehr sein, sich sogar bis zum ARM-Core vorzuarbeiten oder die Daten vom letzten Crash auszulesen.

Wenn wirklich eine defekte NVRAM-DB die Ursache für die Probleme auf dem ARM-Core sein sollte (ich würde das zuerst versuchen zu ermitteln, bevor man an irgendeinem angenommenen Symptom herumdoktert und das war es dann am Ende doch nicht - hier gibt es auch keinen wirklichen Weg zurück), dann könnte eben das Neuinitialisieren der "config-space"-Partition eine Lösung sein.

Dazu braucht es entweder eine Firmware für den ARM-Core, die auf "CONFIG_C4" keine Rücksicht nimmt bzw. in der die "docsisfactorydefaults" fehlt und die daher auch mal diese Partition über "/proc/mtd" löscht oder man erstellt sich selbst ein leeres JFFS2-Image und läßt das über den Bootloader in die Partition schreiben.

Wie man sich ein solches JFFS2-Image auf einem System mit "mtdram"- und "jffs2"-Support erstellen kann, wenn man die Gesamtgröße (der Partition) und die "erase size" des verwendeten Flashs kennt, habe ich in einem Skript (https://github.com/PeterPawn/YourFritz/blob/master/eva_tools/prepare_jffs2_image) mal gezeigt ... das Auspacken irgendwelcher TAR-Files als "Start-Inhalt" für das Image ist natürlich komplett optional und auch das Ermitteln der passenden Größenangaben muß man ja nicht automatisch machen lassen.

Wie schon einmal geschrieben ... welche Probleme sich auf dem ARM-Core jetzt wirklich ergeben (das Hinausschieben des Neustarts - durch Übergehen des Wartens auf die Synchronisation - ist für mich schon ein ziemlich deutliches Zeichen, daß irgendetwas auf dem ARM-Core vermutlich nicht stimmt), kannst Du nur selbst einschätzen - denn Du bist der Einzige, der die Historie des Problems wirklich kennt und genau weiß, was er vor dem Auftreten des Problems im Einzelnen angestellt hat.

So etwas tritt ja im Allgemeinen nicht plötzlich und von alleine auf ... wenn da eine Chance besteht, daß das JFFS2 in "/nvram" zerwürgt sein kann (neuere Firmware würde dort eben nicht mehr automatisch Fehler beheben, um ggf. im Download erlangte Zertifikate dabei nicht auch gleich zu vernichten), dann wäre das zumindest eine mögliche Erklärung, warum das eCM nicht richtig arbeiten will ... wenn das wirklich die Ursache des Neustarts ist - aber innerhalb von 2,5 zusätzlichen Minuten müßten sich sogar die letzten Crash-Logs noch auslesen lassen, so daß man gar nicht mehr spekulieren muß - ansonsten bleibt immer noch die Serielle als "last resort".

 

[ice012345]

Das hattest Du aber bereits für den Fall beschrieben, daß die Box nach 75 oder 90 Sekunden neu startet ... wenn das jetzt bis zu vier Minuten dauert, hast Du ja weit mehr als die doppelte Zeit zur Verfügung und es dürfte gar kein Problem mehr sein, sich sogar bis zum ARM-Core vorzuarbeiten oder die Daten vom letzten Crash auszulesen.

Ja die Zeit ist länger gewesen und obwohl ich auch ganze zeit die Box in diese zusätzlichen 2,5 Minuten an pingen konnte ist der WebUI nicht erreichbar gewesen. Auf "ftp 192.168.178.1" kam auch keine Antwort.

Wie schon einmal geschrieben ... welche Probleme sich auf dem ARM-Core jetzt wirklich ergeben (das Hinausschieben des Neustarts - durch Übergehen des Wartens auf die Synchronisation - ist für mich schon ein ziemlich deutliches Zeichen, daß irgendetwas auf dem ARM-Core vermutlich nicht stimmt), kannst Du nur selbst einschätzen - denn Du bist der Einzige, der die Historie des Problems wirklich kennt und genau weiß, was er vor dem Auftreten des Problems im Einzelnen angestellt hat.

Box war Neu mit der erwähte kdg 6.50 firmware.
Ich habe die avm 6.85 firmware per ftp auf:
mtd11 filesystem.image ARM
mtd12 kernel.image ARM
lcd x86
mtd13 filesystem.image ATOM
mtd14 kernel.image ATOM
geflasht und mit "quote SETENV linux_fs_start 1" und "quote SETENV firmware_version avm" geändert.
Neustart der box.
Fritzbox ist ganz normal hochgefahren. Habe mir erweiterte support daten geholt, cert kontrolliert(das hatte ich auch schon mit kdg 6.50 firmware schon gemacht) NEW/NEW.
Box über Menü ein Werkseinstellung durchführen lassen.
Fritzbox startet und dann habe ich wieder über die menü per Firmwardatei auf 6.87 Update gestartet. Die Info LED fing an zu blinken ich ging zu kleine Jungs als ich wieder da war Bootloop.
Habe gedacht O.K kein problem umschalten auf linux_fs_start 1 damit es mit 6.85 startet, leider immer noch bootloop. Wieso auch immer. Neue tffs-image von meinem erweiterten support erstellt und auf mtd3,mtd4 geschrieben, immer noch bootloop.
Danach habe ich im Forum hilfe gesucht

Dazu braucht es entweder eine Firmware für den ARM-Core, die auf "CONFIG_C4" keine Rücksicht nimmt bzw. in der die "docsisfactorydefaults" fehlt und die daher auch mal diese Partition über "/proc/mtd" löscht oder man erstellt sich selbst ein leeres JFFS2-Image und läßt das über den Bootloader in die Partition schreiben.

Wie man sich ein solches JFFS2-Image auf einem System mit "mtdram"- und "jffs2"-Support erstellen kann, wenn man die Gesamtgröße (der Partition) und die "erase size" des verwendeten Flashs kennt, habe ich in einem Skript (https://github.com/PeterPawn/YourFritz/blob/master/eva_tools/prepare_jffs2_image) mal gezeigt ... das Auspacken irgendwelcher TAR-Files als "Start-Inhalt" für das Image ist natürlich komplett optional und auch das Ermitteln der passenden Größenangaben muß man ja nicht automatisch machen lassen.

Da komme ich leider nicht mehr mit. Welche Partition ist es, mtd? erase-size weiß ich auch nicht.
Ich bin über jeder lesematerial dankbar wo mich in die Richtung stößt. Per suche im Forum habe ich mal jetzt nichts gefunden wo mir in der Richtung eventuell helfen könnte.

 

[PeterPawn]

War denn die Box beim allerersten Bootloop nun auf "linux_fs_start=0"? Wenn ja, wäre das ein Zeichen dafür, daß der Flash-Vorgang der 06.87 korrekt abgeschlossen wurde - ansonsten (wenn da immer noch "1" stand), wäre das ja mehr oder weniger ein Bootloop noch mit der 06.85 im zweiten Satz von Partitionen gewesen, weil das Update eben nicht richtig lief.

Wobei ich auch noch nichts davon gelesen habe, daß ein mißglücktes Update auf 06.87 die Box im Anschluß in eine Schleife schickt ... paßt auch nur schlecht zum Inhalt der "/var/install" im 06.87-Image. Da hat sich ggü. der 06.85 nichts am Ablauf geändert und die Umschaltung auf die anderen Partitionen ist immer noch die letzte Aktion im Rahmen so eines Updates (das steht ja auch alles hinter den originalen Kommandos in der "/var/post_install" und da kann dann praktisch nichts mehr kommen, was dort noch etwas ändert).

Was ich auch nicht verstehen kann ... warum hast Du die Box dann nicht gleich auf 06.87 aktualisiert, wenn Du das nicht zum ersten Mal gemacht hast? Was war der Grund dafür, daß Du da erst eine 06.85 installiert hast?

Was ich aber überhaupt nicht verstehe (ja, es steigert sich langsam), ist die Feststellung, daß Du die Box nicht bereits direkt nach dem Start des WLANs (der "ctlmgr" startet eben noch davor und der "dsld" unmittelbar danach und der richtet dann die LAN-Interfaces mit ein anhand der Einstellungen in der "ar7.cfg") über ihr GUI erreichen kannst ... das ergibt irgendwie gar keinen Sinn für mich. Vor allem dieses erratische Verhalten, wo es mal funktionieren soll und mal nicht - daß der FTP-Server nicht erreichbar ist, verwundert mich hingegen wieder überhaupt nicht. Der wird während des Startvorgangs einige Male umkonfiguriert (bei jedem Mounten irgendeines Volumes) und braucht außerdem den - erst in "S75-inetd" gestarteten - "inetd" als Basis. Der FTP-Server ist also als Indikator ziemlich untauglich ... ich bin nicht mal sicher, daß der bei der 06.85 per Default aktiviert wird, zumal der dann ja jedes Volume erst einmal ohne jede Beschränkung im LAN bereitstellen würde (solange die Benutzerverwaltung nicht umkonfiguriert wird). Nicht umsonst muß der ja bei neuerer Firmware erst einmal eingeschaltet werden ... ob das bei 06.85 oder 06.87 bei der 6490 auch schon so ist, weiß ich aber nicht (und werde ich meinerseits nicht austesten).

Unverständlicher ist es da schon, warum der USB-Stack nicht in die Gänge kommt und die Volumes (oder "das") nicht mountet ... spätestens bei der Suche nach TR-069-Einstellungen auf einem USB-Volume müßte die Controller-LED eines angesprochenen Sticks (die auch Lesezugriffe tatsächlich mit anzeigt, darauf habe ich oben ja schon hingewiesen) blinken wie ein Weihnachtsbaum. Wenn das nicht geschieht, wird es wieder noch mysteriöser ... es gibt ja absolut nichts, was zwischen dem Warten auf Sychronisation mit dem ARM-Core und dem Start des USB-Stacks noch geschehen würde. Wenn jetzt also nicht mehr gewartet wird (das verbuche ich mal aus dem geänderten Timing als Erfolg von "no_core_sync" in den "kernel_args"), was hält das System dann davon ab, die USB-Geräte zu starten?

Egal ... jetzt erst mal wieder auf "Los" und eine gültige oder auch keine "wlan.cfg" in das Image packen und anschließend - nach dem nächsten Start bis zum Bootloader und dem erneuten Setzen von "no_core_sync" - noch (mind.) einmal versuchen, auf das GUI zu kommen bzw. den USB-Stick genau beobachten. Irgendetwas muß ja nun anders sein - die Box wird ja nach dem Verzicht auf das Warten auf den ARM-Core jetzt nicht plötzlich gar nichts mehr machen.

Warum Du dann beim "leeren JFFS2-Image" nicht mehr mitkommst, verstehe ich ebenfalls nicht ... ich denke, Du hast eine zweite Box? Da findest Du dann in den Support-Daten problemlos die Nummer und die Größe des MTD für "config-space" (anhand der Größe findet man dann auch die richtige Nummer beim Zugriff über den Bootloader) und die "erase-size" ist - wie bei den anderen Partitionen im SPI der 6490 auch - halt 4KB. Aber noch einmal deutlich ... das würde ich erst dann in Angriff nehmen, wenn ich sicher wüßte, daß es tatsächlich ein Problem im "/nvram" auf dem ARM-Core gibt und die aktuellen Anstrengungen sollten sich jetzt erst einmal darauf richten, die Ursache des Problems einzukreisen ... erst dann muß man sich Gedanken um dessen Beseitigung machen.

Also gilt es erst einmal die Frage zu klären, ob das Verhalten der Box beim GUI-Zugriff jetzt wirklich so unvorhersehbar ist, wie Du es beschreibst oder ob das nicht am Ende nur Fehler in der Handhabung sind ... daher das "zurück auf 'Los' ...", weil inzwischen wohl eher wieder ein undefinierter Zustand erreicht wurde.

Reagiert die Box jedenfalls nicht auf LAN-Zugriffe und auch die USB-Devices werden nicht initialisiert, weiß ich auch nicht mehr weiter ... dann hält der ATOM-Core vermutlich einfach den ATEM an, bis er blau anläuft und umkippt, woraufhin dann die Box neu startet - das ist als Erklärung genauso logisch wie jede andere Vermutung, was da zwischen "S50-lan-sync" und "S55-usb" noch geschehen könnte.

 

[ice012345]

War denn die Box beim allerersten Bootloop nun auf "linux_fs_start=0"? Wenn ja, wäre das ein Zeichen dafür, daß der Flash-Vorgang der 06.87 korrekt abgeschlossen wurde - ansonsten (wenn da immer noch "1" stand), wäre das ja mehr oder weniger ein Bootloop noch mit der 06.85 im zweiten Satz von Partitionen gewesen, weil das Update eben nicht richtig lief.

Das weiß ich nicht mehr 100%, in meinem kopf gehts drunter und drüber.

Was ich auch nicht verstehen kann ... warum hast Du die Box dann nicht gleich auf 06.87 aktualisiert, wenn Du das nicht zum ersten Mal gemacht hast? Was war der Grund dafür, daß Du da erst eine 06.85 installiert hast?

Ganz einfach um einen Manuellen oder per Internet Update anstoßen zu können. Das ich zum schluß weiß, das auch dies funktioniert nach debranding. Habe auch nie probleme damit gehabt, naja bis jetzt halt.

Unverständlicher ist es da schon, warum der USB-Stack nicht in die Gänge kommt und die Volumes (oder "das") nicht mountet ... spätestens bei der Suche nach TR-069-Einstellungen auf einem USB-Volume müßte die Controller-LED eines angesprochenen Sticks (die auch Lesezugriffe tatsächlich mit anzeigt, darauf habe ich oben ja schon hingewiesen) blinken wie ein Weihnachtsbaum.

Ja der USB-Stick leuchtet sofort los wenn ich Ihn an meine PC oder Laptop stecke.

Sonst kam ich Heute nicht viel weiter, Sonntag=Familietag.

 

[ice012345]

Egal ... jetzt erst mal wieder auf "Los" und eine gültige oder auch keine "wlan.cfg" in das Image packen und anschließend - nach dem nächsten Start bis zum Bootloader und dem erneuten Setzen von "no_core_sync" - noch (mind.) einmal versuchen, auf das GUI zu kommen bzw. den USB-Stick genau beobachten. Irgendetwas muß ja nun anders sein - die Box wird ja nach dem Verzicht auf das Warten auf den ARM-Core jetzt nicht plötzlich gar nichts mehr machen.

Nach dem ich jetzt mehrmals probiert habe, einen tffs image mit gepackte wlan.cfg(habe auch ohne wlan.cfg probiert) zu erstellen musste ich feststellen das ich sie mit dissect_tffs_dump nicht zerlegen konnte.Immer kam "unexpected error reading TFFS dump".
Dann habe ich es statt auf win10 mit bash auf VM-Server mit ubuntu"freetz-linux" probiert, siehe da jetzt klappte auch das zerlegen ohne Fehler.
Ich habe also eine tffs-image mit wlan.cfg erstellt, danach zerlegt und gegen kontrolliert. 0073.bin(gepackte) und 0073.inflated(ungepackte gleich wie wlan.cfg) sind mit im image.
Also ab auf die Box mit der Image. Trotzdem wurde wlan immmer wieder gestartet. Nach mehrmaligen versuch habe ich es mal mit eine alte 6490 (mit old/old certs) mit bootloaderVersion 1.2279 versucht (natürlich mit seine eigene daten) hier klappte es sofort, Box startete hoch WLAN LED blieb aus.
Zu gegen vergleich habe ich es diesmal mit meine andere (identische) 6490(New/New certs) mit dem selben bootloaderVersion 1.3272 probiert (auch hier natürlich mit seine eigen daten). Bei diese Box hat allerdings die WLAN LED genau 4X geblinkt beim starten danach blieb sie aus. Im WebUI dann konnte man sehen das WLAN abgeschaltet war.

Also gilt es erst einmal die Frage zu klären, ob das Verhalten der Box beim GUI-Zugriff jetzt wirklich so unvorhersehbar ist, wie Du es beschreibst oder ob das nicht am Ende nur Fehler in der Handhabung sind ... daher das "zurück auf 'Los' ...", weil inzwischen wohl eher wieder ein undefinierter Zustand erreicht wurde.

Ich konnte zu keine zeit auf WebUI zugreifen(trotz das ich die 192.168.178.1 anpingen konnte bis zum Neustart)
Ich habe auch nach dem ich das Neu tffs-image geflasht und keine erfolg hatte auf WebUI zu kommen wieder no_core_sync=1 probiert. Auch keine WebUI zugriff.


Beobachtungen LED zeiten:

Spoiler: tffs-image + no_core_sync=1

=>Alle LEDS kurz aufgeleuchtet
=>Power LED blinkt(ca. in sekundentakt)
=>Sekunde 15 Power LED dauer an
=>Sekunde 32 Power LED blinkt(ca. in Sekundentakt)
=>Sekunde 52 POWER LED doppel blinken
=>Sekunde 62 POWER LED blinkt
=>Sekunde 98 WLAN LED blinkt dazu (etwas schneller wie Sekundentakt 3 mal)
=>Sekunde 100 WLAN und POWER LED leuchtet
=>Sekunde 115 WLAN und POWER LED aus
=>Sekunde 118 Neustart

Spoiler: Nur tffs-image

=>Alle LEDS kurz aufgeleuchtet
=>Power LED blinkt(ca. in sekundentakt)
=>Sekunde 15 Power LED dauer an
=>Sekunde 32 Power LED blinkt(ca. in Sekundentakt)
=>Sekunde 48 WLAN LED blinkt dazu (etwas schneller wie Sekundentakt 15 mal)
=>Sekunde 54 Power LED doppel blinken
=>Sekunde 63 POWER LED blinkt WLAN leuchtet
=>Sekunde 70 Neustart

Spoiler: nach tffs-image 1x gebootet und danach no_core_sync=1

=>Alle LEDS kurz aufgeleuchtet
=>Power LED blinkt(ca. in sekundentakt)
=>Sekunde 15 Power LED dauer an
=>Sekunde 30 Power LED blinkt(ca. in Sekundentakt)
=>Sekunde 48 WLAN LED blinkt dazu (etwas schneller wie Sekundentakt 15 mal)
=>Sekunde 54 Power LED doppel blinken
=>Sekunde 60 POWER LED leuchtet WLAN aus
=>Sekunde 63 POWER LED aus WLAN leuchtet
=>Sekunde 70 Neustart

 

[robert_s]

Liegt nicht allmählich die Vermutung nahe, dass die besagte 6490 schlichtweg einen Hardwaredefekt entwickelt hat? Dann könntest Du es bis zum St. Nimmerleinstag mit tffs-Images versuchen...

 

[ice012345]

@robert_s Natürlich kann man das Vermuten, aber die Box ist Neu und hatte bis zum Update einwandfrei funktioniert, es wäre nicht Logisch das es jetzt einen Hardware defekt hat.

 

[PeterPawn]

Selbst wenn es ein Hardware-Defekt ist, sollte sich die betroffene Komponente ja isolieren oder zumindest bestimmen lassen.

An der Box ist ohnehin nichts mehr zu zerstören und da wohl auch ein Gewährleistungstausch kaum in Frage kommt (ansonsten kann man den tatsächlich versuchen und notfalls einfach eine 06.50 in die Partitionen flashen), gibt es auch - m.E. - keinen Grund, die Flinte ins Korn zu werfen .. und sei es nur aus "wissenschaftlichem Interesse", denn wo könnte man besser Wissen schaffen als anhand eines Patienten, der ohnehin nicht mehr zu retten ist nach eigener Ansicht. Die Anatomie-Ausbildung in der Medizin mittels Sektionen erfolgt ja nach ähnlichen Prinzipien - vielleicht hat diese 6490 ja ihren Körper auch der Wissenschaft vermachen wollen.

===============================================

In Anbetracht der zweiten vorhandenen FRITZ!Box mit identischer Hardware würde ich jetzt folgende zwei Schritte in Angriff nehmen:

1. Die andere Box auf "LAN1" konfigurieren, damit das CM so wenig wie möglich zu tun kriegt und deren "ar7.cfg" (die sollte reichen) auf die nicht funktionierende Box "transplantieren". M.E. sollte da keine MAC-Adresse o.ä. in der "ar7.cfg" auftauchen - solange die weder am Kabel noch am LAN hängt (mit identischem LAN-Segment), sollte so eine Transplantation folgenlos bleiben und gleichzeitig sicherstellen, daß die notwendigen Einstellungen für den LAN1-Modus in der "ar7.cfg" komplett und richtig sind.

2. Das WLAN mal über "CONFIG_WLAN=n" in der "featovl.cfg" deaktivieren ... das ist am Ende dasselbe, was der Provider auch machen könnte/würde, wenn er über PACM das WLAN abschaltet. Solange das eCM gar nicht in Benutzung ist (ein weiterer Grund, warum LAN1-Modus einen Versuch wert ist), sollte auch kein nachfolgender Aufruf von "boxfeaturedisable" zusätzlich an der "featovl.cfg" herumändern wollen.

Die "featovl.cfg" kriegt man wieder genauso ins Image, wie eine eigene "wlan.cfg", die ich hier dann aber weglassen würde. Die "ar7.cfg" (aus der anderen Box) kommt genauso ins Image. Es gibt auch noch die Möglichkeit, das eCM so richtig abzuschalten (allerdings auch hier nur die Intel-Services und nicht den gesamten ARM-Core - jedenfalls beim Einsatz originaler Firmware) - kämen wir ggf. später drauf zurück, wenn sicher ist, daß ein Reboot vom ARM ausgelöst wird.

Sichere Dir mal mit "RETR CONFIG" im Bootloader (z.B. durch Einsatz von "eva_get_environment CONFIG") noch die Konfigurationsdaten aus der nichtfunktionierenden 6490 (sollten mehr als 32 KB binär sein) ... reine Vorsichtsmaßnahme, man weiß ja nie, wozu man das noch mal brauchen könnte. Wenn ein alter Dump des Bootloaders existieren sollte, wäre das noch besser (als Zusatz) ... auch darauf kann man später noch einmal eingehen und das ggf. mit dem Ergebnis des "RETR CONFIG" vergleichen.

Ich würde auch mal den LAN-Port wechseln ... der Bootloader und das gestartete System könnten die durchaus unterschiedlich initialisieren und vielleicht liegt das Connection-Problem bei der Verwendung von "no_core_sync" auch tatsächlich an einem nicht mehr 100% funktionierenden LAN-Port, der sich nur im FRITZ!OS und nicht im Bootloader bemerkbar macht (der Bootloader aktiviert m.W. keine GbE-Funktion für den Port).

Auf keinen Fall würde ich die Box jedenfalls entsorgen ... selbst wenn es mit originaler Firmware (und ohne UART-Zugriff) vielleicht etwas schwerer ist, das Problem einzugrenzen, stehen diese Möglichkeiten (sowohl das Bestücken der Seriellen als auch die Verwendung einer modifizierten Firmware, die nur noch "Rumpffunktionen" startet und sehr frühen Shell-Zugriff erlaubt) ja immer noch im Raum und selbst wenn man einen Hardware-Defekt unterstellen will, kann man - je nach betroffener Komponente - damit häufig genug immer noch etwas anfangen.

===============================================

Ich habe noch einmal etwas in den Update-Prozess hineingeschaut in der Hoffnung, eine mögliche Ursache für eine solche Schleife zu entdecken ... aber nicht wirklich etwas gefunden. Da ich aber nicht genau weiß, ob der Update-Prozess (der sich bei den DOCSIS-Boxen ja nicht nur wegen der zusätzlichen Dateien anders gestaltet als bei den anderen Modellen) schon mal "beschrieben" wurde, mache ich das hier mal schnell, indem ich die Unterschiede zu den DSL-Boxen aufzeige.

Während bei den anderen Modellen die Installation neuer Firmware tatsächlich bis zum nächsten Neustart verzögert wird (weil die Kommandos, welche wirklich Änderungen am System vornehmen, an die "/var/post_install" am Ende angefügt werden), ist das bei den DOCSIS-Boxen (ich unterstelle einfach mal, daß die 6590 genauso arbeitet, auch wenn ich das jetzt nicht noch einmal geprüft habe) so, daß unmittelbar bei der Ausführung der "/var/install" bereits die neuen Dateien geschrieben werden.

Deshalb ist hier ein "Hook" in der "/var/post_install" (sie stammt ja aus dem "alten" System) auch schon zu spät dran, wenn er eine zu installierende Firmware vor dem Schreiben noch einmal abändern will - er müßte den Schreibvorgang also komplett wiederholen, nachdem die Firmware angepaßt wurde und vor den Aufruf der "/var/install" kann man sich auch nicht wirklich klemmen (um die Firmware schon vor dem ersten Schreibvorgang zu ändern), solange man ein originales Firmware-Image verwendet, was eine intakte Signatur haben muß (was die Änderung der "/var/install" unmöglich macht oder man braucht einen eigenen Key auf der Box).

Da unmittelbar nach dem Schreiben die Einstellung von "linux_fs_start" auch schon geändert wird, ist das also ebenfalls noch vor der Abarbeitung der "/var/post_install" bereits geschehen ... auch das muß man berücksichtigen, wenn man noch weitere manuelle Änderungen an irgendwelchen Einstellungen vornehmen will. Ein "Abbruch" der "/var/post_install" (z.B. durch Steckerziehen) wäre auch schon zu spät, um die Änderung von "linux_fs_start" noch zu verhindern.

Seit der 06.83 packt AVM auch das Programm zum Download eines neuen Zertifikats (cm_dl_cert) nicht mehr mit in das Update-Image und auch der Inhalt der "ewnw_check_install" (die wiederum die "/var/docsiscertdefaults" aufrufen würde, mit der schon vor dem Neustart das Zertifikat vom Urlader in die "config-space"-Partition befördert würde) ist deutlich geändert ... läuft das "install"-Skript nicht auf dem ARM-Core (anhand von "CONFIG_DOCSIS={y|n}" wird das entschieden), werden die beiden Skripte auch nicht aufgerufen - damit passiert das letztmalig beim Update von einer Version vor 06.83 (ich betrachte jetzt nur mal die Retail-Firmware), wo das laufende FRITZ!OS noch auch dem ARM-Core zu finden ist. Danach läuft auch das "/var/install"-Skript wieder auf dem ATOM-Core und die beiden Skript-Dateien sind komplett aus dem Spiel.

Damit wird eigentlich bei einem solchen Update (von 06.8x aus) auch das Dateisystem in "/nvram" gar nicht mehr angefaßt - das war der eigentliche Punkt, den ich hier noch einmal überprüfen wollte, weil ich ja irgendwo auch einen Fehler in der "config-space"-Partition vermute bei dem letzten Patienten hier.

Aber anders als bei anderen Modellen fügt AVM bei der 6490 anstelle der Kommandos zum Installieren der neuen Firmware-Dateien dann eine Reaktivierung eines Watchdogs an (nachdem zuvor alle noch bestehenden Watchdogs deaktiviert wurden, wie bei allen anderen Modellen auch), die der Firmware von diesem Punkt an nur noch 20 Sekunden Zeit gibt, bis das System zwangsweise neu gestartet wird.

Parallel dazu werden aber an das Ende der "/var/post_install" noch vier zusätzliche Kommandos geschrieben, mit denen das Crash- und das Panic-Logfile für beide Kerne (TFFS-Minors 93 bis 96) gelöscht werden sollen - zusätzlich zu einem direkt in der "/var/install" auszuführenden Löschen für Minor 95 und 96 (was bei Boxen mit nur einem System halt Panic- und Crash-Log wäre).

Ich müßte zwar erst noch einmal durch die TFFS-Quellen krauchen, aber es gibt im TFFS-Treiber zwei Besonderheiten ... er verwendet einen asynchronen Ablauf, um solche Schreibzugriffe tatsächlich auszuführen (der vermutlich vor dem tatsächlichen Shutdown auch noch ein Signal erhält, jetzt noch verbleibende Änderungen endlich zu schreiben) und er kennt zumindest die Überprüfung des Füllstands eines TFFS-Images und eine automatische Konsolidierung, wenn dieser ein gewisses Level überschreitet ... das kann sogar dadurch auftreten, daß dort Daten "gelöscht" werden, denn diese Löschen erfolgt praktisch durch Schreiben eines neuen Eintrags mit Datenlänge 0 für die Datei an das Ende der vorhandenen Daten.

Ich könnte mir durchaus vorstellen, daß ein solche noch laufende Konsolidierung zu einem ungünstigen Zeitpunkt den tatsächlichen Neustart so weit verzögern kann, daß der Watchdog für die 20 Sekunden zuschlägt und das System auch dann neu startet, wenn eine solche Konsolidierung gerade noch läuft. Nun soll das TFFS zwar soweit "transaktionssicher" sein, daß immer mind. eine gültige Kopie der Einstellungen noch vorhanden ist (beim Konsolidieren wird natürlich die Partition im SPI-Flash gelöscht mittels "erase") - aber angesichts der ganzen Änderungen im TFFS-Driver (die beim Puma6 noch einmal "speziell" sind, weil dort beide Systeme auf das TFFS zugreifen wollen und das wohl als "Client-Server-Konzept" realisiert wurde, bei dem ein Kern den Hut aufhat) ist das auch nicht mehr wirklich "langzeitstabiler" und gut getesteter Code (einige erinnern sich vielleicht noch an das plötzliche "Vergessen" aller Einstellungen in der Labor-Reihe vor der 06.50 mit dem Umstieg auf den Kernel 3.10.73) und halte ich einen unentdeckten Bug, der unter ungünstigen und eher seltenen Umständen gerade beim Firmware-Update für das Zerstören der vorhandenen Einstellungen sorgt (und dann natürlich inkl. Environment, womit ein Loop fast vorprogrammiert ist), nicht für ausgeschlossen.

Das wäre dann hier "Pech gehabt" gewesen und man sollte daraus vielleicht (aus reiner Vorsicht) die Empfehlung ableiten, vor einem solchen Update einfach noch einmal die Werkseinstellungen zu laden ... dabei wird dann auch die Konsolidierung des vorhandenen Inhalts im TFFS angestoßen (durch Schreiben von "cleanup" nach "/proc/tffs" in "setfactorydefaults") und es sollte beim anschließenden Update eigentlich nicht erneut zum Konsolidieren kommen.

Um Mißverständnisse zu vermeiden ... das oben Geschriebene zum Ablauf ist "geprüft" (nach bestem Wissen und Gewissen) anhand des Inhalts von Skript-Dateien. Die Möglichkeit, daß es zum unpassenden Zeitpunkt eine Konsolidierung im TFFS-Treiber geben könnte und die vielleicht vom Watchdog unterbrochen wird (der ist eben auch eine Besonderheit beim Update der Puma-Firmware), ist nur reine Theorie und braucht erst einmal die Überprüfung anhand der Quellen des TFFS3-Treibers von AVM in der betroffenen Firmware (des Ausgangssystems, weil natürlich dafür noch der "alte" TFFS-Treiber zuständig ist und nicht der aus dem Kernel im Update).

Wenn die Vermutung aber stimmen sollte, kann das jederzeit auch mit einer "offiziellen" Retail-Box geschehen ... das wäre ja nur von einem ungünstigen Füllstand und Inhalt des TFFS zum Zeitpunkt des Updates abhängig (wobei ich nicht einmal mehr weiß, ob der neue TFFS-Driver beim "clear_id" auf weitere Schreibzugriffe verzichtet, wenn die Daten ohnehin schon gelöscht sind).

 

[ice012345]

2. Das WLAN mal über "CONFIG_WLAN=n" in der "featovl.cfg" deaktivieren ... das ist am Ende dasselbe, was der Provider auch machen könnte/würde, wenn er über PACM das WLAN abschaltet. Solange das eCM gar nicht in Benutzung ist (ein weiterer Grund, warum LAN1-Modus einen Versuch wert ist), sollte auch kein nachfolgender Aufruf von "boxfeaturedisable" zusätzlich an der "featovl.cfg" herumändern wollen.

Wie komme ich zu featovl.cfg datei heran?

ar7.cfg habe ich aus erweiterte support nehmen können, nach dem ich die Spender-Box auf LAN1 konfiguriert habe. Mit der ar7.cfg habe ich dann auch eine tffs-image gebaut und auf empfänger-Box übertragen.
Transplantation hat auch geklappt wie man aus der ergebnis sieht.
Ergebnis:

Spoiler

=>Alle LEDS kurz aufgeleuchtet
=>Power LED blinkt(ca. in sekundentakt)
=>Sekunde 15 Power LED dauer an
=>Sekunde 30 Power LED blinkt(ca. in Sekundentakt)
=>Sekunde 48 POWER LED dauer an WLAN LED blinkt dazu
=>Sekunde 62 WLAN LED dauer an
=>Sekunde 64 WLAN LED aus
=>Sekunde 68 POWER LED aus
=>Sekunde 70 Neustart

 

[PeterPawn]

Eine "featovl.cfg" muß man sich selbst erstellen (sind ja nur Zeilen mit "variable=value") ... und dann einfach diese Textdatei ins TFFS einbauen lassen - die Minor-ID steht wieder in der "tffs.files".

Diese Datei wird bei der "Fernkonfiguration" von DOCSIS-Boxen über SNMP genutzt, um zusätzliche Features ein- oder auszuschalten - je nach Modell und Branding kann das etwas vollkommen anderes sein, wie man in der "bin/docsis_feature_disable" (auf dem ARM-Core, man muß also die ARM-Firmware entpacken) nachlesen kann. Das (optionale) Einschalten von DVB-C erfolgt bei Provider-Branding dann z.B. auch auf diesem Weg.

Anhand der Ergebnisse und des Timings kann man leider immer noch nicht erkennen, von welchem Core jetzt der Neustart ausgeht ... das Abschalten der WLAN-LED kann durchaus auch im Rahmen des "reboot" erfolgen - wobei sich der "Auslösezeitpunkt" ja (iirc) damit auf zwei Sekunden nach der WLAN-Bereitschaft (durch Dauerleuchten der LED signalisiert) verschoben hätte.

Da nach dem WLAN jetzt eben der USB-Stack dran wäre, kann man ja auch mal - spaßeshalber und im nächsten Schritt - die USB-Initialisierung weitgehend blockieren (wenn man das mit der "featovl.cfg" erst einmal getestet hat und den Umgang damit beherrscht), indem man die ganzen "CONFIG_USB*"-Variablen entsprechend setzt. Es gibt allerdings viele davon und ich würde mich nicht darauf verlassen, daß die alle mit "CONFIG_USB=n" oder "CONFIG_USB_HOST=n" ebenfalls abgeschaltet werden, sondern würde nach einem beherzten "grep CONFIG_USB" über die entpackte Firmware jeden vorhandenen Variablennamen explizit setzen. Vielleicht ist ja tatsächlich irgendwas am USB defekt ... auf demselben Weg kann man dann auch die Initialisierung vieler weiterer Komponenten unterdrücken (das ist immer noch etwas anderes, als diese irgendwie per (GUI-)Einstellung abzuschalten) und so weiterhin versuchen, die "schuldige Komponente" zu umzingeln (oder einzukreisen).

 

[MuP]

http://www.wehavemorefun.de/fritzbox/Feature-Overlay

Wer DECT nicht benötigt:
CONFIG_DECT=n funktioniert ebenfalls super

 

[ice012345]

Wer DECT nicht benötigt:
CONFIG_DECT=n funktioniert ebenfalls super

@MuP könntest du mir deine vorgehensweise eventl. kurz erläutern? Ich bekomme das mit CONFIG_WLAN=n nicht hin oder der Fritzbox übernimmt dies einfach nicht, weil der WLAN bei mir immer noch gestartet wird.
Nur damit ich vergleichen kann ob ich was falsch mache.

 

[PeterPawn]

@ice012345:
Wie hast Du denn die "featovl.cfg" genau in Dein TFFS-Image eingebaut?

 

[ice012345]

@ice012345:
Wie hast Du denn die "featovl.cfg" genau in Dein TFFS-Image eingebaut?

Naja im prinzip selben weg wie die ar7.cfg wo ja funktioniert.
featovl.cfg datei erstellt mit der inhalt

Spoiler

featovlcfg {
CONFIG_WLAN=n
CONFIG_DECT=n
CONFIG_USB_STORAGE_USERS=n
CONFIG_USB_HOST_AVM=n
CONFIG_USB_TETHERING=n
CONFIG_USB=n
CONFIG_USB_HOST_TI=n
CONFIG_USB_INTERNAL_HUB=n
CONFIG_USB_STORAGE=n
CONFIG_USB_XHCI=n
CONFIG_USB_PRINT_SERV=n
CONFIG_USB_GSM=n
CONFIG_USB_HOST_INTERNAL=n
CONFIG_USB_WLAN_AUTH=n
CONFIG_USB_HOST=n
CONFIG_USB_STORAGE_SPINDOWN=n
CONFIG_WEBUSB=n

}

datei gepackt und als 00d7.bin bei build_tffs_image als vierte position eingebunden. Allerdings kann ich den erstellten mtd.img mit dissect nicht entpacken.
Wenn ich denn selben weg für ar7.cfg nehme und es als 0071.bin an vierte position bei build_tffs_image einbinde klappt es.

 

[PeterPawn]

Da sind schon mal die erste und die letzte Zeile komplett überflüssig ... deshalb hatte ich (absichtlich) auf das Thema "CONFIG_LINEARTV=y" hingewiesen (auch wenn ich es als "DVB-C auf Provider-Boxen" eingeführt habe), weil dort u.a. auch das Format der "featovl.cfg" beschrieben ist, wenn man nicht gleich selbst in die "rc.conf" schauen will, wo diese Datei schließlich verarbeitet wird.

Du kannst jedenfalls mit einiger (eigentlich sogar hoher) Wahrscheinlichkeit davon ausgehen, daß die "featovl.cfg" auch nicht mit einem gültigen Inhalt im TFFS-Image gelandet ist, wenn Du das hinterher nicht wieder sauber zerlegen kannst ... insofern verstehe ich Deine Vermutung "... die FRITZ!Box übernimmt dies einfach nicht ..." auch nur in Grenzen.

Man kann auch mehr als eine Datei beim "build_tffs_image" zusätzlich angeben ... es ist also auch machbar, sowohl die "ar7.cfg" zu verwenden (was ich immer noch machen würde, um erst einmal das eCM auch für den "dsld" aus dem Spiel zu nehmen als Absturzursache) als auch eine "featovl.cfg" einbauen zu lassen. Dabei muß man zwar aufpassen, daß man den Dateinamen auch tatsächlich vierstellig angibt (das wird direkt in den hexadezimalen Inhalt des TFFS-Images übernommen und auch nicht weiter geprüft), aber das hast Du nach eigener Aussage ja getan.

 

[ice012345]

Du kannst jedenfalls mit einiger (eigentlich sogar hoher) Wahrscheinlichkeit davon ausgehen, daß die "featovl.cfg" auch nicht mit einem gültigen Inhalt im TFFS-Image gelandet ist, wenn Du das hinterher nicht wieder sauber zerlegen kannst ... insofern verstehe ich Deine Vermutung "... die FRITZ!Box übernimmt dies einfach nicht ..." auch nur in Grenzen.

Ich habe die YourFritz-ordner von dir wieder neu erstellt, weil ich die vermutung hatte das der skript build_tffs_image oder dissect_tffs_dump nicht saubert Arbeitet(höchst warscheinlich bin ich da drann Schuld). So wars dann auch, jetzt klappt es mit der zerlegen auch wieder.

Man kann auch mehr als eine Datei beim "build_tffs_image" zusätzlich angeben ... es ist also auch machbar, sowohl die "ar7.cfg" zu verwenden (was ich immer noch machen würde, um erst einmal das eCM auch für den "dsld" aus dem Spiel zu nehmen als Absturzursache) als auch eine "featovl.cfg" einbauen zu lassen.

Ja das ist mir klar aber ich wollte mal nur die featovl.cfg einbauen, weil es ja ganze zeit nicht geklappt hatte(mit tffs-image und zerlegen) um meine fehler zu finden.

Ich werde Jetzt "featovl.cfg" Neu erstellen ohne die erste und letzte zeile

EDIT:
Ich habe es nochmals mit der neue featovl.cfg datei an meine funktionierende 6490 probiert. WLAN wird trotzdem gestartet.
Wenn ich denn selben vorgehensweise für wlan.cfg probiere an der funktionierende box blinkt WLAN LED beim start 6X und bleibt danach aus. Wenn man davon jetzt ausgehen sollte würde ich sagen das es ja auch mit der featovl.cfg klappen sollte?
Kann das sein das bei "firmware_version avm" der featovl.cfg nicht abgearbeitet wird?