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

EDIT 25.09.2018:
Wie komme ich zu einem Shell-Zugang in einer FRITZ!Box, wenn ich noch die originale AVM-Firmware (ab 06.5x) installiert habe und das alte "modfs-Starter"-Image damit nicht verwenden kann? Hier nachlesen: https://www.ip-phone-forum.de/threa...ierte-fritz-boxen.273304/page-71#post-2269839

EDIT 27.09.2016:
Version 0.4.0 mit Abfrage der aktuellen Version beim Hersteller und Prüfung der Signatur von verwendeten Firmware-Images, damit man besser gegen eventuell manipulierte Quellen gewappnet ist ... man kann ja immer wieder im entsprechenden Thread die Suche nach alten Firmware-Images mitverfolgen und wenn AVM jetzt eine striktere Prüfung der Signatur vornimmt, dann sollte man da nicht abseits stehen (zumindest will ich das nicht, überspringen darf der Benutzer die Prüfung immer noch, das bleibt seine Entscheidung). Außerdem ist jetzt eine Möglichkeit des Debuggens (eher als "trace") von "modscripts" eingebaut (MODFS_DEBUG_SHELL=1 im Environment sorgt für die Erzeugung der Datei /var/tmp/modfs_debug_shell.log).

EDIT 09.09.2016:
AVM hat seit der Laborversion 113.06.69-40929 (bei der 7490, da ist es zuerst zu finden für mich) das Mounten von USB-Volumes abgeändert, dort wird jetzt mit der Option "noexec" gearbeitet. In der Folge sind von dort keine Programme mehr auszuführen - der interne NAND-Flash (auch kleinere Modelle haben den ja, wenn auch mit weniger Platz, aber für das Auspacken von "modfs" sollte es eigentlich immer reichen) steht aber immer noch zur Verfügung, ansonsten muß man entweder "/var" (tmpfs, volatil) dafür nehmen oder die Volumes anders mounten, bevor man "modfs" ausführen will.

