[Info] FRITZ!Box 7490 - debug.cfg reaktivieren ohne Image-Update

Es gibt eine neue Version des Skripts, dazu habe ich auch ein neues Thema aufgemacht.
Um es noch einmal ganz deutlich zu schreiben: Wenn jemand die nach wie vor auf dem Server vorhandene alte Version (modfs_7490.tgz) nutzen will, habe ich nichts dagegen. Aber irgendwelche Anfragen beantworte ich nur noch zur neuen Version (modfs.tgz) ... ich ändere auch nichts mehr an der alten Version, selbst wenn mir Fehler dort zur Kenntnis gelangen.

Quickstart für diejenigen, die grundsätzlich nur "machen" wollen - die Kommandos ohne Lametta
Nach dem Neustart sollte der Inhalt der rc.user (AVM nennt sie debug.cfg) abgearbeitet werden.

Wer das jetzt trotz aller Warnungen als Einzeiler für die Box haben will, nimmt folgendes:

Und das Ganze noch einmal als Einzeiler mit dem Download einer "frischen Kopie" des Firmware-Images vom AVM-FTP-Server:

Der originale Text beginnt hier, aber Einzelheiten wurden nachträglich korrigiert:
Auf der Basis des in der 7490 doppelt vorhandenen Flash-Speichers für das Kernel-Image und der anderen Handhabung des root-Filesystems ist es - mit zwei zusätzlichen Binaries - möglich, die Abarbeitung der debug.cfg (aka rc.user) direkt auf der FRITZ!Box 7490 wieder zu aktivieren.

Bereits bei der Abschaffung der debug.cfg in den Labor-Versionen wurde von er13 ja ein Patch und eine Änderung von "fwmod" im Freetz-Trunk eingepflegt, mit denen man sich ein eigenes Freetz-Image ohne freetz-mod erstellen konnte. Einige sind diesen Weg bereits gegangen, andere werden sicherlich noch zögern.

Auch wenn ich i.d.R. das Benutzen von "fremden Übersetzungen" eher ablehne (also die Verwendung von Binaries aus "OpenSource"-Quellen, die von anderen erzeugt wurden, eher nicht empfehlen würde), habe ich mich doch entschlossen, diese Binaries - zusammen mit einigen Shell-Skripten - auch anderen zur Verfügung zu stellen. Ich hoffe, damit noch weiteren Interessenten wieder die Verwendung eigener Software auf einer 7490 ohne großen eigenen Aufwand zu ermöglichen.

Spätestens wenn das dann nicht nur ein paar Skripte unter Verwendung bereits vorhandener Kommandos sind, sondern auch wieder zusätzliche Binaries benötigt werden, würde ich aber wieder auf die vorstehende Bemerkung verweisen und die Verwendung von Diensten(!) auf Basis fremder Binaries eher ablehnen.

Egal, zum Wesentlichen ... die Aktivierung der Abarbeitung der debug.cfg ließe sich ganz einfach in einer Telnet-Session mit den folgenden Kommandos erledigen:
Als erstes wird das Paket mit den Binaries und den Skripten von einem meiner Server geladen und die Prüfsumme des geladenen Archivs gebildet. Hier bin ich leider auf die Verwendung des echt antiquierten MD5 als Algorithmus angewiesen, da die AVM-Firmware von sich aus keine Kommandos für einen moderneren Algorithmus anbietet.
Wichtig ist es in jedem Falle, daß die oben farbig dargestellte Prüfsumme auch wirklich stimmt, ansonsten wurde das Archiv irgendwie modifiziert und man sollte die Finger davon lassen.

Weil ich gerade beim "Finger davon lassen" bin, mir ist genauso wenig zu trauen, wie jedem anderen Anbieter von nicht zu überprüfender Software auch. Wer also meiner Beschreibung folgt, tut dies absolut auf eigenes Risiko. Allerdings kann ich mir keinen Schaden vorstellen, der größer wäre, als er bei einem "normalen" Flashvorgang auch sein könnte. Insofern sollte im Falle eines unerwarteten Abbruchs spätestens mit dem AVM-Recovery-Programm jedes Problem wieder zu beseitigen sein.

Wenn jemand für das Archiv modfs_7490.tgz die Hashes mit anderen Programmen prüfen will, hier sind die Werte für einige andere gängige Algorithmen:


Wenn wir jetzt sicher sind, daß das Archiv auch wirklich das richtige ist, können wir weitermachen:
Wir legen uns ein Verzeichnis /var/mod auf der Box an (das ist temporär, da nur im RAM) und entpacken dort das Archiv. Nach einem kurzen Blick, was da so alles drin ist, checken wir erst, ob die notwendigen Voraussetzungen für das Aktivieren der debug.cfg vorliegen. Dabei werden noch einmal die einzelnen Dateien anhand ihres MD5-Hashes mit den von mir eingepackten Dateien verglichen (die stehen in checksums), was sicherlich doppelt gemoppelt ist, aber ich bin ein vorsichtiger Mensch.

Eine der Voraussetzungen für den erfolgreichen Einsatz der Skripte ist, daß die Box in den beiden verfügbaren Flash-"Versionen" dasselbe FRITZ!OS enthält. Die Modifikation zur Reaktivierung der debug.cfg erfolgt nämlich so, daß das root-Filesystem des laufenden FRITZ!OS (in der Datei /wrapper/filesystem_core.squashfs enthalten und per loop-Device als / gemounted) entpackt, anschließend modifiziert und dann wieder zu einem SquashFS gepackt wird. Dieses neue SquashFS wird dann in die nicht-aktive Filesystem-Partition kopiert und anschließend auf den Start aus der anderen "Flash-Variante" umgeschaltet. Beim nächsten Start der Box wird dann das neue root-Filesystem mit den ausgeführten Änderungen benutzt.

