Firmware update per remote

[hermann72pb]

Da hier irgendwo vor kurzem angefragt wurde, wie man die Firmware auf die Box ohne Benutzung des Web-Interfaces bringt, frage ich hier etwas allgemeiner und mache dafür ein Thema auf.

Ist es überhaupt möglich, die Box per remote zu updaten?

Meine Erfahrung:
Ich habe eine 7170 mit ds-mod (ich glaube noch 0.2.6), die ich per SSH erreichen kann. Kurzerhand ein SSH-Tunnel mit Putty aufgebaut und versucht per Web-Interface auf ds-0.2.9 zu updaten. Irgendwann ging die Verbindung verloren und die Remote-Box blieb hängen. Nur Hard-Reboot (Netzteil rausziehen) brachte die Box aus dem Schlaf zurück. Auf der Box blieb die alte Version der Firmware. Damit habe ich diese Idee erstmal ruhen lassen.

Es wäre wünschenswert, wenn jemand hier kurz erläutern könnte, wie das Update auf der Box passiert und wie man es am besten per remote realisieren könnte (web oder ssh).

Ich vermute, dass nachdem das Image im RAM der Box entpackt wurde, entweder die Internetverbindung getrennt wird oder sämtliche Dienste angehalten werden, sodass das Web-Interface der Box nur aus dem lokalen Netz zu erreichen ist. Daher war mein Update nicht möglich.

MfG

Hermann

[olistudent]

Das Firmware-Image wird nach / entpackt und die Signatur wird geprüft. Dann wird die Install-Datei aufgerufen und abhängig von deren Exit ein reboot eingeleitet. Der Flashvorgang beginnt erst beim reboot. Dazu werden vom install-Skript die Befehle nach /var/post_install geschrieben.

=>Remote-Update

1. Du musst das Firmwarefile auf die Box kopieren und mit 
"tar xf firmware.image -C /" entpacken.
2. Dann rufst du "/var/install" auf
3. "reboot"

Jetzt weiß ich natürlich nicht wie sich das verhält, wenn die ganzen Daemons noch am Laufen sind. Eventuell langt der Platz schon nicht um das Image zu entpacken. Beim Firmwareupdate per Webif wird noch "/bin/prepare_fwupgrade start/end" aufgerufen. Aber dann ist deine Verbindung fort.

MfG Oliver

[hermann72pb]

Das Firmware-Image wird nach / entpackt und die Signatur wird geprüft.

ok. Das ist schon mal der erste Stolperstein. Ich glaube mein Image mit ds-0.2.9 war schon mit der Firmware mit Signatur-Überprüfung. Da kommt natürlich die berühmte Frage, ob man die nicht-AVM Firmware dennoch flashen will. Und die Verbindung ist zu dem Zeitpunkt wahrscheinlich weg. Entweder dsld oder dropbear runtergefahren. Ergo, man kann die Frage nicht beantworten und die Box bleibt eingeschlafen.

Dazu werden vom install-Skript die Befehle nach /var/post_install geschrieben.

Liegt denn diese Datei im Flash? Sonst würde sie das reboot nicht überleben.

Eventuell langt der Platz schon nicht um das Image zu entpacken.

Warum? Wenn ich es richtig verstehe, macht das Update-Skript vom Webinterface ungefähr dasselbe, was du mir vorschlägst per Hand zu machen. Warum entstehen bei Webinterface-Update keine Platzprobleme? Werden dabei vielleicht einige Dienste runtergefahren, um RAM zu räumen?

Beim Firmwareupdate per Webif wird noch "/bin/prepare_fwupgrade start/end" aufgerufen. Aber dann ist deine Verbindung fort.

Kannst du es bitte etwas genauer erläutern? Ist das ein Skript oder eine Binärdatei? Wann wird es ausgeführt? Ganz am Anfang, weil "prepare"? Und warum ist dann die Verbindung fort? Wird in diesem "prepare" dsld runtergefahren?

MfG

Hermann

[olistudent]

1. /var/post_install wird vom reboot aufgerufen.
2. Die Firmware wird direkt entpackt und gar nicht erst im RAM gespeichert.
3. Die Dienste werden in dem Skript /bin/prepare_fwupgrade beendet. Schau einfach mal rein. Dann siehst du es.

