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

PeterPawn

IPPF-Urgestein
Mitglied seit
10 Mai 2006
Beiträge
13,041
Punkte für Reaktionen
991
Punkte
113
Das habe ich noch nicht probiert ... ich schaue es mir aber gerne mal an.

Hast Du zufällig noch ein Protokoll (aus "showshringbuf modfs") von einem solchen Versuch, der abstürzt? Es geht mir in erster Linie darum, dieselben Bedingungen wie beim Absturz reproduzieren zu können und die Angaben zum freien Platz in den gemounteten Partitionen zu sehen.
 

Chatty

Aktives Mitglied
Mitglied seit
13 Mrz 2006
Beiträge
1,737
Punkte für Reaktionen
29
Punkte
48
Weiter zum 7.19-Problem geht es hier (Workaround inklusive).
 

PeterPawn

IPPF-Urgestein
Mitglied seit
10 Mai 2006
Beiträge
13,041
Punkte für Reaktionen
991
Punkte
113
Ich finde das Problem beim Entpacken nicht und dem Protokoll nach, hat Dein "sed"-Kommando gar nichts am "modfs"-Skript geändert und es hat trotzdem - auch mit 134 MB in den beiden Werten, die Du auf 144 MB ändern wolltest - funktioniert.

Woher das "date"-Problem beim Bootmanager am Ende kommt, untersuche ich gerade - aber auch mit mäßigem Erfolg, was eine vernünftige Erklärung angeht. Vielleicht können ja andere Benutzer von "modfs" beim nächsten Mal in der Protokoll-Datei nachsehen, ob bei ihnen das Löschen des Bootmanager-Caches (wenn der im laufenden System installiert sein sollte) funktioniert oder nicht.

Wie im GitHub geschrieben, verstehe ich gar nicht, wie da ein "'date' command not found" bei herauskommen kann - ich habe noch kein System gesehen, wo das Applet nicht in der BusyBox war. Und selbst mit einem vollkommen leeren Environment sollte sich das noch aufrufen lassen, denn der Loader des Kernels sucht (quasi als letzte Instanz) auch immer noch einmal in "/bin", wenn er ein Kommando nicht finden kann - das geht sogar soweit, daß er das notfalls auch ein zweites Mal durchsucht, selbst wenn es zuvor schon in der PATH-Variablen angeführt war. Wobei das mein alter Stand ist, das überprüfe ich gleich noch einmal - steht irgendwo in den Kernel-Quellen in "fs/exec.c".

