[Info] modfs - SquashFS-Image (AVM-Firmware) ändern für NAND-basierte FRITZ!Boxen

Also kann von einem Freund berichten er konnte von der letzten Final auf die 06.90 updaten und keine Probleme bisher. Meine 2 Boxen werden wohl die Tage folgen
 
2 Boxen Remote upgedatet.
Läuft
 
Hallo zusammen,

mein System Ereignis-Log wird ständig voll gemült mit den An- und Abmeldungen von meiner Netatmo Wetterstation. Gibt es vielleicht eine Möglichkeit spezielle Anmeldungen auszublenden? Ich möchte aber für alle anderen WLAN-Geräte sehen, wann wer sich wie angegemeldet hat?

Vielen Dank.

Gruß kami
 
Das hat doch nichts mit dem Thema zu tun @kami23
 
Sorry hast recht, ich dachte nur daran das über modfs als Funktion einfließen zu lassen. Habe einen Thread aufgemacht.
 
Hallo Micha0815,
ich verstehe das Problem noch nicht:

Ausgangsstand: FB7490 mit Branding avme in Partionsset 0

Code:
# grep firmware_version /proc/sys/urlader/environment
firmware_version        avme
# grep linux_fs_start /proc/sys/urlader/environment
linux_fs_start  0
#

Ziel: die FB7490-06.90-DE mit modfs-0.4.6-190920172210 flashen:

Code:
# ./modfs update FRITZ.Box_7490.113.06.90.image
# echo firmware_version avm > /proc/sys/urlader/environment

Kontrolle:
Code:
# grep firmware_version /proc/sys/urlader/environment
firmware_version        avm
# grep linux_fs_start /proc/sys/urlader/environment
linux_fs_start  1
#


nun sollte FB7490-06.90-DE beim nächsten Start booten;
sollte der DSL-Treiber (xDSL vs. VDSL) nicht passen, so kann man im Web-IF auf Int-Version zurückswitchen.


IMHO wäre es auch denkbar, das Branding aus der Image-Datei auszulesen und wie die linux_fs_start Variable zu setzen, so dass es beim nächsten Booten keine Probleme gibt;
oder hat PeterPawn dies schon bei der letzten Änderung mit einfließen lassen
 
Zuletzt bearbeitet:
@Pokemon20021:
Eine Umschaltung eines Brandings nimmt "modfs" selbst nicht vor ... warum auch? Wer eine Firmware mit abweichendem Branding über "modfs" installieren läßt (die AVM-Firmware selbst würde sich komplett diesem Ansinnen verweigern), der muß auch in der Lage sein, die notwendigen Umschaltungen selbst vorzunehmen. Zumal das ja ohnehin nur in dem einzigen Fall funktioniert, daß man beim Aufruf von "modfs" den Namen der Vorlage explizit festlegt und es sich dabei um die "falsche" Datei handelt. Bei allen anderen Formen (inkl. Nachfrage bei AVM nach der neuen Version) gibt es gar keine unterschiedlichen Brandings ... jedenfalls nicht in einer Form, die zu Problemen beim nächsten Start führen könnte. Daher prüft "modfs" selbst gar nicht erst, ob das Branding im neuen System zu dem im alten paßt ... selbst wenn "modfs" die Variable "linux_fs_start" umschaltet. Die "Alternative", die Verarbeitung einer Firmware mit abweichendem Branding einfach abzulehnen, macht auch nur bedingt Sinn und vor allem verhindert sie dann erst recht, daß man einmal die deutsche und einmal die internationale Version gleichzeitig auf der Box hat.

@Micha0815:
Irgendwann solltest Du jetzt auch mal wieder aufhören zu heulen ... es wirkt nur noch albern, wenn man mal unterstellt, daß Du die Volljährigkeit bereits erreicht hast. Ich habe jetzt einige Male gar nicht darauf reagiert (in anderen Threads als diesem hier mit "modfs" als Thema, iirc war es zuletzt irgendwo bei GSM zu lesen, wie schwer ich Dich beleidigt habe), aber wenn das so weitergehen sollte, erkämpfst Du Dir tatsächlich mit aller Macht und Konsequenz einen Ehrenplatz in meiner "Ignorieren"-Liste. Ab diesem Zeitpunkt wären dann auch fundierte Fragen von Dir für mich nicht mehr zu sehen ... solltest Du also nicht bereits für alle Zeiten ausgeschlossen haben, daß Du jemals wieder eine solche Frage an mich richten würdest/möchtest/müßtest, wäre das ein Bärendienst, den Du Dir damit selbst erweist.
 