MfG Oliver

[kriegaex]

Das Thema ist zwar schon alt, aber ich sah es gerade und mache mir gerade meine Gedanken darüber. Wenn ich mal laut denken darf, dann könnte es doch so gehen, wenn man

1. vermeiden möchte, daß das Image gepackt auf der Box gespeichert wird und
2. das Problem der abbrechenden Verbindung umgehen möchte:

Maßnahmen:

1. Das Image wird auf einen Web- oder FTP-Server gepackt. Der kann im Internet oder im LAN beheimatet sein. Letzteres ist wohl einfacher, aber im Grunde ist es wurscht.
2. Man führt auf der Box ein Skript aus, das den Reboot automatisch macht, ohne daß der Benutzer interaktiv nochmal eingreifen müßte.

Das Skript könnte in etwa so aussehen (keine Lust, das jetzt zu testen, also Vorsicht):

{
# Unnötige Dienste stoppen, aber websrv und dsld weiter laufen lassen
prepare_fwupgrade start_from_internet
# FW-Image herunterladen und direkt nach "/" entpacken
wget -q -O - http://mein.server.xy/mein.image 2> /dev/null | tar -C / -x
# Restliche Dienste stoppen
prepare_fwupgrade end
# Installation vorbereiten
/var/install
# Installation initialisieren
/var/post_install
# Box neu starten
reboot
} &

Man beachte das "&" am Ende, um den Job im Hintergrund auszuführen.

[hermann72pb]

Hallo kriegaex!

Danke, dass du das Thema wieder "ausgrabst" und so eine Anleitung schreibst!

Nun einige Fragen und Bedenken:

Das Image wird auf einen Web- oder FTP-Server gepackt.

Dann lieber an FTP mit passwort, sonst heißt es wieder man verbreite gemoddete Firmware im Netz

# Unnötige Dienste stoppen, aber websrv und dsld weiter laufen lassen
prepare_fwupgrade start_from_internet

was ist dieses "prepare_fwupgrade start_from_internet"? Gibt es schon auf der Box? Ich hatte leider keine Zeit gehabt, mir die Skripte anzuschauen. Werden es zufällig nicht gerade in diesem Skript alle Dienste runtergefahren?

# FW-Image herunterladen und direkt nach "/" entpacken

Was liegt dann physikalisch in diesem Fall unter "/"? RAM? D.h. man packt das Image ins RAM?

# Restliche Dienste stoppen
prepare_fwupgrade end

Ist das jetzt wieder ein Standardskript von Fritzbox?


Sonstige Bedenken:
Reicht denn die RAM-Kapazität dafür aus, wenn man die Dienste so wie vorgeschlagen nicht alle auf einmal, sondern nach und nach runterfährt?

Aber ausprobieren kann man ja. Schlimmer als Recover wird nichts passieren. Und 7050 zum Testen habe ich ausreichend.

MfG

Hermann

[kriegaex]

Fragen über Fragen. Also der Reihe nach:

Dann lieber an FTP mit passwort, sonst heißt es wieder man verbreite gemoddete Firmware im Netz

Ich meinte natürlich einen privaten Web- oder FTP-Server (am besten sowieso einer im eigenen LAN, hatte ich ja auch erwähnt), den keiner sonst kennt und von dem man das Image gleich wieder löscht, wenn es auf der Box ist. Es ging nur um einen Trick, eine "Firmware-Infusion" hinzukriegen ohne doppeltes Speichern auf der Box (Tar-Archiv und entpackte Dateien), damit der Speicher nicht überläuft bei kleinen Boxen.

was ist dieses "prepare_fwupgrade start_from_internet"? Gibt es schon auf der Box? Ich hatte leider keine Zeit gehabt, mir die Skripte anzuschauen.

Die Zeit hättest Du Dir ruhig nehmen dürfen. Liegt unter /bin auf der Box und gehört dazu. Es wird vom regulären Update ebenfalls aufgerufen, wie olistudent ja bereits erwähnte. Ich simuliere mit meinem kleinen Skript ja nur den normalen Upgrade-Vorgang (vermutlich nicht genau, aber so gut ich ohne Ausprobieren durch lautes Nachdenken konnte).

Werden es zufällig nicht gerade in diesem Skript alle Dienste runtergefahren?

Doch, aber in zwei Schritten, um mehr Speicher für den Entpack- und später für den Flash-Vorgang frei zu machen. Das soll so sein.

Was liegt dann physikalisch in diesem Fall unter "/"? RAM? D.h. man packt das Image ins RAM?

Unter / entpacke ich, weil das Firmware-Image (schau mal rein, es ist ja ein Tar-Archiv) dort sein Wurzelverzeichnis hat, aber alles unterhalb von /var entpackt. Und /var ist tatsächlich im RAM, der Rest der Verzeichnisstruktur sind gemountete Read-Only-Sachen aus dem Flash-Speicher bzw. virtuelle Dateisysteme wie /proc und /dev.

Ist das jetzt wieder ein Standardskript von Fritzbox?

Meinst Du /var/install? Das ist Bestandteil des Firmware-Images und existiert nach dem Entpacken zu dem alleinigen Zweck, aufgerufen zu werden und den Flash-Vorgang mit einigen Prüfungen und Maßnahmen vorzubereiten (die Details würden zu weit führen, schau mal meinen Wiki-Artikel zum Thema an).

/var/install erzeugt übrigens "live" /var/post_install, ebenfalls siehe Wiki.

Reicht denn die RAM-Kapazität dafür aus, wenn man die Dienste so wie vorgeschlagen nicht alle auf einmal, sondern nach und nach runterfährt?

Manche werden eben noch gebraucht in der Vorbereitung des Flash-Vorgangs. Ohne dsld z.B. kein wget von einer externen Seite, ohne websrv kein Upload der Firmware via Web-Browser (ist ja in unserem Fall irrelevant).

Damit sollte dann die Herkunft jedes Skripts geklärt sein, hoffe ich.

Aber ausprobieren kann man ja. Schlimmer als Recover wird nichts passieren. Und 7050 zum Testen habe ich ausreichend.

Stimmt, solange in Deinem Image kein Update für den Bootloader enthalten ist. Viel Spaß beim Testen.

[kriegaex]

Update 15.04.2007: Zwei Änderungen zur Originalversion vom 03.04. weiter oben: Erstens wurde ein Notfall-Reboot neu eingefügt, zweitens wird der Rest des Skripts nun im Vordergrund ausgeführt. Ich habe beim Testen erlebt, daß ansonsten eine TTY-Ausgabe, z.B. von prepare_fwupgrade, den Hintergrund-Job stoppt, weil solche Jobs eigentlich nicht auf das kontrollierende Terminal schreiben oder davon lesen dürfen.

Update 20.06.2007: Mini-Korrektur in Zeile 1: reboot -f; braucht in dieser einzeiligen Schreibweise des Klammer-Ausdrucks ein Semikolon am Ende.

# Bevor wir anfangen, ein Hintergrundbefehl: notfalls in 10 min die Box
# zwangsweise neu starten, das müßte für Download + FW-Update reichen.
{ sleep 600 ; reboot -f; } &

{
# Unnötige Dienste stoppen, aber websrv und dsld weiter laufen lassen
prepare_fwupgrade start_from_internet
# FW-Image herunterladen und direkt nach "/" entpacken
wget -q -O - http://mein.server.xy/mein.image 2> /dev/null | tar -C / -x
# Restliche Dienste stoppen
prepare_fwupgrade end
# Installation vorbereiten
/var/install
# Installation initialisieren
/var/post_install
# Box neu starten
reboot
}

Man beachte das "&" am Ende der ersten Zeile, um den Job im Hintergrund auszuführen.

Anmerkung zum Schluß: Das Ganze funktioniert nicht nur mit einer traditionellen Telnet- oder SSH-Konsole. Man kann es notfalls genausogut mit der Rudi-Shell machen.

[knox]

Bei der genaueren Beschäftigung mit dem hier diskutierten Thema habe ich mir u.A. das Script /bin/prepare_fwupgrade angeschaut und dabei ist mir folgende Idee gekommen:

Wenn AVM fleißig alle möglichen Dienste abschaltet, um freien Speicher zu bekommen, hat das ja durchaus einen Sinn.
Was aber passiert mit den Diensten, die erst durch das Mod auf die Box gekommen sind? Werden die auch irgendwo beendet oder laufen sie im Zweifel einfach weiter?
Es wundert mich, dass es da bisher noch keine Probleme gegeben hat (bei mir laufen z.B. OpenVPN und TOR und der Speicher ist voll bis in die letzten Bits).

