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

@bmaehr:
Dann schreib' das doch einfach gleich hin, was Du bereits gelesen und selbst ausgeschlossen hast, dann denkt man auch nicht in die falsche Richtung.

Trotzdem bleibt bei mir die Frage stehen: Hast Du denn nun Swap-Space aktiviert oder nicht? Die zwingende(!) Notwendigkeit von Swap-Space steht in #1 in dem Teil, der am 06.11.2015 hinzugefügt wurde, der ist entsprechend gekennzeichnet.

Nicht jede Box hat dieselben Dienste am Start (ich gehe mangels Masse im Beitrag auf der vorhergehenden Seite von einer 7490 aus), schon die Frage, ob und wieviel der AHA-Daemon zu tun hat oder wie voll die Anrufliste ist oder ob die Kindersicherung verwendet wird (oder das Gastnetz) und mit wievielen Profilen und wievielen Geräten im LAN oder per DECT, ob mit oder ohne WLAN, usw., kann den entscheidenden Kick liefern, der das System ohne passende Vorbereitungen über die Klippe schubst.

Ich bin - tut mir leid, aber ich schreibe es lieber so deutlich, damit es keinen Raum für Mißverständnisse gibt - erst dann bereit, über weitere mögliche Probleme nachzudenken, wenn es definitiv kein Speichermangel sein kann und am Ende ist dazu neben der "Versicherung", daß es den passenden (und passend formatierten) USB-Stick gibt und der angesteckt wurde, auch noch die Ausgabe von "cat /proc/swaps" erforderlich, weil erst dann auch sichergestellt ist, daß dieser Stick korrekt vom System erkannt und eingebunden wurde. An allen Stellen davor kann es noch zu Fehlersituationen kommen und daher ist das tatsächlich die einzig sichere Stelle, an der man den Swap-Space diagnostizieren kann.

Eine andere Idee habe ich erst einmal nicht und solange da kein Swap-Space existiert, denke ich auch nicht darüber nach ... ich hoffe, Du verstehst diesen Standpunkt, es ist nicht persönlich gemeint.

Ich kann jedenfalls (ohne passende Erklärung, die ich aber gerne zur Kenntnis nehme) erst einmal keinen Zusammenhang zwischen einem automatischen und einem manuellen Download erkennen, der sich - abseits der "Speicherproblematik" - auf das Packen des neuen Dateisystems auswirken würde. Aufgrund des Aufbaus der Image-Datei von AVM braucht zwar der Download direkt innerhalb von "modfs" ein paar mehr Dateien in den Zwischenschritten (die eigentliche Image-Datei wird dann auch wieder gelöscht, um Platz zu sparen - gerade bei der Verwendung des yaffs2-FS kann es schnell eng werden), aber ab einem bestimmten Stadium der Ausführung sollte das auf dasselbe hinauslaufen. Aber die Speicherbenutzung und -auslastung ist nun mal dynamisch und da kann schon die Zuordnung von Dateipuffern das Zünglein an der Waage sein.

@all:
Ich baue einfach mal die Ausgabe von /proc/swaps und /proc/mounts noch mit in die Debug-Ausgabe in den Ringbuffer ein, dann braucht man (wenn denn das nunmehr immer erzeugte Debug-Protokoll so einem Fehlerbericht "beigeordnet" wird, was auch in #1 in der Änderung vom 24.03.2016 steht) nicht mehr nachfragen zu diesen Punkten. Auch die generelle Verfügbarkeit dieser Protokollierung steht in #1 (in der Änderung vom 26.07.2015) und dort ist auch der Beitrag zur "Handhabung" des Debug-Protokolls (steht in #190) verlinkt. Wenn ein Problem auftreten sollte, ist auch das Debug-Protokoll das richtige (und eigentlich auch das einzige, die Console-Ausgaben interessieren bei der Fehlersuche nicht mal richtig am Rande, weil sie sich im Debug-Protokoll auch entdecken lassen), was man hier (unaufgefordert) an seine Fehlermeldung anhängen sollte.

Mehr kann (und will) ich nicht machen - ich habe absolut keine Lust, das irgendwie anders und neu zusammenzufassen, was es an verstreuten Beschreibungen in diesem Thread gibt. Denen, die ihre Zeit nicht mit dem Lesen verbringen wollen, kann ich nur schreiben: Ich habe mit einiger Sicherheit mind. eine Zehnerpotenz mehr an Zeit investiert, als ich die ganzen Informationen zusammengetragen, in Shell-Skripte gegossen und dann hier beschrieben habe. Ist das jemandem zuviel, bliebe ihm immer noch Freetz oder eine andere (eigene) Lösung - nicht "modfs" geht auf die Suche nach einem Anwender, der Anwender findet i.d.R. "modfs", macht sich schlau, was das kann und entscheidet dann, ob es seine Anforderungen erfüllen könnte oder nicht. Wie er das überhaupt kann, ohne zuvor etwas dazu zu lesen, verstehe ich schon mal nicht.

Wenn mir dann jemand schreibt, er würde irgendwelche Informationen in #1 nicht finden und ich weiß genau, daß ich sie aufgeschrieben und dort auch verlinkt habe (oder zumindest die Nummer des Beitrags im Thread erwähnt habe), dann bringt es auch nichts mehr, mich "zu loben" für "modfs" ... dann bin ich erst einmal sauer, wenn mir jemand die objektive Unwahrheit schreibt und sehe das als "Schutzbehauptung" - das mag zwar subjektiv sogar der Wahrheit entsprechen, aber ein "ich kann es nicht finden" ist etwas vollkommen anderes als ein "es steht da nicht". Wer mir wirklich einen Gefallen tun will und sich "bedanken" möchte, der überlegt sich einfach, ob meine Bitte in #1 (erster Absatz nach dem roten Text) bzgl. irgendwelcher zusätzlichen Fragen wirklich so unangemessen ist, wenn ich dort auf das wiederholte Stellen derselben Fragen eingehe und darum bitte, dieses zu unterlassen.

Ich habe meinerseits keinerlei Bauchschmerzen damit, wenn jemand ein echtes Problem beim Einsatz von "modfs" entdeckt und werde jede nur denkbare Anstrengung unternehmen (nun gut, vielleicht nicht jede, aber viele), um das Problem zu lokalisieren und - sofern möglich - zu beheben ... aber es ist einfach auch LANGWEILIG, wenn immer nur dieselben Probleme berichtet werden, die man auch bei "richtiger Handhabung" (und das Thema Swap-Space steht auch in der Anleitung von @eisbaerin und zwar hier und hier) eigentlich gar nicht haben sollte. Dort steht u.a. auch schon (in #6), daß es eben einen Unterschied beim Speicherbedarf macht, wieviel die verwendete FRITZ!Box ansonsten noch zu tun hat.

Ich freue mich über jeden Nutzer (ob neu oder nicht), der mittels "modfs" sein Ziel erreichen konnte - noch mehr freue ich mich über jemanden, der sich an die Anleitung hält (und bei Problemen dann erst einmal prüft, ob er das getan hat - wenn er nicht vorher alles gelesen hat, dann sollte er es eben beim Auftreten von Problemen nachholen) und damit ohne weitere Probleme zum Erfolg gelangt. Ein "zu lang, zu umfangreich, zu unübersichtlich" finde ich - abseits aller anderen nettgemeinten Worte - reichlich unpassend. Wenn die Beschreibung jemandem zu lang ist, dann muß/kann/darf er auf den Einsatz von "modfs" verzichten oder seinerseits eine bessere Beschreibung abliefern.

Nichts gegen berechtigte Kritik und Nachfragen bei echten Problemen ... aber "ich habe keine Lust und keine Zeit, mir das alles durchlesen, also frage ich einfach und irgendjemand wird mir schon antworten", ist deutlich die falsche (weil selbstsüchtige) Lösung - es macht es dem "Nachfolger" noch einmal schwerer und dabei hatte man ja dann selbst schon Probleme, das alles zu lesen; daran sollte man aber auch einmal einen Gedanken verschwenden. Ansonsten macht einfach einen weiteren Thread auf, in dem dann "Anfängerfragen" gestellt werden sollen (das geht beim Linux dann los und endet bei bereits besprochenen Lösungen für "modfs") und dann fühle ich mich auch nicht mehr "verpflichtet", meinerseits auf solche Fragen zu antworten, weil dann sofort klar ist, daß ich nicht der Adressat der Frage bin - dann braucht es auch meinerseits keine "schlechte Laune" (aka "rant"), dann halte ich mich einfach raus.

Aber ich bin da auch recht empfindlich ... ich fühle mich nämlich bei Nachfragen in diesem Thread oder auch im Zusammenhang mit anderen Dateien aus meinem GitHub-Repository dann tatsächlich angesprochen und denke, ich müsse nun dem Fragesteller helfen. Das werde ich einfach noch weiter einschränken und dann sinkt sicherlich auch die (meinerseits unterstellte) Erwartungshaltung beim Fragesteller bzgl. einer Antwort. Ein anderer, weiterer Thread würde da aber eine deutlich bessere "Abgrenzung" ermöglichen - meinetwegen irgendetwas mit "Probleme und Fragen bei der Verwendung von "modfs" und ich verspreche auch tatsächlich, den gar nicht erst selbst zu lesen (und mir damit auch keine Meinung zu Fragen und Fragestellern zu bilden, das kann sicherlich niemand für sich selbst verhindern, daß er "einen Eindruck" gewinnt und der will dann erst einmal wieder korrigiert werden).

So ... wieder ein recht langer Beitrag - erneut mit einer Bitte um vorheriges Nachdenken und in dem Bestreben, meinen Standpunkt zu verdeutlichen und zu begründen. Nun mag auch dieser Beitrag wieder zu lang zum Lesen sein - dann nehme ich mir vor, beim nächsten Mal wesentlich kürzer und prägnanter zu reagieren, egal ob das dann wieder als "Unfreundlichkeit" oder gar "Unhöflichkeit" interpretiert wird. Entweder lang, mit Begründung und mit dem Versuch, Verständnis beim Gegenüber zu bewirken oder kurz und grob - das sind die Alternativen, die ich anbieten kann; ein Lavieren dazwischen liegt mir nicht, dann lasse ich das Schreiben einfach bleiben.

- - - Aktualisiert - - -

Gesagt, getan ... neues Datum, einzige Änderung: /proc/mounts, /proc/swaps und 'df -h' werden ins Debug-Protokoll geschrieben.

Bitte bei Fehlermeldungen dieses Debug-Protokoll (auszugeben mit "showshringbuf modfs", Ausgabe umleiten in eine Datei nach Belieben) anhängen (nochmal: anhängen und nicht zwischen "CODE"-Tags direkt einstellen).

Ggf. kann die Ausgabe von /proc/mounts und/oder 'df -h' Daten enthalten, die man vor der Veröffentlichung noch einmal auf "Vertraulichkeit" überprüfen sollte.

Wenn da also irgendwelche Speicherpfade (u.a. vielleicht zum Onlinespeicher) stehen, dann kann man die verfremden - wer ganze Zeilen löscht oder die Angaben zum verwendeten Dateisystem oder dem freien Platz usw., der sollte wissen, was er da tut und warum, denn die Informationen werden ggf. zur Beurteilung von Problemen mit dem Speicherplatz (das geht bis zum Arbeitsverzeichnis, dessen Auswahl vom "modfs" eigentlich in die Hände des Benutzers gelegt werden sollte) benötigt.

Weitere "individuelle" und schützenswerte Informationen im Debug-Protokoll fielen mir jetzt ad hoc nicht ein, wenn jemand da irgendetwas entdecken sollte, was mir (dann schon länger) entgangen ist, muß man darüber reden (oder besser schreiben).
 
Servus miteinander,

bei den aktuellen Fritz!OS werden die Datenträger ja nicht mehr mit Executable Permissions gemountet. Kann mir jemand einen Hinweis geben, welche Datei ich im entpackten Image bearbeiten muss (also wo ist die mount Routine) um das executable Flag da persistent hinzuzufügen?
 
Das sollte reichen ... allerdings für alle Dateisysteme, keine Ahnung, ob das tatsächlich erforderlich ist.

Vielleicht sollte man lieber ein paar Zeilen für ausgewählte "volume label" ergänzen, bei denen dann das "noexec" auf Basis des Volume-Namens weggelassen wird, denn eigentlich ist das ein sinnvoller Schritt und vielleicht wird der ja bei AVM irgendwann auch mal auf die per "davfs2" eingebundenen Dateisysteme ausgedehnt - bisher wird da m.W. immer noch das x-Flag vom Server übernommen und das eröffnet ggf. jemandem mit Zugriff auf den Server in Kombination mit einer (neuen oder bereits bekannten) RCE-Lücke wieder den direkten Aufruf auch binärer Dateien (bei Skripten ist das wg. der verbleibenden Möglichkeit des direkten Aufrufs eines Interpreters mit der Datei als Eingabe ohnehin nur ein unzureichender Schutz, wenn das x-Flag nicht gesetzt ist).

Code:
--- /etc/hotplug/udev-mount-sd
+++ /etc/hotplug/udev-mount-sd
@@ -167,20 +167,20 @@
 ;;
 squashfs)
 echo "MOUNT: mount -t 'squashfs' $DEVNODE $MNTPATH" >/dev/console
-if mount -t squashfs -o ro,noexec $DEVNODE "$MNTPATH"; then
+if mount -t squashfs -o ro $DEVNODE "$MNTPATH"; then
 new_filesystem=true
 fi
 ;;
 vfat)
 echo "MOUNT: mount -t 'vfat' $DEVNODE $MNTPATH" >/dev/console