Hallo Peter,

habe eben meine Basis Box die direkt am DSL hängt erfolgreich aktualisiert. Dabei habe ich als Kommando die "faule Variante" gewählt:
Code:
mkdir -p /var/mod;cd /var/mod;wget -qO- http://yourfritz.de/modfs.tgz | gunzip -c | tar x;./modfs update

Bei der zweiten Box, die als Repeater arbeitet und über LAN1 angeschlossen ist habe ich es analog versucht.
Leider erhalte ich immer folgenden Fehler:
Code:
Ermitteln der Hardware-Version ... OK
Prüfen, ob die Hardware-Version unterstützt wird ... OK
Suchen der Einstellung zur Umschaltung auf das alternative System ... OK
Prüfen der aktuell zu startenden Systemversion ... OK
Suchen der aktuellen Kernel-Partition ... OK
Suchen der alternativen Kernel-Partition ... OK
Vergleich der Systeme in den Kernel-Partitionen ... übersprungen
Suchen der aktuellen Dateisystem-Partition ... OK
Suchen der alternativen Dateisystem-Partition ... OK
Überprüfen des zur Verfügung stehenden Speicherplatzes im RAM ... OK
Überprüfen des freien Speicherplatzes für das Auspacken des Dateisystems ... OK

Das System erfüllt die Voraussetzungen zur Modifikation des root-Dateisystems.

Im Moment läuft auf der Box die Version: 113.06.83-43494

Die Auswahl des 'update'-Modus erfordert eine neuere Firmware-Version vom Hersteller.

Ermitteln der neuesten Version durch Abfrage beim Hersteller ... Fehler
Es wurde keine neuere Version als 113.06.83-43494 gefunden, Abbruch.

Mache ich etwas falsch oder werden die Boxen unterschiedlich je nach Anbindungsart behandelt ?

Danke und Gruß
Bonvie
 
Das kann ich leider nicht fundiert sagen ... aber es gibt ja mehrere Berichte, daß man bei AVM nicht von jeder Box aus auch die passende Antwort vom JUIS erhält und der wird ja auch (ganz tumb) von "modfs" befragt, wenn man nur "update" angibt.

Du kannst ja noch einmal mit den Daten der ersten Box (und zusätzlicher Angabe von "Version=113.06.83") die Abfrage machen und Dir dann die Datei von AVM direkt herunterladen bzw. beim direkten Download vom FTP-Server mußt Du den JUIS ja gar nicht erst befragen; das sollte immer funktionieren. Ältere Versionen haben halt noch das Inhaltsverzeichnis vom FTP-Server ausgelesen und dort versucht, den richtigen Dateinamen zu erraten ... seitdem da "check_update" verwendet wird, gibt der JUIS von AVM den Takt vor.
 
Danke für das Feedback.
Leider kommt mein Erfolgsmeldung genauso wenig fundiert daher. Es hat heute, ohne dass ich etwas verändert habe funktioniert.

Ich hatte gestern auf Grund deiner Beschreibung, das Update von der Admin-Seite getestet und wie erwartet die Meldung bekommen, das alles up to date ist. Eben gerade wieder versucht und siehe da es gibt ein Update. Gleich per Telnet modfs aufgerufen und was soll ich sagen, es lief durch.
 
Ich habe das mal verlagert, da es hier besser hin paßt:
https://github.com/PeterPawn/modfs/commit/56775280ac63072a61044657e7bf0cd12d1ea8db

So, das sind jetzt alle Modelle, bei denen es (nach der Hardware-Liste) funktionieren sollte ...
IMO ist die 7412 zu viel/falsch dort.
Was ist aber mit der 5490 und 7369 und 6840?

Wann kommen eigentlich die 75x0?
Ich dächte, das hattest du schon mal im Februar angekündigt.
Und nach deiner Aussage soll es ja mit dem neuen Filesystem viel einfacher sein.

