[Problem] FRITZ!Box 6591 Cable (HW233.8, LGI→Retail debranded): Bootloop ab Firmware > 8.03 — DPD/NP-CPU Initialisierung schlägt fehl

[neo.b]

Gerätedaten​

Merkmal	Wert
Produkt	FRITZ!Box 6591 Cable (Fritz_Box_HW233)
Hardware	HWRevision 233, HWSubRevision 8
Annex	Kabel
Bootloader	4711.0815 (Platzhalter-Anzeige)
Speicher	eMMC, 18 Partitionen (GPT), zusätzlich SPI-Flash (Descriptor/BIOS/ME/Platform Data)
Branding	Ursprünglich LGI, selbst auf Retail umgestellt (DMC=RTL=y, firmware_version=avm)
Laufende Firmware	161.08.03, Build 118553
Kernel (funktionierend)	Linux 5.15.153, Build 2024-12-05

Symptom​

Die Box bootet mit FRITZ!OS 8.03 stabil (Uptime mehrere Tage). Jede getestete Firmware > 8.03 (konkret 8.21 und 8.25) führt zu einem Bootloop. Die Box startet, mountet das Root-Dateisystem, aber die Init-Sequenz hängt und der AVM-Watchdog löst nach ~142s eine Kernel-Panic aus.

Wichtig: Auf Retail-Boxen (nicht debranded) funktionieren 8.21+ normal. Das Problem ist spezifisch für diese debranded Box.

Belegter Fehlerpfad (8.21-Panic-Log)​

FW: 08.21
Buildnumber: 126328
Bootloader: 4711.0815
Linux version 5.15.179
VFS: Mounted root (squashfs filesystem) readonly on device 179:3.
AVM_WATCHDOG: System Init Ueberwachung 120 Sekunden
Kernel panic - not syncing: avm_watchdog_reboot: init sequence hangs!

Der Kernel startet, das RootFS wird gemountet — der Abbruch erfolgt während der Systeminitialisierung nach dem Root-Mount.

Root Cause: DPD/NP-CPU Initialisierung​

Was ist dpd_netdev?​

dpd_netdev ("Data Pipe Driver for Network Device") ist der Treiber, der die Kommunikation zwischen der APP-CPU (Hauptprozessor, läuft Linux) und der NP-CPU (Network Processor, ARM/Puma7) über eine Hardware-Mailbox herstellt. Ohne diese Verbindung funktioniert kein Netzwerk.

Verhalten unter 8.03 (funktioniert)​

Aus dem Support-Dump (8.03, Kernel 5.15.153):

[   13.19s] [DPD ERROR] dpd_netdev_default_appcpu_params_init(4202): HW mailbox hwMbox_sendOpcode failed, peer is not ready.
[   14.22s] [DPD ERROR] ...
[   15.62s] [DPD ERROR] ... STATUS = 0xb (11)
[   15.63s] unload module: dpd_netdev
[   20.85s] loaded module: dpd_netdev 0x62641919-0x5900a27e

• 124 DPD-Errors von ~13s bis ~138s
• Modul wird bei ~15.63s entladen, bei ~20.85s neu geladen → Erfolg
• System läuft danach stabil (Uptime 2+ Tage)

Verhalten unter 8.21 (bootloop)​

Aus dem Panic-Log (8.21, Kernel 5.15.179):

• 123 DPD-Errors von ~14.86s bis ~142.75s
• Kein erfolgreiches loaded module: dpd_netdev
• Init-Watchdog aktiviert bei ~14.46s
• Softwatchdog-Reboot bei ~137.76s
• Panic bei ~142.88s: avm_watchdog_reboot: init sequence hangs!

Der stärkste belegte Unterschied: Unter 8.03 löst sich der DPD-Fehler nach Retries auf, unter 8.21 nie.

Fehlerdetails​

HW_MBOX_KERNEL_ERROR send Opcode to NP_CPU(0) - subject replied with internal error! STATUS = 0xb (11)
[DPD ERROR] dpd_netdev_default_appcpu_params_init(4202): HW mailbox hwMbox_sendOpcode failed, peer is not ready.

Die NP-CPU antwortet auf Mailbox-Anfragen, aber mit STATUS = 0xb (11) ("internal error") — sie lehnt die Initialisierung ab. Die APP-CPU sendet OpCodes, die die NP-CPU nicht verarbeitet.