Eventuell wäre es sinnvoll, dass wir das prepare_fwupgrade Script patchen und die jeweils installierten ds-mod Dienste mit herrunter fahren, bevor das Upgrade entpackt wird?

[MaxMuster]

... das gibt aber Probleme (bzw. kann welche geben) was meiner Erinnerung nach auch schon öfters benannt wurde. Das Update "bleibt dann einfach stehen", was durch Abschalten der "größeren" Dienste (besonders OpenVPN) meist zu beheben war.
Daher ist die Idee nur zu empfehlen - es sei denn, man möchte ein Update über VPN wagen ( ja, habe ich auch schon gemacht!)

Jörg

[kriegaex]

Technisch möglich wäre das Patchen des Skript schon, kein Problem. Wie ich aber bereits schrieb, überlasse ich es dem Anwender, die nicht benötigten Dienste zu stoppen. Ich will keinen Riesen-Auswahldialog anbieten, um einzelne Dienste zu selektieren, wenn es doch eine Webseite früher eine Liste von Diensten zum starten/stoppen bereits gibt. Der Updater kann ja nicht riechen, ob jetzt jemand lokal über über SSH oder VPN oder Matrixtunnel arbeitet, ob er hinterher booten will oder nicht usw.

[hermann72pb]

knox, ich gebe Alexander recht. Ich hatte ihm bereits das Ähnliche für das Update-Feature im neuen mod vorgeschlagen. Allerdings riechen kann der Updater wirklich nicht, wie man auf der Box unterwegs ist. Von daher sollte man dem Benutzer etwas Intelligenz auch überlassen.
Ich hatte bis jetzt nur einmal das Update einer 7050 mit dem obigen Skript gewagt. Obwohl da OpenVPN lief und sogar im RAM gelagert war, hatte ich es nicht gewagt darüber zu flashen und hatte es mit putty+tunnel gemacht. Vor dem Flashen alle nicht benötigten Dienste gestoppt, alle runtergeladenen Binaries aus dem RAM gelöscht. Dann ginge es auch. Man sollte sich schon bewusst sein, was man tut.

MfG

[knox]

Alles, was ich vorschlage (und nach eingehenden Tests auch für überaus sinnvoll halte) ist, ein paar Zeilen in das AVM Script einzufügen:

/mod/etc/init.d/rc.tor stop >/dev/null 2>&1
/mod/etc/init.d/rc.openvpn stop >/dev/null 2>&1
/mod/etc/init.d/rc.openvpn-lzo stop >/dev/null 2>&1
/mod/etc/init.d/rc.samba stop >/dev/null 2>&1
...

Ich glaube, dass es richtig und sinnvoll ist, damit das Firmware Update (auch und vor allem von einem "normalen" Anweder über das AVM WebIF) problemlos abläuft.

[kriegaex]

Wenn jemand via VPN flasht, hat er mit Deinem Beispiel schon verloren. Ich bleibe bei meiner oben ausführlich begründeten Ansicht, daß man die DS-Mod-Dienste selbst stoppen soll, falls notwendig, da es keinen verallgemeinerbaren Anwendungsfall gibt und auch weiterhin Pseudo-Updates ohne Reboot möglich sein sollen. Die allgemeine Grundregel, daß man vor einem "echten" Firmware-Update die DS-Mod-Dienste stoppen soll, soweit möglich, sollte bekannt sein, und es gibt eine bequeme Oberfläche dafür. Das Denken will ich keinem Anwender abnehmen zu Lasten der Profis, die eben in manchen Fällen nicht microsoft-mäßig bevormundet werden wollen und z.B. OpenVPN weiter laufen lassen möchten.

[dsteinkopf]

Also ich bin offenbar total unwissend und kann Euch nicht folgen:
Was ist ein "echtes" Firmware-Update? Wann muss ich welche Dienste anhalten? Woher müsste ich das wissen?

Ich habe bisher noch nie irgendwas angehalten - daher fände ich es nicht schlecht, wenn das von selber passieren würde, sofern nötig.


Dirk

[RalfFriedl]

