- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,298
- Punkte für Reaktionen
- 1,760
- Punkte
- 113
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
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:
Code:
ADD_TO_WRAPPER=/var/media/ftp/extend modfs ...
- 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
Zuletzt bearbeitet: