[Problem] push_firmware schlägt fehl

[Miyamoto]

Moin!
Ich versuche Freetz mit FritzOS 6.60 auf meine 7490 zu bekommen - leider scheitere ich
Über die originale Firmware geht es ja nicht, da jetzt eine Signatur von AVM geprüft wird. Ergo: tools/push_firmware nutzen und direkt nach dem Neustart pushen lassen.

Problem: Ich bekomme keine Verbindung:

user@laptop:~/temp/freetz/build$ tools/push_firmware images/7490_06.60-freetz-devel-13867.de_20160807-125038.image -f 

Hint: file seems to be a full firmware image archive in 'tar' format
containing the 'kernel.image'. Now trying to unpack and use that image.


ftp command found.


 * You should now reboot your box (192.168.178.1).
         Waiting for box to shut down.
         Tip: switch off, if reboot is not detected because it happens too quickly
   ..............


 * No reply from box (192.168.178.1). Assuming switch-off or restart.
         Trying to re-detect box.
   ........................................................


 * Box is back up again.
         Initiating transfer.
         Tip: switch off/on box several times, if FTP client cannot log in ...


ftp: connect: Connection refused
Not connected.
Debugging on (debug=1).
Not connected.
Not connected.
Not connected.
Not connected.

Suchen hier im Forum und anderswo hat nur den Tip zutage gefördert, es mehrfach zu versuchen. Aber nach mehr als 20 Versuchen hat es immer noch nicht geklappt. Auch Neustart der Box mehrfach kurz hintereinander und dann erst den push versuchen hat nix gebracht.

Hat hier jemand einen Tip, woran es liegen könnte? Oder 'n Vorschlag, wie es sonst klappen könnte?

 

[PeterPawn]

Das "ergo" funktioniert mit viel Glück auf alten NOR-Boxen. Die NAND-Modelle arbeiten anders, Vorschläge für das Installieren der Firmware gibt es auch zuhauf ... irgendwo habe ich sogar einen (ungetesteten) Patch für die /sbin/flash_update im wrapper-FS angehangen, mit dem man anstelle des aktiven Systems das inaktive flashen können sollte, wenn man das resultierende Image (also Kernel+FS, wie das aussehen muß, ist auch irgendwo beschrieben) in den RAM lädt und auch dafür gibt es die passenden Skript-Dateien im YourFritz-Repo auf GitHub.

Wobei ich schon staune, wo man beim Suchen hier im Forum tatsächlich den Tipp finden sollte, bei der 7490 (oder irgendeinem anderen NAND-Modell) einfach so lange mit "push_firmware" zu probieren, bis es irgendwann mal klappt. Eigentlich sollte man da eher die Information finden, daß es mit "push_firmware" gar nicht funktionieren kann, weil dort einfach die notwendigen FTP-Kommandos gar nicht vorhanden sind. Das neueste, was dort "eingearbeitet" wurde, war die Alice 7570 vor fünf Jahren ... so lange gibt es bei AVM noch gar keine NAND-Modelle.

 

[Miyamoto]

Da kann man mal sehen, wie lange ich nicht mehr auf dem Wege flashen mußte - war wohl noch zu 7270- oder 7390-Zeiten...

Danke für die Infos und auch für die Arbeit, die Du da anscheinend schon geleistet hast. Hast Du noch einen Link zur Hand, wie ich jetzt das Image auf die Box bekomme, das ich auf der Platte schon liegen habe?

 

[PeterPawn]

Der Patch-Vorschlag (nochmal: ungetestet, nur mal schnell eingetippt) liegt hier, ob "fwmod" damit klarkommt, wenn man das /sbin/flash_update in der "modified"-Variante der Firmware anpassen will, weiß ich nicht (also testen). Auch nicht vergessen, ein "touch .inactive" dann irgendwo einzubauen, diese ".inactive" muß in der Wurzel des Wrapper-FS liegen.

Wenn "fwmod" damit umgehen kann, einfach das fertige Freetz-Image wieder auspacken, Kernel und Dateisystem um 8 Byte kürzen und hintereinander kopieren - das kann man dann in den RAM laden und starten. Irgendwo habe ich ein Skript für den "Umbau" eines Firmware-Images (also des Tarballs) in ein solches "in-memory image" ... mal schauen, ob ich es auf Anhieb finde. Ansonsten ist das auch schnell heruntergeschrieben ... auch das muß eben nur die beiden Dateien aus dem Tarball extrahieren (bei Freetz könnte man tatsächlich das Einpacken in ein image-File auch gleich weglassen), ggf. die TI-Prüfsumme entfernen und die Dateien hintereinander kopieren.

- - - Aktualisiert - - -

Ich habe mal ein Beispiel eingecheckt, wie man ein "normales Firmware-Image" in eines umwandeln kann, das für das Laden ins RAM geeignet ist: https://github.com/PeterPawn/YourFritz/blob/master/eva_tools/image2ram

Das ist wieder als Filter ausgelegt (also originales Image auf STDIN, Ausgabe auf STDOUT), weil man es so gleich anstelle eines "cat" beim FTP-Upload einsetzen kann und nicht erst eine "Zwischendatei" erzeugen muß ... wobei das Skript selbst den Platz unter /tmp schon noch braucht (1x Eingabedatei + 1x Kernel + 1x FS -> das ist nicht gerade wenig auf einem Embedded-Device) - auf der Box muß man also wohl Swap-Space haben.

Aber unter einem ausgewachsenen System sollte es funktionieren und dann erspart man sich eben die Verwaltung dieser "aufbereiteten Images", wenn man sie direkt aus den TAR-Files erzeugen kann.

 

[Miyamoto]

Also irgendwie habe ich noch nicht ganz verstanden, wie jetzt der Workflow ist und welche Schritte (Freetz bauen, Upload, ...) wo stattfinden und wie ich an die Shell komme.
Ich habe mir zwar das YourFritz ausgecheckt, aber mir fehlt da noch ein klares Howto, wie ich damit umzugehen habe.

 

[PeterPawn]

@opto:
Was heißt "ohne zu beschreiben"?

Es müssen natürlich die anderen Parameter im Bootloader noch richtig gesetzt werden (memsize, kernel_args_temp), aber dafür gibt es ja "eva_to_memory", dem man nur die Box im passenden Zustand vorsetzen muß (das macht ggf. eva_discover), zusammen mit einem passenden Image. Das "image2ram" als Filter ist natürlich dafür nicht so richtig geeignet (weil man es nicht einfach in "eva_to_memory" austauschen kann gegen das "cat", denn die Berechnungen für "memsize" brauchen natürlich die richtige Image-Größe), aber dann muß man eben den Weg gehen und die Ausgabe von "image2ram" irgendwo abspeichern. Anschließend kann man dann diese Datei aber tatsächlich mit "eva_to_memory" laden lassen ... was dann passiert, hängt vom Inhalt der dort enthaltenen /sbin/flash_update ab. Der originale Code von AVM überschreibt tatsächlich das gerade aktive System.

Der Patch für /sbin/flash_update soll genau dem entgegenwirken ... mit dieser Änderung und einer Datei ".inactive" im Wrapper-FS wird nicht das aktive System überschrieben (das ist bei den meisten ja lauffähig), sondern das in der anderen Partition und dann wird dorthin umgeschaltet. Sinn der Sache ist es, das funktionsfähige System eben nicht zu "zerstören" und bei nicht funktionierendem Freetz-Image den Rückweg über die Änderung von "linux_fs_start" offen zu halten.

