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

antonvm

Mitglied
Mitglied seit
10 Jan 2016
Beiträge
347
Punkte für Reaktionen
5
Punkte
18
So werden reproduzierbare, nachhaltige Projekte, hier jetzt Freetz aufgestellt.

Die anderen Forks, soweit sie es noch nicht haben, sollten auch darüber nachdenken.

Danke

MfG
antonvm
 

PeterPawn

IPPF-Urgestein
Mitglied seit
10 Mai 2006
Beiträge
13,860
Punkte für Reaktionen
1,284
Punkte
113
Beim Aufräumen auf lokalen Rechnern sind mir einige ältere Änderungen noch untergekommen, die sich mit "run_modscripts" und der Auswertung von Return-Codes beim "postcheck"-Schritt befassen:


- ein "precheck" halte ich immer noch nicht für notwendig ... die Lösung, das Verzeichnis mit den entsprechenden "modscripts" angeben zu können beim Aufruf (darin können sich ja auch nur die Symlinks auf die "echten" Skript-Dateien befinden), erleichtert einem auch das Zusammenstellen unterschiedlicher Modifikationen für jedes Modell und jede Firmware-Version; ja, man könnte sogar pro Gerät einen eigenen Ordner dafür verwenden, wenn man das wollte.

Da auch bisher keine zusätzlichen Verzeichnisse durchsucht wurden, wie das in "modfs" beim "contrib"-Verzeichnis der Fall war, sollte das jetzt auch nicht notwendig werden und wenn man tatsächlich die Modifikationen für einzelne Geräte/Modelle in getrennten Verzeichnissen verwaltet (die Dateien hinter den Symlinks kann man ja trotzdem aktualisieren lassen, falls doch mal eines der Skripte geändert wurde), kann man da auch gleich alle Files (inkl. irgendwelcher aus "custom" oder "contrib" oder ähnlichem) verlinken - nur muß man beim Schreiben eigener Modifikationen, die sich auf mehr als eine Datei in unterschiedlichen Ordnern verteilen (mein Boot-Manager wäre so ein Beispiel), dann ein wenig aufpassen, wenn man mit Pfaden hantiert.

Gestartet werden die Skript-Dateien immer aus dem Verzeichnis heraus, in das man "run_modscripts" (und den Rest der Dateien) entpackt hat - zumindest wenn man meinen Empfehlungen zum Aufruf folgt. Alle weiteren Pfadangaben sollten also immer relativ dazu erfolgen und am besten noch mit "readlink -f" in die absoluten Pfade übersetzt werden (wenn man neue Skripte schreibt zumindest). Und um da ganz sicher zu gehen, daß es so etwas wie ein "Stammverzeichnis" für die entpackten "modfs"-Dateien gibt, wird jetzt eine Umgebungsvariable "MODFS_DIR" mit an die aufgerufenen Skript-Dateien übergeben, die auf den Wert des aktuellen Verzeichnisses (CWD - current working directory) beim Aufruf von "modfs" (und auch von "run_modscripts") gesetzt wird. Braucht ein Skript zum Modifizieren weitere Dateien (die sollten ja nicht im "modscripts"-Ordner liegen), kann es diesen Wert benutzen, um die zu lokalisieren, wenn sie unterhalb des "modfs"-Verzeichnisses (dessen Namen ja jeder Benutzer frei wählen kann, daher geht das nur mit relativen Pfaden) liegen.

Weitere Folge: neuer Timestamp, neues Archiv auf yourfritz.de

Ich habe die letzten Änderungen auch nicht direkt durch den Aufruf von "modfs" getestet (ich hoffe trotzdem, daß sich da keine Probleme ergeben, weil die Änderungen an diesen Dateien dann doch eher gering waren, im Gegensatz zum "run_modscripts"), sondern dafür das folgende Skript verwendet, was eine etwas erweiterte Form der Statements ist, die ich in diesem Thread: https://www.ip-phone-forum.de/threa...h-meine-eigene-dann-auf-der-fritz-box.307161/ mal zum Besten gegeben habe.

Diese Version kann einfach mit dem Modellnamen und der Versionsnummer der AVM-Firmware aufgerufen werden (für Release-Versionen und solange die URL bei AVM dann denselben, einfachen Regeln folgt wie im Skript - Standard wäre, wie ersichtlich, 7590 und 07.21), paßt sich beim Benutzernamen automatisch an den verwendeten Account an (alles nur als "root" zu machen, ist mir zu unsicher - ein "sudo" wird bei mir nur da genutzt, wo es sein muß und so werden z.B. auch die "modscripts" nicht als "root" abgearbeitet), detektiert die passende Version (byte order) für das Entpacken und Packen selbst und verwendet die "postcheck"-Aufrufe samt Auswertung der Return-Codes.