Sollten auf der Box noch zwei unterschiedliche System sein (z.B. direkt nach einem Update mit einem neuen AVM-Image), sähe das in etwa so aus:
Aber auch dieser Fall läßt sich relativ leicht lösen, indem einfach auch der Kernel des laufenden Systems in die inaktive Kernel-Partition kopiert wird. Dasselbe wird mit dem Wrapper-Filesystem praktiziert, danach enthalten beide "Versionen" der FRITZ!Box 7490 dann ein identisches System und der Modifikation des root-Filesystems steht nichts mehr im Weg.
Jetzt sind die beiden Systeme identisch und ein erneuter Test mit "./prereq_7490" sollte keine Probleme mehr melden.
Wer absolut auf Nummer sicher gehen will, bootet noch einmal kurz seine Box neu und fängt von vorne an.
Zur Sicherheit empfehle ich die Box nach dieser "Gleichmacherei" neu zu starten und von vorne zu beginnen.

Im nächsten Schritt wird jetzt das root-Filesystem des laufenden FRITZ!OS ausgepackt (dazu dient das unsquashfs) und anschließend werden alle im "modscripts"-Verzeichnis liegenden Shell-Skripte (in aufsteigender alphabetischer Reihenfolge der Dateinamen) abgearbeitet. Diese Skripte kriegen als einzigen Parameter den Pfad zum "root-Verzeichnis" des entpackten SquashFS übergeben und können nun ihrerseits die dort liegenden Dateien modifizieren.
Ich habe meinerseits dort drei Skripte bereits hinterlegt, das entscheidende dürfte 'mod_rc_tail_sh' sein:
Damit wird die Datei etc/init.d/rc.tail.sh in der vorletzten Zeile dahingehend geändert, daß die frühere debug.cfg-Datei (unter anderem Namen an anderer Stelle, aber das ist meine volle Absicht) auf das Vorhandensein irgendeines Inhalts geprüft wird und - wenn dort etwas drin stehen sollte - dieser Inhalt dann in die Datei "/var/tmp/rc.user" kopiert wird. Dann wird auch - mit einer Sekunde Verzögerung über einen Mechanismus im FRITZ!OS - eine Shell gestartet, die die Abarbeitung der Kommandos übernimmt. Anschließend wird das "Fenster" in das TFFS, durch das wir den Inhalt der debug.cfg kopiert haben, wieder geschlossen (auch wenn die debug.cfg leer war). Das ist eine etwas andere Vorgehensweise, als die bisher von AVM gewählte, aber sie hat in meinen Augen folgende Vorteile:
1. Der Init-Prozess ist praktisch abgeschlossen, die meisten AVM-Prozesse laufen schon.
2. Die Abarbeitung der debug.cfg erfolgt jetzt asychron zum Init-Prozess, in der debug.cfg auftretende Fehler beeinflussen die weitere Abarbeitung der rc.tail.sh nicht mehr.
3. Durch die Nutzung von multid (über das delay-Kommando) werden solche Spiele wie nohup o.ä. unnötig.

Selbstverständlich ist das aber nur eine denkbare Modifikation des Filesystems. Wer es lieber mag, wenn seine eigenen Skripte eher bei einer Änderung des Online-Status der Box ausgeführt werden, schreibt sie eben nach /etc/onlinechanged. Auch diverse andere Änderungen, für die ansonsten die debug.cfg bisher immer "zu spät" kam im Init-Prozess, lassen sich mit einem Einzeiler realisieren:
Das fügt in ein udev-Skript die Suche nach einem Label für ein Filesystem auf einem angeschlossenen Speicher ein und sorgt - wenn eines gefunden wird - dafür, daß dieses Label als Pfad in /var/media/ftp für das Volume verwendet wird. Wenn man also seinem USB-Volume den Namen "Music" gibt, steht dieses dann unter /var/media/ftp/Music zur Verfügung.

Ich habe aus meinem Vorrat an Skripten nur noch zwei weitere bereits in das Paket integriert.
Das erste modifiziert die Datei /etc/profile so, daß als letzte Aktion das Vorhandensein einer Datei /var/custom/profile getestet wird und - so diese Datei existiert - die dort stehenden Kommandos auch noch abgearbeitet werden. Da das ja bei jedem Shell-Login passiert, kann man dort gut noch weitere eigene Modifikationen einbauen, die nicht unbedingt im root-FS liegen müssen und man spart sich trotzdem das bind-Mount für die nachträgliche Änderung der /etc/profile.
Das zweite zusätzliche Skript erzeugt im neuen root-FS ein zusätzliches Kommando "edit_rcuser", das im Endeffekt nichts anderes als eine Art 'nvi' für die rc.user (AVM nannte sie ja debug.cfg) ist und das Editieren der Datei auch dann erlaubt, wenn es kein "char-Device" dafür in /var/flash gibt (ansonsten einfach mal in die README schauen).

Auch die komplette Integration eigener Binaries und Skripte direkt ins root-Filesystem ist natürlich machbar, wenn man die entsprechenden Skripte dafür vorbereitet. Das geht von der Korrektur kleiner nerviger Probleme (z.B. ist es problemlos möglich, die VPN-Verbindungen wieder in die Übersicht zu bringen oder den FTP-Server wirklich komplett abzuschalten - der kann zwar AUTH TLS auch nach innen, aber wer benutzt das schon wirklich und schickt nicht spätestens beim FTP-Zugriff dann im LAN die Credentials im Klartext durch die Gegend) bis zur Integration eines SSH-Servers anstelle des doch eher unsicheren Telnet-Zugangs. Wenn man dann den Link zum Busybox-telnetd (/usr/sbin/telnetd) mit einem Link zu einem passenden Skript für den Start des Dropbear ersetzt, kann man diesen sogar über die Tastenkombination von AVM für den Telnetd ein- und ausschalten. Der Phantasie sind also fast keine Grenzen gesetzt, das muß halt nur alles in einem Skript im Unterverzeichnis passieren, solange man das "update_7490"-Skript unverändert benutzen will. Die Skripte müssen dann natürlich auch vor dem Start von "update_7490" ins richtige Verzeichnis gelegt werden.
An Platzmangel wird das ja bei einer 7490 nicht so schnell scheitern, da paßt noch so einiges hinein ... auch die Integration der SquashFS-Hilfsprogramme in das root-Filesystem trägt nicht merklich auf, die Skripte kann man auch irgendwo im System lagern.
Wie weitere Änderungen bewerkstelligt werden könnten (es führen in der Shell immer mehrere Wege zum Ziel), steht wieder in der README.

Das ist zweifellos natürlich auch alles mit einem eigenen Freetz-Image möglich, aber gerade die "Bastler", die desöfteren mal neue Software in ihr Image integrieren wollen, werden vielleicht die Vorteile auch zu schätzen wissen, daß man mit den Skripten und dem Boot-Manager in Kombination ziemlich gefahrlos eigene Sachen ausprobieren kann, ohne auf ein Recover oder Downgrade zurückgreifen zu müssen. Man muß lediglich beachten, daß die Änderungen kumulativ sind, da ja immer das root-Filesystem des laufenden Systems als Basis für die Modifikationen dient. Führt man also dieselben Skripte zur Modifikation mehrmals aus, werden diese Änderungen auch mehrfach übernommen. Das von mir bereitgestellte Skript fügt dann eben mehrmals eine vorletzte Zeile in die rc.tail.sh ein. Das wäre wohl kaum im Sinne des Erfinders, das sollte aber jeder selbst bei Kenntnis des potentiellen Problems lösen können.Die neue Version des 'update_7490' kann jetzt auch ein anderes SquashFS-Image für die Basis verwenden als das root-FS des laufenden Systems. Wieder hilft ein Blick in die README-Datei ...
EDIT: Neu ist jetzt auch die Möglichkeit, durch die Angabe von 'fresh' als Parameter für den Aufruf des update_7490-Skripts auch ein "frisches" Firmware-Image vom AVM-Server laden zu lassen und die Änderungen dann auf das root-Filesystem in diesem Image anzuwenden. Das setzt allerdings voraus, daß auf dem AVM-Server auch ein passendes Image liegt (und das gilt auch nur für die deutsche Version der Firmware, solange man das Skript 'get_7490_freshcopy' nicht selbst modifiziert - dann aber die MD5-Prüfung in update_7490 auch ausschalten oder den Inhalt von 'checksums' entsprechend korrigieren).
Ansonsten muß man eben den Download aus einer passenden Quelle von Hand ausführen und kann dann durch den Aufruf von
das root-Filesystem aus diesem Image extrahieren und in das NAND-Flash der Box verschieben (das ist kein Einzeiler für C&P, da muß der eigene Image-Name ersetzt werden). Dann kann man den Aufruf von update_7490 auf ändern und - je nach Platzbedarf im NAND-Flash - das "Basis-Filesystem" dort für weitere Versuche gleich liegen lassen.

:doktor:
Bitte auch immer darauf achten, daß im tmpfs ausreichend freier Speicher zur Verfügung steht. Nach meinen Tests sind ~ 90 MB freier Speicher in /var erforderlich. Wer also dort 3 verschiedene Firmware-Images als Downloads liegen hat und dann trotzdem die Skripts startet, wird wahrscheinlich nur seine Zeit vergeuden, da spätestens beim Packen des neuen Filesystems dann wohl der freie Platz im tmpfs ausgehen wird.

Also weiter im Text. Als nächstes wird jetzt also das root-Filesystem entpackt (das rekursive Kopieren aus / war mir persönlich zu kompliziert angesichts der u.U. dort schon erfolgten Modifikationen durch bind-Mounts o.ä.) und die Skripte zur Modifikation abgearbeitet. Anschließend wird das Ganze wieder zusammengepackt. Dabei werden absichtlich alle Dateien im neuen SquashFS aufgelistet, da der Vorgang zwischen 3 und 5 Minuten dauern kann, dient die Ausgabe gleichzeitig als "Lebenszeichen" des mksquashfs.
Wenn dann das neue SquashFS erstellt wurde, wird es in die inaktive Partition kopiert und für den nächsten Start des FRITZ!OS auf die alternative Partition umgeschaltet.

Jetzt noch schnell das Verzeichnis /var/mod entsorgt, um den dort belegten Platz im RAM für den Neustart des Systems (eigentlich eher für das Beenden der AVM-Prozesse) wieder zur Verfügung zu stellen, und wir können die Box neu starten.
Nach dem Neustart des Systems sollte dann auch unsere debug.cfg (unabhängig vom Namen, denn sie heißt ja jetzt rc.user) wieder abgearbeitet werden. Ich hoffe mal, niemand kommt auf die Idee, die Kopie der Kommandos aus dem TFFS in /var/tmp/rc.user zu modifizieren und dann zu erwarten, daß diese Änderungen einen Neustart der Box überleben.

Zum Editieren der Kommandos in der "rc.user" (oder meinetwegen auch debug.cfg) empfehle ich die Verwendung von 'edit_rcuser', wenn man das hat erzeugen lassen.

Auch beim Editieren der Kommandos unter dem Dateinamen "/var/flash/debug.cfg" (der existiert ja nicht, solange man ihn nicht selbst als char-Device anlegt) ist bei der 7490 besondere Vorsicht anzuraten. Anders als andere Modelle hat die 7490 auf /var/flash kein tmpfs ("geerbt" von /var) sondern ein NAND-Flash (/dev/mtdblock4) gemounted, wenn man dort eine reguläre Datei anlegt, überlebt diese - eben anders als bei den anderen Modellen - auch einen Neustart. Das kann - wenn man sich darauf verläßt, das bei einem Neustart schon alles in /var/flash ordentlich "restauriert" wird - auch mal eine böse Überraschung geben, wenn dann eine vorhandene reguläre Datei das Anlegen eines char-Devices für den TFFS-Inhalt verhindert und plötzlich eine leere Einstellungsdatei daraus entsteht.

Eigentlich bilden also die Skripte und die beiden Hilfsprogramme zum (Ent-)Packen des SquashFS nur eine Art "Framework", was man damit machen will, muß man sich selbst überlegen. Der eine baut mit 6 Kommandos per C&P von hier einfach wieder die debug.cfg in seine Box ein, der andere modifiziert bei der Gelegenheit gleich noch das GUI der Box dauerhaft für seine Zwecke oder schaltet durch Änderung der provider-049.tar das TR-069 für seinen Provider richtig aus (irgendwann wird auch wieder eine einheitliche Umsetzung für die verschiedenen Modelle einziehen).

Noch ein paar Bemerkungen zur Sicherheit:

Erstens benötigt man zur Benutzung des Paketes den Zugang zur Kommandozeile der FRITZ!Box. Wenn ein Unbefugter diesen erlangt, ist ohnehin schon alles zu spät. Insofern wird die Sicherheit per se nach meinem Dafürhalten nicht geschmälert ... wenn man die Änderungen an seiner Box nicht vornimmt, ändert sich gegenüber dem AVM-Original absolut nichts.

Zweitens ist mir sehr wohl bewußt, das ein Angreifer nach demselben Prinzip auch die Box gegen den Willen des Besitzers modifizieren könnte. Aber ich bin auch der Überzeugung, daß ein potentieller Angreifer dazu nicht meine Anleitung benötigen würde und daß dieser sicherlich wesentlich finsterere Absichten und mindestens genauso viel Kenntnis des FRITZ!OS hätte. Die Zeiten, als das noch "Script-Kiddies" ohne eigene Erfahrungen und Ideen waren, sind lange vorbei.

Drittens kann ich damit auch mal zeigen, daß die permanente Modifikation des FRITZ!OS - immer unter der Voraussetzung, ein Angreifer erlangt Shell-Zugriff - nicht nur theoretisch möglich ist. Dieselbe Vorgehensweise läßt sich natürlich auch für ein anderes Modell adaptieren, da läuft dann nur der Flashvorgang etwas anders (im Rahmen eines Neustarts) und im Falle eines Problems brickt der Angreifer die Box (was bei genauer Überlegung ja sogar von Vorteil wäre). Bei einigen Modellen mag es sogar am Speichermangel im RAM scheitern, dann würde ein Angreifer das eben "extern" ausführen.

Es ist also ein sehr reales Szenario, daß bei Shell-Zugriff das System der Box (fast) mit Bordmitteln modifiziert werden kann. Daraus leitet sich dann wieder für mich die Folgerung ab, auf jede nur erdenkliche Weise den Shell-Zugriff für einen Unberechtigten zu unterbinden. Dazu gehört es eben auch, selbst im LAN nur verschlüsselt mit der Box zu kommunizieren. Selbst wenn man vielleicht nicht direkt ein Kennwort für den Zugriff "sniffen" kann, der Mißbrauch einer SID nach gezielter Ausschaltung des berechtigten Benutzers (oder nachdem der "fertig hat" mit der Box ohne sich abzumelden) ist nun wirklich kein Hexenwerk.

Letzte Bemerkung, jetzt zu den Binaries: Ich werde in den nächsten Tagen auch noch einen Patch für den Freetz-Trunk auf dem Server bereitstellen, damit sich jeder ggf. auch selbst sein mksquashfs und unsquashfs für die 7490 erzeugen kann. Im Moment habe ich da noch ein Problem, weil die Toolchain ein benötigtes Include-File (squashfs_fs.h) nicht in der korrekten Version für den Kernel enthält. Da bin ich noch am Überlegen, ob nicht auch ein einfaches Kopieren der Datei an die richtige Stelle ausreichend wäre. Baue ich das mit allen Abhängigkeiten in das make für die Toolchain ein, würde vermutlich nach der Anwendung meines Patches erst einmal die Toolchain neu erstellt. Das wäre dann zwar die "automatische" Lösung, aber auch ein unverhältnismäßig hoher Aufwand für das Erzeugen dieser beiden kleinen Hilfsprogramme.
Ich werde direkt im Anschluß einen Patch für das Erzeugen der beiden Binaries als Freetz-Package auf freetz.org hochladen (erst einmal nur für die 7490), der dann hoffentlich in nicht allzu ferner Zukunft seinen Weg in den Trunk findet. Das unsquashfs-Binary aus der vorhergehenden Version (in debugcfg_7490.tgz) hatte ein Problem mit dem Entpacken eines bereits vom zugehörigen mksquashfs "behandelten" Images, da wurde eine falsche Versionsnummer des SquashFS angegeben.

Es steht nicht explizit in den Skripten drin (die beiden Binaries sind ohnehin nicht von mir), aber das steht natürlich alles unter GPLv2. Es darf also jeder damit machen, was er will. Genauso gilt natürlich auch der Rest des Textes der GPL, besonders der Teil zum Nutzwert der Software.
Ich habe nur keine Lust mehr auf das Hinzufügen des GPLv2-Hinweises zu den ganzen Files, da sich dann auch wieder die Hashes ändern und ich zumindest dort von vorne beginnen müßte. Sowie der Patch (damit wäre dann auch das Veröffentlichen der Quellen nach GPL für mich erledigt) verfügbar ist, ändere ich diesen Beitrag noch einmal. Vielleicht entschließe ich mich dann ja doch noch zur Änderung der Skripte, inkl. der Aktualisierung der o.a. Hashes.
Ich habe das Paket um eine README-Datei und die entsprechenden Lizenzhinweise auf die GPLv2 ergänzt.

Semenchkare schrieb:

denn der "Mod" ist ein FW-Image.

Zum Vergrößern anklicken....

Falsch verstanden. Die Skripte modifizieren eine installierte Firmware-Version 06.20 so, daß beim nächsten Neustart die debug.cfg wieder abgearbeitet wird.
Der Telnet-Zugriff ist bei der 06.20 noch ganz normal möglich. Alle aufgeführten Kommandos werden direkt in einer Shell-Session auf einer Box mit 06.20 ausgeführt.

Habe ich das dann richtig verstanden: die Datei ist /var/flash/rc.user

Zum Vergrößern anklicken....

Sorry, auch falsch.

Die ganzen Konfigurationsdateien in /var/flash sind spezielle "Geräte" für zeichenorientierte Ein-/Ausgabe. Das führt unter anderem dazu, daß man an so ziemlich jedem beliebigen Ort im Dateisystem ein solches Device mit "mknod" erzeugen kann und was man dort dann hineinschreibt (mit char i/o, also z.B. cat oder sed) wird dann im Flash - der sich dahinter verbirgt - gespeichert.