Zwar wird beim Aufruf der zweiten Shell-Instanz (absichtlich) PATH ausschließlich auf das Verzeichnis mit der zu verwendenden BusyBox eingestellt (https://github.com/PeterPawn/modfs/blob/master/modfs#L2794), aber das dient ja genau dazu, keine Applets/Kommandos/Skriptdateien mit abweichender Syntax aus Versehen aufzurufen. Vielleicht sollte ich das "gui_bootmanager"-Skript auch explizit über die aktuelle BusyBox-Shell aufrufen, damit das dann auch definitiv die statisch gelinkte Version verwendet ... wobei das Entscheidende ja nicht das statische Linken ist, sondern die Suche nach Applets, bevor es im Dateisystem mit der Suche weitergeht - und dabei sollte das "date"-Applet ja dann auch gefunden werden.

=============================================================================

EDIT:

Also mit der Version, die bisher nur im Branch "beta" im Repo steht (die ist also noch nicht als TAR-File verfügbar), kriege ich zwar auch einen Fehler beim Packen (und nicht beim Entpacken), aber der ist dadurch zu erklären, daß das neue Image inzwischen deutlich größer ist und damit mein eigenes "custom.custom"-Image, das in die Wrapper-Partition kopiert wurde (und zwar vor dem gepackten Root-Dateisystem, weil das schon zuvor durch "ATW" (add to wrapper) erfolgte), nicht mehr ausreichend Platz für das neue Image übrig läßt.

Das ist aber nur ein "Zwischenstand" ... ich lasse jetzt das Kopieren dieser Datei in die Wrapper-Partition mal aus und habe dann 16 MB mehr zur Verfügung. Ich gehe mal davon aus, daß das bei Dir (@Chatty) nicht auch das Problem war, denn ich hatte das als "Entpacken klappt nicht" verstanden und mein Problem taucht erst dann auf, wenn das fertig gepackte SquashFS-Image in die Zielpartition kopiert werden soll.

=============================================================================

EDIT2:

Also ich finde kein Problem beim Auspacken ... und ich bin absichtlich (unter "Zerstörung" der Release-Version in der anderen Partition) von einer früheren Labor-Version auf die 75160 gewechselt.

Zwar ist das AVM-Image tatsächlich außergewöhnlich groß nach dem Entpacken, weil die Dateien für die internationale und die (bisherige) deutsche Version natürlich für jedes Branding (1und1, avm, avme) einmal vorliegen und zunächst mal auch doppelt entpackt werden müssen, so daß aus der gepackten Datei "filesystem_core.squashfs" mit einer Größe von 29 MB am Ende ein Verzeichnis mit Dateien in einer Gesamtgröße von 139 MB wird. Beim späteren Packen werden dann Duplikate aber wieder automatisch zusammengefaßt und bei mir hat das produzierte RootFS-Image dann wieder eine ähnliche Größe, wie das AVM-Original.

Ich werde die Größen für die Prüfung des freien Speicherplatzes trotzdem vorerst nicht anpassen ... bei älteren Versionen reicht ja weniger freier Platz auch noch aus und ich kann/will jetzt nicht alles wegen der 07.19 umwerfen. Solange man selbst dafür sorgt, daß ausreichend Speicher im verwendeten Arbeitsverzeichnis zur Verfügung steht (notfalls setzt man eben "MODFS_WORKING_DIR" von Hand schon passend, das spart auch die Nachfrage nach dem zu verwendenden Volume, wenn es mehrere geben sollte), gibt es auch kein Problem beim Entpacken oder beim späteren Packen.

Mir fällt im Moment kein zuverlässiger Weg ein, die notwendigen Größen irgendwie "zu berechnen" ... man könnte höchstens die Größen aller Dateien aus einem "unsquashfs -lls" zusammenrechnen und dann noch die Inodes zählen, um den ungefähren Platzbedarf des entpackten Images zu ermitteln. Dazu kommen dann - je nach Modus - noch die Wrapper-Partition, der Kernel oder sogar das Download-Image ... auch wenn ich jetzt schon temporäre Dateien schnellstmöglich löschen lasse, sind das jede Menge Permutationen, die da zu berücksichtigen wären. Da fehlt mir im Moment irgendwie der Antrieb ... der funktionierende(!) Workaround ist halt die Bereitstellung von genug Platz durch den Verwender.

Ich könnte das jetzt gleich auf 256 MB hochdrehen und hoffen, daß das eine Weile reicht ... andererseits sollten (bei "update" oder "update <source_image>" beim Aufruf) normalerweise 134 MB für das Arbeitsverzeichnis gefordert werden und die sollte niemand auf seiner 7490 ohne Probleme im "tmpfs" frei haben (bei kleineren Modellen erst recht nicht, vielleicht gibt's noch bei der 3490 ein Problem, weil die weniger Features hat - die hat aber wieder keine Labor-Version) und die Benutzung des NAS-Flashs erfordert zusätzliche Environment-Settings beim Aufruf und ist ebenfalls eher "expert mode", wo man sich selbst zu helfen wissen sollte.

Solange man also dafür sorgt, daß die eigene Box genug freien Speicher auf einem nativen Linux-Dateisystem zur Verfügung hat, sollte sowohl das Entpacken als auch das Modifizieren und das spätere Packen nicht mit Speicherplatzproblemen zu kämpfen haben.

Ich packe die neue Beta jetzt noch nicht zusammen, weil ich erst noch die "modscripts" so weit anpassen will, daß die auch für 07.19 funktionieren ... einige sehen zwar gut aus, aber andere brauchen definitiv eine Anpassung an die neue OS-Struktur und dazu muß ich die jeweilige Version erst mal auf meiner Box laufen lassen, um die passenden Änderungen testen zu können.

Ich habe mal das Log meines Versuchs mit der "0.6.0-beta" (noch ohne Timestamp, weil die erst bei Einchecken gesetzt wurde) angehangen ... so ähnlich sollte das bei anderen "modfs"-Nutzern halt auch aussehen.
 

Anhänge

kami23

Neuer User
Mitglied seit
1 Jan 2007
Beiträge
88
Punkte für Reaktionen
0
Punkte
6
Hallo zusammen,

ich habe gerade von meiner alten 7490 mit modfs umgestellt auf die 7590. Ich habe dort auch den telnetd aktiviert bekommen. Nun habe ich schon gelesen, das es noch keinen offiziellen Support von modfs für die 7590 gibt.
Ich wollte hier aber trotzdem mal fragen ob schon jemand folgende Mods für die 7590 umgesetzt hat:

  • edit_rcuser
  • mod_default_show_mac
  • mod_enable_calllog
  • mod_show_vpn_on_overview

Ich wäre für jede Hilfe dankbar.

Gruß kami23
 

PeterPawn

IPPF-Urgestein
Mitglied seit
10 Mai 2006
Beiträge
13,041
Punkte für Reaktionen
991
Punkte
113
Keine Antwort möglich, Cloudflare blockiert alles.

Die Antwort, welche ich eigentlich geben wollte, kann man hier nachlesen: http://www.yourfritz.de/www.ip-phone-forum.de_post-2361612.txt

Cloudflare läßt mich diesen Inhalt weder direkt in einer Antwort senden, noch wird diese Datei - in exakt dieser Form, nur mit einem anderen Namen - als Attachment hier akzeptiert:
blocked_attachment.PNG

Weiteres dazu, habe ich hier: https://www.ip-phone-forum.de/threads/blockaden-durch-cloudflare.306200/ mal niedergeschrieben, weil es inhaltlich mit "modfs" nichts mehr zu tun hat.
 
Zuletzt bearbeitet:

kami23

Neuer User
Mitglied seit
1 Jan 2007
Beiträge
88
Punkte für Reaktionen
0
Punkte
6
Hey PeterPawn,

danke für die Antwort. Ich weiß auch ganz genau was ich tun will aber mir ist gerade die Anpassung für edit_rcuser etwas unklar. Was macht da dein Skript genau? und du hast recht die ganze Prechecks und postchecks brauche ich nicht ich muss nur wissen, was direkt am Image geändert wird entsprechend wie bei der aktivierung von telnetd auch. da sind es ja eigentlich auch nur 2 Änderungen (ln-s auf busybox und /etc/init.d/S85_...)

Danke und schönen Abend.

Gruß kami23
 

PeterPawn

IPPF-Urgestein
Mitglied seit
10 Mai 2006
Beiträge
13,041
Punkte für Reaktionen
991
Punkte
113
Ich verstehe die Frage eigentlich nicht wirklich ... was "edit_rcuser" macht bzw. genauer, was das "modscript" macht, steht hier: https://www.ip-phone-forum.de/threads/modfs-squashfs-image-avm-firmware-ändern-für-nand-basierte-fritz-boxen.273304/post-2037875 und wenn man sich fragt, was das wohl sein mag, mit den dort erwähnten "Besonderheiten" bei der Bearbeitung von Dateien aus dem TFFS, ist das ja eine gänzlich andere Frage (die aber auch vielfach ventiliert wurde ... hier im Thread und im gesamten IPPF).

Und so erzeugt das "modscript" mit dem Namen "edit_rcuser" dann am Ende auch nur die (zusätzliche) Datei mit dem Shell-Skript, das sich um die Kommandos "rundherum" um die Bearbeitung des TFFS-Nodes mit der Minor-ID 98 kümmert ... und auch erst mal ermittelt, ob überhaupt ein weiterer Schreibzugriff erforderlich ist, weil sich der Dateiinhalt tatsächlich änderte. Das ist es letztlich auch, was dieses Skript von dem "nvi" von AVM unterscheidet ... der Benutzer muß sich nicht um die Minor-ID oder einen Inode für das passende Char-Device kümmern und es werden nur dann neue Daten geschrieben, wenn sich der neue Inhalt auch tatsächlich vom bereits vorhandenen unterscheidet.

Letztlich ist dieses Skript nur deshalb entstanden, weil es immer wieder Leute gab, die beim Editieren der Datei Fehler machten (und zwar viele verschiedene) und dann am Ende nicht etwa die Schlußfolgerung ziehen wollten, daß sie die Änderungen wohl nicht korrekt gespeichert hätten, sondern den Grund für das "Versagen" beim Patch zur Verarbeitung des Inhalts dieser Datei (rc.user oder auch debug.cfg) suchen wollten.

Aus genau diesem Grunde schreibt das "modscript" mit dem Namen "mod__rc_tail_sh", das genau diese Verarbeitung wieder in die Firmware hineinpatcht, auch einfach ein Kommando zur Erzeugung eines Eintrags im Event-Log in diesen TFFS-Node, wenn der zum Zeitpunkt der Abarbeitung des Skripts noch leer(!) ist ... ungeachtet der Tatsache, daß damit (fälschlicherweise) impliziert wird, daß das gerade von "modfs" bearbeitete System auch tatsächlich das Ziel für die Modifikationen bzw. das modifizierte SquashFS-Image wäre (was ja häufig der Fall, aber keineswegs zwingend ist).

Das ist dann auch eines der Skripte, die eigentlich davon ausgehen, auf einer FRITZ!Box zu arbeiten und bei denen man - wenn man das außerhalb macht - noch ein paar Änderungen vornehmen muß. Andererseits steht dieser Teil dann eben auch absichtlich im "postcheck"-Abschnitt ... denn da ist die Installation bereits vorbei und das einzige Ergebnis, wenn dieser Teil noch fehlschlagen sollte, ist dann eben weiterhin eine leere Datei (bzw. ein leerer TFFS-Node) auf dem System - wenn man "postcheck" überhaupt machen läßt (was eben auch nicht immer sinnvoll ist, s.o.).

Irgendwo habe ich auch noch ein Makro (bzw. eine Funktion in der "scriptlib", die ggf. auch bei sehr alten Versionen nicht richtig funktioniert, wenn die noch kein passendes Environment vorweisen können), welche(s) erst einmal prüft, ob man gerade auf einer FRITZ!Box ist oder nicht ... damit kann man solche Aufrufe auch von diesem Test abhängig machen.
 

kami23

Neuer User
Mitglied seit
1 Jan 2007
Beiträge
88
Punkte für Reaktionen
0
Punkte
6
Hi PeterPawn,

danke für deine Erläuterung habe es verstanden und mir selber ein Start-Shell-Skript gebaut. Klappt super und habe jetzt meine Funktion erreicht. Vielen Dank und schönes WE.

Gruß kami23
 

topversand

Neuer User
Mitglied seit
3 Mrz 2013
Beiträge
17
Punkte für Reaktionen
0
Punkte
3
Hi,
wann kann man mit modfs(aktualisierte Modscripts) für OS 7,19 rechnen?
 

PeterPawn

IPPF-Urgestein
Mitglied seit
10 Mai 2006
Beiträge
13,041
Punkte für Reaktionen
991
Punkte
113
Ich sage mal: "Wenn die 07.2x als Release-Version erschienen ist."

Warum so spät?

Weil es doch auch für die verschiedenen "modscripts" einige weitreichende Änderungen braucht (das reine Auspacken, Ändern, Einpacken funktioniert ja auch im Moment schon für die 07.19, solange man es nicht gerade auf einer solchen Version auch ausführen will - mit Updates von 07.19 zu weiteren 07.19-Versionen könnte es also noch Probleme geben, wobei die Tools dafür eigentlich auch alle statisch gelinkt sind und die älteren Versionen funktionieren sollten auf dem neueren Kernel), fehlt mir so ein wenig der "innere Antrieb", das schon zu einer Zeit in Angriff zu nehmen, wo noch niemand sich sicher sein kann, daß es "das jetzt war" mit diesen (größeren) Umstellungen. Das geht wohl auch Freetz so, denn da sind (afaik) auch keine Aktivitäten in dieser Richtung zu sehen im Moment.

Auch das Verwenden von "modfs" auf einer 07.19 (bzw. späteren Versionen) selbst, möchte ich natürlich dann gleich in einem Aufwasch mitmachen und dazu braucht es wieder die passenden Tools (mit der richtigen Toolchain kompiliert), solange man die nicht statisch linkt.

Ich habe z.B. bei der 07.19 das Problem, daß meine eigenen, bisher verwendeten Zusatzpakete (die ich über E99-custom eingebunden hatte, was man auch "von Hand" aufrufen kann nach einem Reboot, solange es nicht in den Startablauf des FRITZ!OS eingebaut ist) gegen die Wand fahren, weil sie ihrerseits noch weitere Bibliotheken in "/var/custom/lib" bereitstellen und dieses Verzeichnis in der Suchreihenfolge vor die Bibliotheken aus dem FRITZ!OS stellen (über LD_LIBRARY_PATH).

Finden jetzt AVM-Programme, die ich aus so einer Sitzung aufrufe, dann die alten Bibliotheken (1.0.14) vor den neuen in "/lib" (1.0.31), passen die Relokation-Infos in den Binaries nicht mehr so richtig und die AVM-Programme verabschieden sich mit einem "segmentation fault". Ich brauche also auch erst einmal passende eigene Erweiterungs-Images, damit ich überhaupt die eigenen Shell-Sessions auf der Box ausführen kann, die wieder notwendig sind, um die Änderungen an den AVM-Dateien auszuführen und zu testen, bevor man sie in die Form einer automatischen Änderung (aka "modscript") gießt.

===========================================================================================

Andererseits ist das tatsächlich auch ein wenig eigene Faulheit (die C-Library und die Kernel-Quellen habe ich hier tatsächlich schon vor ca. 4 Wochen auf einem Rechner ausgetauscht - nur ist der beim Bau der Toolchain komplett gestorben (Hardware) und ich konnte mich noch nicht zum Ersatz entschließen bzw. zum Um-/Ausbau der SSD mit den Daten), weil ich - dank vieler anderer, die wg. Covid-19 daheim sitzen und sich langweilen - mich zu leicht ablenken und für anderes (z.B. Online-Games) begeistern lasse (wann hat man dazu schon mal dieselben Gelegenheiten, wie in dieser Zeit), wenn da Anfragen kommen. Und wie das aussieht, bei geschlossenen Schulen und Universitäten, kann sich ja jeder ausmalen ... da geht die große, graue Langeweile um bei manchem. Auch wenn das nach "Schuldzuweisung an andere" klingt ... das ist nun mal so, daß ich da einfach GEZWUNGEN werde, mich ablenken zu lassen. :cool:

===========================================================================================
 

topversand

Neuer User
Mitglied seit
3 Mrz 2013
Beiträge
17
Punkte für Reaktionen
0
Punkte
3
Danke für die Info.
Ich hatte es mal mit der 7.19 probiert und mir war aufgefallen das die Daten aus RCuser nicht übernommen wurden und die Neustartseite nur als Original vorhanden ist. Sonst lief es durch.
 

PeterPawn

IPPF-Urgestein
Mitglied seit
10 Mai 2006
Beiträge
13,041
Punkte für Reaktionen
991
Punkte
113
die Neustartseite nur als Original vorhanden ist.
DAS ist mir wieder noch gar nicht aufgefallen - da schaue ich dann (außer der Reihe, weil das eher unter "boot manager" läuft, denn unter "modfs") nachher doch noch einmal direkt nach.

Ich weiß im Moment nur, daß 07.19 richtig erkannt wird, wenn es in der alternativen Partition liegt:
bm-07.12.PNG
und ich teste gleich mal, wie das aussieht, wenn die Box aus der anderen Partition (also mit der (schon älteren) 07.19) gestartet wurde.

EDIT 1: Stimmt, ist bei mir derzeit auch so. Einige der Patches haben wohl geklappt (zumindest in der "reboot.lua", wo bei mir die Zeichenkette "gui_bootmanager" vorkommt in der modifizierten Firmware), einige andere (wohl die in der "reboot.js") hingegen nicht, damit fehlen die notwendigen JSON-Daten. Ich schaue es mir an, weil das auch auf anderen Boxen wichtig ist - nur meine Testbox schalte ich häufiger mal per Serieller um und da merke ich das dann nicht.
 
Zuletzt bearbeitet:

BurningCrash

Aktives Mitglied
Mitglied seit
21 Jun 2007
Beiträge
1,757
Punkte für Reaktionen
0
Punkte
38
EDIT 1: Stimmt, ist bei mir derzeit auch so. Einige der Patches haben wohl geklappt (zumindest in der "reboot.lua", wo bei mir die Zeichenkette "gui_bootmanager" vorkommt in der modifizierten Firmware), einige andere (wohl die in der "reboot.js") hingegen nicht, damit fehlen die notwendigen JSON-Daten. Ich schaue es mir an, weil das auch auf anderen Boxen wichtig ist - nur meine Testbox schalte ich häufiger mal per Serieller um und da merke ich das dann nicht.
Wenn du noch Test-Objekte brauchst findet sich sicher was :)
 

PeterPawn

IPPF-Urgestein
Mitglied seit
10 Mai 2006
Beiträge
13,041
Punkte für Reaktionen
991
Punkte
113
Update:
Ich habe den Beitrag noch einmal überarbeitet (nach der Unterbrechung gestern wegen des neuen Formats in der Inhouse-Version) und hier kommt er jetzt "als Ganzes" und hoffentlich ohne die Notwendigkeit ständiger "Nachträge".

Die Änderungen haben jetzt auch alle Einzug in die Datei http://yourfritz.de/modfs-0.6.0-beta.tgz gehalten, wenn mir kein Fehler unterlaufen ist.

Ob AVM am Ende das Format der "filesystem.image" ändert oder nicht, stört "modfs" auch nicht weiter, solange das entweder das bisher (seit 06.35) genutzte "ext2"-Image mit Dummy-Header oder das früher benutzte SquashFS-Image (inzwischen halt mit SquashFS4-Format, aber das macht nichts) bleibt. Ich habe das jedenfalls auch erfolgreich mit der Inhouse-Version 113.07.19-77415 getestet - wobei die Patches in erster Linie gegen die 77201 geprüft wurden und u.U. ganz aktuelle Änderungen da noch ein Problem sein könnten.

Da der Kernel der 7490 unverändert 3.10.107 ist und die von "modfs" verwendete BusyBox ohnehin statisch gelinkt wurde (somit die verwendete uClibc-ng nicht relevant ist), gibt es für die 07.19 bei der 7490 auch keine neuen Binaries im Rahmen von "modfs" - das ist im Moment ja die einzige Box, die von "modfs" unterstützt wird und in der Labor-Reihe "bedient" wird von AVM.

Gibt es innerhalb von ca. einer Woche keine (negativen) Rückmeldungen, gehe ich davon aus, daß es entweder keine Probleme gibt oder kein Interesse mehr - in beiden Fällen würde ich den Beta-Status dann aufheben, sagen wir mal spätestens zum 01. Mai 2020.

=====================================================================

Enthaltene Modifikationen und erfolgte/notwendige Änderungen

contrib/modscripts/mod_multiple_fax_pages
- nicht von mir, sondern als Pull-Request über's Repo hinzugekommen: https://github.com/PeterPawn/modfs/pull/30 - auch nicht von mir getestet, hält leider erst jetzt mit der nächsten Version auch Einzug in das von mir bereitgestellte "modfs.tgz" (bzw. die Beta-Datei oben) und stand bisher nur denjenigen zur Verfügung, die mit dem geklonten Repo arbeiten

copy_binaries - unverändert, wird demnächst aber noch ersetzt, weil die Kombinationen aus HWRevision, Kernel-Version (die sind bisher schon im Dateinamen berücksichtigt) und C-Library immer weiter "ausfransen" ... ich denke über eine neue Struktur beim Hinzufügen von Dateien auf diesem Wege nach

edit_rcuser - unverändert, es gibt keinen Grund, warum das nicht länger funktionieren sollte

gui_boot_manager_v0.6 - angepaßt an die neuen "Anker" in den JS- und Lua-Files der 07.19, ein paar Regressionstests bis zurück zur 06.86 für die 7412 habe ich gemacht (06.86, 07.12, 07.19)
07.19-inhouse-vs-labor.PNG

mod_default_show_mac - unverändert, funktioniert auch bei 07.19 noch

mod_enable_calllog - die "versteckten" Funktionen sind auch weiterhin verfügbar, wenn "CONFIG_RELEASE=0" gesetzt wird beim Start des "telefon"-Daemons, daher sind hier keine Änderungen notwendig; auch die Abarbeitung der "calllog"-Kommandos erfolgt noch bei eingehenden Anrufen

mod_exec_on_nand - wurde um die Änderung an zwei Stellen erweitert; in den Dateien "/etc/boot.d/ubi_functions" bzw. "/etc/boot.d/yaffs_functions" gibt es ab 07.19 jeweils eine zusätzliche Zeile, wo für den internen Speicher "noexec" festgelegt wird ... das wird ebenfalls auf "exec" geändert, die Kommentarzeile darüber ist dann zwar falsch, aber das ignoriere ich (auch wenn die VR9-Modelle nur YAFFS2 verwenden, wird die Stelle für UBIFS gleich mitgeändert, was dann bei GRX-Boxen wichtig wird, wenn jemand den Patch auf ein solches entpacktes Dateisystem anwenden wollte)

mod_exec_on_usb - unverändert, funktioniert auch mit der neuen Labor-Reihe wie bisher ... aus gegebenem Anlaß noch einmal der Hinweis, daß damit für Volumes mit NTFS- oder FAT-Format (wo die x-Flags ohnehin nicht pro Datei existieren, sondern für den gesamten Mountpoint gelten) absichtlich nichts geändert wird

mod_fixed_branding - unverändert

mod_led_display - war schon seit 07.08 nicht mehr erforderlich, erkennt beim "precheck", ob es eine Version vor sich hat, bei der "led_display.lua" nicht im Menü verlinkt ist ... ob man ggf. die Funktion für das "LED-Anzeige verzögert ausschalten" wieder in die "led_display.lua" einbaut, muß ich mir mal bei Gelegenheit ansehen - so wichtig ist das wohl auch nicht bzw. es wird kaum einer nutzen

mod_mount_by_label - unverändert, anstelle der Auswertung der "usb.cfg", ob die Einstellung gesetzt ist (was beim Zurücksetzen auf Werkseinstellungen ab einer bestimmten Version der Fall wäre), wird hier fest auf "yes" (also Mounten unter dem Volume-Label) gesetzt

mod_multi_annex - unverändert; das ist zwar seit 07.19 (nicht ab der ersten, aber ziemlich am Beginn) nicht mehr erforderlich (weil AVM das mittlerweile nicht mehr ausschaltet), aber das Skript erkennt das auch und behandelt es dann korrekt

mod_night - geändert; die bisher verwendete Datei "system/nacht.lua" existiert ab 07.19 nicht mehr, daher wurde diese Modifikation auf Versionen davor begrenzt

mod_no_tainted_message - unverändert

mod_ntp_on_ip_client - unverändert, minimale Anpassung beim Patch (ein Leerzeichen weniger in 07.19)

mod_prefer_fonnumber_name - unverändert

mod_profile - unverändert

mod_rc_tail_sh - geändert; bei der neuen Startreihenfolge wird die Abarbeitung der eigenen Kommandos an die Datei "/etc/boot.d/core/tail" angehangen (nach wie vor über "delay" und damit "detached" zum Rest der Initialisierung) geändert, siehe https://www.ip-phone-forum.de/threads/modfs-squashfs-image-avm-firmware-ändern-für-nand-basierte-fritz-boxen.273304/post-2366717

mod_remove_avm_vpn_from_overview - unverändert, funktioniert auch mit 07.19 noch

mod_show_name - geändert, aber nur hinsichtlich der leicht verschobenen/geänderten Stelle für den Patch

mod_show_vpn_on_overview - unverändert, kompaktere Darstellung als im AVM-Code, gerade bei vielen VPN-Verbindungen (mit "mod_remove_avm_vpn_from_overview" gemeinsam verwenden)

mod_swapoff - unverändert

mod_telnet_enable - unverändert, zusätzlich zum Link für den Daemon wird auch die Datei "/usr/bin/system_status" geändert, so daß bei deren Abruf über "http://fritz.box/cgi-bin/system_status" der "telefon"-Daemon neu gestartet wird, wenn (a) das Flags für den Telnet-Service gesetzt ist (dafür ist der Telefon-Code da, deshalb funktioniert das auch nur, wenn parallel "mod_enable_calllog" verwendet wird oder etwas Adäquates, was die Funktionen im "telefon"-Daemon reaktiviert) und (b) der Telnet-Daemon trotzdem nicht läuft - beim Neustart des "telefon"-Daemons (Achtung, laufende Gespräche werden abgebrochen, wenn der Neustart erforderlich ist) wird dann der Telnet-Service mitgestartet - das ist ein Workaround für das Problem des "telefon"-Daemons, daß der keinen erneuten Start des "telnetd" zuläßt, wenn dieser zuvor von derselben "telefon"-Instanz gestoppt wurde

mod_volatile_nas_dir - geändert, bei neuen Versionen wird das Mount-Kommando für das Verzeichnis an der richtigen Stelle (/etc/boot.d/core/files) eingefügt

mod_xchg_sort_icons - unverändert, ist ohnehin nur für ältere Versionen relevant und behandelt das im "precheck" richtig

mod_yourfritz_key - unverändert

=====================================================================

Was von mir noch nicht angepaßt wurde, ist die "E99-custom", die in "files" liegt. Wer die benutzen will, muß ja ohnehin noch einiges andere selbst organisieren ... dazu gehört dann jetzt auch der "Einschluß" des Aufrufs für dieses Skript dazu. Mein Vorschlag wäre es z.B., daß man sich dafür einen zusätzlichen Service in "/lib/systemd/system" anlegt, in etwa mit dieser Definitionsdatei:
Code:
[Unit]
ExecStart=/bin/sh /etc/init.d/E99-custom
Type=oneshot
After=debug.service
DefaultDependencies=no
[Install]
WantedBy=sysinit.target
- wobei man dann natürlich dafür sorgen muß, daß auch die "E99-custom" am richtigen Ort landet, ebenso wie die Images, die man als Erweiterungen mounten will. Nennt man den Service dann auch noch "/lib/systemd/system/custom.service", sind alle "Unklarheiten" hinsichtlich seiner Bedeutung ebenfalls beseitigt.

=====================================================================

Man muß seit 07.19 halt bei der Nutzung des "/wrapper"-Verzeichnisses als Zusatz-Speicher beachten, daß die "filesystem_core.squashfs" deutlich größer geworden ist ... das verringert nicht nur den Platz, den man für eigene Erweiterungsimages dort nutzen kann, es erhöht auch die Zeit, welche die Box zum Zusammenpacken des SquashFS-Images braucht, sehr deutlich (bei mir auf der 7490 mit drehenden Platten auf 08:30 min) - und wer bisher noch versucht hat, das auch ohne Swap-Space auf USB-Datenträgern in den Griff zu kriegen (es gibt ja ein paar Settings für die ganz Mutigen), der wird auch deutlich schneller Schiffbruch erleiden (bis hin zum Reboot bei "oom" oder "oom_pressure").

=====================================================================

Wegen der gestiegenen Größe der Firmware-Images seit 07.19, habe ich auch die Speicherplatzangaben in "modfs" deutlich nach oben korrigiert ... eine Ausführung mit "reinem NAS-Flash" wird damit eher nicht mehr funktionieren (nur die Puma-Geräte hätten bisher genug NAS-Speicher, um das darin abzuwickeln). Auch wenn man die Möglichkeit mit dem "ext3"-Image über das Loop-Device eigentlich nicht mehr nutzen sollte (damit kann ja auf einem Dateisystem, was keine Linux-Flags versteht, auch entpackt und neu gepackt werden), habe ich das mal auf ein 256 MB-Image erweitert.

Mit einem passenden USB-Stick (inkl. Swap-Partition und ext2/ext3/ext4 für die Daten - etwas anderes kennt dann das FRITZ!OS nicht unbedingt) sollte das jedenfalls auch weiterhin für 07.19 funktionieren ... eine Unterscheidung zwischen 07.19 und älteren Versionen hinsichtlich der Anforderungen an den bereitzustellenden Speicherplatz wollte ich jetzt nicht noch treffen, daher "leiden" eben die älteren Versionen und Boxen jetzt einfach mit.

=====================================================================

Das Repo bei GitHub ist - nebenbei bemerkt - noch nicht komplett aktualisiert ... da muß ich erst mal neu sortieren und ggf. auch mittels "rebase" zusammenfassen. Wenn die Commits fertig sind auf meinem lokalen Repo, erfolgt die Veröffentlichung auf GitHub dann auch - das sieht man dann dort ja relativ leicht.

=====================================================================

EDIT: Na toll, das erste Problem habe ich schon gefunden ... zwar wird in der "/etc/boot.d/core/tail" die Datei für die "rc.user" ordentlich angelegt (das Kommando also abgearbeitet), aber offenbar ist zu diesem Zeitpunkt beim Start der "multid" noch nicht bereit, über den dieser verzögerte Start als unabhängiger Prozess mit dem "delay" dann laufen sollte. Das war mir entgangen (weil ich die Datei ja nicht wirklich nutze, wenn ich "E99-custom" habe), da ich da nur das "eventadd" drin stehen habe und das fehlte am Ende im Event-Log.
 
Zuletzt bearbeitet:
  • Like
Reaktionen: eisbaerin

eisbaerin

IPPF-Promi
Mitglied seit
29 Sep 2009
Beiträge
7,807
Punkte für Reaktionen
341
Punkte
83
Ich schreibe mal einen Zwischentext, damit du weiter schreiben kannst. ;)
Danke für die Auflistung der modscripts!

