Fritzbox 6490 Cable Bootloop

[PeterPawn]

Von mir vorweg noch eine Bemerkung: Wenn Du nachträglich an einem Beitrag änderst und andere haben diesen Thread schon als "neu" gelesen, kriegen die von solchen Änderungen null-komma-nichts mit ... es ist also mehr Zufall (oder wie hier der Antwort von jemand anderem geschuldet), wenn man so einen Thread dann wieder auf den Schirm kriegt - "nicht schieben" ist sicherlich auch richtig (und wichtig), aber kein (noch so eifriger) IPPF-Leser rennt noch einmal durch einen Thread, den er - nach Ansicht der Forensoftware - schon gelesen hat, solange da nichts Neues kommt. Also sollte man - gerade bei so wichtigen und laaange nach dem Schreiben des ersten Beitrags erfolgten Änderungen wie bei Deinem Anhängen der Log-Files - dann einfach noch einen Einzeiler mit einem Hinweis als neuen Beitrag anhängen; den kann man ja dann einen oder zwei Tage später wieder entsorgen und das versteht sicherlich auch jeder Moderator als Notwendigkeit, wenn zwischen Beitrag und Bearbeiten so viel Zeit lag.

Ansonsten fehlt schon einiges an Kontext zu den Protokollen ... hier:

[   27.635180][1]Kernel panic - not syncing: ol_ath_pci_configure failed

gibt es in Zeile 1163 Kernel-Panic (vermutlich auf der seriellen Schnittstelle mitgeschnitten, würde ich zumindest anhand der Steuerzeichen vermuten) - wohl beim Laden eines WLAN-Treibers - und danach startet die Box offenbar noch einmal neu. Wo ist denn die Beschreibung dazu, was da jeweils gestartet wurde (man kann es "kriminalistisch" anhand des 06.09.2017 als Datum für den Toolchain-Build der 06.85 jedoch ermitteln) und wann bzw. wie es abstürzte?

Dem Stack-Trace beim (ersten) Absturz nach sieht das zunächst mal so aus, als wäre da ein PCI-Device nicht vorhanden bzw. nicht bereit (auch wenn das da tatsächlich alles wild durcheinander geht im Log) ... allerdings sollte das schon vorher (Zeile 561) "geweckt" worden sein.

Ich habe inzwischen auch den Überblick verloren ... gibt es überhaupt eine Kombination, bei der das WLAN noch funktioniert bei dieser Box? Wenn ja, mach' mal in dieser Version auf der Console ein "lspci" im größtmöglichen Umfang (keine Ahnung, was da als "lspci" an Bord wäre bzw. ob es in der AVM-Firmware überhaupt eines gibt - kann man sich ja mit einer statischen BusyBox oder als statisches Zusatztool einfach in die Box kopieren - ansonsten muß man eben das "sysfs" einzeln ausspionieren), einfach damit man mal sieht, welche Devices vorhanden sind und wie hier wohl die WLAN-Adapter angebunden sind.

Ich habe bisher noch nirgendwo gelesen, daß bei der 6490 auch zwei Hardware-Revisionen (eine mit steckbarem WLAN und eine mit fest verlötetem) existieren würde, wie bei einigen anderen Modellen und auch nach der "wlan_product.cfg" in den ect-Defaults gibt es eigentlich nur eine WLAN-Version - damit dürfte dieses "Wecken" der WLAN-Adapter am PCI-Bus (durch Reset über die entsprechenden GPIO-Pins, kann man sich in der E39-irgendwas ansehen) auch tatsächlich für jede 6490 (siehe Kommentar am "else"-Zweig) dasselbe sein.

Bei meiner 6490 (ist allerdings eine Retail) sieht es so aus:

# /var/media/ftp/pentest/bin/busybox lspci -k
00:00.0 Class 0600: 8086:0931 iosf-sb
[...]
01:1f.0 Class 0280: 8086:0946 mailbox driver
02:00.0 Class 0200: 168c:abcd ath_pci
03:00.0 Class 0280: 168c:003c ath_pci

, die beiden WLAN-Adapter hängen also am Bus 2 und 3.

Der zweite Versuch sieht auch nicht viel anders aus (Panic steht dann in Zeile 2363), nur daß diesmal wohl sogar noch das Panic-Log ins TFFS geschrieben wurde. Der dritte Versuch(?) startet dann wohl in Zeil 2506 und ist in Zeile 3685 dann wieder mit "panic" beendet. Was verstehe ich hier jetzt nicht? Warum muß man sich praktisch denselben Ablauf denn (mind.) dreimal ansehen ... ändert sich beim vierten Versuch (ab Zeile 3693) dann irgendetwas?

Na ja, nicht wirklich ... aber hier kommt jetzt ab Zeile 5047 die Anzeige des Inhalts des Inhalts der "panic.log" (als Dumper für "kmsg"-Inhalte) und zwar, nachdem in Zeile 4969 ein Lock für das TFFS-Device eingerichtet wurde. Hier bei der 6490 ist der ATOM-Core der Client für den TFFS-Server auf dem ARM-Core (dort findet man auch die Message "Remote storage server for TFFS 3.x" dann irgendwo) und die beiden kommunizieren dann über den "avm_event"-Treiber miteinander.

Die folgenden Zeilen mit einer printk-Nummer (die in den spitzen Klammern) dürften dann zur Ausgabe des Panic-Logs auf der Console gehören (siehe AVM-Treiber) und die eingestreuten und nachfolgenden Probleme beim TFFS3_Open sind mit einiger Sicherheit nicht auf ein defektes, sondern auf ein "gelocktes" (und das meint nicht "curled" ) TFFS zurückzuführen. Wenn ich nichts übersehen habe in "tffs_core.c", gibt es nach "panic" auch kein "unlock" oder ähnliches ... macht ja auch nur wenig Sinn, weil i.d.R. ja das System neu startet. Jedenfalls endet - solange das Lock aktiv ist - jeder weitere Versuch von TFFS3_Open() mit "-EBUSY" ... das dürften dann die ganzen zusätzlichen Fehlerzeilen sein.

Bis dann der Watchdog nach 64 Sekunden das System über die RCU (Reset Control Unit) neu startet, wiederholt sich halt der ständige Zugriffsversuch auf irgendeinen TFFS-Node ... ob das wirklich die ar7.cfg wäre (für den "ddnsd"), kann man nur vermuten.

Nur ändert sich das beim nächsten Start (Zeile 19406) jetzt auch nicht wirklich, wodurch bei mir wieder die Frage auftaucht, warum das so viele identische Versuche nacheinander in dieser Protokoll-Datei sind, denn in Zeile 20838 kommt dann (vermutlich) der letzte, der auch nicht anders verläuft.

Beim vierten Versuch schaffen es die Systeme entweder, sich wirklich am Sync-Point "LAN_up" zu treffen oder das war dann doch einer ohne Synchronisation über die "kernel_args" ... man sieht so einem Startversuch ja nicht wirklich an, wieviel Zeit zwischen der letzten Zeile des vorhergehenden Logs und der ersten des aktuellen vergangen ist ... wobei ich bei bestückter serieller Schnittstelle jetzt erwartet hätte, daß man irgendwelche Änderungen an Variablen gleich über diese Console auch im Bootloader vornimmt - dann sollten sie ja irgendwo im Protokoll zwischen den Startversuchen stehen.

Da ist dann wohl wirklich irgendein WLAN-Adapter nicht mehr vorhanden ... wobei ich das schon einigermaßen komisch finde als Resultat eines versuchten Updates. Ich würde hier wieder eher auf irgendwelche EEPROMs tippen, die ihrerseits irgendwie mit falschen Werten gefüttert wurden und nun die Devices irgendwie totlegen ... obwohl die - nach dem Inhalt von "E39-pcie_fixup" - ja zumindest mit ihren Konfigurationsregistern irgendwo auf dem PCI-Bus zu sehen sein müssen, wenn die "grep"-Statements erfolgreich sind. Außerdem wäre das ja ein ausgesprochen dämliches Zusammenfallen des Hardware-Fehlers beim WLAN mit einem Firmware-Update ... da erscheint mir irgendwelches wildes Schreiben in Konfigurationsregister irgendwie logischer - zumal die WLAN-Adapter halt wieder die Komponenten (neben dem DECT-Chip, der halt wohl auch noch irgendein eigenes EPROM für irgendwelche Keys) mit einem eigenen Datenspeicher wären.

Ich würde jetzt auch mal den "umac.ko" umbenennen ("blacklisted" ist der schon in "/etc/modprobe.d" - damit wird er nur noch mit direktem "insmod"-Aufruf geladen und nicht mehr als Abhängigkeit) ... an die Initialisierung über den "wland" kommt man vermutlich nicht ohne weiteres heran und der ruft dann wieder die "/etc/rc.d/rc.wlan" (nicht mit der in "init.d" zu verwechseln) auf, in der die Treiber geladen werden - allerdings kann es auch gut sein, daß ein fehlender Kernel-Driver den "wland" erst recht zum Reboot veranlaßt, zumal viele andere WLAN-Treiber halt auf dem "umac.ko" aufsetzen.

Wobei ich immer noch nicht so richtig verstehe, warum die Abschaltung des WLAN über die "featovl.cfg" hier nicht funktionieren soll ab Version 06.61 ... allerdings ist das natürlich auch genau der Zeitpunkt, ab dem da nicht mehr irgendwelche Zuweisungen in der "featovl.cfg" stehen dürfen, sondern die Zeilen mit einem "grep" auf ein bestimmtes Format geprüft werden. Da könnte so eine Zeile dann aus den unterschiedlichsten Gründen durchfallen und ich würde Dich bitten, mal einen Hexdump der von Dir verwendeten "featovl.cfg" hier zu zeigen - ich werde den Verdacht nicht los, daß die Abschaltung bei den Retail-Versionen bei Dir am Ende nur an irgendeiner Kleinigkeit wie einem zusätzlichen Leerzeichen oder irgendeiner anderen Banalität scheitert. Die Datei sollte exakt so aussehen, wie der folgende Dump:

~ # echo "CONFIG_WLAN=n" | hexdump -C
00000000  43 4f 4e 46 49 47 5f 57  4c 41 4e 3d 6e 0a        |CONFIG_WLAN=n.|
0000000e

Wenn das nicht so ist, dann ändere sie mal entsprechend und dann sollte sich eigentlich auch mit einer Version jenseits der 06.61 das WLAN über diese Datei deaktivieren lassen.

 

[ice012345]

Von mir vorweg noch eine Bemerkung: Wenn Du nachträglich an einem Beitrag änderst und andere haben diesen Thread schon als "neu" gelesen, kriegen die von solchen Änderungen null-komma-nichts mit ... es ist also mehr Zufall (oder wie hier der Antwort von jemand anderem geschuldet), wenn man so einen Thread dann wieder auf den Schirm kriegt - "nicht schieben" ist sicherlich auch richtig (und wichtig), aber kein (noch so eifriger) IPPF-Leser rennt noch einmal durch einen Thread, den er - nach Ansicht der Forensoftware - schon gelesen hat, solange da nichts Neues kommt. Also sollte man - gerade bei so wichtigen und laaange nach dem Schreiben des ersten Beitrags erfolgten Änderungen wie bei Deinem Anhängen der Log-Files - dann einfach noch einen Einzeiler mit einem Hinweis als neuen Beitrag anhängen; den kann man ja dann einen oder zwei Tage später wieder entsorgen und das versteht sicherlich auch jeder Moderator als Notwendigkeit, wenn zwischen Beitrag und Bearbeiten so viel Zeit lag.

Sorry, ich habe schon in der letzten Zeit einpaar verwarnungen bekommen(kommt von meinem unwissen),das ich dachte so sei es diesmal richtig.

Ansonsten fehlt schon einiges an Kontext zu den Protokollen ... hier:

[ 27.635180][1]Kernel panic - not syncing: ol_ath_pci_configure failed

gibt es in Zeile 1163 Kernel-Panic (vermutlich auf der seriellen Schnittstelle mitgeschnitten, würde ich zumindest anhand der Steuerzeichen vermuten) - wohl beim Laden eines WLAN-Treibers - und danach startet die Box offenbar noch einmal neu. Wo ist denn die Beschreibung dazu, was da jeweils gestartet wurde (man kann es "kriminalistisch" anhand des 06.09.2017 als Datum für den Toolchain-Build der 06.85 jedoch ermitteln) und wann bzw. wie es abstürzte?

Der vorgehen von mir ist ja immer das selbe und da ich schon mehrmals Timing und Led zustände erläuterte, habe ich es diesmal nicht mit geschrieben. (Mit der firmware 6.85 avm REBOOT bei versuch WLAN zu startet.)

Ich habe inzwischen auch den Überblick verloren ... gibt es überhaupt eine Kombination, bei der das WLAN noch funktioniert bei dieser Box?

Nein.

Nur ändert sich das beim nächsten Start (Zeile 19406) jetzt auch nicht wirklich, wodurch bei mir wieder die Frage auftaucht, warum das so viele identische Versuche nacheinander in dieser Protokoll-Datei sind, denn in Zeile 20838 kommt dann (vermutlich) der letzte, der auch nicht anders verläuft.

Beim vierten Versuch schaffen es die Systeme entweder, sich wirklich am Sync-Point "LAN_up" zu treffen oder das war dann doch einer ohne Synchronisation über die "kernel_args" ... man sieht so einem Startversuch ja nicht wirklich an, wieviel Zeit zwischen der letzten Zeile des vorhergehenden Logs und der ersten des aktuellen vergangen ist

Das war bei mir eine lange nacht und bin dazu noch momentan angeschlagen. Dazwischen waren keine veränderungen meinerseit am system,bin höchstwarscheinlich kurz eingenickt. Hätte schwören können das es nur 2 startversuche waren.

wobei ich bei bestückter serieller Schnittstelle jetzt erwartet hätte, daß man irgendwelche Änderungen an Variablen gleich über diese Console auch im Bootloader vornimmt - dann sollten sie ja irgendwo im Protokoll zwischen den Startversuchen stehen.

über die Serielle kriege ich keine Bootloader ausgaben, einen prompt kriege ich auch nicht das ich was eintippen könnte. Kommt mir so vor als könnte ich über die serielle nur betrachten.

Wobei ich immer noch nicht so richtig verstehe, warum die Abschaltung des WLAN über die "featovl.cfg" hier nicht funktionieren soll ab Version 06.61 ... allerdings ist das natürlich auch genau der Zeitpunkt, ab dem da nicht mehr irgendwelche Zuweisungen in der "featovl.cfg" stehen dürfen, sondern die Zeilen mit einem "grep" auf ein bestimmtes Format geprüft werden. Da könnte so eine Zeile dann aus den unterschiedlichsten Gründen durchfallen und ich würde Dich bitten, mal einen Hexdump der von Dir verwendeten "featovl.cfg" hier zu zeigen - ich werde den Verdacht nicht los, daß die Abschaltung bei den Retail-Versionen bei Dir am Ende nur an irgendeiner Kleinigkeit wie einem zusätzlichen Leerzeichen oder irgendeiner anderen Banalität scheitert. Die Datei sollte exakt so aussehen, wie der folgende Dump:

~ # echo "CONFIG_WLAN=n" | hexdump -C
00000000 43 4f 4e 46 49 47 5f 57 4c 41 4e 3d 6e 0a |CONFIG_WLAN=n.|
0000000e

Wenn das nicht so ist, dann ändere sie mal entsprechend und dann sollte sich eigentlich auch mit einer Version jenseits der 06.61 das WLAN über diese Datei deaktivieren lassen.

Ich fasse es nicht nach dem ich deine hexdump mit meiner vergliechen habe
00000000 43 4f 4e 46 49 47 5f 57 4c 41 4e 3d 6e 20 0a CONFIG_WLAN=n .
bemerkte ich das tatsächlich hinter "CONFIG_WLAN=n" eine leerzeichen war. Du bist der Hammer @PeterPawn

Da der abschaltung bei 6.50 und sogar mit 6.31 geklappt hatte und das entpackte 00d7.inflated von zerlegten dump gut aussah (eine leerzeichen sieht ,man ja nicht ) ging ich davon aus das es passt.

Also jetzt geht auch WLAN abschaltung mit der 6.85 und ich komme auf die WebUI drauf.
Ich füge mal Logs vom firmware 6.85 mit abgeschaltete WLAN.


EDIT: Ich bekomme jetzt mit Putty bei serielle ein prompt und kann auf das laufende system zugreifen(denke ich mal).
Habe mir die featovl.cfg auf angeschlossene usb-stick raus kopiert um zu probieren und hat wunderbar geklappt. Da stellt sich mir die frage, kann in Prinzip auf dem selben weg mir von der identische box was ich brauche raus kopieren und in dem patient einfügen(eventuelle WLAN-Treiber wo angesprochen wurde)?

 

[ice012345]

Wie soll der nächster schritt von mir jetzt aussehn?
Da ja WLAN abschaltung jetzt klappt und ich auch mit der firmware avm 6.83 auf die WebUI drauf komme, muss(soll) ich immer noch einen image bauen ohne WLAN?
Oder wie ich schon in meinem vorbeitrag gefragt hatte, kann ich von spender-box nicht irgendwelche dateien(was WLAN betrift) kopieren?

Ich würde jetzt auch mal den "umac.ko" umbenennen ("blacklisted" ist der schon in "/etc/modprobe.d" - damit wird er nur noch mit direktem "insmod"-Aufruf geladen und nicht mehr als Abhängigkeit) ... an die Initialisierung über den "wland" kommt man vermutlich nicht ohne weiteres heran und der ruft dann wieder die "/etc/rc.d/rc.wlan" (nicht mit der in "init.d" zu verwechseln) auf, in der die Treiber geladen werden - allerdings kann es auch gut sein, daß ein fehlender Kernel-Driver den "wland" erst recht zum Reboot veranlaßt, zumal viele andere WLAN-Treiber halt auf dem "umac.ko" aufsetzen.

