Fritzbox 06.20 entpacken und wieder packen geht nicht

full2000 schrieb:

Geht das etwa so nicht?

Zum Vergrößern anklicken....

Kann ich nicht sagen, ich benutze kein mit Freetz gepacktes Image. Daher weiß ich auch nicht, ob da alles richtig eingepackt wird, um ein System auf einen neuen Kernel + ein neues FS zu aktualisieren.

EDIT: Es wird von Freetz alles ordentlich eingepackt, bitte nicht ins Bockshorn jagen lassen.

Willst Du nicht einfach mal ein 06.20 flashen ? Der Rückweg auf Deine 06.05 ist nur ein einziger Befehl in einer Telnet-Session und braucht kein Recover - es gibt zwei Systeme in einer 7490. Die 06.05-Einstellungen trotzdem sichern und gut weglegen.

full2000 schrieb:

Wenn du mir da noch ein paar Infos geben könntest...

Zum Vergrößern anklicken....

Dachte zwar, ich hätte es schon geschrieben ... aber
nochmal als Einzeiler zum Rauskopieren (auch für spätere Leser).

[EDIT]Etwas kürzer und daher leichter zu kopieren:
[/EDIT]


Wenn Du dann ein 06.20 in der Box hast (in der anderen Partition immer noch ein 06.05), mußt Du ohnehin auf die 06.05 zurückschalten (bei der Vorgehensweise, die ich Dir vorgeschlagen habe), damit Du Dein eigenes SquashFS in die inaktive Wrapper-Partition kopieren kannst. Und die für das 06.20 ist eben nur dann inaktiv, wenn das andere System gestartet wurde.

full2000 schrieb:

@PeterPawn: Hast du noch einen Tipp zu meinen Edits oben?

Zum Vergrößern anklicken....

Sch... Edits, kriegt man immer gar nicht richtig mit.

1. Mit dem echo nach /proc/sys/urlader/environment wird nur die linux_fs_start-Variable wirklich geschrieben, es ist ein procfs ... das ist ein wenig anders als ein reguläres File.

2. Das Image-File nach MTDirgendwas zu mounten, verstehe ich nicht.

3. Ich habe gerade (um meine Antwort zu verifizieren) noch einmal in ein AVM-Firmware-Image geschaut (die 113.06.20 von AVM direkt) und dabei festgestellt, daß dort eben nur das SquashFS in der Datei filesystem.image enthalten ist und da liegt dann auch schon der Grund, warum Du das mit Freetz gepackte Image nicht auf der 7490 zum Laufen kriegst. Da wird dann beim Start des neuen Systems eben nicht das SquashFS als rootfs gemounted, sondern der äußere Wrapper. Spätestens seitdem AVM das so macht - und unter der Annahme, daß Freetz das AVM-install-Skript 1:1 wieder einpackt - dürfte kein Mensch mehr ein Freetz-Image über das AVM-GUI lauffähig auf die 7490 kriegen ... und Du bist offenbar der Erste, der darüber gestolpert ist. Das zeigt entweder eine geringe Verbreitung der 7490 bei den Freetz-Nutzern an oder die flashen alle nur noch direkt über ein schon vorhandenes Freetz in der Box. Mir kam das auch schon etwas komisch vor, als Du gestern den Inhalt des filesystem.image aus dem Freetz-Image beschrieben hast, denn es stand/steht ja in direktem Widerspruch zu dem, was ich weiter oben zum Wrapper-FS und der unklaren Zuständigkeit für dessen "Restaurierung" bei Fehlern geschrieben habe.
Das kommt eben davon, wenn man schnell antworten will, ohne sich selbst erst einmal richtig schlau zu machen. Auch das AVM-Image enthält ein Wrapper-FS als SquashFS, in den sich das eigentliche root-Filesystem als "filesystem_core.squashfs" befindet. Das "äußere" SquashFS wird bei der Installation des Images dann zum YaFFS (also die Dateien als Inhalt werden von einem FS in das andere kopiert).

Wenn Du jetzt Dein Freetz-Firmware-Image (das TAR-File) auf die Box bringst, müßtest Du folgendermaßen weiter machen:
Anschließend auf das andere System umschalten (s.o.) und neu starten.

Das AVM-Skript kopiert die Datei "/var/tmp/filesystem.image" direkt unter dem richtigen Namen in den inaktiven Wrapper, da entfällt der Zwischenschritt mit dem Mount für "freetz_wrapper".Falsch, es wird ein SquashFS als Wrapper gemounted und dessen gesamter Inhalt (da gehört dann auch das rootfs dazu) in die YaFFS-Partition kopiert.