Wird modfs irgendwann auch für die GRX Modelle freigegeben?
Intern sieht man ja schon lange Vorbereitungungen darauf...

Nach den IPQ Modellen traue ich mir ja schon gar nicht zu fragen.
 
Zuletzt bearbeitet:

PeterPawn

IPPF-Urgestein
Mitglied seit
10 Mai 2006
Beiträge
13,041
Punkte für Reaktionen
991
Punkte
113
Nein, es wird kein "klassisches" "modfs" für GRX-Boxen geben (jedenfalls nicht von mir), auch nicht für Vx180-, Puma6- oder IPQ-SoCs.

Das heißt nicht, daß ich die komplett vergesse oder vergessen habe ... das Vorgehen, was "modfs" benutzt, macht auf diesen Boxen keinen rechten Sinn - dabei bleibe ich.

Am Ende lassen sich alle Modifikationen, die ich bisher für die Boxen veröffentlicht habe, auf die folgenden, grundlegenden Schritte reduzieren und das auch noch unabhängig davon, auf welchem System (FRITZ!Box oder nicht) sie ausgeführt werden:
  1. Erkennen des Format und Ermitteln der Parameter für den späteren "Zusammenbau"
  2. Zerlegen der Firmware in die verschiedenen Teile (Kernel, Dateisystem (entpackt natürlich) und ggf. "Wrapper")
  3. Vornehmen von Änderungen
  4. Zusammenpacken der neuen Firmware (je nach Modell)
  5. Installation der Änderungen
Nur der Schritt 3 mit den jeweiligen Änderungen unterscheidet sich bei den verschiedenen Anwendungsfällen - der Rest rundherum ist praktisch immer derselbe.

Wenn die Schritte 1, 2, 4 und 5 wirklich "fertig" sind bzw. einen Stand erreicht haben, den ich mit anderen teilen möchte, werden die natürlich auch veröffentlicht - nur wird das dann mit "modfs" nicht länger etwas zu tun haben und dieses "Projekt" wird dann leise sterben ... weil das andere alles das ebenfalls leisten kann, was bisher in "modfs" alles in einem großen Klumpen zusammengefaßt wurde.

========================================================================

Nur gibt es immer wieder ein paar Überraschungen, was das Auftauchen neuer Formate bei AVM angeht - das geht bei der Erkennung, welche C-Library da eigentlich verwendet wird, schon los und zieht sich über die Firmware für Repeater (hier konkret der 546E, wo das Entpacken bzw. automatische Erkennen aller Parameter derzeit noch scheitert, wie ich erst vor ein paar Tagen bemerkt habe) bis hin zur neuesten Form bei der 7490 mit der akt. Inhouse-Version. Hier gibt es immer dann, wenn ich der Ansicht bin, es wäre langsam fertig, wieder neue Überraschungen - bis hin zu fehlenden Kommandos auf einer Plattform, denn bei AVM gibt es in der Firmware (und damit auf der Plattform "FRITZ!Box") nicht mal ein "strings"-Kommando in der BusyBox.