Daher legen meine Skripte auch keine Datei "/var/flash/rc.user" oder "/var/flash/debug.cfg" an, letztere in erster Linie deshalb, damit dort niemand seitens der AVM-Firmware hineinschreiben kann.

Da hinein muss ich den Inhalt "meiner" debug.cfg bringen. Am Besten mittels Deines "edit_rcuser"-scriptes. (evtl. auch mit vi oder mit cat /var/flash....)

Zum Vergrößern anklicken....

Wenn Du schon eine "debug.cfg" auf der Box hast, wird die beim Update auf die 06.20 ja nicht gelöscht. Die dort enthaltenen Kommandos werden nur von der originalen 06.20 nicht mehr abgearbeitet.

Aktivierst Du nun nach dem Update auf die 06.20 dann per Skript die Abarbeitung der debug.cfg in dem zweiten System (zwischendrin mußt Du dann mit "copy_7490_systems" noch die 06.20-Version in beide Partitionen bringen), ändert sich ja am Inhalt der debug.cfg immer noch nichts.

Deine bisherigen Kommandos bleiben also erhalten und werden dann wieder abgearbeitet. Allerdings wird das "Fenster" in den Flashspeicher, das bisher "/var/flash/debug.cfg" hieß, nicht mehr angelegt, da AVM das auch nicht mehr macht. Und um ein versehentliches Überschreiben des Inhalts dieses "Flash-Nodes" zu verhindern, legt meine Version des ModScripts auch kein permanentes char-Device dafür an. Dieses "Fenster" wird nur temporär geöffnet, der dort erreichbare Inhalt (Deine "debug.cfg" aus der 06.05) wird in eine temporäre Datei als /var/tmp/rc.user kopiert und dort dann abgearbeitet, nachdem das "Fenster" wieder zugemauert wurde.

Da das "Fenster" dann ja auch für Dich beim Editieren der Kommandos in der Datei zu ist, legt "edit_rcuser" das Fenster an, läßt Dich die Datei ändern, speichert die Änderungen, wenn Du das bestätigst und mauert dann erneut das Loch zu, wo das Fenster war.

3.) was geschieht, wenn ein weiteres reguläres FW-Update von AVM angeboten wird:
a) geht nur per recover einzuspielen (Siehe Freetz)
b) geht "direkt" über die V. 6.20, der "Mod" geht verloren
c) auf neues Mod von Dir warten??

Zum Vergrößern anklicken....

Ein neues Firmware-Update schreibt dann ja seinerseits sich selbst wieder in die ungenutzte Partition.

Wenn diese neue Version dann immer noch den Telnet-Zugang ermöglicht, kannst Du z.B. ganz einfach mit dem Bootmanager zwischen der 06.20 und der neuen Version umschalten.

Die neue AVM-Version wird dabei aller Voraussicht nach die debug.cfg wieder nicht abarbeiten. Wenn Du Dich dann mit der neuen Version so weit angefreundet hast, daß Du diese anstelle der 06.20 verwenden willst, rufst Du die Skripte von der nächsten Version aus einfach wieder einmalig auf und modifizierst dann eben die "neue" Version von AVM damit.

Nur wenn AVM etwas Grundlegendes am Design der Firmware ändern sollte, würde das "live"-Modifizieren evtl. nicht mehr funktionieren. Ob und was das sein könnte, wäre Kaffeesatz-Leserei.

Es ist kein "Mod", es ist nur ein "Rahmen" für die Abarbeitung von Shell-Skripten, die das root-Filesystem einer 7490 modifizieren und diese Modifikation bleibt dann eben auch beim nächsten Neustart des Systems erhalten.

Man verliert letzten Endes (wegen des "Zwangs" für zwei identische System in beiden Partitionen beim Modifizieren) nur die Möglichkeit, einfach mit dem Bootmanager auf die vorherige Version "zurück" zu können. Da das bisher auch nicht ging, kann/muß man das verschmerzen.

Semenchkare schrieb:

-> sollte etwa die Ausführung der "debug" daran schuld sein??
Kann ich die "debug" mal kurz "ausschalten", ohne jede einzelne Zeile auszukommentieren??

Zum Vergrößern anklicken....

Die Ferndiagnose ist schwierig, die Änderungen beim Aktivieren der debug.cfg sollten aber nicht selbst die Ursache sein können - zumindest solange Du nicht auch noch ein File /var/custom/profile für das Login per Dropbear hast.

Da ich ja mit den Skripten außer dem Abarbeiten der Kommandos nichts weiter ändere, solltest Du vielleicht generell mal über ein "Signal" für die Abarbeitung der debug.cfg nachdenken. Ich nehme dafür meist eine Variable im Urlader, die "freies Format" hat.

Wenn Deine Kommandos als erste Zeile folgendes enthalten:
kannst Du mit einem einfachen
die Abarbeitung der Kommandos beim nächsten Start unterdrücken und mit demselben Kommando unter Auslassung des "norcuser" (oder den Ersatz durch etwas anderes) auch wieder zulassen. Das bräuchte zwar zum "Wiedereinschalten" auch einen Shell-Zugang, notfalls macht es aber auch der FTP-Server der EVA.
Die crash-Variable wird zwar u.U. bei einer Fehlerbedingung innerhalb des Kernels (bzw. eines Kernelmoduls) von der Box selbst überschrieben, aber man muß nur die "richtige Frage" stellen, in Abhängigkeit von dem Zustand, den man als "Normalfall" ansehen will.

Wenn Du ohnehin USB-Speicher an der Box hast (oder den bei Deiner 7490 ja vorhandenen NAND-Flash unter /var/media/ftp nutzt), kannst Du das natürlich auch mit einem File als Semaphore machen. Das braucht dann zwar eine moderne Box oder USB-Speicher, ist aber unkomplizierter als die andere Variante - die auch auf älteren Modellen funktioniert - und ermöglicht das Ein-/Ausschalten auch über einfachen FTP-/Samba-Zugriff und die Box greift da nicht selber zu (jedenfalls beim USB-Speicher, das yaffs2 in NAND formatiert sie schon mal ohne das Zutun des Besitzers).