umac.ko umbenennen zu können brauche ich doch bestimmt telnet zugang oder? Über serielle komme ich zwar auch ran, aber umbenennen kann ichs von dort aus nicht "read only-filesystem".

 

[PeterPawn]

Ich habe auch keine Idee, wie man das WLAN jetzt wieder zum Leben erwecken kann bzw. ob das überhaupt möglich ist. Schon die genaue Ursache für den Absturz ist nicht ohne weiteres zu ermitteln, weil AVM für den "umac.ko" (von dem das Problem dem Backtrace nach ausgeht) ja keine Quellen mitliefert - das ist alles schon Teil des Atheros-Treiberpakets. So ganz kann das Gerät eigentlich nicht "verschwunden" sein - ich wette mal, daß es auf dem PCI-Bus durchaus noch sichtbar ist (dann natürlich auch mit seinen Konfigurationsregistern).

Eine eigene Firmware zu bauen, bei der "CONFIG_WLAN" jetzt permanent auf "n" gesetzt ist, ist einfach ... Anleitungen zum Entpacken, Ändern und Packen gibt es hier im IPPF wie Sand am Meer und bis auf die Notwendigkeit anderer Tools (die x86-Partition verwendet Little-Endian-Speicherung), die aber in jeder normalen Linux-Distribution installiert werden können, unterscheidet sich das nicht ein Jota von anderen Boxen. Hier kommt dann noch "erleichternd" hinzu, daß die Systeme ohnehin über den Bootloader installiert werden können und man damit problemlos auch nur das geänderte x86-Dateisystem neu flashen kann.

Was man ansonsten noch machen könnte mit Modifikationen des Dateisystems, sprengt jetzt den Rahmen dieses Threads deutlich und hat mit einem Bootloop dann auch nicht mehr wirklich etwas zu tun.

Die tatsächliche Ursache des Problems nach dem ersten Update-Versuch auf die 06.87 wird hier sicherlich weiterhin im Dunklen bleiben (das ist schon ein eher rares Zusammenfallen von Umständen), die Ursache für die "kernel panic" ist erkannt und wie man das umgehen kann (durch komplette Abschaltung des WLANs der Box) ist ebenfalls bekannt. Da bleibt jetzt nicht mehr so sehr viel zu tun und was Du da von der anderen Box auf diese hier übertragen willst, verstehe ich gar nicht. Es ist ja deren Hardware, die nicht funktioniert und da Du vermutlich nicht davon redest, diese SoC auf die andere Box zu löten, verstehe ich das Anliegen nicht.

Ob meine Vermutung tatsächlich zutrifft, daß es irgendwelche Konfigurationsregister bei den Atheros-SoC gibt, die erst einmal den Chip "generell freischalten", weiß ich - schon mangels Daten zur Programmierung des Chips, das ist ja praktisch noch einmal ein geschlossenes System innerhalb der Box - auch nicht. Wenn es so etwas geben sollte und angesichts der Tatsache, daß dieses System selbst noch einmal über ein EEPROM zur Speicherung von Einstellungen verfügt, würde ich dann eben einen marodierenden Schreibzugriff (direkt beim letzten Lauf mit der 06.85 oder auch erst bei einem späteren Startversuch mit einem mind. unvollständigen Environment) für wahrscheinlicher halten als einen Defekt des WLAN-Adapters, der auch noch ausgerechnet in dem Moment auftritt, wo man ein Update der Firmware gestartet hat.

Für "HWRevision" gibt es jedenfalls keinen "Fallback-Wert" in der "rc.conf" - die Firmware geht hier davon aus, daß dieser Wert immer existiert und verwurstet ihn an vielen verschiedenen Stellen, wie man mit einem einfachen "grep -r HWRevision" schon leicht ermitteln kann - da gehören auch diverse WLAN-Komponenten zu den "Abnehmern".

Ob man mit einer fehlenden "HWRevision" im Environment jetzt die WLAN-Initialisierung tatsächlich dazu bringen kann, einen WLAN-Adapter in einer Art und Weise anzusprechen, daß dabei auch in einem Konfigurationsregister Werte landen (und persistent gespeichert werden), die ein späteres Ansprechen über den PCI-Bus verhindern, wird vermutlich niemand außerhalb von AVM freiwillig und systematisch testen wollen ... ausgehend davon, daß in unterschiedlichen Modellen auch unterschiedliche Adapter mit unterschiedlichen Adressen, Befehlssätzen und Registerbelegungen verbaut sein werden, halte ich das nicht für absolut unmöglich und auch solche SoC werden häufig genug noch mit einer Art "Microcode" (bzw. eigener binärer Firmware, die auch unter Linux nur in dieser Form vorliegt) geladen - hier kann ich mir auch vorstellen, daß diese Firmware (sollte sie für das falsche SoC sein) entsprechenden Schaden angerichtet hat, der nur über JTAG zu beheben oder vielleicht sogar irreparabel ist.

Die Frage, ob ein Bootloop bereits am Beginn auch auf das WLAN-Problem zurückzuführen war oder ob es erst als Folge der Startversuche ohne "HWRevision" entstanden ist (bei den Zählern war das sicherlich weniger ein Problem), kann man im Nachgang leider nicht mehr wirklich klären ... dazu hätte man eben vor dem ersten Flashen eines eigenen TFFS-Images erst einmal alles aus der Box sichern müssen und dazu hätte dann - mit ein wenig Glück - auch noch das Panic-Log aus dem letzten Absturz im Rahmen des Bootloops gehört, denn das liegt ja ebenfalls in einem TFFS-Dump vor.