Das ist also tatsächlich alles nicht so einfach und ich habe mich - anhand einiger Erfahrungen, die ich zuvor machen mußte - auch dazu entschlossen, das nicht mehr "stückweise" zu veröffentlichen, wenn ich denke, daß ein Teil jetzt "fertig" wäre. Erstens gibt es immer wieder Änderungen, weil eben auch AVM die Entwicklung nicht einstellt und zweitens will ich das erst dann wirklich freigeben, wenn es halbwegs "rund" läuft und andere damit auch etwas anzufangen wissen, denn "Meckereien" gibt und gab es schon genug und mehr davon brauche ich nicht wirklich.

Da ist dann jedenfalls wieder der Teil, bei dem die eigentlichen Veränderungen an der Firmware vorgenommen werden, derjenige, der auf die Angebote eines "Frameworks" zurückgreifen kann/sollte - das erspart es, für jede mögliche Änderung an der Firmware auch diesen ganzen Aufwand jedesmal erneut umzusetzen.

Schon wenn man sich die Skripte aus "toolbox" ansieht, merkt man ja, daß die alles selbst enthalten, was für das Erstellen der Images erforderlich ist und das eben auch in jedem einzelnen Skript - der entscheidende Unterschied ist nur, was die jeweils in das neue Image einbauen.

Das kann man also auch zusammenfassen und dann muß man es (a) nicht immer neu machen und (b) bei Änderungen durch AVM nicht an mehreren Stellen Anpassungen vornehmen - das sind ja die Vorteile einer "Modularisierung".

========================================================================

Der Monolith, als der "modfs" heute daherkommt, war vielleicht notwendig, damit es überhaupt Leute gab, die sich damit befaßt und es benutzt haben ... den Ausgangspunkt des Ganzen, der aus einzelnen Skripten bestand, die man selbst nacheinander aufrufen mußte, haben viele ja gar nicht mehr auf dem Schirm.

Der war also eigentlich schon modularisiert und es war (im Nachhinein betrachtet) wohl auch ein Fehler, diese Aufsplittung in einzelne Skript-Dateien mit spezialisierten Aufgaben nicht in "modfs" zu übernehmen ... das machte dann natürlich (im ersten Schritt zumindest) die Handhabung auch für Benutzer leichter, wenn es nur ein Skript gab, was alles Wesentliche (mit Ausnahme der eigentlichen Modifikationen) enthielt und da keine weiteren Abhängigkeiten bestanden.

Die ganzen Dateien rundherum (bis hin zur passenden, statisch gelinkten BusyBox) kamen ja erst nach und nach wieder hinzu, als die unterstützten/getesteten Modelle zahlreicher wurden (und damit auch die BusyBox-Versionen von AVM, wo dann mal ein Kommando vorhanden war und es auf der nächsten Box (dem nächsten Modell) dann wieder fehlte) und man sich nicht mehr auf einen vorhandenen Umfang an Kommandos verlassen konnte.

Es wird jedenfalls kein "modfs" (von mir) geben für Modelle, die einen anderen Aufbau als die VR9-Boxen haben. Wenn das einer bauen will - bitte, es steht alles unter der GPLv2 bzw. GPLv3, was es dazu bräuchte. Die Teile, die ich noch nicht unter diese Lizenz gestellt habe (damit ich das erst mal in Ruhe selbst zu einem vorläufigen Ende bringen kann), braucht es für ein "modfs" für diese Boxen auch nicht.

========================================================================

Ich sehe jedenfalls nicht, wie das sinnvoll (ohne die Möglichkeit des Hinzufügens von SIAB, die ja bei anderen Modellen nicht so deutlich und einfach existiert) realisiert werden kann, daß eine FRITZ!Box (ohne weitere Modifikationen) dann "modfs" ausführt ... das braucht in jedem Falle zuvor schon ein passendes Image, was seinerseits einen Shell-Zugriff ermöglicht und wenn man das zusammenbaut und installiert, kann man auch gleich das "komplette System" dabei ändern.

Ich habe zwischendrin auch mal mit einem "Bootstrap-System" experimentiert, so wie es ja OpenWRT z.B. auch macht ... da wird ein (kleines) System auf die Box geladen und gestartet, mit dem man sich dann per SSH verbinden kann. In dieser Shell installiert man dann erst das eigentliche System (üblicherweise mit "sysupgrade"), wobei das bei OpenWRT dann eben auch jeweils fertige Images sind und die auch erst mal irgendjemand zusammengestellt haben muß (i.d.R. auf einem passenden Build-Host), damit man sie installieren kann.