@eisbaerin:
Machst Du einfach
Das erzeugt das char-Device, zeigt den Inhalt an (kann man auch umleiten in eine Datei auf einem USB-Stick o.ä.) und schmeißt das char-Device wieder weg.

EDIT:
@seme:
Das mit dem Speicher kann ich nicht so richtig glauben. Die 7490 hat 256 MB RAM (minus ein paar MB Kernel).
Bei mir läuft ein Dropbear (multi mit allem) und eine Busybox, die so ziemlich jedes denkbare Applet enthält. Dabei sagt dann die Box
Da ist also jede Menge Platz im RAM.

Selbst wenn da bis zu 5 Sekunden Video komplett im RAM der Box zwischengespeichert werden sollten (das ist ja sicherlich kein non-interlaced-HD, was Deine Kameras da liefern), dürfte das nicht einmal annähernd ein Problem werden.
Da würde ich also nicht nur die Symptome prüfen und auf den Dropbear oder die Busybox schließen, da wird schon noch etwas anderes im Argen sein. Ich habe ja keine Ahnung, wo Du die eigene Busybox her hast ... vielleicht läßt Du die einfach mal weg, falls da etwas von AVM benutzt wird beim Livebild-Streamen. Den Dropbear würde ich auch eher für unschuldig halten.

BTW: Wenn es am Ende dann geklärt ist und Du beide zusätzlichen Komponenten dauerhaft verwenden willst, kannst Du die ja auch direkt in das root-FS integrieren. Wie machst Du es denn jetzt eigentlich ? bind-Mount über /bin/busybox ? Da würde ich dann wirklich eine potentielle Störquelle sehen, hängt ein wenig davon ab, wo Du Deine eigene Busybox abgelegt hast bzw. wie das Mount dann aussieht.

Semenchkare schrieb:

Habe beide übrigens so eingebunden:

Zum Vergrößern anklicken....

Ich weiß nicht, wieviel Speicher die Dateien bei Dir unter /var/media/ftp/avmfiles insgesamt belegen und ob das dort das NAND-Flash oder ein USB-Speicher mit eigener Zusammenstellung des Pfadnamens ist.

Wenn Du aber nicht noch zusätzliche Vorkehrungen beim Stoppen der Box (oder beim Restart) triffst und die Daemons ordentlich beendest, kann das dort liegende Filesystem nicht sauber dismounted werden. Tritt dann deshalb ein Problem beim Mounten des yaffs2 für das NAND-Flash beim nächsten Start auf, legt die Box ihrerseits das Dateisystem neu an. Auch bei einem USB-Filesystem ist es immer besser, es sauber dismounten zu lassen (mindestens bei den Typen, die ansonsten ein "dirty"-Flag führen).

Da die 7490 ja im tmpfs genug Platz haben dürfte fur einige zusätzliche Binaries in einem Unterverzeichnis von /var (ich nehme bei mir eben /var/custom), würde ich in so einem Falle (also Daemons, die erst "auf der letzten Rille" gekillt werden) das ganze Zeug vor dem Start nach /var kopieren. Dann braucht es u.U. die Links nicht mehr, außer die liegen dann an einer anderen Stelle.
Aber selbst wenn die von dort gestarteten Dienste dann bei post_install noch laufen oder sich (kommt ja auch mal vor) nicht beenden lassen, kann in jedem Falle alles unter /var/media/ftp sauber dismounted werden.

Ich weiß nicht, wie groß die Binaries bei Dir sind, bei mir kommen (für die Daemons, das Kleinvieh macht natürlich auch Mist, stört aber i.d.R. beim Dismount nicht) da keine 5 MB zusammen. Ob die da noch im Speicher liegen oder nicht, macht den Kohl auch nicht mehr fett.

user34 schrieb:

Bei mir will das ganze nicht laufen. Die befehle laufen entsprechend deiner Beschreibung ohne fehler durch.

Zum Vergrößern anklicken....

Ok, aber sicherlich doch nicht ohne Ausgabe, oder ?
Das sollte dann eigentlich etwas drinstehen, ansonsten solltest Du mit den Befehlen aus #9 mal in Deine debug.cfg gucken. Da man ja nichts anderes "sieht" als das beim nächsten Start die dort stehenden Befehle wieder abgearbeitet werden, kannst Du ja auch ein
in die erste Zeile als "Kontrolle" einbauen und dann ins Eventlog schauen nach dem Neustart.
EDIT:
Wobei das mit dem "nichts sehen" ja auch nur bedingt stimmt. Je nachdem, welche Modifikationen Du ausführen läßt, solltest Du diese Änderungen ja dann im root-FS sehen können. Bei der "mod_rc_tail_sh" sollte ein "cat /etc/init.d/rc.tail.sh" die vorletzte Zeile richtig anzeigen.

@user34:
Fehler gefunden in mod_rc_tail_sh, den ich eigentlich schon für beseitigt hielt, ist nun aber wirklich korrigiert auf dem Server. Jetzt stimmt aber der Hash-Wert im ersten Beitrag nicht mehr, er lautet nun:

Bitte den Rest trotzdem wenigstens überfliegen und zu Herzen nehmen beim nächsten Versuch, so Du denn noch einen starten willst.

user34 schrieb:

reboot

Zum Vergrößern anklicken....

Ok, wenn dann das System auch noch neu gestartet wird, sollten beim nächsten Start auch die Kommandos in der rc.user abgearbeitet werden.Ich hoffe mal, Du hast den Ablauf mit dem Modifizieren nicht zu oft wiederholt oder in der README nach dem Verwenden einer "frischen" Vorlage für das Dateisystem gesehen.
EDIT: Im ersten Beitrag ist jetzt die Verwendung eines originalen AVM-Images als Quelle für das root-FS hinzugekommen.