Untersuchte und ausgeschlossene Ursachen​

1. Partition/Dateisystem-Integrität — NICHT die Ursache​

• Beide APP-Root-Dateisysteme (/dev/mmcblk0p3 und /dev/mmcblk0p9) lassen sich read-only mounten
• tar-Leseprüfung für beide mit Exitcode 0
• Der 8.21-Kernel mountet sein RootFS erfolgreich (VFS: Mounted root (squashfs) readonly on device 179:3)
• → Kein defektes RootFS

2. Environment/Platform-Data — Verdächtig, aber nicht allein erklärend​

• avm-prom: restore_finalization: Environment data corrupt! erscheint bei beiden Versionen (8.03 und 8.21)
• Bei 8.03: Warnung vorhanden, aber System bootet
• Bei 8.21: gleiche Warnung, aber System hängt
• → Die Warnung allein erklärt nicht den Bootloop

3. Bootloader (4711.0815) — Verdächtig​

• Anzeige 4711.0815 ist offensichtlich ein Platzhalter
• Backup-String bootloaderVersion1.3614 (aus mtd3_backup.bin, nicht verifiziert)
• Externer Thread auf Digital Eliteboard berichtet gleiche Diskrepanz
• → Unklar ob Bootloader-Version zur neueren Firmware passt

4. Bank-/Partitionszuordnung — Verdächtig​

• linux_fs_start = 0 im Environment
• Erfolgreicher 8.03-Boot: Root-Mount auf p9 (APP_CPU_ROOTFS1)
• Fehlgeschlagener 8.21-Boot: Root-Mount auf p3 (APP_CPU_ROOTFS0)
• Diskrepanz zwischen logischer Bankauswahl und physischer Partition
• → Möglicherweise falsche Partition wird unter neuerer Firmware verwendet

Firmware-Analyse (eigene Extraktion)​

Ich habe die offiziellen AVM-Images 8.03 und 8.25 heruntergeladen und extrahiert (uimg → unsquashfs):

Partitionen (beide Versionen identisch)​

Partition	Inhalt	Größe 8.03	Größe 8.25
p2	APP_CPU_KERNEL	9.0 MB	9.0 MB
p3	APP_CPU_ROOTFS	34.9 MB	36.7 MB
p8	NP_CPU_KERNEL (ARM)	3.1 MB	3.2 MB
p9	NP_CPU_ROOTFS (ARM)	9.9 MB	9.9 MB
p10	GWFS	20 KB	20 KB

Kernel-Versionen​

• 8.03: Linux 5.15.153 (Build 2024-12-05)
• 8.25: Linux 5.15.179 (Build 2026-03-03)

NP-CPU (ARM) RootFS​

• Branding-Dateien in beiden: default.language.lgi, default.Fritz_Box_HW233a/lgi, default.0.lgi
• Kein struktureller Unterschied in der Firmware-Architektur
• Boot-Skripte (puma_startup.sh, puma_setup.sh) unterscheiden sich nur in Details (Testmode, Build-Datum)
• NP-CPU-Kernel-Version konnte nicht aus dem ARM-Kernel extrahiert werden (komprimiert/verschlüsselt)

Schlussfolgerung aus Firmware-Analyse​

Die Firmware-Struktur ist zwischen 8.03 und 8.25 identisch. Der Unterschied liegt ausschließlich in der Software-Version (Kernel 5.15.153 vs 5.15.179) und der strengeren Validierung.

Meine Hypothese (unabhängig von der Fallakte)​

Die debranded Box hat inkonsistente Platform-Daten (TFFS/mtd3), die unter 8.03 toleriert werden, aber unter 8.21+ die NP-CPU-Initialisierung blockieren. Begründung:

1. Die Firmware-Struktur ist identisch — kein Hardware/Partition-Problem
2. Auf Retail-Boxen funktioniert 8.21+ — das Problem ist debranding-spezifisch
3. restore_finalization: Environment data corrupt! erscheint bei beiden Versionen, aber nur 8.03 toleriert es
4. Die NP-CPU antwortet mit STATUS = 0xb (11) — sie läuft, aber lehnt die APP-CPU-OpCodes ab
5. Die NP-CPU erhält ihre Konfiguration aus den Platform-Daten (mtd3/SPI-Flash)
6. Wenn diese Daten durch das Debranding inkonsistent sind, initialisiert die NP-CPU unter strengerer Validierung (8.21+) nicht → "peer is not ready"