Bash:
# /bin/sh
set -x
MODEL=${1:-7590}
VERSION=${2:-07.21}
MYDIR="${TMPDIR:-/tmp}/$(id | sed -n -e "s|uid=[0-9]*(\([^)]*\)).*|\1|p" | sed -e "s|[ \t]|_|g")/yf_sample"
[ -d "$MYDIR" ] && printf "Error creating working directory (already exists).\n\a" && exit 1
! mkdir -p "$MYDIR" && printf "Error creating working directory.\n\a" && exit 1
cd "$MYDIR"
URL="http://ftp.avm.de/fritzbox/fritzbox-$MODEL/deutschland/fritz.os/FRITZ.Box_$MODEL-$VERSION.image"
wget -q -O avm.tar $URL
tar -x -f avm.tar -O ./var/tmp/kernel.image >kernel
dd of=kernel.bin if=kernel bs=8 count=$(( ( $(stat -c %s kernel) / 8 ) - 1 )) 2>/dev/null
rm kernel
tar -x -f avm.tar -O ./var/tmp/filesystem.image >fs.sqfs
git clone --recurse-submodules https://github.com/PeterPawn/YourFritz.git
git clone --recurse-submodules https://github.com/PeterPawn/modfs.git
MAGIC=$(dd if=fs.sqfs count=4 bs=1 2>/dev/null)
[ "$MAGIC" = "sqsh" ] && ENDIAN=be || ENDIAN=le
sudo YourFritz/bin/squashfs/$(uname -m)/unsquashfs4-$ENDIAN -no-progress fs.sqfs
sudo chown -R $(id | sed -n -e "s|uid=\([0-9]*\).*|\1|p"):$(id | sed -n -e "s|.*gid=\([0-9]*\).*|\1|p") squashfs-root/
rm fs.sqfs
mkdir modfs/$MODEL
cd modfs/
for modscript in gui_boot_manager_v0.6 mod_enable_calllog mod_fixed_branding mod_telnet_enable mod_rc_tail_sh; do
        ln -s ../modscripts/$modscript $MODEL/
done
./run_modscripts ../squashfs-root/ $MODEL
modrc=$?
cd ..
if [ "$modrc" -eq 0 ]; then
        YourFritz/bin/squashfs/$(uname -m)/mksquashfs4-$ENDIAN squashfs-root/ fs.sqfs -all-root -no-progress
        cat kernel.bin fs.sqfs >new.image
        ls -l
else
        printf "At least one 'modscript' reported an error, packing skipped.\n\a"
fi
exit $modrc
... und ehe mir wieder "Klagen" kommen, daß das jemand nicht aus der Seite hier so einfach herauskopieren kann, hänge ich es (trotz "Wer immer strebend sich bemüht, den können wir erlösen." - um mal wieder eine Textstelle aus einem Werk von J.W.v.Goethe zu zitieren, nämlich "Faust II") noch einmal als Datei hier an. Kommt jetzt allerdings der Nächste und empört sich darüber, daß die Datei aber die Endung ".txt" hat (weil die Board-Software das so will), dann möge er das bitte gleich für sich behalten ... wenn jemand eine Datei (beim oder nach dem Download) nicht alleine umbenennen kann, interessiert mich das (in meinem Elfenbeinturm) nicht die Bohne.

Und auch hier betone ich noch einmal (schon um erneute Mißverständnisse zu vermeiden, auch wenn der gewählte Verzeichnisname "yf_sample" für sich selbst sprechen sollte), daß es sich meinerseits nur um ein Beispiel handelt, wie man die Firmware für andere Boxen (bei VR9 funktioniert das so gar nicht, weil das Entpacken auch dann anders aussehen muß, wenn nicht länger "ext2", sondern auch wieder SquashFS verwendet wird für die "wrapper"-Partition) modifizieren KÖNNTE, wenn man "modfs" dafür nehmen wollte.
 

Anhänge

  • modify.txt
    1.6 KB · Aufrufe: 17
Zuletzt bearbeitet:
  • Like
Reaktionen: Insti

Insti