In jedem Falle sollte Dein neues System jetzt in der Datei /etc/init.d/rc.tail.sh folgendes enthalten:
Die oben besonders markierte Zeile sollte genau ein einziges Mal in dieser Datei stehen - zur kumulativen Natur der Änderungen habe ich im Text etwas geschrieben. Wie man ein anderes SquashFS-Image als Template verwendet, steht in der README-Datei. Die mehrfache Ausführung derselben Modifikationen ist natürlich nicht sinnvoll, wenn die vorhergehenden doch erfolgreich gewesen sein sollten.

Steht/stehen in Deiner Box die o.a. Zeilen in der Datei, fehlt Dir offensichtlich ein Inhalt im entsprechenden TFFS-File. Diesen kannst Du Dir mit "edit_rcuser" anzeigen lassen (auch das natürlich nur, wenn die Änderungen ausgeführt wurden) oder - da edit_rcuser ja den vi automatisch ausführt - auch mit den Kommandos aus #9 anzeigen lassen und kopieren.

Wenn Du wegen mehrfacher Anwendung in Deiner rc.tail.sh auch mehrfache Aufrufe einer Shell für Deine eigenen Kommandos stehen haben solltest, hängt die konkrete Reaktion etwas von den Umständen beim Start des Systems ab.

Normalerweise (das habe ich in den letzten Versionen aber nicht mehr getestet) startete der multid nicht mehrere "Jobs" mit derselben ID (das ist das 'USER' nach dem '-d 1' (der Verzögerung) in der Zeile in der rc.tail.sh), eine neue "Definition" überschrieb den vorherigen Auftrag und startete auch die Verzögerung von vorne.
Ein neuer Auftrag mit demselben Namen (bzw. derselben ID), während der "alte" schon/noch ausgeführt wurde, wurde früher auch einfach ignoriert.
Selbst wenn da also bei Dir dann mehrere Aufrufe der Kommandos in der rc.tail.sh stehen sollten, dürfte theoretisch immer noch nichts schief gehen (deshalb habe ich auch auf den Test vor der Modifikation verzichtet, der macht das dann bloß anfälliger bei Änderungen der Originaldatei durch AVM).

Die entscheidende Frage ist also nun, wie sieht Deine rc.tail.sh aus (nur die letzten Zeilen nach 'modulemem' - [OT]irgendwann wird da hoffentlich auch mal das 'n' in ein 'm' geändert[/OT])und was da in Deiner "debug.cfg" (ich nenne sie weiterhin aus Prinzip rc.user, wie es schon im originalen TI-Source der Fall war) steht.

Ok, beim Korrekturlesen habe ich jetzt doch noch den (oder auch nur einen) Fehler gefunden.

Das bisher auf dem Server im Paket enthaltene Skript "mod_rc_tail_sh" enthielt schon wieder die falsche Modifikation der rc.tail.sh, das hatte ich eigentlich im Rahmen der letzten Änderungen schon korrigieren wollen, offenbar dann aber doch wieder die falsche Variante eingepackt ohne es zu bemerken. Der Test "! [ checkempty $rcuser.tffs ]" ist natürlich falsch, die eckigen Klammern sind hier Blödsinn und nur die Überreste nach dem Ersetzen eines nur in meiner eigenen Box möglichen Tests durch die Variante von AVM. Bei mir gibt es ein zusätzlichen Skript nur für das 'cat' eines beliebigen TFFS-Nodes anhand seiner Nummer (inkl. Anlegen und Löschen des char-Devices und 'gunzip', wenn der Inhalt komprimiert ist), da nehme ich bei mir eben gleich dieses Skript für den Test und das Kopieren in einen Schritt. Da ich das nicht auch noch jedem anderen "auf's Auge drücken" wollte, habe ich dann für die allgemeinere Variante auf AVM-Programme zurückgegriffen und dabei diesen Mist gebaut.

Ich habe das Paket schon korrigiert und Du müßtest dann noch einmal mit einem frischen root-FS starten. Die Unterstützung für die automatische Verwendung ist aber im Paket noch nicht enthalten, kommt jedoch im Laufe des Tages ohnehin dazu. Die Erweiterung um ein Frage-/Antwort-Spiel beim Modifizieren (dafür wären die Vorbereitungen mit den "DESC"- und "QUESTION"-Zeilen ja schon gedacht) kommt dann erst im nächsten Schritt.
Ich habe im ersten Beitrag noch eine C&P-Zeile für die Verwendung einer frischen SquashFS-Kopie vom AVM-Server ergänzt.

Ich werde den ersten Beitrag noch um eine kurze Anleitung zur Verwendung eines originalen AVM-SquashFS-Image als Vorlage ergänzen. Dazu gibt es ein weiteres optionales Skript, das anstelle des aktuell laufenden Systems ein frisches Image vom AVM-Server lädt und dann dieses verwendet, wenn man update_7490 mit einem passenden Parameter startet. Das ist aber noch nicht bis ins letzte getestet (das Ermitteln des "richtigen" Original-Images ist ganz trivial, wenn es automatisch auf der Box laufen soll und man in einem schon modifizierten System das Skript aufruft) und braucht noch ein paar Stunden.

Bis zur Fertigstellung korrigiere ich den ersten Beitrag erst einmal nicht ... das steht auch noch der falsche Inhalt der mod_rc_tail_sh drin und spätestens da hätte es mir auffallen sollen.

Ich habe die Skripte ergänzt, den ersten Beitrag korrigiert und um die Beschreibung der Verwendung eines originalen AVM-Images erweitert.

Ich hoffe, jetzt funktioniert es reibungslos. Lediglich Speicherplatzprobleme im tmpfs traten bei mir hin und wieder auf, wenn ich zuviele Kopien der verschiedenen Stadien der "Entwicklung" eines neuen root-FS dort liegen hatte.

Wer die Skripte mehrmals aufruft (das geht ja, solange kein Neustart ausgeführt wurde, problemlos und nimmt immer wieder dieselben Änderungen vor, da das "Ausgangsmaterial" immer wieder das angegebene (oder das laufende) root-FS ist), der muß das Zwischenstadium /var/newroot.squashfs jedesmal von Hand löschen. Da ich von einem Neustart nach der Ausführung ausgehe, bleibt dieses File im tmpfs erhalten und würde erst im allerletzten Schritt wieder durch die neue Variante überschrieben - das ist dann also wirklich verschwendeter Speicher, der an anderer Stelle fehlt. Nur für das automatische Löschen dieses Überbleibsels - das im Normalfall auch niemanden stört - die ganze Prozedur mit der Änderung des Pakets auf dem Server (inkl. der Änderung des ersten Beitrags) noch einmal auszuführen, lohnt sich nicht; das mache ich dann bei der nächsten Änderung noch mit.