Die NP-CPU-Partitionen (p4, p5, p10, p11) wurden bei der Debranding-Prozedur möglicherweise nicht mit aktualisiert. Die APP-CPU unter 8.21+ prüft strenger, ob APP- und NP-CPU zur selben "Identität" gehören.

Offene Fragen für Experten​

1. Welche Platform-Daten validiert die NP-CPU unter 8.21+? Die restore_finalization-Warnung erscheint bei beiden Versionen, aber nur die neuere scheitert. Was genau wird strenger geprüft?
2. NP-CPU-Kernel-Version: Der ARM-Kernel (p8) konnte nicht extrahiert werden. Welche Version läuft auf der NP-CPU unter 8.03 vs 8.25?
3. Bootloader-NP-Initialisierung: Macht der Bootloader (4711.0815) NP-CPU-spezifische Initialisierung, die für neuere Firmware nötig ist?
4. Bank-Zuordnung: Warum bootet die Box mit linux_fs_start=0 auf p9 (APP_CPU_ROOTFS1) statt p3 (APP_CPU_ROOTFS0)? Ist das normal für diese Plattform?
5. TFFS-Bereinigung: Würde eine TFFS-Bereinigung (Environment zurücksetzen) das Problem lösen? Risiko: Box unbootbar.
6. Vergleich mit Retail-Box: Gibt es jemanden mit einer Retail-6591, der die NP-CPU-Partitionen (p4, p5, p10, p11) auslesen und mit dieser vergleichen kann?

 

[Karl.]

Ich hoffe ich habe es nicht überlesen, aber wie hattest Du aus einer lgi Box eine Retail Box gemacht?

 

[NDiIPP]

Meine Fragen dazu:

1. Wie @Karl. würde ich gerne genau wissen, wie diese Box ursprüngliche debrandet wurde. Nur indem man den Wert der Variable DMC geändert hat (also RTL=n auf RTL=y) oder auch indem der Bootloader manipuliert wurde (wie es eine Anleitung aus dem D"E"B beschreibt)?
2. Wurde bereits versucht (mit laufendem bzw. installiertem FRITZ!OS >=8.2x) die Einstellungen per >recovered=x< (über die Variable firmware_info) zurückzusetzen?

 

[neo.b]

Meine Fragen dazu:

1. Wie @Karl. würde ich gerne genau wissen, wie diese Box ursprüngliche debrandet wurde. Nur indem man den Wert der Variable DMC geändert hat (also RTL=n auf RTL=y) oder auch indem der Bootloader manipuliert wurde (wie es eine Anleitung aus dem D"E"B beschreibt)?
2. Wurde bereits versucht (mit laufendem bzw. installiertem FRITZ!OS >=8.2x) die Einstellungen per >recovered=x< (über die Variable firmware_info) zurückzusetzen?

Richtig, nach der Anleitung aus dem anderen Board inkl. Bootloader edit.
Box steht aktuell auf provider avm und rtl.y und neuestes freetz-ng auf 8.03 Basis läuft einwandfrei. Jegliches flashen einer höheren fw als 8.03, egal ob retail oder freetz, resultiert im Bootloop. Nach manuellem Bank Wechsel, bootet 8.03 wieder.

Punkt 2 habe ich nicht versucht.

 

[NDiIPP]

Wenn Pkt. 2 noch nicht probiert wurde, probieren. Falls das nicht hilft, es gibt hoffentlich noch ein Backup des originalen/unveränderten Bootloader. Falls ja, würde ich diesen vermutlich wieder flashen und damit probieren (vielleicht wird ja bei neueren Firmware-Versionen die Signatur des Bootloader überprüft).

BTW:
Es gibt eigentlich keinen Grund den Bootloader zu modifizieren, die üblichen Brandings werden von der originalen Firmware bereits unterstützt und wenn man sowieso modifizierte Firmware verwendet, kann man damit bei Bedarf den Wert aus dem Environment ignorieren.

 