-if mount -t vfat -o $READMODE,noatime,shortname=winnt,uid=$FTPUID,gid=$FTPGID,utf8,$FMASK,$DMASK,noexec $DEVNODE "$MNTPATH"; then
+if mount -t vfat -o $READMODE,noatime,shortname=winnt,uid=$FTPUID,gid=$FTPGID,utf8,$FMASK,$DMASK $DEVNODE "$MNTPATH"; then
 new_filesystem=true
 fi
 ;;
 ntfs)
 echo "MOUNT: mount -t 'ntfs' $DEVNODE $MNTPATH" >/dev/console
 if test -x /bin/ntfs-3g ; then
-ntfs-3g $DEVNODE "$MNTPATH" -o $READMODE,locale=de_DE.UTF-8,$FMASK,$DMASK,big_writes,noexec
+ntfs-3g $DEVNODE "$MNTPATH" -o $READMODE,locale=de_DE.UTF-8,$FMASK,$DMASK,big_writes
 local NTFS_RET=$?
 case "$NTFS_RET" in
 0 )
@@ -211,7 +211,7 @@
 ;;
 ext2|ext3|ext4)
 echo "MOUNT:mount -t 'extX' $DEVNODE $MNTPATH" >/dev/console
-if mount -t $filesystem_type -o noexec $DEVNODE "$MNTPATH"; then
+if mount -t $filesystem_type $DEVNODE "$MNTPATH"; then
 new_filesystem=true
 chmod 777 "$MNTPATH"
 fi
 
Danke dir PeterPawn,
mir reicht es auf jeden schon mal für die ext - filesystems :D
 
Hallo,
ich habe noch eine alte 3370 mit FW6.51. Gibt es noch eine Möglichkeit Telnet zu aktivieren? Modfs-starter funktioniert ja nur mit 6.50 und ein recovery Image auf eine ältere fw ist bei avm nicht mehr verfügbar.

gruss
xc
 
Es gibt immer eine Möglichkeit, einen Shell-Zugang zu einer FRITZ!Box zu erlangen (zumindest bisher).

Ein denkbarer Weg (für den man dann halt ein paar Kommandos anstatt in die /var/install eines "Pseudo-Images" in eine eigene Datei unter /var/media/ftp schreiben muß) wäre der Aufruf einer Skriptdatei über diese Lücke: https://github.com/PeterPawn/YourFritz/tree/master/reported_threats/796851

Die sollte (theoretisch) in der 06.51 der 3370 funktionieren, mangels Gerät kann ich das aber nicht definitiv sagen. Probieren hilft ... und was beim "Installieren" von ShellInABox in der Wrapper-Partition zu beachten ist bzw. wie das funktioniert, steht irgendwo in einem der beiden Threads, die sich mit "modfs-Starter" befassen (da, wo ich das Prinzip beim Start über ein "in-memory"-Image erklärt habe).

Man muß event. etwas "aufpassen", wenn man den Mailversand z.B. wirklich durch ein Update auslöst (es reicht m.W. aber schon, irgendeine ungültige Datei als Image anzugeben, weil die Prüfung erst nach dem Mailversand erfolgt, auch da bin ich aber nicht sicher, weil das schon wieder länger her ist ... also einfach selbst probieren) ... es macht keinen Sinn in das aktive FS unter "/wrapper" zu schreiben, wenn hinterher ein Firmware-Update auf das andere System umschaltet. Zwar kann man dann auch wieder zurückschalten, aber besser ist es allemal, den weiteren Ablauf so eines Updateversuchs gleich am Beginn "plattzumachen", damit es erst gar nicht zu einer echten Update-Installation kommt.
 