Ich würde gerne meine 7580 von der internen 06.81 erlösen,
da die bestimmt auch in deinen Augen nicht mehr so ganz sicher ist.
 
Auch wenn es auf der 7412 nur mit Kopfständen und nicht mit der originalen AVM-Firmware machbar ist (in der ersten eigenen Firmware könnte man auch über das Netzwerk für den notwendigen Swap-Space sorgen), so funktioniert das Prinzip doch auch für diese Box.

In der derzeitigen "modfs"-Version ist die Abfrage der "HWRevision" ohnehin überholt/unsinnig ... theoretisch kann man das "Umpacken" einer fremden Firmware auf jedem MIPS-Gerät mit ausreichendem freien Dateisystem- und Hauptspeicher machen lassen (mit den passenden Programmen auch auf jeder anderen Architektur) und die nach wie vor existierende Abfrage der "HWRevision" ist eigentlich inzwischen Quatsch und nur ein Relikt aus der Zeit, wo noch identische Versionen in beiden Partitionen installiert sein mußten. Damals war auch noch nicht klar, wie sich das bei AVM mit weiteren Modellen und der Benennung von Partitionen entwickeln würde ... das ist inzwischen alles erkundet.

Warum es mit der 7560/7580/7590 nicht 1:1 nach dem Prinzip funktioniert, wie "modfs" bisher arbeitet, habe ich an anderer Stelle bereits versucht zu erklären (fehlendes FS für "/wrapper") ... eine alternative Lösung für das Modifizieren/Installieren einer Firmware für diese Geräte habe ich in einem anderen Thread ebenfalls ausführlich beschrieben.

Selbstverständlich kann an die Stelle des dort gezeigten Erstellens eines einfachen Symlinks auch die Anwendung der Patches aus den "modscripts" treten - damit ist das Thema zwar für mich noch nicht erledigt, aber so weit "entschärft", daß die Unterstützung der GRX5-Boxen in der derzeitigen Inkarnation von "modfs" keine Priorität hat. Auch das dachte ich bereits zum Ausdruck gebracht zu haben ... man müßte vermutlich hingehen und für die GRX5-Boxen eine "Spezialversion" bauen, die beim Entpacken und Packen genau nur den Weg für die GRX5-Modelle mit dem UBIFS-Layer unterstützt.

Das widerspricht direkt der eigentlichen Intention, das wieder zu modularisieren (auch wenn die meisten es nicht mehr wissen bzw. nicht mitbekommen haben, ist das Ganze ja mal mit einzelnen Skripten gestartet, die man selbst nacheinander aufrufen mußte) und solange ich das als "Einzelkämpfer" durchziehen muß und nur ein (strategisches) Ziel verfolgen kann, muß die abgelieferte Beschreibung für die GRX5-Modelle (auch wenn ich das am Beispiel der 7580 erläutert habe, sollte es für die anderen beiden trotzdem funktionieren) reichen, wenn man eigene Firmware auf der Box haben will.

Der Aufwand ist zwar geringfügig größer, aber nicht in einem Maße, daß ich ihn für unzumutbar halte. Da gibt es viel längere und umfangreichere Anleitungen für alle möglichen anderen Aktionen ... es sind (ohne die eingebauten "ls -l"-Kommandos) gerade mal 12 Eingaben, die zur Reaktivierung von "telnetd" bei einer GRX5-Box erforderlich sind (und zwar inkl. Installation über EVA, wenn ich mich richtig erinnere) und da käme halt für jedes anzuwendende "modscript" noch eine Eingabe hinzu ... es sei denn, man streicht einfach "modfs" so weit zusammen, daß es die Teile zur Auswahl und Anwendung der Patches noch enthält und man das auch mit einem einzelnen Kommando aufrufen kann.

Wenn man es also "offiziell" will: Die Unterstützung für GRX5-Modelle in der derzeitigen (monolithischen) "modfs"-Version wird es aller Voraussicht nach von mir nicht mehr geben. Eine geplante Nachfolgeversion wird aus handlicheren, einzelnen Shell-Skripten bestehen und dort wird es dann auch einfacher sein, das Entpacken und Packen für andere Formate einfach durch den Austausch einer Skript-Datei (bzw. den Aufruf einer anderen Datei für ein anderes Format) zu realisieren.

