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

Wozu dient denn das ruKernelTool in diesem Kontext gleich noch mal?

Aber das wird jetzt eher OT, mach Dir doch einfach einen eigenen Thread zum Thema "6360 - eigenes SquashFS-Image" auf, da beansprucht das (eher abseits gelegene) Thema der DOCSIS-Box dann nicht die Aufmerksamkeit der Leute mit einer NAND-Box.

EDIT: Letzte Bemerkung meinerseits zum Thema "auslesen" ... gab es nicht auch bei der 6360 irgendwie die Möglichkeit, einen USB-Speicher mit der FRITZ!Box zu verbinden? :gruebel: Wozu braucht es dann unbedingt tftp zum Auslesen? Und /data ist i.d.R. ein jffs2-Dateisystem für den AB, das hat mit der Firmware nur entfernt zu tun (eigentlich nur insoweit, als daß der nicht genutzte Platz im NOR-Flash dafür verwendet wird).

- - - Aktualisiert - - -

Ich habe mal wieder einige Änderungen vorgenommen und daher die Version auf 0.3.5 angehoben.

Die Änderungen:

- es gibt jetzt eine Möglichkeit, nach dem Initialisieren der yaffs2-Partition und nach dem Kopieren der Dateien für die Firmware in diese Partition, weitere Dateien dort abzulegen ... das können z.B. Erweiterungspakete sein, die von E99-custom geladen werden sollen oder zusätzliche Dateien, auf die man in seinem Firmware-Image mit einem Symlink verweisen will, weil sie eben doch einmal neu geschrieben werden müssen und man nicht gleich das ganze Image wieder ändern will oder auch zusätzliche Programme oder beliebige andere Dateien, die man für eigene Modifikationen braucht - dieser Teil des Dateisystems ist ja im laufenden Betrieb unter dem Pfad /wrapper jederzeit zugänglich (das Thema habe ich im Zusammenhang mit E99-custom ein paar Beiträge vor diesem ausführlich erläutert)

- um diese Dateien zusätzlich in das neue System zu integrieren, müssen sie in einer ausgepackten Dateisystemstruktur vorliegen (also nicht als .tar.gz o.ä., wie bei "ownfiles") und der Name dieses Verzeichnisses ist mit der Variablen "ADD_TO_WRAPPER" beim Aufruf von modfs anzugeben ... die Dateien werden in genau der Struktur, die in diesem Quellverzeichnis existiert, dann in die yaffs2-Partition kopiert

- ein Aufruf mit dieser Möglichkeit (und dem Quell-Verzeichnis in /var/media/ftp/extend) würde also in etwa so aussehen:

- ich bin mir gerade nicht sicher, ob ich schon etwas zum Stoppen der Swap-Spaces beim Stoppen der USB-Geräte geschrieben hatte, jedenfalls ist "mod_swapoff" dazu gedacht, das Hängenbleiben der Box (nach dem Auslagern durch heftigeren Speicherbedarf, was bei mir reproduzierbar erfolgt) beim Neustart zu verhindern

- "mod_custom_images" (das ist die Modifikation, die für die E99-custom sorgt) ist jetzt "offiziell" in diesem Release

- ich habe ein statisch gelinktes "openssl"-Binary in der Version 1.0.2h dem Paket hinzugefügt - ob ich es schaffe, das jeweils aktuell zu halten (auch wenn es Änderungen gibt, die für "modfs" nicht relevant sind), will ich nicht versprechen

- um dieses OpenSSL-Programm selbst zu erstellen, braucht man die Änderungen aus meinem Freetz-Fork im GitHub, weil Freetz ansonsten nur die zum Ende des Jahres abgekündigte Version 1.0.1 unterstützt

- mit diesem Binary kann man dann in Verbindung mit der ebenfalls enthaltenen Busybox auch mittels "wget" auf HTTPS-URIs zugreifen, u.a. auch auf das GitHub-Repo selbst - irgendwann baue ich mal eine Update-Möglichkeit in "modfs" ein