Ein echtes Update ist eines, das die Firmware im Flash aktualisiert.
Ein Pseudo-Update ist eines, das die Firmware nicht ändert, sondern nur die var/install dazu benutzt, bequem ein Programm zu einem beliebigen Zweck auf die Box zu bringen und auszuführen.

Beispiele dafür sind Änderungen an der debug.cfg, Dienste starten oder stoppen, sonstige Einstellungen ändern. Unter the-construct kann man sich da alles mögliche zusammenstellen lassen.

Bei einem Firmware-Update werden die AVM-Dienste angehalten, um Platz im RAM der Box zu schaffen. Aber wie kriegaex schon geschrieben hat, kann es sein, daß man den Update über VPN durchführen will, und dann ist es schlecht, wenn zur Vorbereitung des Updates das VPN gestoppt wird.

[hermann72pb]

@dsteinkopf: manchmal geht mir auch so. Es gibt Themen, wo man irgendwas verpasst hat und
@kriegaex: Kann man nicht so eine Zwischenlösung basteln, damit knox zufrieden ist und andere nicht daran leidet? Z.B. in AVMs prepare ein link (mit Existenzüberprüfung, natürlich) auf ds-firm-prep.conf einbauen. Diese conf-Datei wird dann wie im mod üblich (z.B. OpenVPN usw.) behandelt. Sprich, wenn sie nicht da ist, dann ist sie nicht da. Wenn einer will, füllt er diese Datei mit dem ähnlichen Inhalt, wie knox es vorschlägt. Und zwar nach seinem Vorlieben. conf-Datei wird zusammen mit den anderen Einstellungen im Mod abgespeichert.
Dann sind alle zufrieden.

Da es mittlerweile unproblematisch ist, firmware per remote zu updaten, steigere ich die Komplexität der Aufgabe. Hat schon jemand geschafft, eine Box ohne ds-mod per remote ds-mod-tauglich zu machen?
Ich habe vor etwa 1,5 Jahren für einen meiner Bekannten die Box mit den damaligen Mitteln gemoddet. Noch ohne ds-mod, aber mit dropbear und sonstigem im debug.cfg. Die Problematik ist, dass beim frischen Aufsetzen vom Mod man nach den Passwörtern gefragt wird. Außerdem ist der Versionssprung von einer xx.89-Version auf heutige gewaltig. Es ist eine der ersten 7170. Der Bekannte wohnt etwa 500 km von mir entfernt und es sind keine Besuche erstmal geplant, so dass es entweder remote oder gar nicht geht.

MfG

[knox]

Es geht doch überhaupt nicht darum, dass irgendwas mir gefällt. Und es geht auch nicht darum, jemanden zu bevormunden.

Ihr werdet schon wissen, was das Beste ist.

[kriegaex]

Hermann, Du findest es wirklich einfacher, eine Datei zu editieren, als einfach im Web-UI, wo Du sowieso schon bist, ein paarmal auf "Stop" zu klicken? Irgendwie werde ich daraus nicht schlau. Es ist doch keine Arbeit. Und wenn das Update schief geht, wird sowieso im Forum gefragt, und dort kommt dann die Standardantwort "vorher DS-Dienste stoppen". Es darf gern auch jemand eine Wiki-Seite schreiben, falls mein Artikel im Forum zu knapp ist (was bei Einsteigern gut und gern sein kann).

[hermann72pb]

Die Datei editierst du einmal, boxspezifisch. Danach ist sie drin im config, und gut ist es. Dienste stoppen muss man beim jeden Update. Und wenn man immer auf dem neusten Stand bleiben will, macht man es schon mal 1.Mal im Monat. So war die Idee.
Wenn man paar Mal dieses dienste-stop-rumklickere gemacht hat, macht man es wahrscheinlich nachher mit links. Beim ersten mal kann es schon mal schief gehen (wie übrigens mit Skript auch). Mir ist es auch bei meinem einzigen bis jetzt Update passiert: dropbear abgeschossen, anstatt OpenVPN. Gut, dass OpenVPN noch am laufen war, schnell darüber auf die Box, dropbear starten und von vorne an.
Aber du hast schon recht, es gibt wichtigere Dinge, die man am mod noch tun kann, als das. Von daher halten wir dich nicht davon ab.

MfG