Für die GRX5-Modelle kann/sollte man entweder meine Beschreibung oder auch gleich Freetz (im "no-freetz."-Modus, der jünger ist als "modfs") verwenden ... wer das anders haben will, kann/muß/darf jederzeit das Repository forken und entsprechende Änderungen vornehmen.
 
7412 nur mit Kopfständen ... so funktioniert das Prinzip doch auch für diese Box.
Naaaa jaaaa. Wer diese Kopfstände beherrscht (ich nicht), der schafft es auch die "209" in der modfs zu ergänzen. Deshalb gehört sie IMO standardmäßig dort nicht rein.
Ich ergänze ja auch die "225" damit ich modfs auf der 7580 ausführen kann, leider nicht für die 7580. *Tränen im Auge*

Ich habe ja auch schon angeboten beim Anpassen und Testen der modscripts auf den 75x0 mit zu helfen.

Du könntest auch (wenn es einfacher ist) ein völlig neues "modfs75x0" machen, welches nur für diese Boxen ist.

BTW: Warum ich modfs jetzt lieber auf der 7580 mache, statt wie bisher auf der 7490:
Die 7580 hat den doppelten RAM 512MB (/var/tmp) und damit spielt sich alles im RAM ab.
Bei der 7490 war das oft der NAND (/var/media/ftp) und damit geht es langsamer und man macht sich irgendwann den Speicher kaputt.

Ich glaube kein anderer hat so oft modfs ausgeführt wie ich. ;)