- gleichzeitig habe ich ein paar Aufrufe einer optionalen Signaturprüfung für AVM-Firmware-Images und ggf. auch für künftig im Rahmen von "modfs" bereitgestellte Binärpakete in "modfs" hinzugefügt, die machen aber außer einer Meldung in der Konsole nichts, solange die entsprechenden Skript-Dateien dahinter noch fehlen - später kann man dann durch Angabe von "NOVERIFY=1" beim Aufruf von "modfs" so eine Prüfung auch überspringen, die ansonsten auf alle Eingabedateien losgehen würde, die wie ein originales Firmware-Image aussehen (also auch auf umgepackte Freetz-Images u.ä.)

- es war/ist ja etwas heikel, einfach irgendwelche Dateien aus dem Internet zu laden (wer weiß denn, ob das tatsächlich vom AVM-Server kommt) und dann mit deren Inhalt die neue Firmware für den Router zu bauen - kriegt jemand an dieser Stelle den Fuß in die Tür, kann er "modfs"-Benutzern so wieder irgendwelche Änderungen unterjubeln und das ist es ja genau, was ich mit dem Beharren auf Shell-Code für "modfs" verhindern möchte (da kann jeder nachlesen, was passiert) ... daher würde ich die AVM-Firmware vor der Verwendung durch "modfs" erst noch einer Prüfung unterziehen wollen, so wie es AVM beim GUI auch macht

Genau für solche Fragen habe ich in modfs eine (inzwischen standardmäßig aktivierte) Protokollierung eingebaut ... hänge bitte einfach mal die Protokolldatei hier an (wirklich als Anhang) und Dir kann bestimmt geholfen werden. Ich würde allerdings als erste Maßnahme mal einen USB-Stick mit mehreren Partitionen anschließen, von denen eine als "Linux Swap" gekennzeichnet sein sollte. Das Stoppen der Dienste ist der eine Punkt ... es kann aber trotzdem zum Speichermangel kommen (das hängt u.a. davon ab, was die Box bei start_tr069 noch am Leben lassen will) und dabei hilft es ungemein, wenn da Speicherinhalte ausgelagert werden können.

Ich hoffe mal nicht, daß es an einer Änderung zur 0.3.5 hin liegt ... ich habe die eigentlich schon seit fast 2 Monaten im Einsatz (mit den meisten Änderungen jedenfalls) und bisher nichts bemerkt. Aber wie gesagt ... dafür gibt es das "debug log" und seit 0.3.3 (oder so ähnlich) ist das auch immer eingeschaltet.

Ansonsten hast Du das mit dem "update" auch etwas falsch verstanden (oder ich das von Dir Geschriebene) ... das "update" erwartet ein volles Firmware-Image und erzeugt aber bloß ein SquashFS-Image, das man mit "installroot" dann in ein ansonsten bereits mit der richtigen OS-Version versehenes Gerät verfrachten kann., das wäre nur der Teil eines normalen Firmware-Images, den man mit der "installroot"-Option installieren würde. Die 18,4 MB sollten also "nur" das SquashFS-Image sein, was unter dem Namen "filesystem_core.squashfs" in der wrapper-Partition liegt und da müßte die Größe auch stimmen.

Ok, ich habe mich in #664 tatsächlich mißverständlich ausgedrückt.

In diesem Beitrag steht etwas dazu, wie man das einzelne erzeugte SquashFS-Image als Ergebnis des "update"-Aufrufs mit einer Zieldatei in die Zielpartition bekommt (mit install_inactive_rootfs). Dafür braucht man kein "modfs" oder irgendwelche anderen Faxen - das ist am Ende nur das Mounten der richtigen Partition und das Kopieren der Image-Datei unter dem richtigen Namen.

Die "installroot"-Option von "modfs" ist nur das Pendant zu diesem einfachen Kopieren, wenn eben ein komplettes Firmware-Image vorliegt, aus diesem aber nur Teile installiert werden sollen. Wie die drei "install*"-Optionen arbeiten, steht hier genau erläutert: http://www.ip-phone-forum.de/showthread.php?t=273304&p=2150764&viewfull=1#post2150764

Es gibt in Deinem Falle ja eigentlich keine Notwendigkeit, da erst ein gesondertes SquashFS-Image zu erstellen und das hinterher mit "install_inactive_rootfs" an seinen Platz zu kopieren (dann müßte man die Umschaltung anschließend auch von Hand vornehmen) ... mit ausreichendem Swap-Space sollte das ja nun funktionieren, das Erstellen des Images ist vom Resourcenbedarf her auch nichts anderes als der "komplette Lauf", es wird nur eben vorher abgebrochen - aber erst nach der Aktion, die den größten Bedarf an freiem Hauptspeicher hat.