Dazu muß man sich aber wirklich seine eigene Firmware-Version für Forensik bauen, die sich auf keinerlei Angaben in der Box verläßt und die Daten, an denen man interessiert ist (vom TFFS bzw. dem kompletten SPI-Inhalt bis zu den eMMC-Partitionen), über TFTP "nach draußen" schreibt ... die LAN-Konfiguration für einen AVM-Kernel ist recht simpel zu realisieren und AVM geht bei der Produktion der Boxen offenbar auch nicht anders vor, wenn man sich z.B. den PTEST-Teil der Firmware näher ansieht (auch mal mit dem Blick in die Vergangenheit und auf andere Modelle, weil da Lücken geschlossen wurden und dabei zusätzlicher PTEST-Code entfernt wurde).

 

[Freesurf]

Ich hab jetzt auch so eine Box hier @ice012345 du hast da nicht zufällig Deine Box bei Kleinanzeigen vertickt oder?
Ich hab das Problem inzwischen auf das 5Ghz Netz eingeschränkt. mit 2.4Ghz Netz startet die Box normal.
Das starten ohne WLAN habe ich im übrigen durch mehrfaches drücken der WLAN Taste in der Startsequenz erreicht.
Anschließend hab ich erst das 2.4er eingeschaltet => ging.
Dann das 5er und es gab wieder ne Schleife. Nun stellt sich mir die Frage, 1.) Kann man ggf. die HW für das 5er ersetzen? 2.) kann man das 5er "sicher" deaktivieren, also so dass es auch einen werkreset überlebt? Dann könnte man zumindest noch das 2.4er "normal benutzen.

 

[ice012345]

Ich hab jetzt auch so eine Box hier @ice012345 du hast da nicht zufällig Deine Box bei Kleinanzeigen vertickt oder?

Nö ich habe meine noch.

 

[Freesurf]

Hmm, also AVM wird keine Unitybox ersetzen, denke ich.
Vg

 

[Mikebatt]

Setze die aktive Partition mal von 1 auf 0, dann sollte es wieder gehen, die UM Boxen haben durch ein falsches Update in der letzten Woche auch den Bootloop, habe soeben 2 Boxen zum einen durch leeren des mtd3 und mtd4 und danach dem Wechsel auf die Partition Null beide wieder zum Leben erweckt

 

[PeterPawn]

habe soeben 2 Boxen zum einen durch leeren des mtd3 und mtd4 und danach dem Wechsel auf die Partition Null beide wieder zum Leben erweckt

Da das jetzt schon in zwei Threads steht: Ich rate meinerseits ganz dringend davon ab, einfach MTD3 und/oder MTD4 zu überschreiben ... eine von beiden ist gerade noch verkraftbar und verursacht keine Schäden, weil die bekanntlich alternativ genutzt werden und man dann halt nur noch einen Stand hat und nicht die beiden letzten. Selbst wenn es irgendwo funktionieren sollte, weil der Bootloader tatsächlich das TFFS wiederherstellt (was definitiv nicht bei allen Versionen klappt) ... mit dem reinen Start der FRITZ!Box ist das Thema noch lange nicht gegessen und die Werte im TFFS (bis hin zur CM-MAC) müssen schon stimmen, wenn das CM sich beim CMTS registrieren will.

Also: Bitte daheim NICHT NACHMACHEN ... erst lesen und schlaumachen.

Dann hat man auch solche Fragen wie @Mikebatt nicht mehr (ohne ihm damit zu nahe zu treten), was denn das Problem bei "501 environment variable not set" sein könnte: https://www.ip-phone-forum.de/threads/fritzbox-6490-diverse-probleme.299551/

Und an @Mikebatt direkt die Bitte, solche Tipps wirklich nur dann zu geben, wenn man sich über die Konsequenzen solcher Aktionen tatsächlich im Klaren ist ... wie man dem Boot-Loop (ob nun wegen falscher Konfigurationseinstellungen oder wegen einer nicht funktionierenden Firmware in einer Partition) am besten zuleibe rückt, ist hier schon mehrfach beschrieben und - das ist das Entscheidende - zwar richtig bzw. mit entsprechenden Hinweisen, wo man VORHER nachlesen/nachdenken/nachsehen muß.

 

[Mikebatt]

Ich kann Deine Bedenken ja nachvollziehen, aber für mich war es halt nicht zu erklären warum vor dem Überschreiben der mtd3 und mtd4 keine setenv oder getenv Befehle möglich waren und danach schon.

Für mich war der wechsel der aktiven Partition halt wichtig, da ich hier testen wollte, da letzte Woche durch ein Update ca 2000 Boxen im UM Netz zerschossen wurden und ich durch den wechsel auf die Partition Null diese wieder zum laufen bekommen habe

 

[tomsoyer]

.. letzte Woche durch ein Update ca 2000 Boxen im UM Netz zerschossen wurden..

nette News

 

[PeterPawn]

@Mikebatt:
Ich habe jetzt im anderen Thread geantwortet ... wenn Du das tatsächlich "bis zum Ende" durchdacht und durchgespielt hast, erkläre es bitte besser und genauer (und bleibe dabei in einem einzelnen Thread).

 

[Mikebatt]

Also die 2000 Boxen sind zerschossen wurden, weil AVM und UM ein falsches Update aufgespielt haben, hat nichts mit mir zu tun.

Was den Vorgang angeht, was ich gemacht habe, erst mal probiert, weil ich bei Null angefangen habe, bin dann auf diverse Infos gestossen was ich in Adam2 alles machen kann, so halt zur Info von @PeterPawn mit dem Wechsel der aktiven Partition, leider merkte ich dann, das weder die Setenv voch die Getenv Befehle akzeptiert wurden. Dann kam ich noch auf eine Seite wo man sagte der mtd3 und 4 soll gegen eine leere Datei ersetzt werden. Da ich nichts zu verliern hatte, habe ich das probiert. Auch beim Schreiben kam es zu Fehlermeldungen, jedoch konnte ich nach diesem Vorgang die Partition wechseln und die Box startete ganz normal mit Werkseinstellungen. Wie gesagt ich habe quasi bei Null angefangen gestern und hab genug Geräte hier zum testen, daher war es mir egal was passiert. Ich weiß auch nicht in welchem Zusammenhang die Ersten Schritte mit dem letzten stehen, aber in den letzten 30 Jahren IT habe ich oft lustige Wege beschreitet um zum Erfolg zu kommen. Was ich in jedem FAll sagen kann, das beide Geräte gehen, denn beide wurden Heute Provisioniert und sind in Betrieb. Ich wollte auch keinem hier auf den Schlips treten, sondern einfach nur einen Tip geben, für Leute bei denen bisher nix ging.