Das ist bei einer FRITZ!Box auch nicht ganz so simpel ... denn auch wenn das vielleicht nicht direkt ins Auge sticht, so braucht das Extrahieren eines SquashFS-Images (aus der originalen Firmware von AVM) eben entsprechenden Speicherplatz und damit müßte man in so einem "Bootstrap-System", was dann seinerseits "modfs" ausführen soll (auch für andere Modelle als VR9), wenigstens bis zu einem funktionierenden USB-Stack kommen, damit man überhaupt irgendein Storage-Device für die Speicherung benutzen kann. Und das Einpacken eines SquashFS-Images braucht sogar "richtig viel" Hauptspeicher und da ist es schon hinderlich, wenn auch nur ein kleiner Teil davon durch das OS blockiert wird, das man aus dem Speicher gestartet hat.

Entweder man stoppelt sich den eigenen Kernel zurecht (und integriert da dann gleich alles, was es für USB bräuchte) oder man verwendet den AVM-Kernel und dann muß man wieder aufpassen, was man in das eigene System (wenn man das zum Download und zur Benutzung durch andere bereitstellen wollte) alles übernimmt - die AVM-eigenen Komponenten (Programme, Bibliotheken, etc.) sind an dieser Stelle dann tabu und so kriegt man (mit einem AVM-Kernel) nicht mal die LEDs der Box sauber zum Leuchten bzw. zum Anzeigen irgendwelcher "Zustände".

Damit ist die Idee mit dem "Bootstrap-System" auch schon wieder gestorben ...

========================================================================

Bei den anderen Modellen wird auch ein Format verwendet, wo die "filesystem.image" jeweils direkt ein SquashFS-Image ist und zwar auch gleich das mit dem "echten" Root-Filesystem. Da ist also das "Auspacken" deutlich einfacher als bei den VR9-Boxen (wo das Root-FS erst wieder im "Container" steckt, egal ob der nun SquashFS-Format oder "ext2" mit Dummy-Header benutzt) und auch das Erstellen des passenden (SquashFS-)Images braucht nur ein einzelnes Kommando - das sind schon erhebliche Unterschiede zum Aufbau der VR9-Modelle, wo das wieder schwerer "zu durchschauen" ist. Selbst die 7390- und 7270vX-Boxen waren da einfacher im Aufbau des Firmware-Images - auch wenn da der Kernel noch davor steht.

Das Einzige, was da also ggf. noch "sinnvoll" wäre aus meiner Warte, ist ein "Shell-Wrapper", der die Umgebung für den Aufruf der "modscript"-Dateien bereitstellt. Der muß dann auch nicht mehr unbedingt "interaktiv" sein (nicht umsonst war eine der ersten Erweiterungen von "modfs" die Möglichkeit, mit der "custom_modscripts"-Datei die Auswahl schon zuvor festzulegen und damit von den "Fragen" verschont zu bleiben) und dann bleibt da eigentlich kaum noch etwas an "Aufgaben" übrig, was so ein Skript als "Umgebung" für die "modscript"-Dateien leisten müßte. Sogar das "extract_version_values", mit dem man aus dem entpackten Verzeichnisbaum die Daten zur Firmware-Version u.ä. extrahieren kann, ist in beiden Repos (YourFritz + modfs) verfügbar.

Ich habe mich jetzt mal breitschlagen lassen und ein Beispiel für ein Skript eingecheckt (das findet sich auch im TGZ-File, das man von yourfritz.de laden kann - es heißt "run_modscripts"), was als ersten Parameter den Verzeichnisnamen der entpackten AVM-Firmware erwartet und dann ALLE "modscript"-Files, die es in "modscripts/*" findet, in alphabetischer Folge der Dateinamen auf die entpackte Struktur losläßt und zwar ohne Berücksichtigung irgendwelcher "precheck"- oder "postcheck"-Aktionen und auch ohne Ansicht der Person (aka "x-flags") oder einer event. vorhandenen "custom_modscripts"-Datei.

Das Skript erwartet, daß es sich in der üblichen Verzeichnisstruktur befindet, die beim Auspacken der TGZ-Datei von yourfritz.de oder beim Klonen des GitHub-Repos entstehen würde - und zusätzlich muß noch eine aktuelle "BusyBox"-Implementierung verfügbar sein (weil die BB-Kommandos teilweise andere Syntax verwenden, als die "großen Versionen") und über den Suchpfad gefunden werden. Für diese BusyBox wird dann ein Symlink unter "bin/000/busybox" angelegt und danach wird diese für die Applets in den "modscript"-Files verwendet.

Um das Entpacken und anschließende Packen muß man sich immer noch selbst kümmern ... wie gesagt: Das ist jeweils ein einzelnes Kommando (unsquashfs + mksquashfs) und auch das Zusammenkopieren von Kernel und Dateisystem, um eine Datei zu erhalten, die man in den Speicher der FRITZ!Box schreiben und starten lassen kann, ist nur ein zusätzliches Kommando (ggf. muß die TI-Prüfsumme vom Kernel entfernt werden).

Ich sehe nichts, was ansonsten für die oder auf den GRX-Boxen (gilt auch für IPQ und Puma, wobei für die IPQ-SoCs noch nicht mal die (ARM-)Binaries in "yf_bin" vorhanden wären) noch irgendeinen Sinn ergeben würde ... zumindest keinen, der eine weitergehende Automatisierung rechtfertigen würde. Die paar Kommandos notfalls auch noch zusammen in eine eigene Shell-Datei zu schreiben, halte ich für absolut zumutbar ... die Benutzung einer "debug.cfg" oder einer "rc.user" würde genau dieselben Fähigkeiten erfordern.

========================================================================

Und damit bin ich auch noch einmal bei mod_rc_tail_sh (bei anderen Änderungen habe ich bisher keine Fehler gefunden) ... nachdem sich dann herausstellte, daß "multid" (der als Voraussetzung für "delay" gestartet sein muß) erst wesentlich später im Initialisierungprozess mit dem "supervisor" an der Reihe wäre (und es somit auch keinen Sinn macht, in der "/etc/boot.d/core/tail" auf den Start des "multid" zu warten), habe ich das für 07.19 und darüber dann doch anders gelöst.

Jetzt werden die Kommandos zum Auslesen der "rc.user" und zum Start der Kommandos in dieser Datei in einem zusätzlichen Skript "/etc/boot.d/core/rcuser" abgelegt und dieses dann durch einen zusätzlichen Service für den "supervisor" gestartet, der erst nach dem Start von "net.service" (was den Start des "multid" ebenfalls beinhaltet) an der Reihe ist. Dort wird dann weiterhin der Inhalt der "debug.cfg"/"rc.user" über "delay" gestartet, somit ist das per se unabhängig von der Ausführung der "/etc/boot.d/core/rcuser" und wird bei deren Ende auch dann nicht abgeräumt, wenn man sich beim Starten von "detached processes" nicht so genau auskennt (wo dann gerne der gerade gestartete Prozess beim Ende des Elternprozesses ebenfalls wieder abgeräumt wird).