Solange man noch keinen Neustart der Box ausgeführt hat, kann man die Umschaltung auf das andere (also das modifizierte) System ja jederzeit mit dem Bootmanager wieder rückgängig machen. Dann ändert sich aus der Sicht der AVM-Firmware rein gar nichts am Aufbau des Systems, beim nächsten AVM-Firmware-Update wird dann ja wieder der Kernel und das Wrapper-FS komplett neu geschrieben. Man kann dann auch guten Gewissens auf den Neustart verzichten ... solange man die Auswahl des als nächstes zu startenden Systems wieder auf das aktuell laufende System ändert und die "Reste" im tmpfs wegräumt, ändert sich rein gar nichts an der Box.
Man muß für das "Zurückschalten" des beim nächsten Start zu ladenden Systems auch nicht den Boot-Manager bemühen, ein simpler Aufruf von "./switch_7490_system" schaltet auch bei jeder Ausführung auf das jeweils andere System um. Allerdings ist es dabei dann wahrscheinlich etwas leichter, den Überblick zu verlieren, welches System denn nun gerade läuft und welches als nächstes gestartet wird. Das zeigt der Bootmanager dann eben deutlich an.

Ansonsten bin ich für jede konkrete Fehlermeldung dankbar.

Dabei bitte dann die letzten Zeilen der /etc/init.d/rc.tail.sh mit anfügen und gerne auch die Abarbeitung des rc.user-Skripts an sich mit dem weiter vorne beschriebenen zusätzlichen Eintrag eines 'eventadd'-Kommandos dokumentieren lassen.

user34 schrieb:

drin stehen tun die Zeilen jetzt. Aber die debug.cfg oder auch rc.user werden nicht ausgeführt.

Zum Vergrößern anklicken....

Das ist ja dann (wenn da nicht die eckigen Klammern um das checkempty-Kommando bei Dir stehen) sehr mysteriös und kann eigentlich nur heißen, daß eben nichts in dem entsprechenden TFFS-Node steht. Dann soll da ja auch kein Job gestartet werden. Stehen da bei Dir doch die eckigen Klammern in der vorletzten Zeile drin, war das meine Schuld mit der verdaddelten Korrektur und es konnte nicht funktionieren (obwohl dann trotzdem edit_rcuser im Zielsystem hätte funktionieren müssen zur Anzeige der auszuführenden Kommandos, das ist ja unabhängig davon, ob die Kommandos dann auch ausgeführt werden oder nicht).

starten von edit_rcuser wird mir gesagt

Zum Vergrößern anklicken....

Das ist vielleicht zum Teil meine Schuld, weil da die Benennung nicht 100% eindeutig ist - es gibt im Paket eine Datei "modscripts/edit_rcuser", die das File "/usr/sbin/edit_rcuser" im Zielsystem erzeugen soll.
Das, was Du da offenbar versuchst auszuführen, ist eigentlich das Skript, welches das neue Kommando 'edit_rcuser' im Zielsystem erzeugen soll. Dieses Skript schreibt also den notwendigen Inhalt der Datei /usr/sbin/edit_rcuser in das entpackte root-Filesystem und wenn Du es ohne das Basisverzeichnis des entpackten Filesystems als ersten Parameter aufzurufen versuchst, kommt dann eben der mißlungene Zugriff auf das laufende System (da ist diese Stelle nicht beschreibbar) dabei heraus.

hab momentan keine Ahnung was ich noch tun kann. habe vorhin sogar das recovery Programm laufen lassen das ich ein frische OS bekomme.

Zum Vergrößern anklicken....

Schön, das frische OS ist in jedem Fall ein neuer Anfang.

Selbst wenn Du es vielleicht nicht mehr glauben willst, wäre das dann wieder der richtige Zeitpunkt für den Aufruf des Einzeilers aus dem ersten Beitrag und einen anschließenden Neustart, wenn die Modifikationen abgeschlossen sind.

Dann führst Du im neuen System erst einmal folgende Kommandos der Reihe nach aus (Deine Eingaben in rot) und postest die entsprechenden Ausgaben hier (bitte nicht immer in voller Länge, die unwesentlichen Zeilen mittendrin - z.B. in der rc.tail.sh - kannst Du weglassen):

Wenn dann auch noch der Inhalt der edit_rcuser-Datei wie oben angegeben ist, kannst Du 'edit_rcuser' aufrufen und kriegst den Inhalt Deiner Kommandodatei im 'vi' angezeigt. Das klappt auch dann, wenn diese Kommandodatei leer ist, dann steht da eben nichts drin und Du kannst selbst etwas eintragen.

Wenn Du nicht weißt, wie Du das machen solltest - bzw. auch für andere/spätere Leser - ein Einzeiler zum Einfügen einer Meldung in das Eventlog bei Start der Abarbeitung der Kommandos (der ist aber für den Shell-Prompt gedacht und nicht für das Einfügen einer Zeile im vi):
Das fügt (unabhängig vom bisherigen Inhalt) als erste Zeile ein Kommando "eventadd 1 rc.user(debug.cfg)" in die Liste ein; ein sogenanntes "She-Bang" in der ersten Zeile wird bei der Art des Aufrufs nicht benötigt, weder bei AVM-Style noch bei meinem.
Anschließend wird zur Kontrolle noch der neue Inhalt der Datei angezeigt. Wenn schon eine Datei oder ein char-Device '/var/98' existieren sollte, wird vorsichtshalber nichts unternommen (da das char-Device am Schluß wieder gelöscht wird).

Im Eventlog wird dann in der Kategorie "System" eine Zeile mit "rc.user(debug.cfg)" angezeigt, wenn die Abarbeitung gestartet wurde.