@PeterPawn , wie gesagt durchdacht war da erst mal nix, ich teste und probiere, so habe ich in der Vergangeheit auch Dinge zerschossen , alleine zu DF1 Zeiten locker 200 Karten, aber am Ende zählte für mich immer das Ergebnis. Ich weiß nicht genau was UM falsch gemacht hat, ich weiß nur wie viele Boxen getauscht wurden, aber vlt ist eben genau für diese Boxen der Weg den ich genommen habe der richtige aber ich bin überzeugt das Du da deutlich mehr KnowHow hast, denn ohne Deine Info mit den 2 Partitionen wäre ich ja gar nicht auf die Idee gekommen, es überhaupt zu probieren, daher ja auch Dank an Deine Infos , denn ohne die wäre ich ja gar nicht so weit

 

[stoney]

Ich unterstelle einfach mal, dass die Verbindung nicht zum Bootloader sondern zum NAS hergestellt wurde, daher kein GET/SETENV möglich

 

[PeterPawn]

So, jetzt noch ein Dump des Environments so einer Box (sollte bei einem "normalen Start" über den Bootloader auch kein Problem sein, die Tools dazu liegen im YourFritz-Repo) und die Feststellung, daß da tatsächlich die richtigen (und zum Zertifikat passenden) Werte eingetragen sind und das auch eine Provisionierung bei einem Provider war, der (a) die alten nicht mehr akzeptiert (das machen praktisch alle so, nur UM hat wohl an einigen CMTS das noch nicht mit voller Härte durchgesetzt) und es sich (b) um ein neues Zertifikat handelt (das ist allerdings etwas schwieriger zu ermitteln, wenn die betreffende Box das Zertifikat nicht bereits im Bootloader hat, ansonsten ist auch das easy) und man kann vielleicht - in jedem Falle aber immer noch nur in Kombination mit der Bootloader- und OS-Version - die Feststellung treffen, daß es tatsächlich Situationen gibt, wo das Environment auch vom Bootloader wiederhergestellt wird.

Was nämlich auch nicht helfen würde, wäre ein generisches Environment und - nach der Umschaltung auf die vorherige Version - eine dermaßen alte Version (bis inkl. 06.5x funktionierte das aber m.W. noch weiter), daß diese mittels "cmcertgen" sich jetzt wieder selbst ein passendes Zertifikat zur CM-MAC ausstellt und die CMTS das dann auch akzeptiert, weil deren CRL nicht aktuell ist. Insofern läßt auch eine erfolgreiche Provisionierung nicht unmittelbar den Schluß zu, daß das alles glattgegangen ist - es kann ja nicht so schwer sein, da noch einmal richtig nachzusehen und die Informationen zu sammeln, die das bisher Geschehene oder auch nur Vermutete mit ein paar Fakten untermalen. Zumindest die jetzt laufende Version und eine damit erstellte Support-Datei sollte ja "drin sein" ... wenn man sich nicht besser gleich auch noch die Information besorgt, welches Update da nun genau (und vor allem warum) schiefgegangen ist.

Das Rauschen im (inoffiziellen) UM-Forum ist nun auch nicht sooo gewaltig - aber es wäre wohl tatsächlich mal interessant, der Ursache des Problems nachzugehen. Man kann da fast alles lesen ... von murmelnden Technikern mit 11.000 betroffenen Boxen bis zurückgezogenen Updates und einer 45 Sekunden währenden Boot-Schleife, die dann nur noch mit sehr geringer Wahrscheinlichkeit etwas mit einem komplett kaputten TFFS zu tun hat - das sollte dann deutlich früher in die Hose gehen, z.B. beim ersten Versuch (noch im Kernel), auf "HWRevision" zuzugreifen.

UM tauscht wohl nur fleißig die Boxen ... aber die neue Firmware bleibt schon erst mal in der anderen Partition stehen (wobei es in der bisherigen Schilderung auch vollkommen unklar geblieben ist, was da nun genau für "linux_fs_start" gesetzt werden mußte, damit die Box wieder startet und ob die dann auch alle mit der vorhergehenden oder mit der neuen Version starten oder ob das "gemischt" ist, usw. ... es sind massenhaft Fragen offen, die man in so einem Zusammenhang einfach stellen und klären muß) und könnte ja analysiert werden, was die nun so anders macht.

Wobei das auch nicht direkt erklärt, warum der Bootloader mit dem TFFS-Inhalt auf einmal nichts mehr anfangen kann ... da müßte ja zumindest mal das neue System erst einmal angestartet werden, dann das TFFS "umbauen" und das auch noch so lange, daß da tatsächlich beide Kopien unbrauchbar werden (nicht jede erneute Schreiboperation landet sofort wieder im anderen Image - da wird durchaus "gesammelt", um die Schreibvorgänge zu minimieren - schon aus Gründen der Lebenserwartung des Flash-Speichers). Erst bei einem anschließenden, erneuten Start würde sich das dann auswirken ... klingt auch einigermaßen komisch.