Das ist zweifellos das Zusammenpacken des neuen SquashFS-Images, bei meiner 7490 sieht die Statistik für diesen Prozess z.B. so aus:
Diesen Speicherbedarf kann man ohne Swap-Space schwer bis gar nicht befriedigen und daher predige ich immer wieder, daß man seinem System für die Verwendung mit "modfs" eine Swap-Partition gönnen soll (dann muß man sich nicht um das Mounten kümmern, das macht dann das FRITZ!OS selbst) oder zumindest das Swappen in eine Datei aktivieren soll. Dann klappt das Einpacken auch auf einem System mit nur 128 MB RAM ... so eines ist natürlich mit dem oben gezeigten Bedarf erst recht überfordert. Wenn das auch anders ginge, könnte man auch die 7412 problemlos auf der Box ändern ... aber das klappt bekanntermaßen nicht (und auch extern über NFS o.ä. funktioniert nicht wirklich, weil das System es nicht unterstützt).

Ich hatte nach langer Zeit mal wieder eine fabrikneue 7490 mit 06.51 in der Hand (wie man da erst einmal ShellInABox aktivieren kann, kommt demnächst als (wirklich leicht nachvollziehbare) Anleitung) und als ich dort die "ursprüngliche Funktion" mit dem Kopieren des aktiven Systems in die zweite Partition verwendet habe (die Box hatte keinen Internetzugang, daher ging das Laden vom AVM-FTP-Server nicht), fiel mir dann auf, daß die jetzt standardmäßige aktivierte Debug-Protokollierung im "modfs" den eigentlich nach dem Kopieren geplanten Neustart verhindert (weil dann das Log auch weg wäre). Der Text dazu ist zwar fest verdrahtet in Englisch, aber ich will hier noch einmal den Hinweis unterbringen, daß nach dem erfolgreichen Kopieren dann einfach durch die eigene Eingabe von "reboot" die Box neu gestartet werden kann/muß. Theoretisch ist allerdings auch das nicht notwendig (die Erkenntnisse da haben sich je verändert seit den Anfängen von "modfs") und man kann einfach mit dem erneuten Aufruf von "modfs" fortsetzen.

Wie mutig müßte man denn sein?

Wenn tatsächlich etwas anders wäre (was ggü. den letzten Laborversionen schon unwahrscheinlich wäre), dann klappt entweder das Modifizieren und die Box startet mit dem neuen System oder eben nicht. Bei "nicht" kostet das 2 Minuten und das vorhergehende System läuft wieder.

Einer der Gründe war es ja, risikolos (oder zumindest mit recht geringem Risiko) die Vorteile des Aufbaus bei den NAND-Boxen zu nutzen - man kann eigentlich nichts kaputt machen. Anders bei den NOR-Modellen, deshalb gibt es dort (anders als ganz am Beginn mal gedacht) auch keine Unterstützung ... auch wenn das praktisch genauso funktioniert (zumindest bei der 7390) und bis zum Einpacken des Dateisystems.

---

-Um aber die eigentliche Frage zu beantworten ... "läuft bei mir" (seit dem Nachmittag).

OT:
Ich suche seitdem nahezu ununterbrochen irgendwie nach der entscheidenden Änderung bei der Sicherheit der Internet-Telefonie ... aber vielleicht habe ich auch zu viel erwartet.

Was ich bisher gefunden habe (bzw. glaube gefunden zu haben - muß ich erst mit älteren Versionen vergleichen), ist eine abweichende "Bewertung" des Kennworts für einen SIP-Client. Kleines 'a' bis kleines 'z' (also 26 Zeichen) gilt jetzt als "kurz" - auch verwürfelt wie in "sfecoqhkanxtdljgmurivpybzw" kommt es gerade mal auf "mittel" (vermutlich wegen des beschränkten Zeichensatzes). Die Einstufung als "kurz - mittel - lang" dürfte auch nicht so richtig günstig gewählt sein, "schlecht - mittel - gut" wäre wohl deutlicher. Irgendwelche Konsequenzen aus einem "schlechten Kennwort" finde ich gar nicht.