Mitglied
Mitglied seit
19 Aug 2016
Beiträge
686
Punkte für Reaktionen
68
Punkte
28
Diese Version kann einfach mit dem Modellnamen und der Versionsnummer der AVM-Firmware aufgerufen werden (für Release-Versionen und solange die URL bei AVM dann denselben
Funktioniert einwandfrei. Gerade auf dem Raspberry Pi für die 7530 getestet
Code:
[email protected]:/opt# ./fritzbuild7530.sh
++ MODEL=7530
++ VERSION=07.21
+++ id
+++ sed -n -e 's|uid=[0-9]*(\([^)]*\)).*|\1|p'
+++ sed -e 's|[ \t]|_|g'
++ MYDIR=/tmp/root/yf_sample
++ '[' -d /tmp/root/yf_sample ']'
++ mkdir -p /tmp/root/yf_sample
++ cd /tmp/root/yf_sample
++ URL=http://ftp.avm.de/fritzbox/fritzbox-7530/deutschland/fritz.os/FRITZ.Box_7530-07.21.image
++ wget -q -O avm.tar http://ftp.avm.de/fritzbox/fritzbox-7530/deutschland/fritz.os/FRITZ.Box_7530-07.21.image
++ tar -x -f avm.tar -O ./var/tmp/kernel.image
+++ stat -c %s kernel
++ dd of=kernel.bin if=kernel bs=8 count=388064
++ rm kernel
++ tar -x -f avm.tar -O ./var/tmp/filesystem.image
++ git clone --recurse-submodules https://github.com/PeterPawn/YourFritz.git
Cloning into 'YourFritz'...
remote: Enumerating objects: 122, done.
remote: Counting objects: 100% (122/122), done.
remote: Compressing objects: 100% (72/72), done.
remote: Total 3487 (delta 75), reused 88 (delta 47), pack-reused 3365
Receiving objects: 100% (3487/3487), 4.03 MiB | 2.85 MiB/s, done.
Resolving deltas: 100% (2229/2229), done.
Submodule 'bin' (https://github.com/PeterPawn/yf_bin.git) registered for path 'bin'
Submodule 'first_aid' (https://github.com/PeterPawn/first_aid.git) registered for path 'first_aid'
Cloning into '/tmp/root/yf_sample/YourFritz/bin'...
remote: Enumerating objects: 99, done.
remote: Counting objects: 100% (99/99), done.
remote: Compressing objects: 100% (78/78), done.
remote: Total 926 (delta 22), reused 90 (delta 19), pack-reused 827
Receiving objects: 100% (926/926), 75.25 MiB | 5.68 MiB/s, done.
Resolving deltas: 100% (180/180), done.
Cloning into '/tmp/root/yf_sample/YourFritz/first_aid'...
remote: Enumerating objects: 42, done.
remote: Total 42 (delta 0), reused 0 (delta 0), pack-reused 42
Submodule path 'bin': checked out '761344186579a26a7f60791f76f0f938b19b3a44'
Submodule path 'first_aid': checked out '0359a4db07ffb555b5714184f16a2ffd7348955b'
++ git clone --recurse-submodules https://github.com/PeterPawn/modfs.git
Cloning into 'modfs'...
remote: Enumerating objects: 130, done.
remote: Counting objects: 100% (130/130), done.
remote: Compressing objects: 100% (86/86), done.
remote: Total 1735 (delta 75), reused 89 (delta 41), pack-reused 1605
Receiving objects: 100% (1735/1735), 17.22 MiB | 3.87 MiB/s, done.
Resolving deltas: 100% (1166/1166), done.
+++ dd if=fs.sqfs count=4 bs=1
++ MAGIC=hsqs
++ '[' hsqs = sqsh ']'
++ ENDIAN=le
+++ uname -m
++ sudo YourFritz/bin/squashfs/armv7l/unsquashfs4-le -no-progress fs.sqfs
sudo: unable to resolve host ubuntu: Name or service not known
Found TI checksum (0xED68084B) at the end of the image.
Filesystem on fs.sqfs is xz compressed (4:0)
Parallel unsquashfs: Using 4 processors
8325 inodes (9284 blocks) to write


created 7631 files
created 516 directories
created 693 symlinks
created 1 devices
created 0 fifos
+++ id
+++ sed -n -e 's|uid=\([0-9]*\).*|\1|p'
+++ id
+++ sed -n -e 's|.*gid=\([0-9]*\).*|\1|p'
++ sudo chown -R 0:0 squashfs-root/
sudo: unable to resolve host ubuntu: Name or service not known
++ rm fs.sqfs
++ mkdir modfs/7530
++ cd modfs/
++ for modscript in gui_boot_manager_v0.6 mod_enable_calllog mod_fixed_branding mod_telnet_enable mod_rc_tail_sh
++ ln -s ../modscripts/gui_boot_manager_v0.6 7530/
++ for modscript in gui_boot_manager_v0.6 mod_enable_calllog mod_fixed_branding mod_telnet_enable mod_rc_tail_sh
++ ln -s ../modscripts/mod_enable_calllog 7530/
++ for modscript in gui_boot_manager_v0.6 mod_enable_calllog mod_fixed_branding mod_telnet_enable mod_rc_tail_sh
++ ln -s ../modscripts/mod_fixed_branding 7530/
++ for modscript in gui_boot_manager_v0.6 mod_enable_calllog mod_fixed_branding mod_telnet_enable mod_rc_tail_sh
++ ln -s ../modscripts/mod_telnet_enable 7530/
++ for modscript in gui_boot_manager_v0.6 mod_enable_calllog mod_fixed_branding mod_telnet_enable mod_rc_tail_sh
++ ln -s ../modscripts/mod_rc_tail_sh 7530/
++ ./run_modscripts ../squashfs-root/ 7530
Running script 'gui_boot_manager_v0.6' ...
      Patching file 'usr/www/1und1/system/reboot.js' ...
      Patching file 'usr/www/1und1/system/reboot.lua' ...
      Patching file 'usr/www/avm/system/reboot.js' ...
      Patching file 'usr/www/avm/system/reboot.lua' ...
      Patching file 'usr/www/avme/system/reboot.js' ...
      Patching file 'usr/www/avme/system/reboot.lua' ...
Finished script 'gui_boot_manager_v0.6', rc=0
Running script 'mod_enable_calllog' ...
Finished script 'mod_enable_calllog', rc=0
Running script 'mod_fixed_branding' ...
Das Branding für das neue System wurde fest auf 'avm' eingestellt.
Finished script 'mod_fixed_branding', rc=0
Running script 'mod_rc_tail_sh' ...
Finished script 'mod_rc_tail_sh', rc=0
Running script 'mod_telnet_enable' ...
Finished script 'mod_telnet_enable', rc=0
++ modrc=0
++ cd ..
++ '[' 0 -eq 0 ']'
+++ uname -m
++ YourFritz/bin/squashfs/armv7l/mksquashfs4-le squashfs-root/ fs.sqfs -all-root -no-progress
Parallel mksquashfs: Using 4 processors
Creating 4.0 filesystem on fs.sqfs, block size 65536.

Exportable Squashfs 4.0 filesystem, xz compressed, data block size 65536
        compressed data, compressed metadata, compressed fragments, no xattrs
        duplicates are removed
Filesystem size 25160.05 Kbytes (24.57 Mbytes)
        21.72% of uncompressed filesystem size (115822.59 Kbytes)
Inode table size 65690 bytes (64.15 Kbytes)
        22.11% of uncompressed inode table size (297074 bytes)
Directory table size 83592 bytes (81.63 Kbytes)
        37.49% of uncompressed directory table size (222986 bytes)
Number of duplicate files found 5052
Number of inodes 8848
Number of files 7637
Number of fragments 383
Number of symbolic links  694
Number of device nodes 1
Number of fifo nodes 0
Number of socket nodes 0
Number of directories 516
Number of ids (unique uids + gids) 1
Number of uids 1
        root (0)
Number of gids 1
        root (0)
++ cat kernel.bin fs.sqfs
++ ls -l
total 86424
drwxr-xr-x 28 root root     4096 Jan 27 22:32 YourFritz
-rw-r--r--  1 root root 30740480 Oct 27 14:50 avm.tar
-rw-r--r--  1 root root 25767936 Jan 27 22:34 fs.sqfs
-rw-r--r--  1 root root  3104512 Jan 27 22:32 kernel.bin
drwxr-xr-x  9 root root     4096 Jan 27 22:33 modfs
-rw-r--r--  1 root root 28872448 Jan 27 22:34 new.image
drwxr-xr-x 13 root root     4096 Oct 19 18:31 squashfs-root
++ exit 0
[email protected]:/opt#
Tolle Arbeit! Vielen Dank!
 

PeterPawn

IPPF-Urgestein
Mitglied seit
10 Mai 2006
Beiträge
13,860
Punkte für Reaktionen
1,284
Punkte
113
Neue Beta-Version 0.6.4

Download über http://yourfritz.de/modfs-0.6.4-beta.tgz

Wer das Repo klont, muß dann halt den Branch beta auschecken (git switch beta nach dem Klonen oder gleich ein -b beta beim git clone mit angeben).

Einzige relevante Änderung:


Die Aktivierung des "Inhouse-Mode" für den telefon-Daemon erfolgt jetzt (dynamisch) in Abhängigkeit von der vorliegenden Version, wobei für den alten und neuen Weg (siehe https://www.ip-phone-forum.de/threads/busybox-mit-telnet-in-fritz-os-7-2x.307385/page-5#post-2416096 und Beiträge davor) derselbe Code verwendet wird, weil die reine Versionsnummer der Firmware wohl kein zuverlässiges Unterscheidungsmerkmal ist, welche Variable von AVM tatsächlich genutzt wird. Ich habe mich auch zur Nutzung von 998 (das, was bei AVM als "private" läuft) entschieden - bisher war dieses private auch der Wert von config.gu_type, der aus dem CONFIG_RELEASE=0 resultierte - solange das also keinen Unterschied zum Wert 2 macht, nehme ich lieber die 998.

Die Änderungen sind für die neuen Versionen von mir auf einer 113.07.24-86493 (also einer 7490) getestet (für den alten Weg habe ich nur geprüft, daß die richtigen Änderungen ausgeführt werden) ... daher kann ich auch bestätigen (siehe die Frage im verlinkten Thread), daß die calllog auch weiterhin abgearbeitet wird, mithin der Name mod_enable_calllog immer noch seine Berechtigung hat.

Nach den ersten zwei, drei positiven Rückmeldungen (oder nach dem Fehlen negativer Erfahrungen in den nächsten drei Tagen) würde ich das in die "reguläre" Version (also den master-Branch) überführen, dann paßt es auch wieder mit dem Symlink unter modfs.tgz ohne die Versionsangabe beim Download.
 

eisbaerin

IPPF-Urgestein
Mitglied seit
29 Sep 2009
Beiträge
11,203
Punkte für Reaktionen
1,017
Punkte
113
Warum hast du dich für 998 entschieden und nicht für 2?

Noch ein Hinweis zur mod_rc_trail_sh.
Ich mußte beim FR1200 und FW 7.14 die "insertline" ändern auf den Start mit nohup, so wie du es bei der /etc/boot.d/core/rcuser machst.
Sonst wurde die /var/tmp/rc.user nicht abgearbeitet.
 
Zuletzt bearbeitet:

PeterPawn

IPPF-Urgestein
Mitglied seit
10 Mai 2006
Beiträge
13,860
Punkte für Reaktionen
1,284
Punkte
113
Warum hast du dich für 998 entschieden und nicht für 2?
Steht doch oben ... der wird als config.gu_type=private gesehen in der /usr/lua/config.lua (die 2 dagegen als beta) und das ist derselbe Wert, der sich bis zur 07.24 aus dem CONFIG_RELEASE=0 ableitete.

Damit bliebe auch config.gu_type im Lua-Code stabil, wenn man das config-Objekt von AVM "nachnutzen" wollte und den Wert systemweit setzt (auch dafür enthält telnetd_by_avm ja die Abfrage/Vorbereitung (https://github.com/PeterPawn/modfs/...9f80e998dd29d74bd9c2/files/telnetd_by_avm#L35 - die zweite Bedingung) und nicht nur für die Änderung, die durch mod_enable_calllog in der rc.voip vorgenommen wird) - das ist ggü. der bisherigen Implementierung die kleinere Änderung im Verhalten eines gepatchten Systems.

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

Noch ein Hinweis zur mod_rc_trail_sh.
Das verstehe ich (so lapidar) nicht - mal abgesehen von der Frage, ob das auch für einen Repeater gedacht ist/war oder nicht.

Die Unterscheidung, ob es sich um ein älteres System (mit serieller Abarbeitung bei der Initialisierung) handelt oder nicht, wird anhand der Existenz einer /etc/init.d/rc.tail.sh getroffen (https://github.com/PeterPawn/modfs/...98dd29d74bd9c2/modscripts/mod_rc_tail_sh#L130) - bisher war bei den Systemen, die supervisor zum Start verwenden, diese Datei nicht mehr vorhanden.

Wenn das beim FR1200 anders sein sollte und der über supervisor startet, aber trotzdem diese Datei noch hat, dann müßte man tatsächlich den Test etwas anders gestalten. Aber das kann man nun beim besten Willen aus #1845 nicht erkennen ... da wäre es hilfreich, wenn Du ein paar genauere Infos bereitstellen könntest; z.B. eben, welche "Startart" da nun tatsächlich verwendet wird und ob (ggf. sogar, warum) da nun noch eine rc.tail.sh von AVM rumsteht und was die im Original enthält.

Wenn da aber tatsächlich noch seriell abgearbeitet wird beim Start (durch die Schleife in der /etc/init.d/rc.S), dann stellt sich eher die Frage, warum die Zeile (die ja keinen asynchronen Aufruf enthält) nicht korrekt abgearbeitet wird ... ich hätte hier eher den Verdacht (wobei mich auch die Frage quält, warum da eine 07.1x noch über die rc.S gestartet wird), daß der Repeater gar keinen eigenen multid enthält (den bräuchte er ja auch nur für die eigene Uhrzeit über chrony, denn DHCP und DNS und den ganzen anderen Kram des multid hat ein Repeater nicht) und damit generell auf diesem Gerät die Verwendung von delay nicht möglich ist, weil das nur ein verkapptes msgsend an den multid ist.

DAS wären jedenfalls Infos, wie man sie für eine halbwegs kompetente Einschätzung der Ursache(n) bräuchte ... so wie jetzt, ist das zwar als Hinweis "nett", aber es bringt nur wenig - ich kann (und will) nicht selbst durch jede einzelne Firmware von AVM latschen.

Dafür sind das nun mittlerweile deutlich zu viele und vor allem gilt für die meisten sogar, daß die mich selbst gar nicht tangieren - mein AVM-Gerätepark ist begrenzt und mein Interesse mittlerweile auch; man merkt's sicherlich auch daran, daß ich nicht mehr jedem Sche** von AVM bei jeder Labor-Version hinterher renne, sondern immer schön auf die erste Release-Version warte, bevor ich mir selbst Arbeit mache und sei es nur die, mich in die AVM-Dateien einzulesen, um Probleme wie das nunmehr gelöste (und die Hinwendung zu CONFIG_BUILDTYPE) zu lokalisieren. Da spielt die Tatsache, daß der FR1200 ja auch per se kein von "modfs" unterstütztes Modell ist und ich nie den Anspruch erhoben habe, daß man irgendeines der vorbereiteten Skripte auch bei einem Repeater erfolgreich verwenden könnte, nur noch eine untergeordnete Rolle und auch wenn ich das durchaus nur als "Hinweis" gelesen und verstanden habe, verbindet sich ja damit wohl trotzdem eine gewisse "Erwartungshaltung".

Vermutlich jedenfalls - zumindest bisher war es häufig so und dann wurde mir später auch gerne mal geschrieben, daß man mir das ja schon vor sehr, sehr langer Zeit (wenn auch eher "am Rande", wie hier wohl auch) mitgeteilt hätte. Und da ist es mir dann auch ein Bedürfnis, noch einmal darauf hinzuweisen, was ich am Beginn des Jahres schrieb: https://www.ip-phone-forum.de/threads/modfs-squashfs-image-avm-firmware-ändern-für-nand-basierte-fritz-boxen.273304/post-2403580 - da ging es zwar auch (primär) um die neue Funktion mit den "Diskussionen", aber die Meldung von Fehlern im Projekt (egal in welchem), sollte ja schon länger als "Issue" im GitHub-Repo erfolgen (da kann man das dann nämlich auch viel besser verfolgen und verwalten, bis hin zur Behebung durch einen Patch/eine neue Version) und nicht mehr hier in irgendwelchen IPPF-Threads im "Volltext".

Wenn ich dann (bei deutlich weniger Zeit, die ich mit dem Lesen von IPPF-Threads verbringe und auch die Zahl meiner eigenen Beiträge ist ja deutlich rückläufig) irgendeine dieser "Meldungen" überlesen sollte (oder sie einfach auch nur vergesse, weil ich nicht sofort darauf einsteigen kann und es nun mal keinen "reminder" hier im Board gibt, den man komplikationslos nutzen könnte), darf man sich darüber auch nicht beschweren. Daher ist es einfach besser, das gleich selbst so zu machen, daß ich es nicht überlesen kann und es sogar (im GitHub-Dashboard) explizit "abhaken" muß - dann wird so etwas auch nicht (zumindest nicht versehentlich) übersehen/ignoriert/liegen gelassen.
 

Micha0815

IPPF-Promi
Mitglied seit
25 Feb 2008
Beiträge
4,387
Punkte für Reaktionen
275
Punkte
83
Nach den ersten zwei, drei positiven Rückmeldungen (oder nach dem Fehlen negativer Erfahrungen in den nächsten drei Tagen)
Ich habe heute mittels des hier beschriebenen Problems das "-b beta" getestet sowohl mit der 7.21 als auch der 7.25,1614950747037.png was jeweils via #96*7* mit einem DECT-Phone (Gigaset S68H) brav telnet einschaltete.
Als FeedBack, falls nicht schon obsolet.
LG
 
Zuletzt bearbeitet:

LazyT

Neuer User
Mitglied seit
12 Jan 2016
Beiträge
28
Punkte für Reaktionen
4
Punkte
3
Hallo,

benutze modfs unter Debian schon länger um für meine 7590 erst in-memory und dann signierte Images für die GUI zu bauen. Das funktioniert auch prima, erstmal vielen Dank dafür!

Jetzt wollte ich das auch mal für eine 7490 probieren, aber das scheitert leider an

Code:
"squashfs-root" seems to be not an unpacked FRITZ!OS structure - so this script was unable to extract needed values from this directory.

Das entpackte Image ist unter "/etc" auch recht leer, sodass er da sicher keine Versionsinfos rausziehen kann.

Muss man für die 7490 etwas anders machen oder was mache ich falsch?

Danke schon mal...
 

PeterPawn

IPPF-Urgestein
Mitglied seit
10 Mai 2006
Beiträge
13,860
Punkte für Reaktionen
1,284
Punkte
113
VR9-Images sind anders gepackt - aber auf diesen Modellen kann man "modfs" ja auch direkt ausführen, da hat es schließlich seine Wurzeln.

Wer noch keinen Shell-Zugang hat (und damit "modfs" nicht auf die Box bekommt), kann sich den mit einem "first_aid"-Image (https://github.com/PeterPawn/first_...2ffd7348955b/implant_siab_3.10.107.image.7490) einigermaßen komplikationslos (auch für supervisor-basierte AVM-Firmware) verschaffen (https://www.ip-phone-forum.de/threads/modfs-starter-einmal-impfung-mit-shellinabox-für-vr9-boxen.283038/).

EDIT: Wer möchte, kann sich natürlich auch das "implant..."-Image selbst bauen: https://github.com/PeterPawn/YourFritz/blob/master/toolbox/build_shellinabox_implant_image
 
  • Like
Reaktionen: LazyT

topversand

Neuer User
Mitglied seit
3 Mrz 2013
Beiträge
19
Punkte für Reaktionen
0
Punkte
3
Fritzbox 7490
Habe die letzte Labor mit der modfs beta mal installiert. Hat alles geklappt. Telnet funktioniert.
Habe nur ein Problem
mod_show_vpn_on_overview funktioniert nicht. Läuft bei der Installation ohne Fehler durch.
Auf der Frìtzbox Seite werden dann aber keine VPN Verbindungen angezeigt. Bis OS 7.21 ging es.
Vielleicht kann man das anpassen. Wäre schön.
Vielen Dank
 

eisbaerin

IPPF-Urgestein
Mitglied seit
29 Sep 2009
Beiträge
11,203
Punkte für Reaktionen
1,017
Punkte
113
mod_show_vpn_on_overview funktioniert nicht.
Wenn du das nicht benutzt werden die VPN Verbindungen bei 7.21 auch angezeigt.
Das sollte bei 7.25 nicht anders sein.
Das modscript ist seit einiger Zeit nicht mehr nötig.
Bei der 7.25 ist es wohl dann sogar kontraproduktiv.
 

PeterPawn

IPPF-Urgestein
Mitglied seit
10 Mai 2006
Beiträge
13,860
Punkte für Reaktionen
1,284
Punkte
113
Ich notiere es mir als ToDo ... ich mag tatsächlich auch meine Version mehr als die Anzeige bei AVM, weil ich in "Einwahlboxen" mehrere VPN-Verbindungen konfiguriert habe, die aber nicht immer alle aktiviert sind und natürlich erst recht nicht immer alle aufgebaut werden.

Wann ich es gelöst haben werden, kann ich nicht sagen - erst muß ich mal erkunden, wo das Problem liegt. Ich vermute mal, die Datenübertragung wird in Ordnung sein, aber irgendetwas im DOM und im JS-Code wird sich wieder geändert haben. Das ist das Risiko, wenn man sich in die AVM-Anzeigen einklinkt - aber es gibt hier keine (sinnvollen) Alternativen. Und da ich mich i.d.R. darum bemühe, die Abweichungen zum AVM-Code so gering wie möglich zu halten, funktioniert das häufig - für mich selbst "erstaunlicherweise" - auch einigermaßen reibungslos.
 

topversand

Neuer User
Mitglied seit
3 Mrz 2013
Beiträge
19
Punkte für Reaktionen
0
Punkte
3
Ich notiere es mir als ToDo ... ich mag tatsächlich auch meine Version mehr als die Anzeige bei AVM, weil ich in "Einwahlboxen" mehrere VPN-Verbindungen konfiguriert habe, die aber nicht immer alle aktiviert sind und natürlich erst recht nicht immer alle aufgebaut werden.

Wann ich es gelöst haben werden, kann ich nicht sagen - erst muß ich mal erkunden, wo das Problem liegt. Ich vermute mal, die Datenübertragung wird in Ordnung sein, aber irgendetwas im DOM und im JS-Code wird sich wieder geändert haben. Das ist das Risiko, wenn man sich in die AVM-Anzeigen einklinkt - aber es gibt hier keine (sinnvollen) Alternativen. Und da ich mich i.d.R. darum bemühe, die Abweichungen zum AVM-Code so gering wie möglich zu halten, funktioniert das häufig - für mich selbst "erstaunlicherweise" - auch einigermaßen reibungslos.
Ja die sieht viel besser aus als die original AVM VPN Ansicht und gehört zu meinen wichtigsten Mods.


Vielen Dank
 
Zuletzt bearbeitet:

PeterPawn

IPPF-Urgestein
Mitglied seit
10 Mai 2006
Beiträge
13,860
Punkte für Reaktionen
1,284
Punkte
113
Kurzes Update meinerseits ... das "mod_show_vpn_on_overview" ist nicht die einzige Modifikation, die mit 07.24+ nicht mehr korrekt funktioniert und ich unterziehe das jetzt alles mal einer Überprüfung. Ich hatte ohnehin vergessen, die letzte Beta in eine richtige Archiv-Datei zu packen und diese unter "modfs.tgz" bereitzustellen.

Es gibt noch ein paar andere Baustellen ... die "unangenehmste" ist es (für mich), daß AVM - anstatt einfach die Behandlung von Swap-Devices und -Files zu reparieren, wie das eine der Modifikationen ja macht - nun das (automatische) Mounten jeglicher Swap-Partitionen entfernt hat, was dann auch auf "modfs" Auswirkungen hat, wenn man sich bisher auf dieses automatische Einbinden von Swap-Space verlassen hat.

Bisher sorgt(e) "mod_swapoff" nur dafür, daß beim Aushängen von USB-Volumes/-Devices auch die Swap-Files und -Devices ordentlich deaktiviert werden ... jetzt wird daraus wohl ein "mod_swap" generell werden, was dann auch das Mounten von Partitionen (und wenn ich dann schon dabei bin, auch gleich von Files mit passendem Namen und passender Struktur im Wurzelverzeichnis eines neu zu mountenden Volumes) beinhalten wird.

Auch beim erwähnten "mod_show_vpn_on_overview" wird es eine Version "bis 07.24" geben und eine danach ... anstatt das jetzt um eine weitere Version aufzublasen, habe ich lieber einen Schnitt gemacht und das Erstellen der Daten mit der AVM-Funktion durch eine eigene Funktion ersetzt. Damit braucht es kein gesondertes "mod_remove_avm_vpn_from_overview" mehr, gleichzeitig gibt es aber auch keine Möglichkeit mehr, beide Versionen (die von AVM und meine) parallel in der Anzeige zu haben, weil ich die (aufgerufene) Funktion tatsächlich austausche und damit die AVM-Einträge in den JSON-Daten gar nicht mehr auftauchen.

Sollte es sich noch für weitere "modscripts" zeigen, daß es umfangreichere Änderungen für 07.24+ braucht, dann werde ich wohl auch bei diesen einen Schnitt machen und die älteren Dateien auf "bis 07.24" (per Versionsprüfung) beschränken, während die für die neueren FRITZ!OS-Versionen dann die "alten Namen" behalten. Das hieße dann im Ergebnis, daß man für die Modifikationen bei älteren FRITZ!OS-Versionen die "custom_modscripts" anpassen muß - so man eine solche verwendet. Das wäre dann ein "Bruch" mit der Rückwärtskompatibilität ... aber m.E. ein vertretbarer, zumal es bei den Namen wohl noch mehr Änderungen geben wird/muß (u.a. "mod_swapoff"->"mod_swap").
 

Erhalten Sie 3CX für 1 Jahr kostenlos!

Gehostet, in Ihrer privaten Cloud oder on-Premise! Ganz ohne Haken. Geben Sie Ihren Namen und Ihre E-Mail an und los geht´s:

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.
oder via