Da ist die Erklärung, daß es direkt beim Update schiefgeht und sich unmittelbar beim nächsten (dem Update zwangsläufig folgenden) Start auswirkt, irgendwie plausibler ... es gäbe auch die passenden Aktionen dafür in der Installationsreihenfolge (wie es dazu kommen könnte, habe ich in #112 mal versucht aufzudröseln) und wenn da wirklich der Watchdog hart zuschlägt, dürfte so ein NMI auch dem Schreiben ins TFFS die Beine weghauen. Wobei es dann deutlich öfter geschähe, als ich vermutet hätte ... diese 20 Sekunden für den Watchdog sind aber tatsächlich eine Besonderheit der 6490 (bzw. auch der 6590) und erst ab einer bestimmten Version überhaupt aktiv.

Das könnte es - zusammen mit einer eher geringen "Testbasis" an Boxen im "Normalbetrieb" - zumindest erklären, warum so ein Problem nicht eher bemerkt wird (nochmal, das ist alles nur Vermutung von meiner Seite, ich hätte zu gerne mal eine dieser Boxen in der Hand) ... denn erst ab einem gewissen Füllstand erfolgt die automatische Reorganisation des TFFS beim Schreiben und den wird man bei einer Box, die regelmäßig bei irgendwelchen Tests auf Werkseinstellungen gesetzt wird, eher selten erreichen.

Allerdings könnte AVM hier auch ganz einfach Abhilfe schaffen bzw. sogar Vorsorge treffen ... eine solche Reorganisation kann man auch deutlich vorher selbst anschieben (und nicht mit dem 20-Sekunden-Wachhund im Nacken) und die Zukunft wird zeigen, ob AVM hier entsprechende Vorsorge treffen wird oder nicht (auch die Logs könnte man schon vor dieser Reorganisation löschen - passen mit einiger Wahrscheinlichkeit im Nachhinein dann ohnehin nicht mehr zum neuen System). Ich habe dieses Problem aber eben auch noch nicht "live" gesehen ... es sind alles nur Ableitungen aus den beobachteten bzw. analysierten Abläufen bei der Installation neuer Firmware und aus dem Zusammenspiel zwischen ARM- und ATOM-System beim Zugriff auf das TFFS (das ist ja bisher der einzige Prozessor, bei dem AVM das mit dem Client-Server-Prinzip beim TFFS3 auch durchgezogen hat).

@stoney:
Auch denkbar, aber bei einer Boot-Schleife? Ich tippe eher darauf, daß hier die "name table" im TFFS nicht ganz stimmte (wie sie genau aussieht bzw. aussah, weiß ich natürlich auch nicht) und da über diese ja die Umsetzung zwischen der TFFS-ID und dem - zum Setzen und Abfragen verwendeten - Namen hergestellt wird, kann das auch problemlos zu solchen "501"-Nachrichten (auch beim "SETENV") führen (der andere Server kennt das Kommando und den Text "environment variable not set" eigentlich auch gar nicht).

Hier kommt dann noch erschwerend hinzu, daß der Kernel entweder mit einer neueren Version ausgestattet sein kann (ich kenne bisher nur Versionen bis "@L") oder mit einer älteren. Bei einer neueren, schreibt der Kernel direkt beim Systemstart diese neue Version dann ins TFFS und bei einer älteren, baut er aus den Daten im TFFS seine interne Name-Table neu auf.

Wenn also AVM irgendeine Firmware mit einer Name-Table "@M" im Kernel an die Front wirft und der Kernel hier beim Update der Name-Table im TFFS Späne macht, sähe das am Ende genauso aus ... je nachdem, wo die Table dann falsch ist, könnte sogar der Rest des TFFS-Inhalts überleben, denn diese Name-Table ist aus TFFS-Sicht eben auch nur ein normaler Eintrag (mit der ID 0x1FE, was ich zufällig gerade noch präsent habe, da ich erst vor ein paar Tagen eine neue C#-Klasse für diese Name-Tables gebaut habe: https://github.com/PeterPawn/YourFritz/blob/fdd0c8b81ec693d769467dc2c7734939b2c6e055/tffs/TFFS.cs).

 

[Mikebatt]

@PeterPawn ich denke mittlerweile, das es Zufall war, das die beiden Geräte wieder laufen. Denn bisher klappt es bei keiner anderen mehr. Für mich bleibt daher immer noch die Frage offen, warum manche Boxen den SETENV und GETENV annehmen und andere Boxen den Fehler 501 erzeugen, daher wäre ich ja dankbar, wenn jemand mir sagen kann, warum dem so ist. Ich komme ja in Adam2 rein und logge mich sauber ein, einige Befehle werden akzeptiert , einige jedoch nicht, deswegen ja meine Ursprungsfrage, eben weil ich es ja lernen möchte

 

[v!king]

Also ich glaube es liegt an. Bootloader, älterer lässt es noch zu und die neuen keine chance

 

[Mikebatt]

Also ich glaube es liegt an. Bootloader, älterer lässt es noch zu und die neuen keine chance

Eben das ist ja der Witz, ein und die selbe Box nimmt die Befehle und dann nimmt sie sie wieder nicht, das ist es was ich ja so komisch finde. Daher suche ich ja Hilfe ,

 

[v!king]

Naja, ich weiß nicht ob man bootloader überhaupt downgraden kann. Also bei Samsung tv ist das jetzt auch so. Neue frimeware kann man nicht mehr auf 0000 flashen..

Ich denke avm kann das über bestimme Adapter.. Bestimmt.. Nur halt alles. Intern

 

[PeterPawn]

Sorry ... "nimmt die Befehle (nicht)" ist weder eine klare Aussage, um welche Befehle es sich konkret handelt, noch ein Anhaltspunkt, welche Fehlermeldung da tatsächlich ausgegeben wird, aus der Du das "nicht" ableitest. Dafür gibt es hier "CODE"-Tags, in die man die eigenen Eingaben und die Reaktionen des Systems wunderbar einbetten kann, nachdem man sie aus seinem Terminal kopiert hat.

Ich habe oben schon versucht zu erklären, daß für die "Umsetzung" der Nummer der Daten (ID) in der TFFS-Struktur in etwas, was man mit einem Namen ansprechen kann, eine Tabelle benötigt wird, die ebenfalls mit in der TFFS-Struktur steht (als spezieller Eintrag mit der ID 0x01FE). Wenn diese Tabelle erkennbar nicht stimmt oder nicht vorhanden ist, kommt eine direkt in den Bootloader einkompilierte Standard-Tabelle zum Einsatz:

<create new TFFS>
{%s}<Entry too long>
AutoMDIX
HWRevision
HWSubRevision
ProductID
SerialNumber
[...]
wlan_ssid
zuende
<ERROR: %s>
<ERROR:
FIRMWARE_CHECK_SUM
FIRMWARE_ILLEGAL_CONFIG
no Config - USING Defaultconfig!

Wenn die aber gelesen werden kann (und sei es nur vermeintlich) und eine neuere Versionsnummer aufweist, als die im Bootloader, dann wird halt die aus dem Flash genommen ... sollten darin aus irgendeinem Grund Einträge fehlen, wird der Bootloader die Variablen mit diesen fehlenden Namen eben auch nicht kennen.

Da AVM auch am TFFS-Treiber schon noch ab und an ändert und der bei der 6490 sogar noch ein paar zusätzliche Besonderheiten hat (es gibt halt zwei unabhängige Systeme in einer 6490 und nur eines von beiden kann den Hut aufhaben, wenn es um (Schreib-)Zugriffe auf das TFFS geht (inzwischen laufen aber m.W. auch die Lesezugriffe für das andere System nur noch im Client-/Server-Modus), muß halt das eine System sich beim Schreiben ins TFFS darauf verlassen, daß das andere diese korrekt umsetzt.

Erschwerend kommt dann noch hinzu, daß es sich um zwei Systeme handelt, die mit unterschiedlicher "endianess" arbeiten (das ist die Reihenfolge, in der "Zahlen" abgespeichert werden, die nicht in ein einzelnes Byte passen) und da reicht dann schon ein einziger Fehler im Code (z.B. eine fehlende Wandlung zwischen BE und LE), damit irgendeine Längenangabe (die aus mind. 2 Bytes besteht im Falle des TFFS) eine vollkommen andere Bedeutung und ungeahnte Auswirkungen haben kann.

Immerhin scheinst Du ja noch Glück zu haben bei einigen Boxen ... normalerweise steht auch die Aufteilung des SPI-Flashs in Partitionen im Environment und damit die Zuordnung, wo MTD3 und MTD4 (die Du ja löschen willst) überhaupt liegen. Wobei eben die 6490 in vieler Hinsicht "besonders" ist ... es gibt eben auch den Bootloader für den ATOM-Core und der ist wohl weitgehend dem Intel-Original nachempfunden. Das geht dann soweit (reine Interpretation), daß man im "cefdk"-Code Zeichenketten wie diese findet: "Load U-Boot from SPI/NOR Flash" - wenn ich das richtig beobachtet habe, wird hier aber (bei AVM) eben der EVA-Loader für den ARM-Core gelesen und kein "u-boot" (was auch wieder unter GPLv2 stünde - dann müßte AVM die Quellen für EVA inkl. FTP-Server veröffentlichen, wenn es da "common code" gibt).

Jedenfalls kann und darf man die Erfahrungen von anderen Systemen eben auch nicht einfach auf Puma-Boxen übertragen (deshalb sind auch viele Anleitungen für DSL-Modelle nicht ohne weiteres auf die DOCSIS-Boxen anwendbar). Wenn man hier wirklich der Ursache des Fehlers auf den Grund gehen will, bräuchte man eine (nicht zusätzlich verwurstelte) Box mit dem originalen Fehler ... neben dem Versuch, das Environment erst einmal auszulesen (was dann auch wieder Hinweise darauf geben könnte, welche Eintragungen in der Name-Table überhaupt vorhanden sind, denn auch dafür wird diese benötigt), bleibt einem dann noch die Möglichkeit, ein System aus dem Speicher zu starten und den TFFS-Inhalt einfach mal zu sichern. Bei Puma6-Boxen ist das allerding nicht trivial (weil eben auch wieder anders als bei den DSL-Boxen), aber die Kernel-Quellen sind ja vorhanden und da kann sich jeder selbst ein Bild machen, wie die Parameter für die (zwei) Kernel wohl aussehen müssen, damit der Bootloader auch zufrieden ist, die Kernel im Speicher finden und entpacken kann und die Steuerung dann an die Kernel übergibt.

Ich habe aber auch nur theoretische Vorstellungen und Ideen, wo das TFFS kaputtgehen könnte (vor ca. 1 1/2 Jahren habe ich einen Bug durch eine fehlerhafte Längenprüfung beim Einlesen einer neueren NameTable-Version aus dem TFFS-Flash im Kernel-Driver gefunden und an AVM gemeldet - das Problem und die von AVM ausgeführten Änderungen kann man sich durch Vorher-/Nachher-Vergleich in den TFFS-Quellen ansehen, ich hatte/habe keinen Bock mehr, das noch ausführlich zu beschreiben) ... woran es hier tatsächlich liegt, kann man (außer bei AVM) auch nur dann genauer untersuchen, wenn man sich mal den Inhalt so eines problematischen TFFS-Images verschafft (womit wir dann wieder beim Start aus dem RAM sind).

Aber das ganze Rüstzeug dazu (bis hin zum passend vorbereiteten System-Image) legt man sich eben nicht erst dann zu, wenn es bei einer Box brennt (bzw. man macht das mit einer tatsächlich funktionierenden) ... denn dann hat man naturgemäß deutlich schlechtere Chancen zu erkennen, was eigentlich "normal" ist, wo man selbst Fehler macht oder was am Ende den bereits vorhandenen Schäden zuzuschreiben wäre.

EDIT: Weil das oben vielleicht auch noch nicht deutlich genug zum Ausdruck kommt ... die ersten (bzw. ältere) 6490 hatten noch die Version @K der NameTable im Bootloader (da gab es den zusätzlichen Eintrag "wlan_ssid" noch nicht, mit dem sichergestellt wird, daß nicht jede Box mit derselben SSID im WLAN funken will) und da erfolgt dann tatsächlich seitens des Kernels nach einem Update des FRITZ!OS auch ein Update der NameTable in den TFFS-Partitionen, wenn der die heute aktuelle Version (bis @L kenne ich und neuere gibt es vielleicht auch schon, aber noch keine Quellen dafür) einkompiliert hat. Daher auch die Idee, daß es irgendeinen "Unfall" beim Schreiben der neuen NameTable geben könnte ... aber mehr als eine Idee, die sich aus der Annahme speist, daß dieser Schreibvorgang erfolgt, ist es dann (bisher) doch wieder nicht.