Die Dauer des Blinkens von Power ist schon mal interessant - wie überhaupt eine (möglichst exakte) Beschreibung des gesamten zeitlichen Verlaufs.
Während das System geladen wird, blinkt die Power-LED ja auch mal, das geht mit 5 Sekunden schon los, in denen der Bootloader auf eine Verbindung wartet und wenn die auf "steady" umschaltet, nachdem sie zwischenzeitlich kurz aus war, ist da eigentlich schon der Kernel geladen. Dann käme irgendwann die Initialisierung des DOCSIS-Teils, aber die läuft eigentlich gesondert zum Rest des Init-Prozesses ab ... wie gesagt, es macht einen Unterschied, ob wir von 10 oder von 30-40 Sekunden "Schleife" reden. Man müßte mal eine Vorstellung gewinnen, wo im Bootprozess der Neustart nun erfolgt.
Den Bootloader kannst Du eigentlich nicht zerschießen, der liegt in einer gesonderten Partition (device ist abhängig davon, wen man fragt ... das System oder den Bootloader selbst) und es gibt eigentlich sogar zwei davon ... für jeden Core (also jede Architektur) einen. Solltest Du allerdings mit dem ruKernelTool (und "clear MTD3/MTD4") an der Box zugange gewesen sein, könnte es gut sein, daß Du tatsächlich einen der Bootloader zerschossen hast, denn die Sichten der beiden Kerne auf die MTD-Devices sind durchaus unterschiedlich:
Code:
# ATOM
# cat /proc/mtd
dev: size erasesize name
mtd0: 00200000 00001000 "nmyx25"
mtd1: 00020000 00001000 "urlader"
mtd2: 00040000 00001000 "tffs (1)"
mtd3: 00040000 00001000 "tffs (2)"
mtd4: 000a0000 00001000 "config-space"
mtd5: 00080000 00001000 "cefdk"
mtd6: 00010000 00001000 "cefdk_config"
mtd7: 00010000 00001000 "gpt_backup"
Code:
# ARM
# cat /proc/mtd
dev: size erasesize name
mtd0: 00020000 00001000 "urlader"
mtd1: 00040000 00001000 "tffs (1)"
mtd2: 00040000 00001000 "tffs (2)"
mtd3: 000a0000 00001000 "config-space"
mtd4: 00080000 00001000 "cefdk"
mtd5: 00010000 00001000 "cefdk_config"
mtd6: 00010000 00001000 "gpt_backup"
und der FTP-Teil des Bootloaders sitzt bei der 6490 auch nicht im Bootloader für den ARM-Teil ("urlader"), sondern in dem für den ATOM-Kern ("cefdk") - und der kennt auch etwas andere Kommandos. Aber das ist wieder eine andere Geschichte ... die Unterschiede zu den DSL-Modellen gehen so weit (wenn ich das richtig sehe), daß der ARM-Bootloader selbst gar keinen Code für den Zugriff auf den Flash-Speicher mit den System-Partitionen hat (eMMC) und der ATOM-Bootloader ihm den ARM-Kernel von der "MMC card" (also dem Flash-Speicher) in den Hauptspeicher lädt, damit dieser ihn starten kann. Aber zurück zum Laden des Systems ...
Irgendwann im Laufe des Bootprozesses werden dann tatsächlich die beiden Systeme miteinander synchronisiert, d.h. der eine wartet auf den anderen. Allerdings geht die Basis-Kommunikation zwischen den Kernen normalerweise nicht über das Netzwerk, sondern über eine "mailbox" zwischen den Systemen (/dev/arm_atom_mbx auf der ARM-Seite). Insofern verstehe ich nicht richtig, wieso eine falsche Netzwerkkonfiguration da schon eine Rolle spielen sollte ... die andere interne Kommunikation beim NFS-Server (NFSv4) läuft intern und dafür werden die Adressen 169.254.1.1 auf dem ARM- und die 169.254.1.2 auf dem ATOM-Core verwendet.
Allerdings wird dann irgendwann im Verlauf des Bootprozesses tatsächlich auf den NFS-Server gewartet - jedoch sehe ich beim besten Willen nicht, wie eine IP-Adresse aus dem 192.168.irgendwas-Bereich (egal wohin sie geroutet wird) die lokale Kommunikation zwischen den 169.254.0.0/16-Adressen (so sind auch die Masken in der IP-Konfiguration) beeinflussen sollte. Solange diese Adressen auf "dev lan" gehen und am Switch beide Cores mit ihrem Port hängen, kann da doch eigentlich gar nichts mehr dazwischen kommen - das klingt mysteriös.
Was heißt denn eigentlich "sehr kleiner Bereich darüber" für DHCP? Entscheidend wäre hier die verwendete Maske für das LAN ... wenn Du die 192.168.10.241 eingestellt hast und dabei die Maske 255.255.255.240 verwendet hast (also /28-Maske), sollte trotzdem noch der ATOM-Core die 192.168.10.254 bekommen können, wenn Du nicht die DHCP-Range bis dahin ausgedehnt hast. Eigentlich sollte aber das GUI solche Fehlkonfigurationen auch von sich aus verhindern ... also bitte noch einmal genau, was da eingestellt wurde. Ich würde das glatt noch einmal an einer 6490 probieren wollen ... ist zwar eine andere Firmware-Version, aber ich kann mir nur schwer vorstellen, daß sich dort etwas so Grundlegendes geändert haben soll.
Wenn ein Core wegen total falscher Konfiguration das "lan"-Interface nicht zum Laufen kriegt, könnte davon vielleicht auch die zweite Adresse (die läuft als lan:0) betroffen sein ... aber dann hättest Du so eine Adresskombination gar nicht erst über das GUI in die Box kriegen sollen - das ist der Punkt, an dem ich die ganzen Vorgänge beim besten Willen nicht verstehe.
Die zweite - neben der Zeitdauer der Schleife - zu klärende Frage wäre es, ob der Switch der 6490 zwischenzeitlich schon aktiviert wurde (ein Hardware-Switch - per LAN-Kabel angeschlossen - zeigt das auch an). Wenn das der Fall ist, sollte auch die Initialisierung des Netzwerks erst einmal funktionieren und die Box müßte in der verbleibenden Zeit bis zum Reboot wenigstens mal auf einen ARP-Request für die 169.254.1.1 antworten, wenn das Interface hochkommt - wahlweise auch auf die .2, denn pingen lassen sich diese Interfaces ja auch. Die MAC-Adresse des ATOM-Cores ist dabei im letzten Byte um eins höher als die des ARM-Cores.
Der Watchdog für den Bootvorgang steht normalerweise auf 300 Sekunden ... bevor der also die Box neu startet, weil die Initialisierung nicht zu einem Ende kommt, dauert das etwas und da sollte sich - wenn kein anderer Grund als der Watchdog für ein Reboot verantwortlich ist - in diesen fünf Minuten schon einiges feststellen lassen.
Deine eigenen Einstellungen sind wesentlich gefährdeter als die vom Provider ... alles, was der dort hinterlegt hat, kommt ohnehin "frisch", wenn man die Box erst mal dazu bringt, sich mit dem CMTS ins Benehmen zu setzen - dauert dann vielleicht etwas länger, bis die Frequenzen abgesucht sind, aber das ist ja nicht das Problem. Ich hatte eigentlich den Verdacht, daß es am DOCSIS-Teil hängen könnte ... wenn da allerdings gar kein Coax-Kabel dran ist, muß das schon sehr sehr früh bei dessen Initialisierung sein.
Man könnte die Box jedenfalls durch die Angabe von "141.06.26,recovered=
n" (am besten mit "n=1") dazu bewegen, anstelle des alten Inhalts der "config-space"-Partition eine leere Partition zu benutzen. Ob das Dein Problem löst, weiß ich nicht. Eine weitere Idee wäre es, den "wlan_key" im Environment zu ändern über EVA. Wenn der auch in die Berechnung des boxinternen Kennworts einfließt, wie bei den DSL-Modellen (er ist m.E. dabei, aber noch irgendetwas außer "wlan_key" und "maca" - zumindest war es bei der 6360 wohl so), dann kann das OS keine einzige verschlüsselte Angabe in den TFFS-Inhalten mehr entschlüsseln ... ob das schon für die Verzweiflungstat des Löschens des gesamten TFFS (aka Werkseinstellungen) ausreichend ist, weiß ich aber auch nicht (und probiere ich jetzt auch nicht aus).
Zumindest könnte man mit dem "recovered=1"-Zusatz in "firmware_info" auch noch erkennen, wie weit die Box überhaupt kommt. Wenn auf dem ARM-Core (der schreibt das TFFS) S01-head im Rahmen des Init-Prozesses abgearbeitet wird, ist hinterher das "recovered" aus dem Environment verschwunden und dort steht wieder nur die Ausgabe von /etc/version ... damit wüßte man aber auch, daß es der ARM-Core wenigsten bis an diese Stelle geschafft hat.
Ansonsten macht eine "Ferndiagnose" gerade bei der 6490 eben wenig Sinn ... sie unterscheidet sich auch an dieser Stelle so sehr von den anderen Modellen, daß einige der alten Weisheiten nicht mehr gelten und man keinesfalls mit solchen Geschichten wie "ruKernelTool" an der Box
etwas ändern sollte (reiner Lesezugriff ist unkritisch, der geht dann eben nur schief). Es fängt eben schon damit an, daß die Sicht auf die Partitionen im Urlader-Environment eine vollkommen andere ist, als das ruKernelTool sie normalerweise hat:
Code:
mtd0 0x0,0x4000000
mtd1 0x4000000,0x4800000
mtd2 0xa0000,0xc0000
mtd3 0xc0000,0x100000
mtd4 0x100000,0x140000
mtd5 0x140000,0x1e0000
mtd6 0x4800000,0x8800000
mtd7 0x8800000,0x9000000
mtd8 0x0,0x80000
mtd9 0x80000,0x90000
mtd10 0x90000,0xa0000
mtd11 0x9000000,0xd000000
mtd12 0xd000000,0xd800000
mtd13 0xd800000,0x11800000
mtd14 0x11800000,0x12000000
mtd8 ist "cefdk", mtd9 "cefdk_config", mtd10 das Backup der Partiotiontabelle des eMMC und danach kommen dann im Layout des SPI-Flash wohl der ARM-Bootloader (mtd2) und die beiden TFFS-Partitionen (mtd3/mtd4), gefolgt von mtd5 mit "config-space" (das ist die DOCSIS-Konfiguration des Providers).
Wie gesagt, der Weg des
Löschens der MTD3/MTD4-Inhalte durch ruKernelTool beinhaltet eben genau das ... ein komplettes Löschen durch Speichern einer Datei der Länge 0. In der Folge hat man eine leere TFFS-Partition, aber die enthält dann eben auch nicht die "basics" des Urlader-Environments und die ganzen dort erwarteten Variablen.
Diese Werte werden bei einer DSL-Box aus dem Bootloader regeneriert beim nächsten Neustart (daher auch die Empfehlung, nach so einer Aktion mit dem ruKernelTool die Box noch einmal neu zu starten, damit auch von Beginn an bei diesem zweiten Start ein korrektes Urlader-Environment vorliegt) - ob das bei einer 6490 auch ohne weiteres funktioniert, kann ich nicht einschätzen.
Wenn ich irgendwann mal dazu gezwungen wäre, würde ich als erstes in so einem Falle vielleicht auch versuchen, die MTD-Partitionen zu löschen, wie es das ruKernelTool macht, dann aber noch einmal den Bootloader zu benutzen und mit irgendeinem "SETENV"-Kommando einen Wert einzutragen. Die Zeile "[%s] Environment is going to be re-initialised." im "cefdk"-Dump könnte ja ein Indiz sein, daß dabei vielleicht doch der Bootloader in der Lage wäre, das Environment wieder mit den Basis-Daten zu befüllen ... aber ich würde das fast bezweifeln wollen.
Während aber bei den "normalen" Boxen die individuellen Daten (MAC-Adresse, WLAN-Key, CWMP-Account) auch noch einmal in der "urlader"-Partition stehen (von wo sie beim Restaurieren der TFFS-Partition dann auch kopiert werden können), ist das bei der 6490 nicht der Fall.
Dort tauchen diese Daten nur in den TFFS-Partitionen und in der nmyx25 auf (letztere ist offenbar der komplette SPI-Flash auf einen Schlag, daher sind da auch "tffs (1)" und "tffs (2)" mit diesen Daten noch einmal enthalten).
Das läßt mich zu der Vermutung gelangen, daß es eben doch keine so gute Idee ist, einfach MTD3 und MTD4 auch bei einer 6490 zu löschen und dabei dann darauf zu bauen, daß die schon irgendwie wiederhergestellt werden können ... zumindest mit den individuellen Daten halte ich das für sehr unwahrscheinlich.
Bleibt also nur das Auslesen der Environment-Variablen über den Bootloader (die Liste, die das ruKernelTool einzeln abfragt, ist alles andere als komplett und sollte nicht als Basis dienen) und das Basteln eines TFFS-Images mit diesen Daten, was dann wieder per FTP-STOR-Kommando in die TFFS-Partitionen geschrieben werden kann - ich sage mal, es sollte zumindest so sein, daß man es speichern kann.
Das wirklich gefährliche Experimentieren an dieser Stelle überlasse ich aber anderen ... ich würde z.B. immer erst einmal hingehen und beim Versuch des Überschreibens von MTD3/MTD4 (ich würde auch erst einmal nur eine der beiden testweise überschreiben, die Quellen zum TFFS sind ja verfügbar und man kann sich ansehen, wie die Synchronisation dort abläuft) einen Dump einer bekanntermaßen funktionierenden TFFS-Partition verwenden und mir ansehen, ob das funktioniert - aber ich interessiere mich ohnehin mehr für die Innereien des FRITZ!OS als für die Feinheiten des Bootloaders.
Jetzt habe ich mich doch wieder hinreißen lassen und mehr zur 6490 geschrieben, als ich eigentlich wollte ... andererseits sind das alles Infos, die seit einem guten Jahr über die 6490 schon bekannt sind und langsam kriegen die auch einen Bart. Wenn die ersten 6490 auf dem freien Markt auftauchen sollten (nach den Änderungen von FTEG und TKG), wird es sicherlich auch einfacher sein, einfach mal etwas zu experimentieren - und zwar ohne die Gefahr, seine Box zu bricken, weil dann vermutlich/wahrscheinlich auch ein Recovery-Programm dazugehören wird. Zumindest kann ich mir nicht vorstellen, daß AVM dann jede einzelne 6490 bei einem Problem als Reklamation auf den Tisch kriegen will ...
Um noch einmal auf Dein eigentliches Problem zurückzukommen ... wenn Du nur die IP-Einstellungen geändert hast, gib mal diese Einstellungen komplett und richtig an und ich konfiguriere eine 6490 glatt mal genauso. Sollte die dann auch in die ewigen Jagdgründe eingehen (was eben bei einer GUI-Einstellung nicht der Fall sein
darf), habe ich wenigstens etwas zum eigenen Experimentieren, weil ich dann ja ebenfalls nicht darum herumkäme ... allerdings habe ich eben schon vorher die Möglichkeit, einen Dump der TFFS-Partitionen zu machen, bevor ich irgendetwas ändere.
