@ice012345:
Ich habe jetzt den Faden verloren ...
hier war das ja noch eine Box mit der identischen Bootloader-Version 1.3272, die (obwohl ehemals auch "kdg") mit "avm" problemlos läuft. Ist die 1.2279 dann die dritte?
Ich will zwar auch einen Bootloader mit unveränderlichem Branding nicht vollkommen und für immer ausschließen, aber ich sehe bei dieser Theorie z.B. keine plausible Erklärung, warum das erste Update auf 06.85 und avm-Branding dann funktioniert hat (nach Deiner eigenen Beschreibung) und erst nach dem fehlgeschlagenen Update auf 06.87 jetzt auch keine Version 06.85 mehr funktionieren sollte.
Ich kann mir zwar auch dafür jede Menge Gründe ausdenken ... die sind aber eben alle nicht sehr plausibel und passen auch nicht zu meiner Ansicht, daß AVM die DOCSIS-Boxen nicht unbedingt in den Fokus der Weiterentwicklungen stellt.
Da ist irgendein verstecktes Feature im Bootloader (bei den Provider-Boxen), das beim Update-Versuch auf die Retail-Firmware irgendetwas blockiert (warum dann erst beim zweiten Update?), schon ziemlich kompliziert gedacht und mir fielen sicherlich noch ein paar einfachere Tricks ein, mit denen man ein "De-Branding" be- oder auch verhindern könnte. Auch die Frage, warum die "Schwester-Box" sich dann nicht genauso verhielt beim Update, ist dann weiterhin offen.
Die einfachste Gegenmaßnahme wäre auch hier vermutlich wieder das Ignorieren des Brandings der Box (wie bei einer 7580 oder 7590 erst vor kurzem hier irgendwo durchexerziert) - das ist als "countermeasure" dann erneut so simpel (sollte es funktionieren), daß sich irgendein Aufwand mit zusätzlichen Vorkehrungen beim Bootloader praktisch nicht rentiert. Gleichzeitig beschränken sich auch die Vorkommen von "firmware_version" (was man zum Auslesen sicherlich bräuchte) im ARM- und ATOM-Filesystem auf die "rc.conf" und die zusätzlichen Stellen haben (soweit ich das sehe) nur mit DECT-Geräten und deren eigener Firmware-Version (hier dann auch nicht mehr im Sinne von "Branding") zu tun. Das läßt es wieder sehr wahrscheinlich erscheinen, daß man einen "Dauerbrand" auch mit einer geänderten "rc.conf" (halt auf beiden Kernen) bekämpfen könnte.
Auch ist in den Quellen für die 6490 (06.85) nichts zu sehen, daß die irgendwie mit einem OpenFirmware-kompatiblen "device tree" arbeiten würde, was bei einem neuen Bootloader zumindest denkbar wäre - aber auch das würde wieder (zumindest nach meiner Ansicht) die 6490-Modelle so weit auseinanderlaufen lassen, daß sich AVM damit praktisch eine weitere Generation ins (Firmware-)Boot holen würde und ich schätze die handelnden Personen bei AVM nicht so ein, daß sie solche wilden Experimente veranstalten würden, nur weil die eine oder andere Provider-Box ihr Leben mit einem anderen Branding und Retail-Firmware fortführt. Wenn das tatsächlich zu den Befürchtungen zählen sollte, hätte man vermutlich bereits beim Design der Retail-6490 besser überlegt und entsprechende Vorkehrungen getroffen - so kurzsichtig sind Produktverantwortliche in der Regel nicht.
Du kannst ja mal - spaßeshalber - versuchen, eine Retail-Firmware zu installieren (damit Du einen Einstieg in die Updates über das GUI hast, wenn es funktioniert), die noch auf dem ARM-Core läuft (also eine 06.6x) - oder auch mal die "featovl.cfg" weglassen beim Versuch mit der Provider-Firmware. Wenn die Box dann abschmiert, hat man zumindest mal einen Anhaltspunkt und wenn sie es nicht macht (ich würde das "oder" von mir auch als solches nehmen und die Tests unabhängig voneinander bzw. nacheinander machen), dann kann man da zumindest mal in die Support-Daten schauen, ob irgendeine Komponente tatsächlich Protest anmeldet und das vielleicht nur wegen des anderen Aufbaus des Systems vor der 06.8x nicht ebenfalls zum Reboot führt.
Eine 06.6x hätte dann auch noch einmal den Vorteil, daß eine "var/install" aus einer neueren Firmware wieder auf dem ARM-Core läuft und die Aktionen mit der Prüfung und ggf. Neuinstallation des Zertifikats aus dem Bootloader direkt beim Update noch einmal nachgezogen wird.
Eine zu lange Liste an denkbaren Tests bringt ja aber auch nichts ... such' Dir eine der beiden Änderungen aus (ich würde zuerst Provider-Firmware ohne "featovl.cfg" versuchen und dann zum Update auf 06.61 greifen im zweiten Schritt) und teste erst einmal die bisherigen Vorschläge.
@Micha0815:
Wenn der Satz:
Da ich ja aber schmerzlos bin
habe ich meiner Problem-Box kurze hat per FTP 141.06.50 (kdg) verpasst und tffs-image mit featovl.cfg.
vollumfänglich stimmt, wurde ja zusätzlich zum (zurück-)geänderten Branding auch noch die andere Firmware installiert.
Die arbeitet dann gleich mal wieder in erster Linie auf dem ARM-Core und reagiert auch auf eine "featovl.cfg" (bzw. bei deren Erzeugung über ein Config-File) vollkommen anders (siehe meine Erläuterung irgendwo weiter oben in einem früheren Beitrag in diesem Thread), als eine Retail-Version.
Wenn hier die per "featovl.cfg" abgeschalteten Komponenten dann auch ausgeschaltet bleiben (nach GUI-Anzeige), ist das ja nur die Bestätigung der Theorie, daß bei Provider-Branding darüber solche "Features" dynamisch ein- und ausgeschaltet werden können (im Rahmen des Codes in der "docsis_feature_disable") und ob man das jetzt auch gleich noch als Bestätigung dafür nimmt, daß eine der mittels "featovl.cfg" abgeschalteten Komponenten spinnt, liegt wieder im Ermessen und der Herangehensweise des Testenden.
Genauso gut kann AVM zusätzlich zur "Sperre" in der "docsis_state_changed", wo bei der 06.85 auf "OEM=avm" und "CONFIG_RETAIL=y" (eine Variable, die es bei der 06.61 auch noch nicht gab) getestet wird, ja auch in einigen Binärdateien noch einen solchen Test eingebaut haben, um die generelle (auch versehentliche) Abschaltung von Features zu verhindern ... das kann man nur anhand von Symptomen ableiten.