Wahrscheinlich stelle ich mich einfach zu glatt an, aber ich kann problemlos (und ohne jeden warnenden Hinweis im GUI, wenn man mal von dem lapidaren "kurz" absieht, aber das sollen ja auch 26 Zeichen noch sein) einen neuen SIP-Client mit dem Kennwort "1234" anlegen und diesen Account aus dem LAN auch problemlos nutzen (mit 3CXPhone) ... allerdings muß ich tatsächlich mindestens 4 Zeichen eingeben. Unter "Änderung - Anforderung für Kennwörter von IP-Telefonen weiter erhöht" hätte ich mir jetzt irgendetwas anderes vorgestellt - vielleicht kann mir ja jemand auf die Sprünge helfen, was sich da tatsächlich verbessert hat.

Ist aber eh' der falsche Thread, ich bin eben total verwirrt von so hohen Anforderungen - das steckt man in meinem Alter nicht mehr einfach so weg, wenn man sich ab jetzt Kennwörter mit mindestens 4 Zeichen ausdenken soll (vor allem dann, wenn die sich auch noch unterscheiden sollen von anderen bereits verwendeten).

Ja, die Steigerung der Sicherheit um 300% hatte ich jetzt nicht berücksichtigt. ;-)

Wie ich auf "kurz - mittel - lang" kam, weiß ich auch nicht ... vielleicht ein freud'scher Vertipper? :mrgreen:

Der Inhalt der rc.user wird vom modscript nur dann geändert, wenn diese leer ist ... das dient(e) nur dem Zweck, die bei einigen anzutreffenden Zweifel, ob die Kommandos tatsächlich ausgeführt werden, auszuräumen ... bei leerer "rc.user" wird ein Kommando für einen Eintrag ins Eventlog hinzugefügt.

Ansonsten bleibt der Inhalt, wie er ist ... enthält das neue System die Einbeziehung der "rc.user" beim Booten, sollten alle Kommandos genauso wieder abgearbeitet werden - immer unter der Voraussetzung, daß die dort aufgeführten Kommandos auch erreichbar sind.

Weil jedes System ja sein eigenes wrapper-Dateisystem hat, gibt es überhaupt nur die zusätzliche Möglichkeit, mit "ADD_TO_WRAPPER=verzeichnis" beim Aufruf von modfs zusätzliche Dateien in das wrapper-FS kopieren zu lassen, nachdem das dort liegende root-FS ausgetauscht wurde.

Startet man die eigenen Kommandos aus dem NAND-FS unter /var/media/ftp oder gar vom USB-Stick (oder braucht man keine weiteren Dateien, was bei einem SSH-Server ja eher unwahrscheinlich ist), braucht man sich um unterschiedliche Inhalte unterhalb von /wrapper natürlich nicht zu kümmern.

Der entscheidende Vorteil (in meinen Augen) einer Swap-Partition ist es, daß ein aktuelles FRITZ!OS den die beim Booten oder beim Anstecken des Sticks automatisch einbindet als Swap-Space (anders als bei einer Datei als Ziel); das gilt auch für erkannte Partitionen mit einem Dateisystem. Die Reihenfolge spielt keine Rolle, auch primäre oder logische Partition macht keinen Unterschied.

1 GB Swap-Space reicht locker und am Ende kann man das Einrichten sogar mit der BusyBox machen, die beim "modfs" dabei ist - der habe ich das "fdisk"-Applet "spendiert".

Ich wollte schon immer mal aufschreiben, wie das funktionieren würde ... mal sehen, ob ich es nachher noch schaffe.

Den Rest kann man formatieren wie man will ... bei der 7362SL mit nur 22 MB im NAND-FS macht es auch richtig Sinn, wenn man dort ein Linux-Dateisystem (ext2 oder ext3) unterbringt.

Zum Vor- und Nachteil von ext2 bzw. ext3 habe ich irgendwo etwas geschrieben (bei der Erklärung zu E99-custom müßte das gewesen sein) ... zwischen diesen beiden muß jeder selbst wählen.

ext4 halte ich an der FRITZ!Box für Unsinn (ältere Modelle/Firmware-Versionen kennen es auch nicht) ud selbst (v)FAT(32) ist nicht wirklich tauglich beim Einsatz von "modfs", weil am Ende ohnehin eine Containerdatei für ein 128 MB-ext3-Image verwendet würde.

NTFS verbietet sich (wie andere fuse-basierte FS) von selbst (und wäre ebenfalls nicht "native").