[neo.b]

Wurde bereits versucht (mit laufendem bzw. installiertem FRITZ!OS >=8.2x) die Einstellungen per >recovered=x< (über die Variable firmware_info) zurückzusetzen?

Hat leider nichts gebracht. Ein Backup vom original Bootloader ist auch nicht vorhanden.

 

[erst_nachdenken]

Wenn die ausgeführten Änderungen am Loader noch nachvollziehbar sind, kann man auch versuchen, diese wieder rückgängig machen - trägt man die alten Werte wieder ein, sollten event. vorhandene Sicherungsmechanismen damit ja auch wieder zufrieden sein.

Sofern nur firmware_version im Bootloader geändert wurde (der DMC-Inhalt wird m.W. ja nicht bei jedem Neustart aus der Konfiguration restauriert und kann durch SETENV effektiv geändert werden), diese Änderung einfach wieder rückgängig machen und das Resultat als neuen Bootloader flashen (mit dem korrekten(!) Vorgehen für SPI-Flash).

Ich würde aber zuerst noch einmal versuchen, den Konfigurationsbereich von EVA über FTP auszulesen und prüfen, ob da die vier Bytes ab Offset 1020 (der eigentliche Konfigurationsbereich ist nur 1 KB groß und das sind die letzten vier Byte darin - der Rest sind dann Zusätze, die über einen Treiber zur Verfügung gestellt werden, wenn der Kernel läuft) einen Wert enthalten oder nur "gelöschte" Bits (also hexadezimal 0xFF). Bei Boxen mit nur einer Kopie des Konfigurationsbereichs stehen (bzw. standen) da m.W. immer irgendwelche unbekannten Werte, die auch zu keinem der bekannten CRC32-Algorithmen passen wollten (wer's selbst probieren will: https://quackez.com/en/tools/crc-calculator). Bei den Boxen mit doppeltem Konfigurationsbereich (und doppeltem Loader-Code, weil NAND-basiert) stehen da allerdings auch nur binäre Einsen in allen Dumps, die mir hier vorliegen.
Ausserdem kann man anhand der Adressen/Offsets im Konfigurationsbereich auch schon sehen, an welcher Stelle im SPI-Flash der Konfigurationsbereich liegt (bei den MIPS-Modellen mit NOR/SPI lag der immer an Offset 0x580) - das könnte sich als nützliche Information erweisen, wenn man gezielt nur einen (bzw. den betroffenen) "erase block" im Flash neu beschreiben will.

Dann kann man sich immer noch überlegen, ob man darauf bauen will, dass AVM vielleicht wg. anderer Modelle da einen Test eingebaut hat, der bei binären Einsen in diesen Bytes die Prüfung übergeht - ich würde (wenn da Werte drin stehen) jedenfalls erst einmal die Änderungen an firmware_version rückgängig machen - das geht ja auch mit einem aktuellen Dump und braucht nicht zwingend das Backup, was man eigentlich zuvor gemacht haben sollte.

Ein weiterer Test wäre es danach(! - in Abhängigkeit von den vorherigen Ergebnissen), einfach mal einen anderen (restaurierten!) Wert (z.B. den vorbelegten WLAN-Key oder die zwei Zeichen am Ende der WLAN-SSID) zu ändern und zu sehen, wie das aktuelle FRITZ!OS (oder auch eine 8.0x) dann reagiert. Ist das tatsächlich ein Sicherungsmechanismus (im Bootloader finden sich ja auch Zeichenketten wie crc failed, auch wenn nicht klar ist, worauf dieser CRC basiert/angewandt wurde), müsste der auch auf andere Änderungen innerhalb des Konfigurationsbereichs reagieren und nicht nur auf ein geändertes firmware_version - zumindest solange es kein "veränderbarer" Wert ist, denn die stehen im Konfigurationsbereich in einer anderen "Tabelle" und die KÖNNTE anders behandelt werden bei der Prüfung in avm_prom.

Ist so eine Sicherung tatsächlich vorhanden (die Zeile mit der o.g. Fehlermeldung kenne ich auch noch nicht aus den Quellen, allerdings habe ich auch keine (Puma7-)Box mit modifiziertem Bootloader), hat man immer noch zwei Optionen ... entweder man verzichtet auf die Änderung von firmware_version und macht das in der installierten Firmware (die man dann natürlich modifizieren muss, was aber ausdrücklich erlaubt ist nach den Lizenzbedingungen) oder man passt auch noch die Werte für diese Integritätsprüfung entsprechend an, denn zu guter Letzt bleibt ja auch immer noch der Blick in den Quelltext der entsprechenden AVM-Treiber. avm_prom sollte (da vermutlich bis sicher statisch in den Kernel gelinkt oder gibt es ein LKM dafür?) auch im OpenSource-Paket für die Puma7-Modelle vorhanden sein und mit der gezeigten Fehlermeldung kann man auch sehr gut in diesen Quellen suchen. Zumindest sollte man dabei herausfinden können, was da geprüft wurde/wird und wenn das tatsächlich im Treiber-Code selbst erfolgt (der (Funktions-)Name restore_finalization deutet für mich zumindest mal darauf hin ... aber vielleicht wird auch nur ein zuvor von EVA irgendwo gesetztes Flag geprüft), dann findet man ggf. auch den Algorithmus heraus, mit dem die Integrität dort geprüft wird.

Ich halte es zumindest nicht für ausgeschlossen, dass AVM (oder meinetwegen jetzt FRITZ!) inzwischen tatsächlich etwas gegen dieses "Rebranding" von (ehemaligen) Provider-Boxen unternommen hat - der Langmut, mit dem man dort auf solche (und andere) "Manipulationen" bisher reagierte, kam mir schon lange spanisch vor und ließ sich für mich nur so erklären, dass es die (alten) Eigentümer nicht so sehr juckte, weil es nur wenige Kunden betraf, die derartige Modifikationen vornahmen. Vermutlich kehren die neuen Besen da inzwischen besser ...

Und mit "Manipulationen" meine ich explizit nur das Verändern des Bootloaders (oder anderer, zu Recht "closed source"-Teile der Firmware), denn der ist nun mal das geistige Eigentum des Herstellers und KEINE OpenSource-Software (auch nicht durch "damit verbundene Werke", weil man die (zumindest anzunehmende) Nutzung von C-Libraries unter GPL nicht wirklich nachweisen kann, solange man lediglich Funktionsnamen als Indizien hat) und ob Änderungen daran durch §§69d-e UrhG gedeckt seien, wird m.W. auch immer wieder heftig diskutiert.

Nur dürfte das meiner Ansicht nach hier auch irrelevant sein, denn §69e Abs. 2 Zf. 2 UrhG legt eben gleichzeitig fest, dass dabei gewonnene Informationen NICHT an Dritte weitergegeben werden dürfen (das also jeder für sich selbst machen müsste). Wobei hier die Grenzen zwischen Programm (geschützt) und Daten (nicht geschützt, da ja auch durch den Benutzer zu ändern) schon wieder "verschwimmen" ... denn den gesamten Konfigurationsbereich rückt der Loader ja freiwillig heraus (RETR config i.d.R.) und dafür braucht es gar keine "Dekompilierung" in irgendeiner Form, nur gesunden Menschenverstand und etwas Erfahrung in RE (reverse engineering - heutzutage macht das meist ohnehin eine KI, allerdings keines der frei zugänglichen Modelle).

Daher kann man das sicherlich noch gefahrlos (auch hier) "diskutieren", was da wohl in der Firmware passiert - ob eine ÄNDERUNG des Konfigurationsbereichs (die nur durch Flashen eines kompletten geänderten Loader-Images möglich ist oder zumindest eines kompletten "erase blocks", der dann sicherlich auch wieder Programm-Code enthält und nicht nur Konfigurationsdaten) durch den (neuen) Besitzer des Geräts auch noch von den Ausnahmen im UrhG gedeckt ist, solange dadurch keine Fehlfunktion der Hard- und Software behoben werden oder irgendeine Interoperabilität mit einem eigenen Werk ermöglicht werden soll, würde ich erst einmal in Zweifel ziehen ... und das Branding-Thema ist definitiv bzw. offensichtlich ein absichtlich implementiertes Feature und kein "Unfall", mithin auch keine "Fehlfunktion", die ein berechtigter Nutzer der Software für sich selbst korrigieren dürfte.