Ich habe zwar meine 7490 schon mehrfach per modfs erfolgreich behandelt, stehe aber jetzt vor der Aufgabe, das bei einer 7362SL zu tun.
modfs starter habe ich installiert.
Als Wissen aus diesem Thread und der Zusammenstellung der Eisbärin habe ich mitbekommen, dass ich aufgrund mangelndem Speicherplatz über einen Stick ein Swapfile bereitstellen muss.
Irgendwie stoße ich bei den hier internen und auch externen Linux-Threads zum Thema "Swapfile erstellen" auf ein Verständnisproblem, wie das zu bewerkstelligen ist und ich habe mich Beiträgen über dieses Thema übers Stunden gewidmet. Manchmal wird man nur mit Befehlszeilen beworfen ohne dass eine für mich verständliche Erläuterung dieser Zeilen dabeisteht. Wo die Erläuterungen zu finden sind, bringe ich sie nicht mit dem konkreten Aufgabe in Einklang.

Wer kann einem DAU wie mir die sicherlich einfachen und wenigen Schritte zum Erstellen dieses Swapfiles an meiner Fritzbox erklären?
 
Nimm das MiniTool Stick plattmachen und als erstes eine SWAP-Partition (ich habe 1GB dafür abgezwackt) anlegen und den Rest ext3. Dann schauen nach der Initalisierung an der FB ob korrekt eingebunden. Die Syntax zur Überprüfung steht hier wo.
LG
 
Alternativ einen ext2 oder ext3 formatierten Stick / HDD benutzen und statt der Swap-Partition (wie vom Vorredner beschrieben wird diese Partition automatisch beim Boot der Box gemountet) ein Swap File erstellen.

Wie geht das? Formatierten Stick / HDD einstecken und dann hier weiterlesen: http://www.ip-phone-forum.de/showthread.php?t=273304&page=10&p=2106798&viewfull=1#post2106798

Was die 3 oder 4 commands genau bewirken kannst du ganz leicht über eine von dir favorisierte Suchmaschine herausfinden ;-)
 
Zuletzt bearbeitet:
Ich weiß zwar nicht genau, was man unter "einfachen und wenigen Schritten" verstehen soll ... ich versuche es trotzdem einmal; auch auf die Gefahr hin, daß das wieder nur als "negative Reaktion" aufgefaßt wird.


-Ich will nicht schon wieder in "allgemeine Diskussionen" einsteigen, aber das Partitionieren und Formatieren eines USB-Datenträgers ist nun einmal Grundwissen (das braucht es nicht nur für "modfs", sondern es ist praktisch für jeden (Linux-)Benutzer eines USB-Sticks unumgänglich) und welche der vielen Anleitungen im Internet dafür man nun "gut findet" und welche nicht, hängt so stark vom eigenen Geschmack und den eigenen Vorkenntnissen ab, daß es einfach keine allgemeingültige "Empfehlung" geben kann und auf eine Diskussion "Du hast die und die "Anleitung" verlinkt, die und die ist aber viel besser ..." habe ich absolut keinen Bock.

Ich halte die Verwendung einer Swap-Datei sogar für eine schlechte Idee (auch wenn die Modifikation bzgl. des Aushängens von Swap-Space beim Neustart auch Dateien berücksichtigt ... im Gegensatz zu einer Datei, die zur Aktivierung zusätzliche Kommandos braucht, wird eine Partitiion automatisch verwendet) und ansonsten braucht es genau einen USB-Stick mit (mindestens) zwei Partitionen. Einmal eine Partition, als "Linux swap" gekennzeichnet, mit einer Größe ab ca. 512 MB (viel mehr macht auch keinen Sinn, weil Swap-Space keinen fehlenden Hauptspeicher ersetzen kann, er ermöglicht dem Linux-OS "nur" das temporäre Auslagern von Speicherinhalten für Programme, die gerade laufen, aber Teile ihres aktuellen Inhalts im Moment nicht benötigen oder dann halt warten müssen, bis wieder Platz vorhanden ist) und zum zweiten eine Partition mit einem nativen Dateisystem für Linux, welches die Verwendung von (Unix- bzw. Linux-)Dateiattributen direkt unterstützt und nicht irgendwo "emuliert", wie das bei FAT der Fall wäre. NTFS fällt schon wegen der Umsetzung über NTFS-3G und Fuse unter den Tisch ... und FAT könnte zwar tatsächlich für eine Swap-Datei verwendet werden (deren Attribute interessieren nicht wirklich), aber dort bräuchte eben ein Linux-Dateisystem eine "Containerdatei" in Form eines Images und das kostet spätestens bei der Ausführung dann einiges an Performance.

Die Dateiattribute sind wichtig, weil sie beim Entpacken und Packen des SquashFS-Images eine Rolle spielen. Angesichts des beschränkten Umfangs der Unterstützung von Dateisystemen im originalen AVM-Kernel, kommt damit nur eine der Versionen eines "extn"-Dateisystems in Frage. Angesichts der "Empfindlichkeit" von "ext2" bei unerwarteten Neustarts (das kann schnell in einem "kaputten" Dateisystem enden und so ein FS muß dann erst repariert werden, was mind. eine Shell-Session zur Box erfordert), bleiben nur "ext3" und "ext4" übrig und gegen die Verwendung von "ext4" habe ich mehrfach argumentiert. Zumindest beim hier zu betrachtenden Einsatzfall bringt "ext4" keinen Vorteil (m.E. ja bei keinem sinnvollen Einsatz an einer FRITZ!Box), also wäre die Wahl von "ext3" naheliegend.

Die bereitgestellten Werkzeuge im "bin"-Verzeichnis von "modfs" ermöglichen jetzt sowohl das Partitionieren eines USB-Sticks (die BusyBox enthält das "fdisk"-Applet) als auch das Anlegen der jeweils benötigten Dateisystem-Strukturen. Ein "mkswap"-Applet ist in der BusyBox ebenso enthalten, wie die (statisch gelinkten) Programme für die Verwendung von "extn"-Dateisystemen ("mke2fs" zum Erstellen und "e2fsck" zum Prüfen, falls doch auch mal ein "journaling filesystem" wie "ext3" oder "ext4" so zerwürgt ist, daß es einer gesonderten Überprüfung bedarf) gesondert bereitsgestellt wurden - wie diese Programme jetzt jeweils zu verwenden sind, wenn man den Stick direkt an der Box einrichten will und nicht an einem externen System, steht im Internet. Bei der Verwendung eines externen Systems hängt das Vorgehen dann logischerweise von diesem System ab ... hier springt die "Unmöglichkeit" einer allgemeingültigen Beschreibung dann direkt ins Auge.

Da ein korrekt eingerichteter USB-Stick dann automatisch auch richtig eingehangen wird (die Verwendung einer Swap-Partition ist auch im originalen AVM-System enthalten in "/etc/hotplug/udev-mount-sd"), braucht es dafür gar keine weiteren (zusätzlichen) Kommandos/Schritte/Vorbereitungen, als das Verbinden des USB-Speichers (ggf. mit externer Stromversorgung, weil die Modelle ohne USB3-Ports nur 500 mA an einem USB-Port bereitstellen). Dazu schaut man sich sowohl den Stecker (der kann auch direkt Bestandteil des USB-Speichergerätes sein, wenn es sich um ein solches handelt, was man gewöhnlich als "Stick" bezeichnet oder es ist das Ende eines "Kabels") als auch die Buchse in der FRITZ!Box an und führt dann den Stecker dergestalt in die Buchse ein, daß dabei keinerlei mechanische Probleme entstehen. Dafür ist sowohl die richtige Orientierung von Stecker und Buchse erforderlich als auch (am Beginn) unbeschädigte Kontaktzungen auf beiden Seiten.

Wer sich jetzt fragt, warum ich ausgerechnet den Vorgang des Verbindens von FRITZ!Box und USB-Speicher so ausführlich darstelle ... das ist dann tatsächlich "der gemeinsame Nenner", für den es praktisch keine Alternativen gibt und bei dem man als einziger Aktion wirklich eine "Anleitung" geben kann, wo zwar Kontroversen bzgl. der notwendigen Ausführlichkeit entstehen könnten (angesichts unterschiedlicher Ausgangskenntnisse bei möglichen Lesern), aber am generellen Vorgehen sollte sich hier eigentlich keine weitere Diskussion entzünden können.

Ich hänge jetzt hier bewußt keine URL an ... die Verwendung der Suchbegriffe "linux usb formatieren" liefert bei der gößten Suchmaschine ca. 177.000 Ergebnisse in 0,43 Sekunden (ich habe extra mal "auf Deutsch" präferiert) und ich fühle mich einfach nicht dazu berufen, meinerseits dieser Ergebnismenge ein weiteres Element hinzuzufügen (durch eine eigene "step by step"-Anleitung) oder gar für irgendjemanden eine Auswahl zu treffen, welcher dieser Treffer nun für ihn oder sie am besten geeignet sein mag.

Wenn jemand eine fremde "Entscheidung" benötigt, wie so ein USB-Stick nun aufgebaut sein soll, dann gerne als "Empfehluing" (solange niemand hinterher auf die Idee kommt, mit mir darüber diskutieren zu wollen):

USB-Stick mit mind. 4 GB mit zwei Partitionen einrichten, eine Swap-Partition mit 512 MB (bis zu 2 GB könnten sinnvoll sein, wenn der Stick am Ende gar 8 GB gesamt haben sollte) und den Rest des verfügbaren Speichers als "ext3"-Partition.

Wie das umzusetzen ist, hängt - wie erwähnt - vom eigenen Betriebssystem ab (es geht sogar unter Windows, hier aber nur mit "Zusatzsoftware" - s. Anleitung von @eisbaerin) und kann einfach nicht Gegenstand dieses Threads sein - das ist genau eines der Themen, die dann in so einen "wie mache ich das und das"-Thread gehören, wie ich ihn angesprochen habe. Ich kann zwar nicht verhindern, daß es auch in diesem Thread in aller Länge und Ausführlichkeit (ggf. inkl. der beliebten Glaubenskriege, ob man dafür nun besser Linux oder Windows oder ganz was anderes nimmt - und da bin ich "gebranntes Kind") diskutiert wird (schließlich "gehört" mir dieser Thread nicht), aber ich kann dann sehr wohl das weitere Lesen (und Schreiben meinerseits) verweigern und das würde ich auch tatsächlich machen.


-Ich will ebenfalls nicht mit einzelnen Benutzern diskutieren, ob man nicht auch bei der Verwendung einer Swap-Datei (auf die @eisbaerin verlinkt hat) die notwendigen Kommandos (und x Vergleiche/Diskussionen, was denn nun besser wäre: Partition oder Datei) durch einfache Suche hätte finden können (warum ich hier eine Partition für besser halte, habe ich zwar schon erwähnt, aber falls es untergegangen sein sollte: Eine Partition wird im Gegensatz zu einer Datei automatisch verwendet im FRITZ!OS.) - ich will nur noch einmal darauf hinweisen, daß es für die generelle Verwendung von Linux als Betriebssystem (und das macht eine FRITZ!Box nun einmal, mithin arbeitet auch "modfs" auf einem Linux-System, da es explizit dafür entworfen wurde, auf einer FRITZ!Box benutzt zu werden) andere und weitaus besser geeignete, ja sogar ausführlichere (was angesichts meiner üblichen Länge unwahrscheinlich erscheint, aber belegbar ist) Quellen gibt und daß es in diesem Thread eigentlich - zumindest nach meiner Ansicht - um Probleme und Fragen zu "modfs" und nicht zur Handhabung von Linux an sich gehen sollte.

Man muß mit dieser Meinung nicht konform gehen ... aber es wäre eben nett, wenn man sich vor solchen Fragen dann überlegt, ob man nur selbst von einer Antwort profitieren würde (dann bleibt immer noch die Möglichkeit, die Frage in einem gesonderten Thread zu stellen) oder ob das tatsächlich ein Thema ist, was auch andere Leser dieses Threads (meinetwegen inkl. "nachfolgender Generationen", wobei die Frage, wie es andere bisher wohl geschafft haben, einen USB-Stick passend zu präparieren, ja auch nicht ganz uninteressant ist) tangieren müßte.

Man muß so ein Thema einfach auch irgendwo beschränken (das klappt ohnehin schon nie, wie man es eingangs plant) ... ich finde jedenfalls außer der Feststellung "Das ist an anderer Stelle zu finden." keine schlüssige Begründung, warum man dann beim Thema "Partitionieren und Formatieren von USB-Datenträgern" die Grenze ziehen sollte und nicht bei "Auswahl und Installation eines passenden Linux-OS auf diversen Hardware-Plattformen inkl. Vor- und Nachteile möglicher Treiber-Dateien". Letzteres ist zwar "noch allgemeiner" und damit umfassender als das erste Beispiel, aber schon das erste ist eben eines, was (aus meiner Sicht) nicht in allen Einzelheiten in diesen Thread gehört und wo man sich mit ein wenig Beschäftigung mit dem Thema (was ist eigentlich Swap-Space unter Linux und wie kann man den bereitstellen) an anderen Stellen problemlos informieren kann.

Ich hoffe, ich bin nicht wieder "mit dem Messer zwischen den Zähnen" auf den Fragesteller losgegangen ... aber es wurde hoffentlich genauso deutlich, daß man - ich schreibe jetzt wirklich und absichtlich wieder "ohne eigene Initiative", weil ich einfach nicht glauben kann und will, daß man tatsächlich bei einer eigenen Suche so gar keine Treffer erzielen könnte - dann vielleicht doch die Finger von "modfs" lassen sollte.