EDIT 19.07.2016:
Dank des Tests durch @qwertz.asdfgh (http://www.ip-phone-forum.de/showthread.php?t=273304&p=2171420&viewfull=1#post2171420) wurde die 7430 in die Liste der erfolgreich getesteten Modelle aufgenommen und gleich noch ein "universelles unsquashfs-Utility" hinzugefügt (das wird aber im Moment nicht direkt in modfs verwendet, weil ja eine funktionierende Versionserkennung für SquashFS-Images implementiert ist).

EDIT 24.03.2016:
Es gibt eine neue Version 0.3.4 - da erfolgt jetzt der "feature freeze", nachdem noch ein Skript zur initialen Anzeige des FRITZ!Box-Namens anstelle des FRITZ!Box-Typs im GUI (HTML-title-Tag und Kopfzeile der Anzeige im neuen Design) hinzugekommen ist. Weiterhin wurde in dieser Version jetzt das Erstellen der Protokoll-Datei (Ringpuffer mit max. 64 KB Größe im tmpfs) zur Standardeinstellung auserkoren, wer es ausschalten will, muß "MODFS_DEBUG=0" als Umgebungsvariable beim Aufruf setzen. Die Ausgabe der Protokolldatei erfolgt weiterhin mit "showshringbuf modfs" und kann in eine Datei umgeleitet werden, wenn man dieses Protokoll einer Fehlermeldung bzgl. "modfs" hinzufügen will.
Ansonsten sei für weitere vorgenommene Änderungen auf das GitHub-Repo und die Liste der Commits verwiesen, einiges dazu steht allerdings auch in #589 (nach dem "Aktualisiert") seit der ersten Änderung zur 0.3.4 hin.

Seit dem 13.03.2016 gibt es von @eisbaerin einen neuen Thread, in dem die hier verstreuten Informationen zur Benutzung von "modfs" (weil eben organisch über 18 Monate gewachsen) zusammengefaßt werden. Wer also keine Lust hat, sich durch diesen Thread hier zu graben, der sollte erst einmal dort nachlesen.

Bleiben dann noch Fragen offen, bitte hier noch einmal lesen (zumindest die von diesem Beitrag aus direkt verlinkten Einträge) und erst dann (bitte, bitte - wiederholte Fragen und wiederholte Antworten machen es Euren Nachfolgern als Leser dann noch schwerer, aus einer Suchabfrage die richtigen Ergebnisse herauszufiltern und genauso wenig, wie es Spaß macht, dieselben Antworten mehrfach zu geben, genauso wenig habe ich persönlich Vergnügen daran, immer wieder auf bereits vorhandene Antworten zu verweisen, wenn Fragen wiederholt gestellt werden) seine eigenen Fragen formulieren.

Damit will ich um Himmels Willen auch niemanden davon abhalten, seine Fragen zu stellen ... wenn er es sich wirklich richtig überlegt hat und tatsächlich die passende Antwort noch nicht existiert. Aber nur so aus Spaß an der Freude und weil er keine Lust hat, sich durch diesen Thread zu graben (daher ja der Versuch, das zusammenzufassen im Thread von @eisbaerin), muß ja nicht automatisch jeder seine eigene persönliche Antwort auf bereits bekannte und beantwortete Fragen erwarten.

Die Verwendung von "modfs" braucht (meiner Meinung nach) keine speziellen Kenntnisse, aber Basiswissen in Bezug auf die Bedienung der Kommandozeile (Shell) von Linux-Systemen (dazu gehören auch die "Standardkommandos") kann es derzeit dem Anwender noch nicht abnehmen. Es soll nur dazu dienen, die bei der Verwendung von Freetz automatisch bestehende Notwendigkeit, einen PC und eine ausgewachsene Linux-Installation (egal ob als VM oder "bare metal") verwenden zu müssen, eine Nummer kleiner ausfallen zu lassen und die Hardware-Voraussetzungen für das Ändern der FRITZ!OS-Versionen von AVM (bei den unterstützten Modellen, denn wenn die Hardware das Prinzip nicht bietet, kann auch "modfs" nichts daran ändern) auf das Vorhandensein einer passenden FRITZ!Box zu reduzieren. Die Notwendigkeit, sich Kenntnisse zum Umgang mit Linux anzueignen, kann und soll "modfs" seinen Nutzern aber nicht abnehmen und für derartiges Basiswissen gibt es tatsächlich im Internet genug andere und wesentlich kompetentere (weil auch didaktisch bessere) Quellen.

Auch das soll also dieser Thread eigentlich nicht leisten ... wenn jemand (als Beispiel) mit der Bedienung des "vi" als Editor nicht klarkommt, muß/soll er einen anderen nehmen (der vi ist aber der einzige, der auch in "stock firmware" verfügbar ist) oder sich die Bedienung erarbeiten (anhand von Internet-Quellen). Es ist ein erheblicher Unterschied, ob jemand die Frage stellt: "Wie bedient man denn den vi eigentlich?" oder ob sie lautet: "Wie verwende ich den vi richtig, um eine Datei im TFFS der FRITZ!Box zu bearbeiten?". Ersteres hat mit der FRITZ!Box gar nichts zu tun (und erst recht nicht mit "modfs") und zweiteres paßt wenigstens noch zur FRITZ!Box ... auch wenn das ebenfalls schon mehrfach durchdiskutiert wurde und damit als Frage auch nicht auftauchen sollte.

Genug der "Grundsatzfragen" ... viel Erfolg beim Einsatz von "modfs". Ich hatte es mal angefangen als ein Beispiel, wie man auch ohne die Verwendung eines "großen Linux-Systems" sich die Firmware von AVM in kleinen Details, die sonst immer nur auf irgendwelchen Wunschzetteln zu finden sind, so anpassen kann, wie man es möchte ... auch heute noch ist es eigentlich kein Problem, damit "iterative Änderungen" auszuführen. Ich nutze das selbst oft genug, um eigene kleine Änderungen erst einmal auszuprobieren und sie dann - wenn sie funktionieren - einfach in das bestehende System zu integrieren, ohne all die anderen Änderungen erneut vornehmen zu müssen. Das erfordert zwar eine halbwegs sinnvolle "Liste", was man da nun wie geändert hat (damit man es beim nächsten "Komplett-Update" mit neuer Firmware vom Hersteller wieder nachziehen kann), aber so eine Liste kann auch ein Verzeichnis mit entsprechenden "patch"-Files sein, die man einfach alle erneut anwenden läßt beim Update auf eine neue Version. Die Richtung, in die sich das jetzt entwickelt hat in den vergangenen 18 Monaten paßt mir zwar nicht in allen Punkten, aber ich gebe es auch auf, mich dagegen zu wehren, daß es mehr als "fertige Lösung" denn als Werkzeug zur Realisierung einer eigenen Lösung angesehen wird.

---

-Folgende Modifikationen sind mit den Skript-Dateien aus dem GitHub-Repository (https://github.com/PeterPawn/modfs) möglich, das ist auch der aktuelle Stand, der in der Datei unter http://yourfritz.de/modfs.tgz enthalten ist:

---

-Um es noch einmal besser sichtbar zu machen: Seit Version 0.3.1 (August 2015) unterstützt das "modfs"-Skript eine Protokollierung, die bei der Eingrenzung von Fehlern helfen soll. An die Stelle der sichtbaren Ausgabe im Terminal bei einem Fehler sollte also bei jeder Fehlermeldung dieses "Protokoll" treten, weil es viel genauere Informationen enthält - gerade bei Aktionen, die aus mehreren Schritten bestehen und im Terminalfenster nur mit einer einzigen Zeile angezeigt werden. Wie man diese Protokollierung einerseits einschaltet und andererseits deren Ergebnisse sichert (der Standard-"Puffer" von 8 KB ist i.d.R. inzwischen zu klein für einen kompletten Lauf, wenn man auch die ersten Zeilen noch finden will und nicht nur die letzten), ist in diesem Thread in #190 beschrieben.
Ich würde also darum bitten, bei der Beschreibung von Fehlern weniger auf Prosa zu setzen (auch wenn natürlich die Protokollierung alleine auch kein Allheilmittel ist) und stattdessen eher die Ausgabe von "showshringbuf modfs" als Datei an so eine Meldung anzuhängen ... das spart auch einige Rückfragen. Danke.
EDIT 18.02.2016:
Es gibt schon die nächste Version, jetzt zieht aber erst einmal wieder Ruhe ein.

- Änderungen ggü. 0.3.2 stehen hier
- der Umzug in Richtung GitHub ist komplett, hier findet man das Repository: https://github.com/PeterPawn/modfs
- der Download eines gepackten tar-Files für das ganze Paket direkt auf die Box wäre von http://yourfritz.de/modfs-0.3.3.tgz möglich (auch der "aktuelle" Link "modfs.tgz" zeigt jetzt auf die neue Version)

- folgende Modifikationen (aka "modscripts") stehen im Archiv zur Verfügung (alle optional, also mit Abfrage vor der Anwendung), diese Liste wird künftig aktualisiert:
<<< Tabelle entfernt, steht weiter oben >>>

EDIT 14.02.2016:
Es gibt eine neue Version (0.3.2) von modfs, die Änderungen ggü. 0.3.1 sind hier beschrieben. Die Download-Links ändern sich entsprechend auf "modfs-0.3.2.tgz", der "aktuelle" Link "modfs.tgz" auf yourfritz.de zeigt ab sofort auf diese 0.3.2-Version. Der zwischenzeitlich mal eingeführte Link "modfs_with_06.35.tgz" wurde ersatzlos gestrichen.

EDIT 16.12.2015:
Für den Shell-Zugriff auf eine FRITZ!Box mit originaler Firmware (dieser Zugriff ist ja eine Voraussetzung für die Verwendung von modfs) gibt es jetzt ein neues Angebot von mir: modfs-Starter

EDIT 06.11.2015:
Über E-Mail wurde ich darauf aufmerksam gemacht, daß es nirgendwo explizit erwähnt ist, daß das modfs-Archiv auf einem Linux-System ausgepackt werden muß (gemeinhin eben auf der Box selbst) und nicht irgendwo anders. Ansonsten stimmt am Ende nichts mehr, von den Symlinks anhand der Hardware-Revision zu den richtigen Binaries für die Plattform (ja, ich weiß, in der veröffentlichten Version sind nur VR9-Boxen unterstützt, aber man kann ja mal überlegen, welche Modelle/Prozessoren es noch so geben könnte, daher dieser "indirekte Weg") bis zu den Dateirechten der Skripte.
Auch noch einmal der Hinweis, daß es (der Einfachheit halber schreibe ich jetzt: zwingend) erforderlich ist (zumindest ist es mehr als dringend anzuraten), einen USB-Stick mit einer Swap-Partition und einer Dateisystempartition mit ext2/ext3 (ggf. auch ext4, wenn die Box damit klarkommt) zu verwenden (bei allen Modellen außer der 7490 praktisch unumgänglich). Es gibt zwar theoretisch auch die Möglichkeit, eine "Containerdatei" per Loop-Device als Linux-FS zu benutzen, das klappt aber wohl nur auf Boxen mit ausreichendem Hauptspeicher (und damit wieder nur bei der 7490) zuverlässig.
Einige (unerklärliche) Phänomene haben sich jedenfalls in Wohlgefallen aufgelöst, wenn diese Voraussetzungen erfüllt waren, bei ganz speziellen Fällen ist dann noch ein "prepare_fwupgrade start_tr069" vor dem Aufruf von modfs erforderlich. Damit wird allerdings die Box teilweise heruntergefahren und nach getaner Arbeit ist dann ein Neustart unumgänglich - ohne "prepare_fwupgrade" kann man sich ja aussuchen, ob man mit "modfs undo" das Ganze praktisch ungeschehen macht ... auch ohne Neustart.

EDIT 30.10.2015:
Da ich mich hier aus dem IPPF zurückziehen will, habe ich eine E-Mail-Adresse (Postfach modfs in der Domain yourfritz.de) eingerichtet, über die künftig bei Fragen oder Problemen dann meinerseits der Kontakt laufen soll ... bitte sparsam benutzen, bei Mißbrauch gibt's (spätestens nach entsprechendem Hinweis meinerseits) auch den Eintrag im killfile.

EDIT 10.10.2015:
Thread-Titel geändert, da das ja lange nichts mehr mit 06.20 zu tun hat und die meisten Anwender es ohnehin eher zur Wiederbelebung des Telnet-Daemons benutzen.

EDIT 03.10.2015:
Die ältere Version, die sich mit der neueren AVM-Firmware "nicht auskennt", habe ich heute in "modfs_old.tgz" umbenannt (es gab noch keine Versionsnummer). Damit ist unter http://yourfritz.de/modfs.tgz kein Download mehr möglich, die anderen URLs bleiben gültig.

Bei der Verarbeitung der aktuellen Firmware-Images von AVM mit dem tar-Applet der von AVM verwendeten Busybox-Version (1.22.1) kommt es zu einer Fehlermeldung "tar: short read", die in Abhängigkeit von der Busybox-Version zu einem Exitcode von 1 (bei 1.22.1) oder 0 (bei mir mit 1.23.2) führt. Eine Anpassung des Skripts an dieses Problem nehme ich nicht vor, die einfachste Lösung besteht in der Korrektur der Archiv-Datei - wie das geht, steht in #305.

EDIT: 26.07.2015
Die neue Version unter der URL

http://yourfritz.de/modfs-0.3.1.tgz - neue Version 0.3.2 (s.o.), auch wenn der Link für 0.3.1 noch existiert

ist jetzt für folgende Szenarien bei der 7490 getestet:
Bei einem "Downgrade" über die Installation einer älteren Firmware-Version muß man sich selbst darum kümmern, daß die Einstellungen passen. Das Skript interessiert sich nur für den Kernel und das Wrapper-Filesystem mit dem dort enthaltenen Root-Filesystem.

Ab Version 0.3.1 (ich habe jetzt mit einer sichtbaren Nummerierung begonnen) unterstützt das Skript eine Protokollierung im Hintergrund. Die Einzelheiten dazu stehen in #190 in diesem Thread. Auch weitere Informationen (u.a. zu den jetzt enthaltenen squashfs-tools) sind dort zu finden.

EDIT: 15.07.2015
Die neue Version unter den URLs


http://yourfritz.de/modfs_with_0635.tgz oder

http://yourfritz.de/7490/modfs.tgz

hat jetzt auch Unterstützung des neuen AVM-Formats für den 06.35er-Zweig der Labor-Reihe zu bieten. Genaueres steht in #109 ... bitte genau lesen.

EDIT 08.06.2015:
Für die Reaktivierung des Telnet-Daemons wurde ein weiteres "modscript" hinzugefügt. Wenn man also auf eine AVM-Version ohne Telnet aktualisieren will, kann man mit dieser Modifikation den Telnet-Daemon auch wieder zum Leben erwecken ... jedenfalls solange er von AVM nur durch das Entfernen eines Symlinks deaktiviert wurde.

EDIT 11.05.2015:
Es besteht jetzt auch die Möglichkeit, mit "modfs" anstelle des GUI der FRITZ!Box ein Update mit gleichzeitiger Integration der eigenen Änderungen zu machen bzw. auch Labor-Versionen auf diese Weise zu installlieren, ohne daß in beiden Partitionen-Sets dasselbe System vorhanden sein muß. Damit bleibt ein Rückweg zur letzten Version offen ... genaueres dazu findet sich in #72 in diesem Thread.

Ausdrücklich werden zur Zeit nur die Modelle 7490, 7362SL, 3370, 3390 und 3490 unterstützt.

Wer das gerne aber mal auf einer 7272, 3272, 3390 oder 3490 testen will, kann mich gerne dazu einladen, wenn er nicht klar kommen sollte.

Ich persönlich würde es gerne auf alle Boxen ausweiten, auf denen es technisch möglich ist ... ob es mit den vorstehend genannten Modellen funktioniert (theoretisch sollte es klappen), kann man aber nur durch Test feststellen. Solange ich nicht wenigstens einen erfolgreichen Versuch mit einer solchen Box vermelden kann, nehme ich die meinerseits nicht in die "HWRevision"-Liste im Skript auf.

EDIT: WICHTIG - Gerade unter dem Aspekt der oben beschriebenen Erweiterung um den "update"-Parameter sollte man sich das etwas genauer durchlesen und den unten stehenden "Quickstart" nur als Referenz nutzen. Wenn man das Skript im "update"-Modus benutzt, kann man einerseits das bisher verwendete System in der dann inaktiven Partition "aufheben" und bei Problemen einfach wieder auf dieses System umschalten und andererseits wird aus dem "Mehrzüger" bei einem Update ein einzelner Durchlauf. Das macht es weitaus einfacher (in meinen Augen) und die unten stehende Anleitung berücksichtigt das nur unzureichend.

tl;dr
Eigene Kommandos (debug.cfg/rc.user) reaktivieren (für passende VR9-basierte Boxen) als "Einzeiler":
ab 0.3.2 gibt es keine "automatischen" Änderungen mehr in der Download-Datei, der Einzeiler:
bleibt zwar gültig, aber jetzt wird jede Änderung "abgefragt" und auch die debug.cfg/rc.user nicht mehr automatisch aktiviert (es gibt andere - imho bessere und sicherere - Wege).
Wenn man die Fragen nach den zusätzlichen Modifikationen alle mit 'n' beantwortet, wird nur die Abarbeitung der Kommandos in der 'alten debug.cfg' wieder aktiviert.
Sollte die Box zwei verschiedene Firmware-Versionen enthalten, ist zwischendurch noch ein Neustart erforderlich, nach dem man dann noch einmal von vorne beginnen muß.

Wer sich das lieber vorher ansehen will, benutzt
und liest sich zumindest die README-Datei einmal durch (README.ger versucht die Erklärung in deutsch zu geben). UPDATE 14.02.2015 -> Die README-Datei ist uralt ... irgendwann schaffe ich es bestimmt mal, da eine passende README.md für das GitHub-Repo zu schreiben - im Moment hilft es nur, wenigstens die hier in #1 verlinkten Beiträge in chronologischer Folge zu lesen, wenn man die Änderungen in der "Bedienung" (und in den gebotenen Möglichkeiten) nachvollziehen will.

Ansonsten die "Langform":
Ich habe das eher komplizierte Vorgehen (6 Kommandos in Abhängigkeit vom vorherigen Ergebnis) beim direkten Reaktivieren der rc.user-Abarbeitung (vielleicht besser bekannt als 'debug.cfg') überarbeitet und es auch auf einem weiteren Modell (einer 7362SL) zum Laufen bekommen.

Diese neue Version (alles nur Shell-Code, mit Ausnahme der squashfs-Tools zum Entpacken/Packen der Images) steht unter der Adresse

http://yourfritz.de/modfs.tgz

als komprimiertes tar-Archiv bereit. Im Paket ist eine Beschreibung (README-Datei) enthalten, bei Problemen bitte erst dort lesen.

Außerdem erfolgt die Abarbeitung der einzelnen Schritte jetzt "im Dialog" mit dem Benutzer und es gibt eine Version mit einem deutschen Interface.

Zusätzlich gibt es jetzt auch noch eine (optionale) Modifikation des AVM-GUI, die direkt beim Neustart der Box die Auswahl des "anderen Systems" auf einem "dual boot"-System ermöglicht.
Anhang anzeigen 77880

An der prinzipiellen Vorgehensweise hat sich gegenüber dieser Beschreibung nicht so sehr viel geändert, nur das "Benutzerinterface" wurde vollkommen umgekrempelt. Auf einer 7490 läuft es auch ohne USB-Speicher, auf einer 7362SL oder 3370 wird zusätzlich ein USB-Speicher mit ca. 256MB freiem Speicherplatz benötigt (da ist ein "Sicherheitsaufschlag" schon eingerechnet). Der USB-Speicher muß angesteckt sein, da fehlt noch ein entsprechender Test im Skript, baue ich mit der nächsten Erweiterung für ein anderes Modell dann ein.

Nach neuen Erkenntnissen muß auch vorher wenigstens auf die Version 06.20 aktualisiert werden (konkret per "Update" und nicht per "Recovery"), damit der "dual boot"-Mechanismus auch wirklich benutzt wird ... der ist nicht immer aktiviert und wird vom AVM-Update auch nur simpel durch das Schreiben der "linux_fs_start"-Variablen aktiviert.

Folgende Modelle könnten wahrscheinlich ebenfalls funktionieren: 7272, 3272, 3390, 3490(geklärt 17.06.2015, 3490 funktioniert)

Wer im Besitz einer der erwähnten Boxen ist und sich einen Test zutraut, ist hiermit herzlich dazu eingeladen. Sollte er/sie dabei Hilfe benötigen, stehe ich gerne per PN oder im IRC dafür zur Verfügung. Das Script muß aber vor dem Test modifiziert werden, zur Sicherheit werden ansonsten nur bereits getestete Modelle unterstützt.

Die 7360(SL) hat zwar ebenfalls einen VR9-Prozessor, aber offenbar auch nur 16MB-NOR-Flash wie die 7390. Da ihr damit auch der NAND-Flash der 7390 fehlt, wird sie in jedem Falle erst dann ein Thema, wenn das Modifizieren einer 7390 auch geklappt hat und auch dann wird dort wohl in jedem Fall ein zusätzlicher USB-Speicher benötigt.

Was ist nun als nächstes geplant ?

1. Ausbau des Skripts für den Einsatz bei NOR-Flash-basierten Geräten, zuerst der 7390; solange im NAND-Flash der Box genug freier Speicher vorhanden ist, sollten die ~50MB freier Hauptspeicher bei einer laufenden 7390 reichen, um die Modifikationen auszuführen und dann läuft es am Ende auch nur auf dieselbe Prozedur wie bei einem "externen" Image-Update hinaus ... allerdings gibt es dort eben "keinen Weg zurück". Diese Idee habe ich zwar tatsächlich realisiert, aber für die "Öffentlichkeit" wird es das nach reiflicher Überlegung nicht von mir geben. Die prinzipielle Vorgehensweise dürfte klar sein, die größte Herausforderung ist das Aufräumen nach dem Erstellen des Images (mksquashfs braucht auch viel Hauptspeicher) und das anschließende Bereitstellen des fertigen Images (zusammen mit dem notwendigen freien Hauptspeicher) im tmpfs, da es bei dieser Box nicht im NAND-Flash abgelegt werden kann, denn wenn man sich auf eine Analogie zum AVM-Skript /var/install einläßt und die notwendigen Kommandos an die /var/post_install anfügt, ist zu dem Zeitpunkt, wo der Kernel-Treiber zum Flashen geladen wird, das yaffs2-FS im NAND schon nicht mehr verfügbar.

2. ein Versuch, mit den FHEM-Leuten ein passendes "ModScript" für die Integration des FHEM-Servers in eine 7490 zu erstellen und damit den Leuten, die sich auch wegen des FHEM-Servers eine 7490 angeschafft haben, wieder die "normale" Funktion zu bieten - UPDATE: Das nachträgliche Installieren des FHEM ist möglich, die Unterstützung der FRITZ!Box-Version von fhem.de ist imho nur bedingt sinnvoll. Wenn dort jemand auf die Idee kommt, die alte libcrypto/libssl von OpenSSL wieder einzuspielen, damit FHEM SSL-Verbindungen unterstützt, dann wird damit eine neue Sicherheitslücke aufgerissen und das ist nun so gar nicht meins.
EDIT 18.06.2015
Da es inzwischen auch auf fhem.de gar kein Paket für die FRITZ!Box (ab Version 06.20) mehr gibt, das auch die - für mich bei so einem Projekt aus prinzipiellen Erwägungen unverzichtbare - SSL-Verschlüsselung mit OpenSSL > 1.0.0 unterstützt, würde das oben stehende das Erstellen eines kompletten eigenen FHEM-Paketes beinhalten ... das fällt für mich persönlich aus, ich nutze es ja gar nicht selbst. Wenn jemand ein solches Paket auch für Firmware ab 06.20 (mit SSL !) schnüren sollte und das verbreiten will, kann er sich gerne melden.

EDIT: Die Informationen zur 3390 liegen vor (danke an den Unterstützer), das ist auch ein Doppelprozessor VR9. Auch der Rest der Komponenten (die für den Zweck der Modifikation relevant sind) ist mit der 7362SL identisch, damit könnte man das auch mit der 3390 versuchen. Allerdings bringt auf der dort aktuellen Firmware (06.03) im Moment wohl nur das Nachrüsten des Dual-Boot-GUI wirklich etwas, debug.cfg usw. dürfte dort ooB noch funktionieren.
EDIT 18.06.2015:
Die Unterstützung der 3390 ist jetzt ebenfalls enthalten im Skript. Wie bei den anderen Modellen ohne Telefonie bleibt bei dieser (Kommandozeilen-)Version des Skripts die Herausforderung, erst einmal einen Telnet-Zugang zur Box zu erhalten.

EDIT 18.11.2014
Dank der Hilfe von Lebedev ist es inzwischen auch auf der 3370 getestet.

Predictor schrieb:

Ist da schon etwas in Sicht?

Zum Vergrößern anklicken....

In Arbeit, kein Ende prognostizierbar.

Wenn es jemanden interessiert, warum ... das derzeit in Freetz vorhandene mksquashfs3-lzma (basierend auf LZMA SDK 4.43) packt auf einer 7390 aus einen 56 MB-Baum leider nicht die erwarteten 14 MB, sondern >40MB. Ich behaupte, das liegt am Unterschied BE vs. LE (fast alle packen ja ihr eigenes Image in einer x86/x64-Linux-Umgebung) und bin dabei, das in squashfs4 genutzte LZMA SDK 4.65 (da basiert der Code dann auf C und nicht auf C++) als Patch in den Code im Trunk zu integrieren. Fehlt ein wenig die Zeit ...

Würdest mich echt retten!

Zum Vergrößern anklicken....

Nimm doch erst einmal Freetz und lasse nur "repacken". Dauert deutlich weniger lang als komplettes Freetz-make ... wie es geht, steht irgendwo in einem Beitrag von er13 (Stichworte "fwmod" und "debug.cfg" sollten eigentlich zielführend sein).

Tut mir leid ... ein FHEM-Skript mache ich aber wirklich noch, aber erst nach 7390-Unterstützung, da ich im Moment wieder nur eine 7390 dafür als "freies Testgerät" habe.

Klaus_Heynen schrieb:

Funzt das auch mit der neue Labor 6.21-29325?

Zum Vergrößern anklicken....

Theoretisch ja. Einfach mal probieren, aber beim "last exit" dann abbrechen und die Änderung an der "rc.tail.sh" kontrollieren. Das Skript kontrolliert zwar selbst den Erfolg der Modifikation, aber einmal mehr kann nicht schaden.

Solange die mod-Skripte alle den gewünschten Effekt haben, sollte es weiterhin funktionieren, wenn AVM nicht den Update-Prozess selbst ändert. Wenn man die "install"-Skripte in der 06.20 und der 06.21 vergleicht:
kann ich da keinen wesentlichen Unterschied sehen ... aber selbst getestet habe ich es mit 06.21 noch nicht.

Wenn das nicht wieder auf Laborversionen im Wochentakt hinausläuft, werde ich nicht mehr lange mit einem eigenen Test warten, aber mir fehlt einfach die Zeit, das jede Woche auf's Neue zu testen.

Bonvie schrieb:

Ich habe ein Problem mit meiner zweiten 7490, die etwas neuere ist und scheinbar keine linux_fs_start Variable hat. Ich habe beide Boxen mit dem gleichen Recover Image 6.20 mehrfach betankt, bei der alten ist Variable linux_fs_start immer im support File enthalten und bei der neuen leider nicht.
Kann ich das selber setzen und wenn wie ?

Zum Vergrößern anklicken....

Das ist/war eine Weile noch unklar, die derzeitige Annahme besagt: Die Variable wird beim ersten Update mit einer neuen Firmware gesetzt, kann man im install-Skript in einem Firmware-Image sehen. Dort werden auch Vorkehrungen getroffen, eine fehlende linux_fs_start-Variable zu setzen. Der Recovery-Prozess (zumindest für 06.20) beschreibt nach meinem Test immer die aktive Partition, ein Update die inaktive.

Du kannst also entweder die Variable von Hand richtig setzen (mtd0/1 -> linux_fs_start=0, mtd2/3 -> linux_fs_start=1, aktiv ist immer das Partitionspaar (kernel+filesystem), bei dem kein reserved im Namen steht beim 'cat /proc/mtd' (ist auch in den Supportdaten irgendwo zu sehen)) oder Du machst einfach mal ein Update auf die neue Laborversion, dann hast Du sicherlich die Variable. Willst Du dann lieber nicht die Laborversion nehmen, löscht der nächste Recovery-Versuch genau die Laborversion, wenn sie die aktive ist zu diesem Zeitpunkt.

flemlion schrieb:

Only thing I'm missing now is a way to add an ipforwardrule to ar7.cfg or equivalent to open internet access to a custom app on the Fritz 7490

Zum Vergrößern anklicken....

You should have a look at this thread: http://www.ip-phone-forum.de/showthread.php?t=274774&p=2051034&viewfull=1#post2051034

Even if it's in german at all, the shown part of the ar7.cfg file should be self-explanatory.

Bonvie schrieb:

Ist es generell Versions unabhängig oder Zufall ?

Zum Vergrößern anklicken....

Solange AVM an den Dateien, die beim Ausführen der Modscripts angepaßt werden, nichts ändert (bzw. nichts ändert, was das fast immer verwendete sed ins Leere laufen läßt) und das Prinzip bei der Partitionverteilung auch beibehalten wird (das werden sie aber kaum aus Spass ändern), ist das schon von der AVM-Firmwareversion unabhängig ... aber eine(r) muß eben immer der/die Erste sein beim Testen. Insofern danke für die Rückmeldung ...

Irgendwann werde ich auch mal soweit kommen, daß die Modifikationen auf Wunsch gleich beim Update vorgenommen werden und der zusätzliche Schritt mit dem Kopieren des Systems (damit zwei identische Versionen in der Box vorhanden sind) dann entfallen kann ... vielleicht klappt es ja noch in diesem Jahr mit der Übertragung auf die 7390 und einem GUI (also dem Webbrowser) anstelle der Telnet-Shell. Nachdem das jetzt ziemlich stabil (auch bei mir selbst) funktioniert, ist die (etwas übertriebene) Vorsicht wahrscheinlich gar nicht mehr notwendig und man könnte sogar einen Mechanismus in die Firmware einbauen, daß die Änderungen ganz normal beim Update über das GUI (wahrscheinlich sogar bei einem automatischen Update) mit eingebaut werden, nachdem erst einmal "der erste Kontakt" (bzw. die erste Installation) ausgeführt wurde.

@mutt123:
Definitiv nicht ... es fehlt einfach die - bisher noch - notwendige Voraussetzung des "doppelt vorhandenen Systems" (aka "dual boot").

Wenn mich nicht noch jemand davon überzeugen kann, daß das eine ganz schlechte Idee ist, wird es bis Ende Januar 2015 wohl eine Version auch für NOR-Flash-Boxen geben ... mit ein wenig Glück sogar mit einer Browser-basierten Oberfläche anstelle der Telnet-Shell (also Laden eines speziellen Images und der Rest läuft dann im Browser ab).

fant schrieb:

Weiß man, wie AVM zu diesem Patch steht? Ich frage wegen der Garantie, die wird dann wohl auch verweigert, oder?

Zum Vergrößern anklicken....

Ich sehe den Zusammenhang zum Patch ehrlich gesagt nicht ... vielleicht liegt das an unterschiedlichen "Begrifflichkeiten".

Garantie ist eine freiwillige Leistung des Herstellers, deren Umfang, Bedingungen und Dauer er selbst bestimmen kann.

Gesetzliche Gewährleistung ist eine Pflichtleistung des Händlers (des Vertragspartners), die sich auf Produktmängel erstreckt (ausgehend vom Zustand zum Zeitpunkt des Vertragsschlusses, i.d.R. des Kaufes).

Support ist wieder eine andere Schiene (i.d.R. auch unabhängig von einer Garantie) -> ebenfalls eine freiwillige Leistung des Herstellers, die er - selbst bei nicht modifiziertem Gerät - auch verweigern kann. Es gibt keinen Anspruch des Endkunden auf einen Support des Herstellers, es gibt nach deutschem Recht nicht einmal eine Vertragsbeziehung zwischen dem Hersteller und dem Endkunden (wenn nicht direkt beim Hersteller das Produkt erworben wurde).

Auswirkungen von modfs:
Der Patch modifiziert die Firmware einer Box und ist - wie jede andere Modifikation der Firmware - durch Recovery vollständig zu beseitigen, nach entsprechenden Vorbereitungen (Löschen eigener Einstellungen mit Minor-ID < 100, inkl. des ominösen "fw_attrib" (minor 87), woraus die "nicht unterstützte Änderungen"-Meldung resultiert) auch bei jedem Update, vollkommen ohne Werksreset.

Leistungen von AVM:
Daß AVM für modifizierte Firmware keinerlei Support leistet, versteht sich von selbst, wobei die Unterscheidung zwischen modifizierter und nicht modifizierter Firmware nicht so einfach ist, wie bei einer Freetz-Installation. Das ist tatsächlich ein Punkt, den ich wahrscheinlich noch ändern sollte, damit niemand auf die Idee kommt, AVM mit einer modifizierten Firmware bzgl. eines Problems zu kontaktieren. Da - zumindest bisher - auf einer mit modfs bearbeiteten Box ja immer zwei Varianten zur Verfügung stehen, sollte es für jeden Nutzer problemlos möglich sein, den AVM-Support nur mit einer unmodifizierten Firmware zu "belästigen", ohne daß man auf den NAND-Flash-Modellen dazu großartige Anstrengungen unternehmen muß. Daß AVM nicht für die eigenen Modifikationen der Firmware zuständig oder gar verantwortlich sein kann, sollte jedem einleuchten, der seine Box modifiziert.

Ansonsten ist AVM der Patch in der derzeitigen Form wahrscheinlich egal.

Die Idee, das am Ende so weit zu vereinfachen, daß es auch ohne eigene Linux-Kenntnisse (aka Shell-Zugriff) funktionieren kann, sieht man dort wesentlich kritischer ... in erster Linie aber wegen zusätzlichem Support-Aufwand, der sich dann ergeben könnte, wenn der Nutzer nicht versteht, daß es nicht Sache von AVM sein kann, wenn er seine Box modifiziert.

Ich kann das Argument sogar nachvollziehen, sehe aber zwei Punkte für eine mögliche Abhilfe: Erstens einen überdeutlichen Hinweis auf die Modifikation in das GUI einzubauen, der auch dem letzten, des Lesens kundigen, Nutzer klarmachen sollte, daß AVM nur für unmodfizierte Firmware Support leistet (ich habe bisher auch noch nicht gehört, daß sich z.B. Kunden mit iOS-Jailbreak bei Problemen an Apple gewandt haben, aber offenbar kann man nie verquer genug denken) und zweitens die dabei angebotenen Modifikationen (mir schwebt tatsächlich so eine Art Repository vor, in dem für unterstützte Modelle eine Standard-Variante eines Freetz-Pakets vorgehalten wird, die dann installiert und - in engen Grenzen - konfiguriert werden kann) so "idiotensicher" und nur für wenige Aspekte konfigurierbar zu machen, daß sich daraus nur wenige Komplikationen ergeben können. Wenn man bei einer Linux-Distribution ein Standardpaket installiert, ist das auch auf den Standardfall zugeschnitten und ob das dann z.B. am Ende mit Readline-Support erstellt wurde oder nicht, entscheiden die Maintainer. Wer ein besser passendes Paket will, muß dann eben wieder selbst zum Compiler greifen.

Dabei ergibt sich allerdings in meinen Augen auch ein Problem: AVM besteht - zu Recht - darauf, daß das GUI-Layout eine "schöpferische Leistung" ist und damit nach dem UrhG in D einen gewissen Schutz genießt. Damit verbietet sich eine entsprechend auffällige Modifikation des GUI theoretisch von selbst, wenn dabei das GUI entscheidend verändert wird. Schon die kleine Darstellungsänderung beim Reboot habe ich lange hin und her gewälzt ... die halte ich aber für vertretbar (zumal sie ja von jedem Besitzer der Box selbst ausgeführt wird und nicht im Rahmen eines kommerziellen Angebotes, wie es bei der Cybits-Kindersicherung der Fall war) und so gering (deshalb auch das "Einpassen" in das AVM-Layout), daß ich da eher gelassen bin, was das UrhG anbelangt. Wenn man also - im Interesse von AVM - eine entsprechend auffällige Modifikation des GUI vornehmen will, müßte man sich wahrscheinlich vorher mit AVM darüber einigen. Ob sie da überhaupt "mitspielen", kann ich nicht einschätzen ... meine Beurteilung "Es ist doch nur zu Eurem Besten." muß man ja nicht unbedingt teilen, das Leben vollkommen ohne Modifikationen ist für AVM sicherlich noch besser.

Aber noch sind ohnehin nicht alle "Zutaten" für eine solche "nur User"-Modifikation (in der notwendigen Qualität) beisammen und auch seitens AVM kommen immer wieder einige Änderungen. Da sich bei dem Versuch, das am Ende ganz simpel nur über das GUI zu starten und ansonsten auf den Telnet-Zugriff zu verzichten, noch weitere - potentielle bzw. theoretische, aber keine akuten (damit niemand irgendwelche Schweine durch's Dorf treibt) - Sicherheitsprobleme aufgetan haben, bin ich tatsächlich mit AVM zu diesem Thema in Kontakt getreten und habe die Lücken (nach meiner Ansicht) gemeldet. Dabei entstand dann auch eine Diskussion zum Thema "Modifizieren" ... das Ende ist noch offen.