Daß der Kernel im neuen System zum rootfs passen sollte, versteht sich sicherlich von selbst. Das Kopieren des SquashFS ersetzt also nicht den gestern beschriebenen Ablauf mit Update auf 06.20 und "switchen" auf 06.05 ... es kommt erst danach, wenn das 06.05 wieder läuft.

Oder Du suchst Dir die Stelle in fwmod, wo das Packen des filesystem.image für die 7490 falsch gemacht wird und änderst gleich da, dann kannst Du das Freetz-Image auch über AVM-GUI flashen lassen (wenn die Signaturprüfung mitspielt - also im zweiten Anlauf ignoriert werden kann -, dazu gibt es wohl immer noch keine verläßliche Aussage).
Die Frage der Signaturprüfung ist für mich immer noch ungeklärt, bei meiner 7490 (allerdings läuft dort als Besonderheit das HTTP-GUI auf Port 1080) wird nach dem Upload eines nicht signierten Firmware-Updates irgendwann mal der ctlmgr gekillt, ohne daß das install-Skript (das wurde aber ordentlich nach /var entpackt, genau wie alle anderen Dateien aus dem Image) gestartet wurde. Das werde ich erst noch einmal mit "Standardport" testen, bevor ich wieder etwas Falsches behaupte.
Das Flashen eines Freetz-Images über das AVM-GUI funktioniert einwandfrei. Lediglich "fremde" laufende Prozesse, die von der AVM-Firmware nicht richtig beendet werden können (bei mir ein dropbear), bringen den Prozess ins Stocken. Ein Timeout existiert da vielleicht nicht, wenn ist es größer als 5 Minuten. Nachdem ich eigene Prozesse vor dem Update beendet hatte, lief das Update mit einem Freetz-Image nach Nachfrage (keine AVM-Firmware) ohne Probleme durch. Ein anschließendes "Umschalten" auf das vorher genutzte Original-Image mit 06.20 funktionierte auch problemlos.

EDIT: Manchmal ist man eben betriebsblind. Du kannst bei den o.a. Kommandos das umount natürlich auch einfach als "umount /var/wrapper" ausführen. :-Ö

Abend

Das hört sich ja superinteressant an.

Ihr könnt also zwischen zwei verschiedene Fritz!OS wechseln wenn sie den selben Kernel benutzen!?
Also einmal recovern, einmal normal flashen und dann mit linux_fs_start 1/0 wechseln.
Hab ich das soweit verstanden?

koyaanisqatsi schrieb:

Hab ich das soweit verstanden?

Zum Vergrößern anklicken....

Ich denke schon. Also ich denke schon, Du hast das richtig verstanden.

Das Umschalten zwischen zwei "Systemen" auf einer 7490 funktioniert eben, weil es jeweils 2 Partitionen für den kernel und das filesystem gibt, wie bei einer 6360 auch, da ist es aber NOR-Flash und das Kopieren funktioniert m.W. nicht mit einem einfachen Wrapper.

Das mit den zwei FRITZ!OS ist halt etwas mißverständlich. Wenn man in der einen Partition 06.05 und in der anderen 06.20 hat, kann man ohne weiteres zwischen diesen beiden Versionen hin- und herschalten - vorausgesetzt die Settings passen auch. Diese (also das, was im TFFS steht) gibt es eben nur einmal. Dann spielt es auch keine Rolle, ob beide Kernel übereinstimmen ... nur das rootfs muß eben immer zu seinem Kernel passen.

Ich bin aber gerade (die LEDs habe ich wg. Problemen mit dem Debugger erst mal zurückgestellt) dabei, eine Art "Bootmanager" für 7490 zu erstellen, der auch zwei getrennte Sets von Einstellungen verwaltet und diese beim Umschalten auf das jeweils andere System austauscht.
Das ist dann vielleicht beim nächsten Labor-Start eine Möglichkeit für 7490-Besitzer, die jeweilige Laborversion "ohne Risiko" zu testen und/oder einfacher zwischen Labor- und Release-Version zu vergleichen.

@full2000:
Also ich habe jetzt - aus reiner Neugierde - selbst mal ein Firmware-Image mit Freetz packen lassen (also im Rahmen eines normalen "make") und da kommt ganz normal ein ordentliches Firmware-Image bei heraus. Die enthaltene tmp/filesystem.image ist ordentlich (wie beim AVM-Image auch) ein SquashFS, bei Dir war das ja noch ein yaffs mit eingebettetem squashfs in #15. Da stimmt etwas nicht ...

Irgendetwas mußt Du dann wohl anders machen als andere, vielleicht überprüfst Du den Build-Prozess ja noch einmal. :gruebel: Ich hatte auch verstanden, Du hättest diverse verschiedene Vorgehensweisen getestet, von 06.05/06.20 mit Freetz-Make bis zum Entpacken/Packen für beide Versionen. Wenn das richtig verstanden war, solltest Du vielleicht mal einem Beitrag Dein .config-File (als Anhang !, bitte nicht im Text) hinzufügen.

Das Freetz-Image ließ sich dann auch über das AVM-GUI einwandfrei flashen, wenn keine eigenen zusätzlichen Dienste auf der Box aktiv waren (diese mußte ich vorher beenden).

EDIT:
So, erst steigerte sich die Verwirrung noch, jetzt habe ich es aber (hoffentlich).

Die Datei "filesystem.image" ist in beiden Fällen (AVM und Freetz) ein SquashFS, das dann seinerseits das "richtige" rootfs wieder als SquashFS in der Datei filesystem_core.squashfs enthält.

Das Install-Script mounted das äußere SquashFS auf /var/tmp/fs und kopiert dann rekursiv dessen Inhalt in ein leeres YaFFS. Das Device für dieses YaFFS wird zuerst gelöscht (mit update_kernel-Binary) und dann gemounted unter /var/tmp/fs_mtd, wobei die FS-Strukturen automatisch erstellt werden. Dabei wird dann also im Prinzip das Wrapper-FS von SquashFS nach YaFFS "konvertiert".

Damit wird also auch die Busybox und die ulibc im Wrapper doch jedesmal aus dem Firmware-Image neu geschrieben.

Das klärt zwar noch nicht mein Verständnisproblem beim Recover, aber da schneide ich als nächstes einfach mal mit, was das Recovery-Programm da seinerseits in die filesystem-Partition schreibt und ob das dann nicht doch das rootfs als SquashFS direkt in einem YaFFS-Wrapper ist.

@full2000:
Das heißt dann doch wieder, daß Deine Datei filesystem.image korrekt war - sorry für die von mir angerichtete Verwirrung. Daß mir der Prozess noch nicht 100%ig klar war, hatte ich ja geschrieben ... ich habe auch keine Korrekturen meiner fehlerhaften Thesen durch andere, die es besser wußten, gelesen.

Da das Dein Problem dann aber immer noch nicht erklärt, würde ich nun wieder als erstes den Start einer 06.20 (meinetwegen auch einer 06.05, wenn Du ohne eigenes Image nicht auf die 06.20 willst) aus beiden Partitionen testen, um sicherzustellen, daß Dich nicht doch ein Hardware-Defekt zum Narren hält. Deshalb würde ich auch in beide Partitionen das identische System bringen, dann kann man über den Vergleich der Hashes (für den Kernel und - wenn schon nicht für das yaffs, weil da unterschiedliche Zeitstempel drin sein dürften, so doch - für das embedded SquashFS-File mit dem rootfs) auch sichergehen, daß da keine Unterschiede durch Fehler in NAND bestehen (warum die dann aber nicht erkannt werden, dafür hätte ich keine Theorie).
Beide Systeme zu testen meint dann eben, eines starten, linux_fs_start notieren, linux_fs_start ändern und neu starten. Dann erneut linux_fs_start prüfen und es sollte nun auch der andere Wert sein. Wenn das dann wirklich geklärt ist und Du beim Flashen des eigenen Images wieder kein lauffähiges System erhältst, würde ich mit dem ruKT (vorher klären, wie man das verwendet) und "Halten in ADAM2" (ist zwar EVA, heißt aber m.W. im ruKT so) per "quote SETENV linux_fs_start <wert>" auf das vorherige System zurückgehen (also ohne Recover und irgendwas neu zu flashen) und aus dem anderen System heraus den Inhalt des filesystem-MTDs prüfen. Anhand der Dauer des Bootvorgangs sollte man abschätzen können, ob da der Kernel richtig geladen wurde und ob es vor oder nach dem Mounten des regulären rootfs zum Problem kommt. Also bitte auch mal die LED-Anzeigen in zeitlicher Folge bei einem fehlgeschlagenen Start notieren, damit man das vergleichen kann.

EDIT2: Ich habe jetzt meine diversen Irrtümer in den vorhergehenden Posts versucht zu kennzeichnen und zu korrigieren. Sollten da noch weitere Stellen sein, die ich überlesen habe, würde ich gerne mit der Nase darauf gestoßen werden, damit spätere Leser nicht unnötig verwirrt werden.

full2000 schrieb:

Bei mir ist es ja auch so, dass nach dem Flashen die Box hängt.

Zum Vergrößern anklicken....

Das ist natürlich eine etwas unklare Beschreibung. Bleibt die Box vor oder nach dem Neustart stehen bzw. vor oder nach der "Nachfrage" wegen Nicht-AVM-Firmware ?

Nur einfach hängt, kann ja auch mal passieren, vielleicht hilft ihr ja auch eine "blaue Pille" ?

Selbst wenn es bei Dir dann vielleicht doch nur nicht beendete Dienste waren (es geht eigentlich auch mehr um irgendwelche Mounts, die sich nicht dismounten lassen wegen dieser Dienste), habe ich trotzdem einiges über den Install-Prozess bei der 7490 gelernt, der sich schon gewaltig von dem bei anderen Modellen unterscheidet und ungeahnte Möglichkeiten bietet.

full2000 schrieb:

Das eizige, was Probleme macht, ist die AVM Weboberfläche. Sobald ich an den Telefoneinstellungen etwas ändern möchte, stürtzt die Box komplett ab und startet neu.

Zum Vergrößern anklicken....

Das ist (vermutlich) ein Freetz-Bug, der aber bisher leider nicht gelöst werden konnte.

AVM-Recovery bei 7490

Nur der Vollständigkeit halber als Ergänzung zu dem vor einigen Tagen von mir geschriebenen:

Ich habe bisher nirgendwo etwas zum Flash-Vorgang bei AVM-Recovery für die 7490 hier gefunden, vielleicht bin ich aber auch nur zu blöd zum Suchen.

Das AVM-Recovery-Programm schreibt (ich habe es allerdings nur zweimal getestet, einmal mit jeder Einstellung von "linux_fs_start") immer in die aktive Partition, anders als beim Flashen über das GUI; dabei kommt ja dann das install-Skript aus dem Firmware-Image zum Einsatz und das schreibt in die inaktive. Die Entscheidung fällt bei Recovery auch nicht einfach die EVA ... das ist wohl schon "more sophisticated", da die EVA mit dem Restaurieren des "Systems" (also des Kernels und des Wrapper-FS) eigentlich gar nichts mehr zu tun hat.

Beim Flashen wird - wie bei den anderen Modellen auch - der FTP-Server in EVA verwendet, soweit keine Überraschung, das Auslesen der Box-Infos ist im ruKT ja auch schon implementiert. Zu meiner Überraschung funktioniert aber nicht einmal das "Halten in ADAM2-FTP" bei einer 7490, da skyteddy wohl vorsichtshalber eine "komplette" Sperre für die 7490 eingebaut hat.
Wenigstens die Umschaltung zwischen den beiden Systemen der 7490 sollte aber problemlos auch für das ruKT machbar sein, mal sehen, ob sich da etwas in der Richtung tun wird.

Der Vorgang der "Erkennung" der Box (nachdem die IP-Adresse mit UDP-BC an 192.168.178.255 auf Port 5035 versucht wurde zu ermitteln, bei mir war ein paralleles ARP dann wohl doch schneller) läuft folgendermaßen ab:
Warum sich das AVM-Recovery-Programm nach dem "RETR env" noch einmal neu anmeldet, würde mich schon interessieren ... in erster Linie, ob das ein Workaround für ein bestehendes Problem ist oder nur eine Frage der Programmierung, weil beim "RETR count" nichts über den aktuellen Status der FTP-Verbindung bekannt ist (und ein USER-Kommando beim FTP auf dem Kommando-Channel sogar mittendrin eigentlich immer erlaubt ist).
Der FTP-Server bleibt jedenfalls nach dem "BYE" weiterhin aktiv, ob es da ein Timeout gibt, nach dem er die Box von sich aus neu startet, weiß ich nicht, ist aber meines Erachtens eher unwahrscheinlich.
Ob die bei "RETR count" geholten Stände des "Betriebsstundenzählers" (irgendwelche ansonsten unerreichbaren Zellen in NOR, die im laufenden Betrieb wohl von "run_clock" beschrieben werden) wirklich stimmig sind, würde ich angesichts dieser Werte
allerdings bezweifeln. Wenn AVM da nicht schon irgendetwas Spezielles "codiert" hinterlegt und "run_clock" da gar nichts mehr hineinschreibt, wäre doch der IV für die Berechnung des Kennworts zur Verschlüsselung des privaten Key-Files mal eine "nette" Idee. Vielleicht ist es aber auch nur ein weiterer "Blinddarm".

Nachdem die Daten der Box gesammelt wurden, werden die MTD-Partitionen 3 und 4 (das sind nur die Nummern für die EVA, das FRITZ!OS vergibt seine eigenen) mit einem aufbereiteten Inhalt - da werden die vorher von der Box ermittelten Daten wieder verwendet - überschrieben:
mtd4 ist dann noch einmal (im Kommandokanal und auch der komplette Dateninhalt der übertragenen Datei bis aufs Byte) identisch. Die übertragenen Daten umfassen offenbar die komplette NOR-Partition für das TFFS (Größe 0x60000 Byte). Ich habe keine Ahnung, ob das beim AVM-Recovery für frühere Modelle auch schon so war ... ansonsten wurden da die Daten im TFFS wohl wenigstens teilweise (was das Urlader-Environment angeht) auch bei ungültigem TFFS-Inhalt aus MTD2 (das Environment ist ja nach den Treiberquellen zu urteilen auch ein "kleines" TFFS) restauriert.
Jedenfalls bestehen die übertragenen Daten aus der kompletten Index-Liste (und den Namen der Variablen) inkl. der (ja getrennt gespeicherten) Werte, netterweise wird sogar der "crash"-Eintrags aus dem Environment wieder restauriert. Am Ende befinden sich dann natürlich jede Menge gesetzte Bits, wie es sich für einen gelöschten NOR-Flash gehört. Ob da auch die einfachere Variante mit einer 0-Byte-Datei als "Upload" funktioniert wie bei früheren Modellen, habe ich nicht getestet.

Aber egal, denn jetzt weicht es definitiv von anderen Modellen ab (zumindest von dem, was ich früher bei AVM-Recovery gesehen habe):
Offenbar wird also kein "Dateisystem" oder "Image" in eine MTD-Partition geschrieben, es wird ein komplettes lauffähiges System in den RAM der Box übertragen (vorher die Größe des verfügbaren Speichers im Environment so gesetzt, daß das System sich im RAM nicht selbst überschreibt) und anschließend mit temporären Einstellungen (kernel_args_tmp) dieser Stub gestartet. Da in der Konversation kein "REBOOT" zu sehen ist, wird wohl beim Schließen der FTP-Verbindung auf das Vorhandensein von kernel_args_tmp getestet oder einfach nach einem STOR in das RAM automatisch immer ein "Neustart" ausgeführt seitens der EVA.

Die generelle Möglichkeit des Starts eines "externen" Systems nach dem Speichern im RAM der Box war ja bereits bekannt, meines Wissens aber die korrekte Vorgehensweise zum Starten eines solchen Systems nicht (bzw. ich habe nichts dazu gefunden). Das öffnet aber wieder einem Angreifer aus dem LAN Tür und Tor auf der Box, da braucht er nicht einmal das System der Box zu verändern. Es genügt vollkommen ein Relay im LAN ... und solange die EVA weiterhin ohne besondere Maßnahmen ansprechbar ist, ist das wohl auch nicht sinnvoll zu verteidigen.

Wenn das auch bei Boxen mit NOR-Flash so funktionieren sollte, ist wohl für einen Angreifer aus dem LAN auch dort ein ganz simpler Angriff in der Form möglich, daß er beim Neustart der Box per EVA-FTP-Server sein eigenes System-Image in den Speicher schreibt und dieses dann ausführen läßt.
Das Auslesen von Daten aus dem TFFS (notfalls des kompletten MTD) und das "Schieben" ins LAN (ggf. per Broadcast, wenn man sich den Aufwand einer Netzwerk-Konfiguration sparen will) ist schnell erledigt, einen Zugriff auf das installierte FRITZ!OS benötigt man dafür gar nicht erst und auch ein "modifiziertes" Firmware-Image braucht man dafür nicht flashen. Wenn sich ein Neustart der Box mal um 10-15 Sekunden (das ist eine eher konservative Schätzung) verzögert, wird das wohl den Wenigsten auffallen.
Anschließend kann man die Daten aus dem erbeuteten TFFS (da die "Schlüsseldaten" auch gleich immer noch mit dabei sind) in aller Ruhe auseinandernehmen und dann später damit die Box übernehmen, auch wenn der Besitzer ansonsten alles richtig macht und selbst die Credentials im Klartext (also ohne TLS) weder im GUI noch im FTP-Server oder wo auch immer eingibt.