@Miyamoto:
Das Vorbereiten eines Images für das Laden ins RAM und den Start eines solchen habe ich irgendwo im "modfs-Starter"-Thread (dem für Diskussionen, der Beitrag ist aber auch prominent in #1 im Dokumentationsthread verlinkt) erläutert - da gibt es meinerseits kein weiteres HowTo, was niemanden davon abhalten muß, seinerseits eines zu verfassen (wenn er damit leben kann, daß ich bei Fehlern meinen Senf dazugebe).

 

[PeterPawn]

@opto:
Die Auswahl über vorhergehende Änderung der "linux_fs_start"-Variablen geht logischerweise auch ... nach der Umschaltung ist dann eben das andere System das aktive und wird überschrieben.

Der Unterschied liegt halt im verwendeten Ansatz ... "vergißt" man vorher "linux_fs_start" richtig zu setzen, schreibt man in die aktive Partition. Bei gepatchtem "flash_update"-Skript kann das nicht passieren ... das arbeitet dann wie das Update über das GUI. Hier wäre dann das vorherige Ändern von "linux_fs_start" natürlich genau wieder das Falsche ... es gibt eben mehrere Wege und ich wollte so eng wie möglich beim "Freetzen" der Box am "normalen" Update-Prozess bleiben.

Vor allem dann, wenn ich hier immer wieder lesen muß, daß die Leute erst mal ein Downgrade machen wollen, damit sie dann ein Freetz-Image installieren können ... Ziel war es in erster Linie, da für mehr Licht im Dunkel des Installationsprozesses zu sorgen - dazu sollten auch die PowerShell-Varianten für den FTP-Zugriff dienen, damit die Leute nicht erst nach einem Linux-System suchen müssen.

Wer von Hand selbst mit FTP-Kommandos installiert, kann es ja halten, wie er will ... Dein Ansatz mit dem Quoten des Zieldateinamens, damit da drei Parameter im STOR-Kommando ankommen, muß auch nicht mit jedem FTP-Client funktionieren; ich habe auch schon gesehen, daß dann genau diese Zeichenkette in Quotes als ein Name auch im STOR-Kommando landete (frag mich aber jetzt nicht, was das für ein Client war - aber der FTP-Client von Windows kennt ohnehin keine passiven Transfers).

- - - Aktualisiert - - -

Könntest im Script noch den Fall vorsehen dass es 2. K+FS in einem Unterverzeichnis gibt

Verstehe ich nicht richtig ... das Skript sollte damit klarkommen, wenn es mehr als eine Datei "kernel.image" oder "filesystem.image" gibt, nimmt halt immer die erste gefundene. Das "set -- ..." interessiert sich normalerweise nicht dafür, wieviele Zeilen das "grep" jetzt ergeben hat.

Das ist ja nun auch nicht so ausgefeilt, daß man da noch irgendwelche Parameter angeben könnte/können sollte, mit denen dann ausgewählt wird, die wievielte Datei bei mehreren vorhandenen im Image jetzt verwendet werden soll.

Wenn jemand wirklich eine "image"-Datei von AVM mit mehr als einer (internen) image-Datei für Kernel und/oder FS hat, muß er eben von Hand ran. Meine Dateien sollen ja in aller Regel eher das Vorgehen dokumentieren und nur in seltenen Fällen (dann haben die auch entsprechende Hilfetexte und Fehlernachrichten) sind sie dafür gedacht, 1:1 genutzt zu werden.

 

[PeterPawn]

Das Ignorieren ist mehr oder weniger Absicht ... ich habe u.a. deshalb die Variante mit dem "set" anstelle von "sed" zum Auseinandernehmen gewählt, weil damit die Ausgabe des tar-Kommandos beliebig viele Dateien enthalten kann und nur die erste verwendet wird.

Für DOCSIS-Boxen warten wir mal ab, was das wird ... ein einfaches Image zu erstellen, macht da ja ohnehin nur wenig Sinn - man müßte ja beide Prozessoren "laden".

Die Zeichenkette ist die TI-Signatur (hex: 23 DE 53 C4), das geht mit "base64" am leichtesten, es mit einem vorhandenen Wert zu vergleichen und das ist ja seit einigen Versionen auch auf der Box verfügbar, weil AVM damit selbst den TFFS-Dump in den erweiterten Support-Daten aufbereitet für die Text-Datei.

 

[PeterPawn]

Ich bleibe ja dabei, daß ich eine zusätzliche Option beim "fwmod" (in der Konsequenz dann auch noch in der .config für Freetz und somit auch als Einstellung für die Konfiguration) für die beste Lösung halte. Dann wird einfach eine Datei für den "Upload" über EVA erstellt (man braucht kein "tichksum" und den ganzen anderen Aufwand) und dann packt man noch eine Beschreibung für den Upload (oder meinetwegen auch noch einen FTP-Client ähnlich wie in meinem "eva_tools"-Verzeichnis) dazu.

Damit ist dann auch der "initiale Flash-Vorgang" bei einer FRITZ!Box mit einer OS-Version, die keine unsignierten Images akzeptiert, wieder auf einem Level angekommen, wo es auch der "normale Freetz-User" bedienen können sollte.

Im Prinzip gab es den Inhalt von "eva_discover" ja irgendwann auch mal in Perl - nur wurde m.W. da die IP-Adresse der Box nicht gesetzt und es muß auch nicht jeder Perl auf einer Maschine bereithalten, die eine direkte Kabelverbindung zur FRITZ!Box hat (bei mir kommt eine VM mit der Freetz-Toolchain schon mal nicht an eine FRITZ!Box heran, das ist bei anderen vielleicht auch anders) - daher der Versuch, das ausschließlich mit Shell-Befehlen zu machen (am "socat" führt leider kein Weg vorbei, wenn man UDP-Broadcasts machen will) oder eben für Windows-User in PowerShell.

Jedenfalls kann man das Zusammenbauen eines solchen Images (egal für welchen Zweck, ob Up- oder Downgrade, ob AVM- oder Freetz-Image) ja auch problemlos direkt unter Windows (unter Zuhilfenahme von 7zip für das Entpacken des Images) ausführen lassen, dann nimmt man eben auch die PowerShell (die alte Kommandozeile sollte man ohnehin vergessen) für das Abschneiden der Checksumme, wenn die vorhanden ist. Ich kenne jetzt kein in Windows eingebautes Kommando für das partielle Kopieren einer Datei und ehe man da einen Download aus irgendwelchen windigen Quellen macht, kann man das auch einfach über die File-Funktionen der .NET-Library abwickeln lassen.

Wenn ein Weg "festgelegt" wäre, könnte man den ja auch mit passenden Tools unterstützen ... ich finde es eben höchst albern, wenn für das erste Flashen der eigenen Firmware immer irgendein Downgrade auf eine Version < 06.5x gemacht wird - abgesehen davon, daß man sich dann erst einmal eine passende Firmware-Version besorgen muß, seit es bei AVM die älteren Versionen nicht mehr gibt.

Das paßt für mich auch alles "unter Sicherheitsaspekten" noch zueinander ... für die erste eigene Firmware wird dann eben eine Kabelverbindung zur Box benötigt (das wäre beim vorhergehenden Downgrade ja auch unerläßlich) und wenn diese eigene Firmware dann einen eigenen Schlüssel für das Signieren enthält, können künftige Updates auch wieder aus der Ferne (also auch per "Fernwartung") erfolgen.

- - - Aktualisiert - - -

Ehe jetzt jemand feststellt, daß auch 7-Zip nicht zum Lieferumfang von Windows gehört: stimmt.

Wer es also "wirklich pur" will, der macht auch noch das Entpacken des Images in PowerShell ... das tar-Format ist nun nicht unmäßig kompliziert und die beiden Dateien in der richtigen Länge aus einem (unkomprimierten) TAR-Archiv zu extrahieren, ist nun nicht wirklich "rocket science".

 

[PeterPawn]

Wann war das so, bei wem war das so, wo ist so ein Image (inkl. passendem öffentlichen Schlüssel)?

Das "auf Zuruf" zu diagnostizieren, ist sicherlich nicht möglich. Ich habe (7490, 7390, 7412) bisher keine Probleme gehabt.

Über Windows mache ich mir aber sehr wohl auch Gedanken ... die Freetz zugrunde liegende Idee ist "open source" - da paßt dann das ruKernelTool (auch wenn r@iner das Versenden des Quellcodes auf Anfrage anbietet) nur bedingt dazu. Ich würde auch nicht auf die Idee kommen, so eine Anfrage zu stellen ... damit vermeidet man schon von Beginn an irgendwelche Streitigkeiten, wer da nun von wem "abgekupfert" hat. Lieber schreibe ich das "from scratch" selbst - das hat auch den Vorteil, daß der (kundige) Verwender der Dateien selbst nachsehen kann, was da wirklich passiert (und sei es nur, daß er jemanden kennt, der für ihn "mal drüber schaut").

In Anbetracht des Alters der NAND-Modelle würde ich jetzt auch nicht auf allzu rasche Abhilfe beim ruKT hoffen ... auch wenn es die "extended version" ja wohl schon eine Weile gibt und die soll ja die NAND-Modelle auch beherrschen.

Ich kann das aber auch nicht wirklich beurteilen ... es gibt für mich derzeit für die von mir verwendeten Boxen (die 7390 ist das einzige NOR-Modell) einfach auch keinen Grund, das ruKT irgendwo einzusetzen und seitdem ich meine Skript-Dateien habe, brauche ich auch Kunden nicht mehr lang und breit zu erklären, wie sie erstens die "Kennwort-Sperre" beim Download des ruKT überwinden können und zweitens in den Untiefen der möglichen Einstellungen (wenn die AV-Software Alarm schlagen sollte, ist die Erklärungsnot noch größer, inkl. der doch höchst unterschiedlichen Schritte bei den verschiedenen Lösungen, um die Dateien dann der Quarantäne wieder aus den Klauen zu reißen) die richtigen ausmachen können.

Für den "Firmware-Sammler", der praktisch sämtliche Firmware-Versionen archivieren und irgendwie verwalten möchte, mag die Software etwas bringen ... für das einfache Flashen einer Firmware oder für die Benutzung des FTP-Clients in der EVA ist sie deutlich überdimensioniert und praktisch auch mehr auf ältere Windows-Versionen ausgerichtet, weil heute kein modernes Windows mehr neu gestartet werden müßte, weil man "auto sense" ab- oder anschaltet.

Aber wie gesagt, meine Kenntnisse des ruKT sind auch nicht die neuesten, wenn sich da neben der regelmäßigen "Erneuerung" wegen der zeitlichen Limitierung und der Aktualisierung der Firmware-Liste zwischenzeitlich substantielle Veränderungen ergeben haben sollten, wären die an mir vorbeigegangen - daher kann ein Teil meiner Informationen auch schlicht veraltet sein. Das meint jetzt nicht die "extended version" ... wenn die fertig wäre, hätte man es sicherlich auch irgendwo hier im IPPF gelesen.

 

[PeterPawn]

Das Problem mit den zusätzlichen Dateien konnte ich nicht nachvollziehen. Solange die unterhalb von ./var liegen, sollte das kein Problem sein und diese Änderung ist eigentlich seit http://trac.freetz.org/changeset/13818 drin. Wenn man so ein Image findet, muß man eben mal von Hand nachsehen, woran sich "firmwarecfg stream" da stören könnte. Das habe ich in dem "Signieren"-Thread gemacht und kein Problem finden können.

 

[Christoph_F]

Wer einfach nur einen Ersatz für „push_firmware“ sucht, kann das nehmen: http://www.ip-phone-forum.de/showthread.php?t=287879&p=2183238#post2183238, braucht aus „YourFritz“ genau eine Datei im Pfad und ein laufendes Linux.