Außerdem habe ich gleich noch den Teil "entschärft", der ansonsten (bei Ausführung auf einer FRITZ!Box) bei bisher leerer "debug.cfg"/"rc.user" ein "eventadd"-Kommando eingefügt hatte, damit die "Bei mir wird da nichts gestartet ..."-Meldungen nicht länger irritieren. Jetzt kann man "mod_rc_tail_sh" auch außerhalb einer FRITZ!Box problemlos auf eine entpackte Verzeichnisstruktur loslassen.

========================================================================

Alles wieder eingecheckt und in die http://yourfritz.de/modfs-0.6.0-beta.tgz gepackt ... eine "Verlängerung" der Beta-Planung über den 01.05.2020 hinaus, halte ich aufgrund der jüngsten Änderungen nicht für erforderlich, solange niemand "schwere Fehler" findet. Und um auch das gleich noch festzuhalten ... "run_modscripts" ist nur ein Beispiel (wenn auch ein ziemlich ausführliches), wie man die Modifikationen auch auf anderen Systemen bzw. außerhalb einer FRITZ!Box benutzen kann ... das ist "ohne Support" bzw. ohne jeden Ehrgeiz, da irgendetwas "besser" machen zu wollen. Auch wenn ich das jetzt mal als Beispiel dazugepackt habe, will ich daraus kein zweites "modfs" machen.
 

topversand

Neuer User
Mitglied seit
3 Mrz 2013
Beiträge
17
Punkte für Reaktionen
0
Punkte
3
habe gerade die letzte Fritz 7.19 Labor mit modfs-0.6.0-beta installiert.
lief alles super durch und es scheint alles zu funktionieren.
Super!
Kann man den Eintrag auf der Startseite "nicht empfohlene Einstellungen" irgendwie löschen oder ausblenden?
 

PeterPawn

IPPF-Urgestein
Mitglied seit
10 Mai 2006
Beiträge
13,041
Punkte für Reaktionen
991
Punkte
113
Vermutlich schon ... wann kommt der denn zur Anzeige und wo taucht der genau auf? (Am besten mal einen Screenshot machen.)

Wenn das daran liegen sollte, daß da jemand seine FRITZ!Box mit unsicheren Einstellungen zur Anmeldung betreibt, passe ich meinerseits ... aus hoffentlich nachvollziehbaren Gründen. Es wäre schon ziemlich krude, wenn ich einerseits mehr Sicherheit einfordere und andererseits dann Meldungen zu "Schwächen" zu unterdrücken helfe - deshalb höchstens Hinweise, wie man das machen könnte, aber kein "modscript" von mir, wenn meine Vermutung hinsichtlich der Ursache stimmen sollte.

Reicht es dafür schon, die 2FA zu deaktivieren, schaue ich es mir bei Gelegenheit mal an - das halte ich für einen legitimen Umgang mit den Security-Settings für die Leute, die sich der damit verbundenen Risiken bewußt sind.
 

topversand

Neuer User
Mitglied seit
3 Mrz 2013
Beiträge
17
Punkte für Reaktionen
0
Punkte
3
Ja es handelt sich um 2FA, wenn ich 2FA (Bestätigung am Telefon) aktiviere, dann ist die Meldung weg. 2FA nervt!
Wäre schön wenn man die Meldung zu 2FA deaktivieren könnte.

Fritzbox Meldung.jpg

-- Zusammenführung Doppelpost + Bilder geschrumpft by stoney

Ich habe "mod_show_vpn_on_overview" geändert, da der Text auf der Startseite zu lang war und bei kleineren Browserfenster abgeschnitten wurde.
"Fernzugang(VPN)" zu "VPN"

Fritzbox VPN.jpg
 
Zuletzt bearbeitet von einem Moderator:

PeterPawn

IPPF-Urgestein
Mitglied seit
10 Mai 2006
Beiträge
13,041
Punkte für Reaktionen
991
Punkte
113
Bei mir sieht es (ohne aufgebaute Verbindung, als Vollbild bei 1920px x 1200px in FF unter Windows) so aus:
vpn_overview.PNG
- da ist also sogar noch massig Platz für aufgebaute Verbindungen und event. Verschiebungen in der Breite der "linken Spalte" mit den Bezeichnungen machen sich noch nicht bemerkbar.

Bei AVM steht da halt nicht "VPN", sondern:
Bash:
~ # echo "9042:115" | /var/media/ftp/YourFritz/root/bin/dbtext.lua
Fernzugang
~ # echo "577:732" | /var/media/ftp/YourFritz/root/bin/dbtext.lua
Fernzugang (VPN)
, je nachdem, welche Zeichenkette aus der AVM-DB man nimmt.

Ich finde das mit dem "VPN" in Klammern immer noch besser, um Verwechslungen mit dem TLS-Zugriff auf das GUI von der WAN-Seite zu vermeiden, auch wenn das mittlerweile "Internetzugriff auf die FRITZ!Box über HTTPS" genannt wird von AVM und früher auch "Fernwartung" hieß. Aber es gibt noch genug Stellen im Netz, wo alles das munter durcheinandergeworfen wird (Fernzugang, Fernzugriff, Fernwartung) und da ist mir der (neue) AVM-Text mit dem "Fernzugang" dann zu "ungenau" (auch wenn AVM das mittlerweile im eigenen Gebrauch ziemlich konsequent umgesetzt hat).

Außerdem habe ich halt immer auch die verschiedenen Sprachvarianten der AVM-Firmware im Blick (der Patch funktioniert zumindest auch für Englisch) - auch wenn das hier bei der Verwendung von "VPN" (pur) sicherlich kein Problem wäre, weil das in beiden Sprachen identisch wäre.

Für alle anderen, die das ebenfalls ändern wollen: Das steht in der "mod_show_vpn_on_overview" in der Zeile 46:
Code:
46 vpn.title=[[{?577:732?}]]
und man kann das problemlos durch eine eigene Zeichenkette (mit passend maskierten Anführungszeichen, siehe die Zeilen rundherum) ersetzen oder auch die "Quelle" in der AVM-DB für I14N anpassen.

=============================================================================

Behebt es Dein Problem mit der 2FA, wenn Du in der Datei "/usr/www/avm/home/home.js" die Zeile 595:
Javascript:
595 if (data.fritzos.twofactor_disabled || data.fritzos.ipphone_from_outside) {
auf
Javascript:
595 if (data.fritzos.ipphone_from_outside) {
änderst, bevor das Image neu gepackt wird? EDIT: Der Pfad ändert sich natürlich, wenn Deine Box ein anderes Branding hat.

Es ist halt immer die Frage, wo man ändern will ... man könnte natürlich auch dafür sorgen, daß "data.fritzos.twofactor_disabled" immer auf "false" steht.