Auch dieses war - zumindest am Beginn - ganz deutlich als "Anregung" für eigene Änderungen an einer FRITZ!Box gedacht (steht ziemlich sicher auch in #1) und schon dafür braucht es auch entsprechende Kenntnisse beim Anwender. Es ist doch geradezu widersinnig, wenn ich auf der einen Seite versuche, das FRITZ!OS von AVM sicherer zu machen durch Aufdecken bestehender Probleme und auf der anderen Seite dann zusehe, wie sich jemand sehenden Auges ins Knie schießt. Da bliebe als Konsequenz dann ja fast nur noch übrig, die Bereitstellung einer "schlüsselfertigen Lösung" wieder aufzugeben, wenn es wirklich um sich greift, daß "modfs" in einer Art und Weise verwendet wird, die am Ende die zusätzlich gewonnene Sicherheit wieder komplett aushöhlt (na gut, nur bei jemandem, der es dann zur Modfikation benutzt und insofern bleibt immer noch ein Plus bei der Sicherheit (der anderen) übrig), weil der (falsche) Eindruck entsteht, man bräuchte dazu keinerlei Vorkenntnisse mehr (oder den Willen, sich solche zusätzlichen Kenntnisse selbständig anzueignen).

Wenn mein erneuter "rant" jetzt auch nur einen neuen Benutzer von der Verwendung von "modfs" abhalten sollte, weil er sich in der Umschreibung oben wiederfindet, dann hätte ich das Ziel ebenfalls erreicht ... die (wiederholte) Betonung, daß es sich bei der (verständigen) Benutzung von "modfs" und Linux allgemein (speziell auch der Kommandozeile dort, weil eine FRITZ!Box nun mal keine X-Windows-Oberfläche hat) nicht um "rocket science" handelt und tatsächlich jeder durchschnittlich begabte Computer-"Versteher" dazu in der Lage sein sollte, impliziert eben noch lange nicht, daß das nun auch vollkommen ohne eigene Kenntnisse (oder entsprechende Bemühungen bei deren Erwerb) machbar wäre.

- - - Aktualisiert - - -

Wegen einer E-Mail will ich noch einmal schnell etwas loswerden ... es mag sein, daß ich hier wie der Elefant im Porzellanladen wirke und am Ende @palast das alles "abkriegt".

Warum gehe ich so "aus dem Sulky"?

Ich habe in #1042 (bei fast jedem - mir bekannten - Lesemodus ist das auf derselben Seite wie die Frage in #1048) lang und breit über Swap-Space geschrieben und im Ergebnis noch etwas dazu am Skript ergänzt.

In dem ganzen Text geht es u.a. auch darum, daß ich diesen Thread für den falschen Ort halte, um generelle Linux-Probleme zu erörtern. Das steht faktisch 1:1 auch bereits in #1 - ist also eigentlich auch nichts Neues, selbst wenn man #1042 nicht gelesen hätte.

Da sehe ich dann tatsächlich in der Frage in #1048 entweder eine Provokation (vielleicht auch zu unrecht, komme ich gleich drauf) oder erneut das Resultat genau des bereits in #1042 angesprochenen Umgangs mit dem Thema. Ich bin per se schon skeptisch, wenn mir jemand erklärt, er habe sich "über Stunden" mit dem Lesen von "hier internen und auch externen Linux-Threads zum Thema 'Swapfile erstellen'" beschäftigt und sei am Ende doch nicht einen Schritt weitergekommen. Das kann ich nicht wirklich glauben und solange jemand "über Stunden" schreibt, gehe ich von mind. 60 Minuten, wenn nicht sogar von mind. 120 Minuten aus, weil wohl jeder mit solch einer Angabe ganzzahlige Werte (von Stunden und das ist nun mal auch noch Plural) in Verbindung bringen würde.

Da würde ich tatsächlich die These wagen, daß entweder jegliche Voraussetzung für die Verwendung von "modfs" fehlt (vielleicht lohnt sich auch da noch einmal ein Blick, was ich schon vor langer Zeit in #1 dazu geschrieben habe - in meinen Augen hat sich nichts Grundlegendes geändert) - darauf bin ich dann eingegangen - oder es ein untauglicher Versuch der Suche im Internet war (das kann man ohne Suchbegriffe nicht beurteilen und die fehlen in der Frage leider - darauf bin ich nicht erneut eingegangen) oder es ist eben doch eine Übertreibung, die man nicht ganz so ernst nehmen kann (oder vielleicht sogar sollte nach dem Willen des Fragestellers). Wie auch immer ... wenn nach der Beschäftigung "über Stunden" so eine simple Frage nicht geklärt ist, was der Unterschied zwischen einer Swap-Datei und einer Swap-Partition ist und wie beide eingerichtet und eingebunden werden, dann stellt sich mir die Frage, warum das durch eine (erneute) Anleitung nun anders werden sollte ... und der Verweis auf Linux-Grundlagen und die Bitte, sich diese Grundkenntnisse anderswo zu erarbeiten, ist weder neu in #1042 noch (nach meinem Dafürhalten) unbegründet.

Es kommt immer wieder die Kritik auf, der Thread wäre so lang und es könne ihn praktisch niemand mehr lesen ... aber das steht dann praktischerweise nicht etwa in einem "Nachbarthread" mit der eigenen Frage, sondern wieder in einem zusätzlichen Beitrag in diesem Thread, was für den nächsten Leser die Lage noch mehr verschärft (der vielleicht doch noch mehr Ausdauer beim Lesen gehabt hätte als der letzte Fragesteller). Wenn jemand tatsächlich keinen Bock hat, den gesamten Thread zu lesen und trotzdem eine Frage hat, die (erkennbar!) mit dem Thema "modfs" zu tun hat, dann muß man wohl resignieren und sich denken: "Wenigstens paßt es zum Thema." ... das sehe ich (egal wie sehr ich mich auch anstrenge) bei der Frage nach dem "Swap-Space" absolut nicht.

Inzwischen hat dieser Thread tatsächlich eine Länge erreicht (da spielt die jeweilige Länge der von mir geschriebenen Beiträge zumindest nicht direkt hinein, denn die zählen nur einmal, egal wie lang sie sein mögen), daß man kaum noch (realistischerweise) darauf verweisen kann, daß das irgendwo hier im Thread bereits steht. Aber das, was direkt in #1 steht und auch jeder von dortaus verlinkte Beitrag - das gilt auch dann, wenn dort nur die Nummer steht und es keinen Link gibt - sollte schon zu dem gehören, was man sich erst einmal durchliest, bevor man sich zur eigenen Frage aufrafft. Dann noch zweimal gründlich nachgedacht, ob das wirklich zum Thema "modfs" gehört und dann kann ich mich tatsächlich nicht erinnern, daß ich jemandem mal keine (sachliche) Antwort gegeben hätte.

Ich finde es nur unfair (sowohl mir selbst als auch anderen gegenüber), wenn man sich "einen schlanken Fuß macht", auf Kosten anderer. Wenn jemand wirklich ernsthafte Probleme hat, etwas zu finden, dann schreibe er in drei Teufels Namen eben auf, was er gesucht und gefunden hat (das wirkt dann auch gleich viel glaubwürdiger) und dann kann man ihm für die nächste Suche vielleicht helfen. Wenn sich jemand schon deshalb weigert, weil die verwendeten Suchbegriffe wohl eher unlogisch waren, dann sagt das eben mehr über die Realität hinter der Behauptung so einer stundenlangen Suche aus (und das kommt ja auch von anderen, das geht nicht nur an die Adresse von @palast) als es jeder "rant" meinerseits könnte.

Wenn ich mich irgendwo "festlese" und vom hundertsten Link zum nächsten springe, dann kann ich mich auch stundenlang mit einer Internet-Suche befassen ... aber ab dem dritten oder vierten Link hat das mit meinem ursprünglichen Anliegen nur noch wenig zu tun (am Ende landet man entweder bei YouTube oder auf einer Pron-Seite) und da kann ich das wohl kaum zu dieser Suche "hinzuzählen".

Wenn das von @palast gar kein Test war, ob ich "ausraste" ... wenn also meine Annahme falsch war, dann ist aber das in #1 - und (zuletzt) in #1042 noch einmal - Geschriebene nach wie vor gültig - wenn ich davon ausgehe, daß ein Verwender von "modfs" spätestens dann, wenn er ein Problem findet, was bei @eisbaerin nicht beschrieben ist, wieder in diesem Thread nachliest (und zwar bevor er fragt), dann finde ich das tatsächlich immer noch "normal". Ich kann mich noch an Zeiten erinnern, wo einfach kurz und schmerzlos "RTFM" oder "STFW" geschrieben wurde (das lehnt die Forensoftware als zu kurz ab) - und das ging auch. Etwas anderes will ich hier auch niemandem "ans Herz legen" - ich kann das nur nicht so kurz und prägnant formulieren.

Ich gehöre jedenfalls noch zu den Leuten, die es sich tatsächlich überlegen, bevor sie anderen eine Arbeit aufhalsen wollen (und auch das Schreiben einer Antwort ist Arbeit), die sie eigentlich selbst erledigen könnten oder gar sollten. Die Masche "Ich bin nur ein armer DAU und kann mir das mal jemand ganz langsam erklären, weil ich nicht so schnell lesen kann." verfängt bei mir schon deshalb nicht, weil es in meinen Augen überhaupt keinen DAU gibt. Das ist entweder (a) eine reichlich überhebliche Bemerkung von Administratoren und Programmierern oder (b) eine reine Schutzbehauptung von jemanden, der etwas nicht weiß, sich damit aber auch gar nicht selbst und aus eigener Kraft befassen will.

Meine (inzwischen 37-jährige) Berufserfahrung hat mich auch gelehrt, daß ein DAU eben keine "feste Größe" ist, mit der man "planen" kann. Egal, wieviel Mühe man sich gibt, bereits im Vorfeld alle nur denkbaren Fehler und Probleme auszuschließen und eine Lösung "DAU-sicher" zu machen ... es fand sich bisher immer noch jemand, der die Latte noch ein Stückchen höher legen konnte.

Wenn also jemand freiwillig hingeht und sich selbst als DAU bezeichnet, dann sehe ich das weniger als eine realistische Einschätzung der eigenen Kenntnisse und Fertigkeiten an (die könnte man ja ohnehin erweitern und verbessern) als vielmehr als das "Vorbauen", daß es auch gar keinen Sinn macht, noch etwas zu lernen, weil man es ja ohnehin nicht begreifen würde ... das ist in der Tat ein Standpunkt, den ich "widerwärtig" finde - erst recht dann, wenn dieses Urteil von einem "Fachmann" über jemand anderen gefällt wird.

Damit ist allerdings gleichzeitig die Erwartungshaltung auf meiner Seite verbunden, daß sich jemand mit einer eigenen Frage "an die Allgemeinheit" tatsächlich auch mit der Materie beschäftigen will und wenn ihm dabei die eigene "Unlust" im Weg steht (auch das "Mir reicht das, was ich davon schon weiß." kennen wir alle zur Genüge), dann konnte mir bisher niemand plausibel machen, warum sein Problem für mich bedeutsamer sein sollte als es für ihn selbst ist und warum ich nun zusätzliche Anstrengungen investieren sollte, um sein Problem zu lösen.

So etwas gibt es tatsächlich auch (seitdem die Menschheit die Arbeitsteilung "erfunden" hat) ... dafür werden diejenigen, die ihrerseits die Arbeit übernehmen sollen, dann aber auch entsprechend entlohnt. Das geht hier im Forum nicht und somit ist das Forum auch nicht der geeignete Platz für derartige Haltungen und Ansprüche - meine Meinung.

So schön es auch sein mag, wenn man jemandem mit einem Stück Code oder einer Antwort am Ende helfen kann (und man damit einen weiteren "Nutzer" hat), daraus leitet sich noch keine "Verpflichtung" zu irgendeiner weiteren "Dienstleistung" ab und wenn jemand (erkennbar - und das kann auch am Behaupten eigener Anstrengungen bei gleichzeitigem "Auslassen" der konkreten Beschreibung bisher bereits "aussortierter" Lösungen oder Fundstellen festgemacht werden) an die Stelle eigener Bemühungen um die Lösung dann einfach jemand anderen "einspannen" will, dann reagiere ich allergisch - auch wenn ich natürlich nur für mich selbst festhalten kann, daß ich nicht der TvD sein will; fühlt sich jemand anderes dazu berufen, kann ich es nicht ändern.

Wenn das dann aber auch noch erkennbar OT ist, muß es eben nach meiner Ansicht nicht unbedingt in diesem Thread sein (ja, auch ich schreibe ab und an mal OT, aber nicht "nun erst recht", wenn es gerade erst wieder angesprochen wurde und die "Bitte" diesbezüglich quasi noch druckfrisch ist - das macht denn eben den Eindruck: "Jetzt erst recht." und der veranlaßte mich zu #1051 ... und keine andere Antwort oder ähnliches).
 
Hallo Peter!

modfs ging ohne Fehler bei:

FRITZ.Box_7490.113.06.80.image
FRITZ.Box_7362_SL.131.06.80.image

und auch noch bei:

FRITZ.Box_7412_Labor.137.06.69-42896.image

Aber die FRITZ.Box_7412.137.06.80.image bringt einen Fehler im "mod_show_vpn_on_overview":
Code:
2017-02-10 11:45:51.350 - execute_modscript: exiting, rc=0
2017-02-10 11:45:51.368 - execute_optional_modscript: exiting, rc=0
2017-02-10 11:45:51.395 - execute_optional_modscript: script=/var/media/ftp/mod/modscripts/mod_show_vpn_on_overview, root=/var/media/ftp/1486723361/squashfs-root, mode=
2017-02-10 11:45:51.493 - progress: mode=1, msg=Überprüfen der unterstützten Sprachen ...
2017-02-10 11:45:51.529 - is_supported: option=language, from=precheck postcheck install language(en,de), rc=1
2017-02-10 11:45:51.581 - progress: mode=3, msg=[1;32m OK[0m
2017-02-10 11:45:52.619 - get_temp_dir: directory=/var/tmp/12335_1486723552
2017-02-10 11:45:52.665 - remove_directory: directory=/var/tmp/12335_1486723552, rc=0
2017-02-10 11:45:52.683 - get_description: Anzeige der VPN-Verbindungen auf der Startseite, inkl. Schnell-Link zur VPN-Konfiguration
2017-02-10 11:45:52.802 - ask_yes_or_no: Q=Soll die Modifikation 'add VPN summary on overview page' mit folgender Beschreibung{LF}[1mAnzeige der VPN-Verbindungen auf der Startseite, inkl. Schnell-Link zur VPN-Konfiguration[0m{LF}angewendet werden?
2017-02-10 11:46:00.892 - ask_yes_or_no: A=j
2017-02-10 11:46:00.920 - execute_modscript: script=/var/media/ftp/mod/modscripts/mod_show_vpn_on_overview, root=/var/media/ftp/1486723361/squashfs-root, mode=onrequest
2017-02-10 11:46:00.975 - is_supported: option=language, from=precheck postcheck install language(en,de), rc=1
2017-02-10 11:46:01.028 - progress: mode=1, msg=Überprüfen der Voraussetzungen für die Modifikation ...
2017-02-10 11:46:01.052 - is_supported: option=precheck, from=precheck postcheck install language(en,de), rc=1
2017-02-10 11:46:01.133 - progress: mode=3, msg=[1;32m OK[0m
2017-02-10 11:46:01.181 - progress: mode=1, msg=Modifikation wird ausgeführt ...
2017-02-10 11:46:12.082 - progress: mode=3, msg=[1;32m OK[0m
2017-02-10 11:46:12.133 - progress: mode=1, msg=Überprüfen des Erfolgs der Modifikation ...
2017-02-10 11:46:12.163 - is_supported: option=postcheck, from=precheck postcheck install language(en,de), rc=1
2017-02-10 11:46:12.243 - progress: mode=3, msg=[1;31m Fehler (1)[0m
2017-02-10 11:46:12.291 - execute_modscript: exiting, rc=1
2017-02-10 11:46:12.308 - execute_optional_modscript: exiting, rc=0
Reicht das für die Fehlersuche oder brauchst du doch das komplette debug?
Der Fehler müßte eigentlich auch bei Dir auftreten, falls du es mal bei Dir laufen läßt.

Ist nicht lebenswichtig, aber irgend etwas muß AVM da noch gegenüber der letzten Labor geändert haben.
 
Zuletzt bearbeitet:
@eisbaerin:

Hotfix für FB7412-FW 06.80:
die nachfolgenden zwei Zeilen mit "-" Prefix durch die zwei Zeilen mit "+" Prefix in Datei modscripts/mod_show_vpn_on_overview tauschen
Code:
--- ./modscripts/mod_show_vpn_on_overview
+++ ./modscripts/mod_show_vpn_on_overview
@@ -229,8 +229,8 @@
  lan = get_lan(data),
  usb = get_usb(data),
 +vpn = get_vpn_connections(data),
- wlan24 = (config.WLAN.is_double_wlan and get_wlan24GHz(data)) or (not config.WLAN.is_double_wlan and get_wlan(data)) or nil,
- wlan5 = (config.WLAN.is_double_wlan and get_wlan5GHz(data)) or nil,
+ wlan24 = config.WLAN and ((config.WLAN.is_double_wlan and get_wlan24GHz(data)) or (not config.WLAN.is_double_wlan and get_wlan(data))) or nil,
+ wlan5 = config.WLAN and ((config.WLAN.is_double_wlan and get_wlan5GHz(data))) or nil,
  smarthome= get_smarthome(data),
 --- usr/www/$TARGET_BRANDING/home/home.js
 +++ usr/www/$TARGET_BRANDING/home/home.js

und dann funktioniert modfs-0.4.1-031220162001 speziell für die FB7412-FW 06.80.
 
Danke für die schnelle Lösung! Probiere ich gleich aus.
Wäre aber nicht nötig gewesen, da wie geschrieben nicht wichtig.

Da braucht man wohl bald eigene modskripts für jede FB?
Oder zusätzliche Abfragen im modskript um welche FB es sich handelt?

EDIT: Ja, ist jetzt ohne Fehler durch gelaufen!
 
Zuletzt bearbeitet:
mod_custom_images - Erweitern von FRITZ!OS um eigene Software-Pakete

Ich habe das erfolgreich ausprobiert und habe wie beschrieben shellinabox als custom-image laufen:rock:

Dabei hat mich etwas aufgehalten, daß ich (da ich es immer ein bißchen anders machen muß:oops:) die rc-Datei rc.custom genannt habe, was im Zusammenspiel mit E99-custom nicht funktionierte - genauer gesagt, kann man sie wohl alles nennen außer rc.custom. Ich habe dazu in github ein Issue gemeldet ...

Ferner wollte ich bestätigen, daß auf einer 7490 unter 6.80 definitiv Swappen erforderlich ist, um in modfs die Images zu generieren!

Gruß, Martin
 
Ich habe mal etwas geändert wg. des neuen Eintrags im GitHub ... ich denke mal, das Ergebnis ist in etwa das, was da gewünscht war.
 
Kein Datenvolumen im Online-Zähler der FB7412

Ich habe mal für die FB7412 die Anzeige der verbrauchten Datenvolumen "zurückgezaubert", da es von AVM bewußt wegprogramiert wurde/wird.
Näheres dazu habe ich hier beschrieben: >>>klick<<<

Gilt für die FW 137.06.8x!
Da ich schon mal dabei war, habe ich die inetstat_budget.lua für den Tarif auch noch mit angepaßt.
EDIT 13.9.2017: Ergänzt Datenvolumenanzeige in der Push-Mail
EDIT 1.10.2017: Nach Test, lauffähig gemacht
EDIT 1.8.2018 CONFIG_VOL_COUNTER=y

mod_show_data_on_counter_7412.06.8x:
Code:
# MODFS_MODSCRIPT
# SUPPORTS precheck postcheck install language(en,de)
# NAME add Data on online-couter page on FB7412 FW 06.8x
# DESCRIPTION en
# show Data counts on the online-couter page and e-mail
# DESCRIPTION de
# Anzeige der Datenvolumen auf der Online-Zähler Seite und E-Mail der FB7412 FW 06.8x
# EOH
#
# process parameters
#
language=$1
rootdir=$2
mode=$3
step=$4
[ ${#4} -eq 0 ] && exit 59 # invalid call
#
# variables
#
rc=0
check_filename="$rootdir/usr/www/$TARGET_BRANDING/internet/inetstat_counter.lua"
check_trigger="colspan"
#
# apply
#
patch_file()
{
    local home=$(pwd)
    cd $rootdir
    $home/bin/$HWRevision/busybox patch -p0 2>/dev/null <<EOT
--- usr/www/$TARGET_BRANDING/internet/inetstat_counter.lua
+++ usr/www/$TARGET_BRANDING/internet/inetstat_counter.lua
@@ -20,10 +20,19 @@
 function get_data_table_header()
 local str = [[
 <tr class="first_row">
-<th class="first_col">&nbsp;</th>
-<th>{?815:715?}</th>
+<th class="first_col"></th>
+<th>Online-Zeit</th>
+<th style="text-align:center;" colspan="3">Datenvolumen (MByte)</th>
 <th>{?815:765?}</th>
 </tr>
+<tr class="first_row">
+<th class="first_col"></th>
+<th>(Std:Min)</th>
+<th>gesamt</th>
+<th>gesendet</th>
+<th>empfangen</th>
+<th></th>
+</tr>
 ]]
 return str
 end
@@ -50,6 +59,15 @@
 local outgoingcalls = box.query("inetstat:status/"..request.."/OutgoingCalls")
 local time = box.query("inetstat:status/"..request.."/PhyConnTimeOutgoing")
 str = [[<td datalabel="{?815:922?}" class="time">]] .. general.convert_to_str(time) .. [[</td>]]
+local inh, inl, outh, outl = query_send_receive(request)
+str = str .. core.sprintf([[
+<td datalabel="Datenvolumen gesamt(MB)" class="vol">%1</td>
+<td datalabel="Datenvolumen gesendet(MB)" class="vol">%2</td>
+<td datalabel="Datenvolumen empfangen(MB)" class="vol">%3</td>]],
+box.tohtml(get_vol_str(inh, inl, outh, outl)),
+box.tohtml(get_vol_str(outh, outl)),
+box.tohtml(get_vol_str(inh, inl))
+)
 str = str .. [[<td datalabel="{?815:560?}" class="conn">]] .. outgoingcalls .. [[</td>]]
 return str
 end
@@ -403,7 +421,10 @@
 <form method="POST" action="<?lua box.html(box.glob.script) ?>" name="main_form">
 <div class="formular small_indent">
 <p>
-{?815:459?}
+Die FRITZ!Box erfasst die Online-Zeit und das verbrauchte Datenvolumen.
+In der Z&auml;hlung wird jedoch nur das Datenvolumen der Internetverbindung ber&uuml;cksichtigt.
+Wenn Sie weitere Verbindungen nutzen, beispielsweise f&uuml;r Internettelefonie oder IPTV, wird deren Datenvolumen im Online-Z&auml;hler nicht mitgez&auml;hlt.
+Beachten Sie, dass der Online-Z&auml;hler von der exakten Abrechnung Ihres Internetanbieters abweichen kann.
 </p>
 <div id="uiNoTime" <?lua hideif(g_timeknown) ?>>
 <p>
@@ -417,7 +438,7 @@
 </div>
 <div>
 <p>
-{?815:95?}
+Nach dem Wechsel des Internetanbieters oder der Verbindungsart (z.B. DSL zu Mobilfunk) sollten Sie den Online-Z&auml;hler zur&uuml;cksetzen, um sp&auml;ter das Datenvolumen und die Online-Zeit eindeutig zuordnen zu k&ouml;nnen.
 </p>
 <div class="btn_form">
 <button type="button" onclick="onResetCounter();" name="reset">
@@ -452,7 +473,7 @@
 </div>
 <div <?lua hideif(g_budget_enabled) ?>>
 <p>
-{?815:65?}
+Wenn Sie einen Zeit- oder Volumentarif haben, k&ouml;nnen Sie sich hier den Verbrauch im aktuellen Abrechnungszeitraum anzeigen lassen.
 </p>
 <div class="btn_form">
 <button type="submit" name="editbudget">
--- usr/www/$TARGET_BRANDING/internet/inetstat_budget.lua
+++ usr/www/$TARGET_BRANDING/internet/inetstat_budget.lua
@@ -280,17 +280,44 @@
 </h4>
 <div>
 <p>
-{?141:619?}
+Geben Sie hier das enthaltene Datenvolumen oder die Freistunden Ihres Tarifs an.
 </p>
 <input type="checkbox" name="budget_enabled" id="uiBudgetEnabled"
 onclick="OnToggleBudget(this.checked)" <?lua write_budget_enabled()?>><label for="uiBudgetEnabled">
 {?141:990?}
 </label>
 <div id="uiBudgetBlock" class="formular reverse">
+<input type="radio" name="budget_type" id="uiVolBudget" value="vol"
+onclick="OnToggleBudgetType('vol')" <?lua write_budget_checked('vol')?>><label for="uiVolBudget">
+Volumentarif
+</label>
+<div id="uiVolBlock" class="formular">
+<input type="text" size="7" maxlength="6" id="uiVolValue" name="budget_vol" value="<?lua write_budget_value('vol')?>"><label for="uiVolValue">
+MB Datenvolumen pro Monat inklusive
+</label>
+<p>Beispiel: 5000 MB (entsprechen 5 Gigabyte)</p>
+<input type="checkbox" id="uiViewRoundUpOn" name="budget_roundup" onclick="OnToggleRoundUp(this.checked)" <?lua write_roundup()?>><label for="uiViewRoundUpOn">
+Runden des &Uuml;bertragungsvolumens pro Verbindung auf
+</label>
+<select id="uiViewRoundUpBytes" name="budget_roundup_bytes">
+<option value="1000" <?lua write_roundup_sel("1000")?>>
+volle KB
+</option>
+<option value="1000000" <?lua write_roundup_sel("1000000")?>>
+volle MB
+</option>
+</select>
+</div>
+<input type="radio" name="budget_type" id="uiTimeBudget" value="time"
+onclick="OnToggleBudgetType('time')" <?lua write_budget_checked('time')?>><label for="uiTimeBudget">
+Zeittarif
+</label>
+<div id="uiTimeBlock" class="formular">
 <input type="text" size="6" maxlength="3" name="budget_time" id="uiTimeValue"
 value="<?lua write_budget_value('time')?>">
 <label for="uiTimeValue">{?141:904?}</label>
 <p>{?141:179?}</p>
+</div>
 <div class="noBreakGroup">
 <label for="uiViewStartOfMonth" style="width:auto">
 {?141:313?}
EOT
    cd $home
}
patch_file2()
{
    local home=$(pwd)
    cd $rootdir
    $home/bin/$HWRevision/busybox patch -p0 2>/dev/null <<'EOT'
--- etc/init.d/rc.conf
+++ etc/init.d/rc.conf
@@ -308,7 +308,7 @@
 export CONFIG_VLYNQ0="0"
 export CONFIG_VLYNQ1="0"
 export CONFIG_VOIP_ENUM="n"
-export CONFIG_VOL_COUNTER="n"
+export CONFIG_VOL_COUNTER="y"
 export CONFIG_VPN="y"
 export CONFIG_VPN_CERTSRV="n"
 export CONFIG_WEBCM_INTERPRETER="y"
EOT
    cd $home
}
#
# execute steps
#
case $step in
    precheck)
    if [ "${TARGET_SYSTEM_VERSION%%.*}" = "137" ]; then
        grep -q "$check_trigger" $check_filename 2>/dev/null 1>&2
        rc=$?
        if [ $rc -eq 0 ]; then
            case "$language" in
                de)
                    echo "Die Modifikation wurde bereits angewendet oder ist nicht erforderlich." 1>&2
                    ;;
                *)
                    echo "The modification is already present or modification isn't necessary." 1>&2
                    ;;
            esac
            rc=1
        else
            rc=0
        fi
    else
            case "$language" in
                de)
                    echo "Die Modifikation ist nur für die FB7412." 1>&2
                    ;;
                *)
                    echo "The modification is only for the FB7412." 1>&2
                    ;;
            esac
            rc=1
    fi
        ;;
    postcheck)
        grep -q "$check_trigger" $check_filename 2>/dev/null 1>&2
        rc=$?
        if [ $rc -eq 1 ]; then
            case "$language" in
                de)
                    echo "Die Modifikation war nicht erfolgreich." 1>&2
                    ;;
                *)
                    echo "The menu file seems to be unmodified." 1>&2
                    ;;
            esac
            rc=1
        else
            rc=0
        fi
        ;;
    install)
        for TARGET_BRANDING in $TARGET_BRANDINGS; do
            patch_file
        done
        patch_file2
        rc=0
        ;;
    *)
        rc=59
        ;;
esac
exit $rc
@peter: Schau bitte mal, ob der trigger richtig gewählt ist.
Evt. kannst du im precheck noch eine Prüfung einbauen, so das dieses modskript nur bei einer FB7412 angeboten wird.
Z.B. existiert bei der 7412 kein Verzeichnis /etc/hotplug und auch andere Dateien für USB fehlen.

@All: Da meine FB7412 im Repeater- oder Client-Mode läuft zählt sie da keine Daten.
Somit ist ein echter Praxistest noch nicht erfolgt.
Meldet euch doch bitte, ob es bei euch geklappt hat.
EDIT: Läuft inzwischen erfolgreich auf mehreren FB7412!

PS: Was ich schon immer mal fragen wollte:
In welcher Datei befinden sich die Texte mit denen z.B. {?815:765?} ersetzt wird?
Ich habe manuell schon lange gesucht und nichts gefunden.
 
Zuletzt bearbeitet:
  • Like
Reaktionen: genuede
Der "check_trigger" ist ja nur (wenn ich das richtig gesehen habe) ein Merkmal, mit dem man zwischen "schon modifiziert" und "noch original (bzw. eher: noch unmodifiziert durch dieses Skript)" unterschieden werden kann, weil am Beginn Änderungen nicht mit "patch" gemacht wurden (gibt es in der AVM-BB nicht und die Verwendung einer eigenen Binärdatei kam erst später). Mehrfache Anwendung von "sed" kann aber leicht zu Problemen führen, deshalb brauchte es eine "Entscheidungshilfe". Bei "patch" ist die Gefahr doppelter Änderungen ja nicht vorhanden, paßt die Ausgangsdatei nicht, wird sie auch nicht geändert.

Da es ja immer noch möglich ist, daß man "inkrementelle Änderungen" vornimmt (also das bereits installierte und schon modifizierte System noch weiter ändert), gibt es auch diesen "precheck" immer noch (einige Dateien benutzen auch noch "sed", weil das nun wieder den Vorteil hat, von der "konkreten Formulierung" in der Ausgangsdatei unabhängiger zu sein), der "postcheck" dient nur der (wahrscheinlichen) Erfolgskontrolle.

Solange es vor der Änderung keine Zeichenkette "Datenvolumen" gibt, paßt das schon und wenn das ein Wort sein sollte, was AVM wirklich nur bei der 7412 aus der "inetstat_counter.lua" entfernt hat, würde ja bei anderen Modellen der "precheck" auch sofort auf "für dieses Modell nicht erforderlich" schließen können und Du könntest die erzeugte Nachricht noch entsprechend anpassen (wie ich es in "default_show_mac" gemacht habe).

Eine Prüfung auf ein spezielles Modell mache ich (in privaten Skripts) ansonsten eigentlich immer anhand des ersten Wertes in der Variablen "TARGET_SYSTEM_VERSION". Das reicht zumindest dann, wenn man ein Skript gezielt für ein Modell ein- oder ausschließen will. Ein Test, ob das Ziel eine 7412 ist, sähe dann z.B. so aus:
Code:
if [ "${TARGET_SYSTEM_VERSION%%.*}" = "209" ]; then
   # 7412
else
   # keine 7412
fi
Das kann man bereits im "precheck" abfragen und dann eben "falsches Modell" als Nachricht zurückgeben, die von "modfs" dann protokolliert und angezeigt wird.

Die Texte befinden sich in der als "/var/htmltext.db" verlinkten Datei. Wie deren Index aufgebaut ist, interessiert mich auch, ich bin bisher bei allen Versuchen der Interpretation immer an irgendeiner Stelle gescheitert. Diese DB enthält auch alle Meldungen für das Ereignisprotokoll, die "Übersetzung" der Event-ID in den Text findet in der Datei "/etc/default/$OEM/strings.tab" statt ("/etc/default" ist ein Symlink auf "/var/default", wo dann wieder auf "/etc/$CONFIG_PRODUKT" verlinkt wird).

Zum Auslesen einer konkreten Meldung (der "Index" ist der Wert zwischen den Fragezeichen) kann man "dbtext.lua" verwenden, habe ich hier irgendwo in einem Thread mal "vorgestellt" (frag' mich nicht wo, ich weiß es auch nicht mehr) - da steht auch, wie man's anwendet.

Will man sich alle denkbaren Einträge für das Ereignisprotokoll anzeigen lassen (afaik), sähe das z.B. so aus:
Code:
while read id target; do [ ${#id} -eq 0 ] && continue; target=${target:2}; len=$(( ${#target} - 2 )); target=${target:0:$len};echo -n "id=$id text="; echo "$target" | dbtext.lua; done </etc/default/$OEM/strings.tab >events.txt
Das "dbtext.lua" funktioniert leider nur auf der Box selbst - solange ich das Format nicht genau kenne, kann ich die Texte auch nicht direkt aus der Datei auslesen und bin auf die Mithilfe des FRITZ!OS angewiesen. Zumal dieses Format schon sehr alt sein muß und wohl von AVM irgendwann mal "aufgebohrt" wurde, aber die Anfänge gehen noch auf den "TI_Interpreter" zurück, wenn ich das richtig sehe.

- - - Aktualisiert - - -

Die ersten Schritte eines anderen Skripts, welches ich im Zusammenhang mit diesen Texten verwende, sehen so aus:
Code:
#! /bin/sh
dirs="bin etc lib sbin usr"
out1=/var/textdb_references.step1
out2=/var/textdb_references.step2
out3=/var/textdb_references.step3
out4=/var/textdb_references.step4
rm $out1 >/dev/null 2>&1
rm $out2 >/dev/null 2>&1
rm $out3 >/dev/null 2>&1
rm $out4 >/dev/null 2>&1
for dir in $dirs; do
        find /$dir -type f -exec grep -rho "{?[0-9]\+:[0-9]\+?}" '{}' \; >>$out1 2>/dev/null
done
sort $out1 | uniq >$out2
[...]
Nach diesen ersten Schritten enthält die Datei "/var/textdb_references.step2" dann eine Liste aller Zeichenketten aus dem laufenden SquashFS-Image, die dem verwendeten Schema für solche Text-Referenzen entsprechen. Die Liste ist sortiert und bereits "eindeutig", d.h. doppelte Einträge sind entfernt.
 
@ Peter Pawn:
kannst du eigentlich bei modfs update das "Shell in a box (SIAB)" per modscript mit einbauen lassen?
XC
 
Theoretisch schon, praktisch will ich nicht.

Warum, habe ich schon oft genug erläutert. Mit der Bereitstellung einer binären Datei, die für den Dauereinsatz bestimmt ist, übernimmt man auch gleichzeitig die Verantwortung, diese immer in der neuesten Version anzubieten und entsprechend zu aktualisieren, wenn in vorhergehenden Versionen (Sicherheits-)Lücken erkannt werden. Das ist "nicht mein Tisch" ... und ein Skript zur Installation ist dann auch nicht mehr so schwierig beim "Eigenbau" - im Prinzip könnte man sogar das /var/install aus einem der alten Pseudo-Updates für die "SIAB-Impfung" als Blaupause verwenden.

Für einen solchen (Dauer-)Einsatz gedacht sind jedenfalls weder die BusyBox noch die extFS-Module, SquashFS-Tools oder das "openssl"-Binary aus dem "modfs"-Paket (selbst wenn man sie auf diese Art "mißbrauchen" kann, ist der Einsatzzweck das Funktionieren von "modfs" und nicht die Übernahme als "ständige Tools" in ein eigenes Image - das erfolgt "auf eigene Gefahr") und da diese eigentlich nur für die Dauer der Ausführung von "modfs" auf der Box (und automatisch erreichbar) sein sollten, geht auch von einer älteren Version mit bekannten Lücken keine inakzeptabel große Gefahr für die Integrität der FRITZ!Box aus. Auch beim "modfs-Starter" ging es ja nur um einen "Einstieg" in die Box für die spätere Verwendung von "modfs" und (als "Wunsch" meinerseits) nicht um die dauerhafte Verwendung einer alten ShellInABox-Version. Es hat auch seine Gründe, warum ich diese Dateien in den "modfs-Starter"-Archiven nie wieder aktualisiert habe, obwohl die IIRC statisch gegen die OpenSSL-Libraries gelinkt waren und vermutlich schon länger eine "Frischzellenkur" vertragen könnten.

Das war die "kurze Version" ... die lange steht bestimmt auch irgendwo schon in einem Thread hier.
 
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

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

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