Schade, daß es jetzt langsam stirbt. :(
 
Zuletzt bearbeitet:
Der Tod ist keineswegs geplant und selbst wenn ich mich aus dem IPPF verabschiede, geht die Arbeit daran tatsächlich weiter ... zwar kann man die Firmware auch auf anderen Wegen (u.a. auch jetzt schon mit E99-custom, auch wenn das noch darauf baut, daß es von "modfs" in das SquashFS-Image eingebettet wurde) mit eigenen Erweiterungen versehen - aber einige, mehr oder weniger nutzliche, Änderungen an der AVM-Firmware sind auf diesem Weg nicht zu realisieren, da bleibt nur das Patchen der originalen Firmware oder man beginnt eine Orgie mit "bind"-Mounts.

Am Beginn war es halt noch so, daß man "modfs" relativ problemlos auf originaler Firmware starten konnte (bis inkl. "modfs-Starter") und da bot sich die Verwendung der Box selbst als Linux-Host an. Inzwischen gibt es (auch jenseits einer Freetz-VM) noch jede Menge zusätzliche "hosts", auf denen man das Anpassen der Firmware vornehmen kann ... das geht von der Windows-Bash bis zum RasPi.

Gerade diese beiden habe ich absolut nicht aus den Augen verloren als mögliches "build system" für eigene Images - für die Verwendung von "unsquashfs/mksquashfs" auch unter der Windows-Bash (da gibt es nämlich keine Möglichkeit, Device-Files zu erzeugen im Dateisystem) habe ich sogar erste Patches im YourFritz-Repository (https://github.com/PeterPawn/YourFritz/tree/master/squashfs), mit denen man schon jetzt auch unter diesem System ein LE-Dateisystem (wie es z.B. bei der 6490 und bei der 7581 verwendet wird) entpacken, ändern und neu packen kann, auch wenn dabei im Moment noch die Datumsstempel der Dateien "leiden" und anschließend nicht mehr den originalen Werten entsprechen (das interessiert aber für die Funktion des Images praktisch niemanden).

Da es eben derzeit irgendein anderes System braucht, auf dem man zumindest das erste Image erstellen kann, ist es auch in gewisser Weise logisch, das zweite, dritte, usw. auf demselben Weg zu erzeugen. Dazu braucht es aber ein "modfs", was sich bei der Auswahl der zu verwendenden Tools am "host" orientiert (einige neue Host-Tools sind mir letztens - mehr versehentlich - auch in das alte "modfs" gerutscht) und was genug über den Aufbau der Firmware für ein bestimmtes Modell weiß, daß es auch außerhalb der "Ziel-Box" arbeiten kann, wo man nicht mal schnell "nachsehen" kann auf dem System, wo die Anpassungen vorgenommen werden.

Von "langsam stirbt" würde ich also nur dahingehend sprechen, daß die Idee, das gleich auf der jeweiligen Box auszuführen und dabei sofort zu installieren, nicht mehr so ganz "up to date" ist - das war sie aber schon in dem Moment nicht mehr, wo es möglich wurde, damit auch die Firmware für ein "fremdes System" anzupassen. Eine neue Version würde hingegen auch andere Systeme als Build-Host unterstützen (sogar das Bauen einer 7412-Firmware auf einer 6490 (x86) ist machbar), denn die anderen Entwicklungen sind eben auch nicht stehengeblieben und das, was man heute auf einem RasPi 3 erledigen kann, ging damals noch nicht (mit ausreichender Performance).

Da man bei so einem Build dann auch gleich die eigene Firmware noch passend signieren kann (auch das kam ja erst nach "modfs"), lehnt sich dann auch deren Installation wieder an das Vorgehen von AVM an und man kann dann (ab dem zweiten Image) auch wieder ganz normal über die AVM-Funktionen die eigenen Modifikationen installieren lassen - das macht den bisher notwendigen Shell-Zugriff für "modfs" weiter obsolet und beendet damit auch ein mögliches Security-Problem.

Wenn die Leute tatsächlich nur mit Shell-in-a-Box oder SSH arbeiten würden (beide Programme gibt es sogar mit Signatur im YourFritz-Repository als statisch gellinkte Binaries für VR9- und GRX5-Boxen), wäre mir auch wesentlich wohler und ich hätte weniger "Bauchschmerzen", daß ich sie mit "modfs" praktisch zur Benutzung einer Shell-Session in ihrem Router "zwinge".

Ich bin ja eigentlich voll bei AVM, wenn man dort den Shell-Zugriff abschafft (bzw. das getan hat) - da sollte dann auch "modfs" zumindest andere Lösungen "anbieten". Ohne "modfs" braucht man sicherlich deutlich seltener einen Shell-Zugang zur FRITZ!Box ... auch das "modfs update" erfolgt dann eben außerhalb und das Ergebnis kann wahlweise als signiertes Image (wenn die bereits installierte Firmware den richtigen öffentlichen Schlüssel enthält) oder über EVA eingespielt werden. In dieser Konstellation brauchen dann noch deutlich weniger Leute den Shell-Zugang zur Box ... das ist u.a. auch ein weiteres Ziel (bzw. ein weiterer Vorteil der "externen Anpassung").
 
Ich würde gerne meine 7580 von der internen 06.81 erlösen,
da die bestimmt auch in deinen Augen nicht mehr so ganz sicher ist.

Bisher habe ich im Forum hier nur eine Beschreibung für's Flashen via Bootloader z.B. für 7580 gefunden; gibt es die OnBoard "var/install" Methode zur Installation bei den neuen GRX5-Modellen (FB756x/758x/759x) auch noch ?
oder hat sich hier nichts zu den VR9-Modellen geändert ?
 
Ich verstehe die Frage (wenn sie überhaupt an mich gerichtet sein sollte) nicht ... die Firmware wird bei einem Update von AVM natürlich auch weiterhin über ein Image im TAR-Format aktualisiert (für den Bootloader muß man dann ja die enthaltenen Dateien entsprechend "strippen", z.B. mit "image2ram") und die darin enthaltene "./var/install"-Datei wird dabei ausgeführt und ist für alle weiteren Aktionen zuständig. Was da bei einer Firmware für GRX5-Boxen genau passiert, kann man ja in jeder beliebigen Firmware "nachlesen" (so ein TAR-Member ist schnell extrahiert).

Der Vorgang unterscheidet sich etwas von dem bei der Installation über die "E03-flash_update" (also bei Start aus dem Speicher) ... dort werden ja immer die Partitionen im UBIFS neu initialisiert (siehe "check_and_setup_ubi_volumes()", wo ja die "ubimkvol"-Kommandos immer aufgerufen werden, was - zumindest nach meiner Erwartung, allerdings habe ich das noch gar nicht explizit überprüft, sondern es immer als gegeben hingenommen - auch immer zu "frischen" Strukturen führt), während im "install"-Skript davon ausgegangen wird, daß die Partitionen bereits existieren und gültige Strukturen aufweisen.

Ich würde also davon ausgehen, daß bei der Installation über EVA (sofern man nicht den Aufruf von "check_and_setup_ubi_volumes()" in der "E03-flash_update" auskommentiert) auch automatisch immer der Inhalt der NAS-Partition (und auch der inaktiven Dateisystem-Partition) dran glauben muß ... deshalb macht es durchaus Sinn, ab den zweiten Image auf den Weg mit der eigenen Signatur zu wechseln (oder man muß dann eben das "flash_update"-Skript entsprechend anpassen).

EDIT: OK, das mit dem "immer formatiert" war etwas ungeschickt ausgedrückt ... das findet eigentlich nur dann statt, wenn es einen Zusatz "recovered=n" in "firmware_info" gibt (wobei bei n={1,2} dann auch so richtig "alles neu" gemacht wird, weil "force" als Parameter übergeben wird) - das ist aber schon beim (direkt vorhergehenden) Zurücksetzen auf Werkseinstellungen der Fall (da ist n=3) und damit wird dabei tatsächlich das Dateisystem in der inaktiven Partition auch gelöscht, wenn man unmittelbar nach so einem Zurücksetzen (ohne zwischenzeitlichen Neustart bis zum Löschen dieses "recovered=3"-Zusatzes) ein Image mit der originalen "E03-flash_update" von AVM (also ohne "entschärften" Aufruf von "check_and_setup...") über den Bootloader installiert. Bei den VR9-Modellen bleibt ja auch die inaktive Version komplett unangetastet, wenn man das AVM-Recovery-Programm verwendet ... bei den GRX5-Modellen werden beide gelöscht und nur das aktive wieder installiert, wenn man das AVM-Programm verwendet und das (vor dem Starten des Images im Speicher) noch "recovered=2" in "firmware_info" einträgt.
 
Zuletzt bearbeitet:
Hallo Peter!

Wieder mal eine Rückmeldung.
modfs_version=0.4.6-190920172210 oder gibt es da schon was entscheidend neueres?

Modfs läuft auch mit der 06.92 für die 7490 mit allen modscripts ohne angezeigten Fehler durch.

ABER:
Bei der LED Anzeige/Abschaltung wird die 90s Möglichkeit nicht angeboten.

AVM hat da wieder mal was an der led_display.lua Datei geändert (auch schon in der 06.90).
Warum die da was ändern, wo sie doch sowieso nicht genutzt wird?

Hier mal der diff:
Code:
--- led_display.lua.83
+++ led_display.lua.9x
@@ -20,7 +20,7 @@
 function refill_user_input_from_get()
 g_led_display =box.get.led_display
 end
-if next(box.post) then
+if box.post then
 if box.post.apply then
 read_box_values()
 refill_user_input_from_post()
@@ -37,9 +37,8 @@
 http.redirect(href.get(g_back_to_page))
 return
 end
-else
-read_box_values()
 end
+read_box_values()
 function write_led_selected(current)
 if (g_led_display==current) then
 box.out([[checked="checked"]])
 
Zuletzt bearbeitet:
Schaue ich mir an ... vermutlich kam die 7590 mit dem Gedimme dazu und nun hat man die "led_display.lua" dann doch wieder angefaßt bei AVM.
 
IMO gab es das Gedimme bei der 7590 auch schon in der 06.83, oder?
Die 7590 mit 06.83 hatte aber die gleiche "led_display.lua" wie alle anderen NAND mit 06.83.
Und die "led_display.lua" wird auch bei der 7590 nicht in der "menu_data.lua" verwendet.
Also IMO kein Grund da was zu ändern.

Für das Gedimme muß es noch eine andere Datei geben. In welchem Bereich in der GUI befindet es sich denn?
In der "menu_data.lua" der 7590 gibt es kein "dim". Wie hat AVM denn die benannt?
 
Zuletzt bearbeitet:
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.