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

[koyaanisqatsi]

Moins


@Riverhopper: Stimmt, ich habs durcheinandergewürfelt.
Der Fehler kommt bei meinen Test auf einer 7360SL mit Firmware 6.30 wenn udevadm trigger eine Swappartition findet und swapon meldet...

Mounting SanDisk-CruzerBlade-01 to device /dev/sda1...
MOUNT: use blkid to get device /dev/sda1 data
MOUNT: filesystem type is: swap
MOUNT: try to add swap
mkswap: /dev/sda1: warning: wiping old swap signature.
[COLOR=#ff0000]swapon: can't load library 'libmount.so.1'[/COLOR]
MOUNT: swap added

Ist dass bei euren Boxen mit AVM busybox und Firmware 6.50/51 auch so?

 

[PeterPawn]

Bei den Boxen ohne CONFIG_NAS=y läßt AVM in wechselnden Konfigurationen auch Tools weg, die nur dafür benötigt werden im Normalfall.

Bei der 7412 betrifft das z.B. das komplette "blkid"-Kommando (gibt halt keinen USB-Anschluß) und - wenn ich die Fehlermeldung zur libmount.so richtig interpretiere - bei der 7360SL ist es wohl die libmount.so, die "dann mal weg" ist, weil die wohl eigentlich auch nichts so richtig automatisch mounten sollte, wenn es ein "storage"-Device ist.

Die extX-Filesysteme sind - zumindest bei neueren Versionen - aber schon statisch im Kernel und nach meinen bisherigen Vergleichen verwendet AVM da denselben Kernel über mehrere Modelle mit demselben Prozessor (ich vermute mal, deshalb ist auch der modellspezifische Teil bei den LEDs immer noch in Form eines LKM dabei und nicht fix eingebunden, was das sehr frühe "Blinken" ohne Dateisystem (mithin ohne led_module_irgendwas.ko) etwas kompliziert macht), damit wird die libmount.so u.U. gar nicht gebraucht für das Einbinden solcher Partitionen (müßte man aber auch nachsehen).

Wenn nicht auch die Busybox der 7360SL eine Spezialversion ist, könnte aber das dort enthaltene swapon-Applet funktionieren, denn das oben, wo die fehlende libmount.so angemault wird, ist vermutlich das externe Binary aus den e2fsprogs ... das in der Busybox dürfte diese Abhängigkeit gar nicht aufweisen.

 

[andiling]

Ist denn eigentlich mal als Erweiterung von modfs geplant, eine build(root) Umgebung/toolchain samt Rezepten mit zu generieren, damit man sich Anwendungen auf der Box selber bauen kann bzw alternativ eine Art Paketverwaltung? Ich hatte mal was vor einiger Zeit davon gelesen gehabt (da fiel m.E. auch "SoftEther" mit in dem Atemzug).

 

[PeterPawn]

"Paketverwaltung" ist das Fernziel (aber eher nicht mit einem der bekannten Formate) ... eine buildroot-Umgebung auf der Box wäre auch nur als Download-Toolchain denkbar (niemand will die wirklich auf der Box selbst übersetzen, nicht mal auf den VR9-Modellen oder Puma6) und dann braucht auch deren Verwendung wieder (zumindest Grund-)Kenntnisse beim Verwender, das geht bei "autoconf" los - wenn man nicht nur Pakete bereitstellen will, die schon "fertig konfiguriert" sind. Ich habe das zwar mal der Einfachheit halber auf der 7490 probiert (auch weil Freetz u.a. ein Crossbuild der bintools ermöglicht und das damit ein denkbarer Weg wäre), aber auf kleineren Boxen ist das vermutlich wieder nicht sinnvoll - ich vergesse eben immer wieder, daß es auch Modelle mit 128 MB RAM gesamt gibt und diese dann für die Zeit solcher Übersetzungen ihre eigentliche Arbeit eher einstellen würden bzw. müßten.

Dann kann man die auch gleich in Binärform anbieten, solange man die Authentizität irgendwie sichert. Problematisch an der Stelle ist u.a. das Format so einer Paketverwaltung, die Busybox unterstützt rudimentär das deb-Format ... aber alles, was im FOSS-Bereich so an Formaten verwendet wird, setzt auf PGP für Signaturen und auch das müßte man dann erst für die Boxen basteln.

Alles nichts, was man aus dem Ärmel schütteln kann ... die AVM-Methode der Signatur ist gar nicht so schlecht und ich würde inzwischen wieder am ehesten dazu tendieren (das ändert sich mit jedem neuen Versuch in der Richtung auch immer mal wieder, weil sich einige Ideen als schlecht herausstellen), da Pakete (die aber auch gleich alles enthalten, was dafür benötigt wird und nicht auf anderen Paketen aufbauen, womit dann die Verwaltung von Abhängigkeiten wegfallen kann) in diesem Format (tar-Archiv mit nachträglich angehangener /var/signature, die vermutlich erst mit dem fertigen tar-File als Eingabe erzeugt wird) "anzubieten", die man dann auf der Box zu einem gemeinsamen SquashFS-Image zusammenpackt, das dann als /var/custom wieder gemountet wird (wie bei "modfs-Starter" auch praktiziert).

In "kleineren Einheiten" ist das alles schon (weitgehend jedenfalls) vorhanden (fehlen halt die einen oder anderen Binärdateien auf der FRITZ!Box, z.B. ein generisches "openssl"-Kommando für die Verwendung von libssl und libcrypto auch zum Signieren bzw. zur Prüfung) ... man muß es nur zu einer irgendwie vom Nutzer leicht konfigurierbaren Erweiterung zusammenfügen. Das braucht alles seine Zeit (und ggf. sogar Mitstreiter, die sich da engagieren wollen, der "Aufruf" ist praktisch auch so alt wie "modfs" an sich).

Das ist auch mit den jetzt bereits veröffentlichten Skript-Schnipseln (nicht nur "modfs", auch "YourFritz" enthält da ein paar Teilaspekte im GitHub-Repo) in Handarbeit mit einer funktionierenden Crossbuild-Umgebung relativ leicht zu realisieren ... das Prinzip mit dem zusätzlichen SquashFS-Image funktioniert ja auch mit einer originalen AVM-Firmware (auch wenn es nicht mehr über Pseudo-Update "installiert" werden kann) schon recht gut, wobei natürlich der eine oder andere "hook" in der originalen Firmware auch nicht schaden kann, das ist es ja, was ich mit "yourfritz_hooks" früher (bis zur 06.30) umgesetzt hatte.

Man braucht nur das mksquashfs passend zur eigenen System-Version, die zusätzlichen Dateien und ein entsprechendes zusätzliches "init"-Skript (im "Erweiterungsimage"), das alle unterhalb von /var/custom/etc/init.d/Sxx-irgendwas liegenden Dateien parallel zum Init-Prozess der AVM-Firmware (oder auch danach) noch abarbeitet. Dann kann man sich auf diesem Weg auch mehrere "Pakete" zu einem gemeinsamen Image zusammenschnüren (früher habe ich noch ein Image pro Erweiterung erzeugt, was dann durch die Anzahl der Loop-Devices die Anzahl der Pakete begrenzt oder man erweitert die Liste der Devices) und dieses eine SquashFS-Image dann wieder sehr leicht in der wrapper-Partition verwalten. Solange man (beim derzeitigen Stand) unterhalb von 20 MB zusätzlichem Platzbedarf bleibt, ist das alles kein Problem.

Aber es braucht im Moment eben noch eigene Handarbeit und es ist nicht so ganz einfach, das in eine Form zu bringen, die einerseits so flexibel ist, daß sie "Experten" nicht wirklich behindert und andererseits so einfach zu handhaben ist, daß auch ungeübte Benutzer damit klarkommen.

Ich bin ja eher der Typ, der solche Lösungen immer als Beispiel entwickelt (proof of concept) und als "Rahmen" (framework) für eigene Experimente (auch "modfs" ist ja eigentlich nichts anderes, die wirkliche Arbeit der Änderung sollen ja die "modscripts" übernehmen und "modfs" automatisiert nur das Entpacken und Packen der originalen Firmware) ... da ist mein eigener Antrieb, das in eine "laientaugliche Form" zu bringen, eher unterentwickelt und so etwas als regelmäßig aktualisierte Institution zu etablieren, ist eher nicht meins (schon gar nicht alleine).

Aber wenn man so etwas macht, muß man natürlich auch auf Security-Probleme umgehend reagieren können und wollen ... nichts fände ich persönlich schlimmer als ein 6 Monate altes dropbear-Image mit bekanntermaßen verwundbarer Server-Komponente, das immer noch neu installiert wird von irgendwelchen Nutzern (dann lieber gar kein dropbear-Image).

tl;dr:
Ich würde es gerne in diese Richtung erweitern, aber die damit dann auch einhergehende Verantwortung für die Verwaltung und regelmäßige Aktualisierung solcher Erweiterungen will und werde ich als Einzelner nicht auf mich nehmen. Daher kommen vermutlich von mir doch nur die Werkzeuge und Anleitungen, wie man das selbst umsetzen könnte und keine fertigen Erweiterungspakete (außer mich reitet doch irgendwas und ich will einfach mal zeigen, wie simpel das am Ende ist, wenn man denn die Idee dahinter nur verstanden hat und sie für eigene Zwecke umsetzen kann).

EDIT:
Der bei der 7390 nun auch in der deutschen Version wieder zum Leben erweckte Mechanismus für die "Plugins" macht das ja im Prinzip auch so ... daher auch mein Umschwenken auf ein gemeinsames SquashFS-Image für alle Erweiterungen anstelle einzelner Images. Auch wenn das bei der AVM-Firmware im Moment nur für die 7390 verwendet wird (die modfs ohnehin nicht kennen soll) und auch dort nur mit dem WLAN-Plugin als einziger Erweiterung bisher noch nicht wirklich kritisch wird mit der Anzahl der zusätzlich gemounteten Images, so muß man ja nicht unbedingt hingehen und die derzeit vorhandenen 8 Loop-Devices (eines bräuchte man auch als "Reserve", damit solche Sachen wie "modfs" dann damit arbeiten können) am Ende noch durch neue Nodes erweitern (auch wenn es zumindest bis 15 wohl mit dem originalen loop.ko noch möglich ist, auch ohne passende Parameter beim Laden des LKM - wobei das vermutlich sogar nachträglich über das sysfs noch erweiterbar wäre).

 

[Freem]

Guten Tag Zusammen

bin neu hier und wollte mal fragen wie ich das installiere finde leider keine Anleitung daür
wollte den auto start wieder zurück holen für fritzload aber irgendwie finde ich keine passende anleitung im netz.

 

[KunterBunter]

Da hast du Recht, im Netz kannst du noch keine passende Anleitung finden.

 

[Freem]

Danke schon mal


Läuft der Mod auch auf ner 7330sl Box

 

[PeterPawn]

Gegenfrage: Wie sollte das gehen?

http://www.ip-phone-forum.de/showthread.php?t=279759

Wenn ich jetzt darum bitte, daß anstatt zu schreiben auch mal gelesen werden möge ... dann wird das hoffentlich nicht wieder falsch verstehen.

Aber wenn sich schon die @eisbaerin die Arbeit macht (und alle anderen, die sich daran beteiligen) und dann sogar in der noch unfertigen Anleitung die denkbaren Modelle aufgezählt werden - dann stellt sich mir die Frage, wie es nach dem Lesen des verlinkten Threads zu solchen "Nachfragen" kommen kann.

Daher noch einmal deutlich: Nein, es läuft nicht auf allen FRITZ!Box-Modellen, nur auf denen, die bestimmte Voraussetzungen erfüllen. Die 7330SL gehört da in vielerlei Hinsicht nicht dazu ... auch keine TP-Link-, Zyxel-, D-Link-, Linksys-, Huawei-Modelle --> und jedes andere denkbare Modell, das im Thread mit der Anleitung nicht erwähnt ist, reiht sich per se auch in diese illustre Riege ein, genauso wie Einplatinen-Rechner, Spielekonsolen, Smartphones, uvm.

Ich konnte ja die erste Frage noch (in Maßen) verstehen, auch wenn es gerade auf den letzten Seiten ja genau um diese - im Werden begriffene - Anleitung ging (da wird es schon merkwürdig, wenn man so gar nichts finden kann) ... aber nach dem Link von KunterBunter dürfte das (in meinen Augen) eigentlich nicht mehr passieren. Oder ich verstehe da generell etwas falsch, wofür solche Threads (und überhaupt diese Foren) am Ende da sind ...

Klar könnte ich jetzt auch einfach die Klappe halten, solche Fragen künftig komplett ignorieren und mir einfach nur meinen Teil denken ... aber dann stellt sich mir auch wieder die Frage, ob sich nicht der Nächste dann ebenso animiert fühlt, einfach seinerseits erneut (anstatt zu suchen und zu lesen) bereits beantwortete Fragen zu stellen (gleiches Recht für alle, was unterscheidet den Fragesteller bei der dritten von dem bei der vierten Nachfrage zu demselben Thema) und dann dreht sich am Ende alles nur noch um solche Wiederholungen.

Dazu habe ich persönlich eher keine Lust (und das darf ich auch so deutlich machen, es ist mein eigener, höchst persönlicher Standpunkt) und dann müßte in der Folge ich selbst das Abo dieses Themas aufgeben - und auch ohne daß ich mich selbst für unentbehrlich halte, ist das vermutlich eher nicht im Sinne derjenigen, die wirklich mit "modfs" (und nicht nur mit dem Lesen) Probleme haben.

Daß es mit @Freem jetzt wieder mal einen Neuling erwischt mit diesem "rant", tut mir zwar in gewissen Grenzen auch leid ... aber es gibt nun wirklich genug Anleitungen im Netz, wie man sich auch in solchen Foren (und das hier ist - mein Standpunkt - immer noch Technik und kein Streichelzoo) am besten bewegt und unter Berücksichtigung des "gleichen Rechts für alle", darf es dann auch keinen "Welpenschutz" geben bzw. der ist bei der zweiten derartigen Frage dann auch nicht mehr angebracht.

- - - Aktualisiert - - -

Nächste Version 0.3.4 (als "Zwischenupdate" zum Abarbeiten der Issues) ...

Änderungen:

- neue Skripte für

(a) LED-Anzeige ein-/ausschalten ... hier irgendwo vorher mal angesprochen, gab aber kein Attachment, habe es dann selbst erstellt - dabei auch gleich noch einen "init failure" behoben in der AVM-Datei (der zumindest bei mir auftrat und den ich durch "Abzählen" der "if"s dann auch nicht sofort finden konnte, das AVM-Lua liest sich bekanntermaßen lausig), die immer mit "LEDs ein" in der Seite starten wollte, wenn man sie das erste Mal aufrief

(b) Anzeige des Namens der (eigenen) Telefonnummer in der Anrufliste für diejenigen, die nicht sofort anhand der (ebenfalls angezeigten) Nummer den "Zweck" zuordnen können

(c) Anzeige des (groben) VPN-Status in der "Übersicht" ... ich hoffe, ich habe alle Fälle richtig unterschieden bei der Anzeige - wobei mir die Anzeige eher egal ist, für mich selbst war und ist der direkte Link auf die VPN-Seite viel entscheidender

Warum AVM die VPN-Anzeigen von der Startseite entfernt hat, weiß ich auch nicht so richtig ... ich habe bei mir (13 Verbindungen, 3 aktiviert, 1 verbunden - und das ist i.d.R. bei der Anzahl der Verbindungen schon mehr, als der Durchschnittshaushalt da pflegen würde) einen Zeitunterschied unter 100 ms festgestellt, das bewegt sich bei den ansonsten 2,5 Sekunden so eines Roundtrips schon fast an der Grenze der Meßungenauigkeit.

- die Binärdateien zum Entpacken und Packen von SquashFS-Images wurden alle durch statisch gelinkte Versionen ersetzt, die jeweils mit dem Freetz-Trunk und den dort möglichen Einstellungen in "make menuconfig" erzeugt wurden

- die Busybox hat zwar jetzt selbst ein "blkid"-Applet erhalten, das taugt aber generell nicht für die Analyse einer Image-Datei

Da es mit "blkid" ja ab und an Probleme gibt (z.B. bei Modellen ohne NAS nicht immer definitiv vorhanden) und das Applet für diesen Zweck nichts taugt, habe ich die Formaterkennung auf ein kleines Programm umgestellt, was m.W. in jeder AVM-Firmware enthalten ist. Das nennt sich "testvalue" und kann aus einer Datei an einem angegebenen Offset einen 1-, 2- oder 4-Byte-Wert auslesen und als Dezimalzahl anzeigen. Mit diesem kleinen Programm habe ich jetzt einfach die Erkennung von SquashFS-Images und von ext2-Images nachgebaut, etwas anderes ist bisher in freier Wildbahn m.W. bei AVM nicht gesichtet worden.

- fast alle Aufrufe von Kommandos aus "modfs" heraus erfolgen jetzt direkt über die beigelegte Busybox, nur bei den normalerweise als "shell builtins" bekannten Kommandos (cd, pwd, echo, read, usw.) habe ich auf diesen expliziten Aufruf verzichtet

- es liegt jetzt ein mke2fs bei (ebenfalls mit der Freetz-Toolchain erzeugt), das allerdings dynamisch gelinkt ist (zumindest teilweise) und noch die ld-uclibc.so, die libc.so und die libpthread.so in passender Version braucht, das sollte aber kein Problem sein, solange die uClibc in der Version 0.9.33.2 vom Host-System verwendet wird ... damit sollte man einen "modfs-USB-Stick" problemlos einrichten können, zumindest eine passende ext3-Partition, nachdem man mit dem fdisk der Busybox die Partitionen eingerichtet hat (am besten noch vorher mit dd die alte Partition-Table löschen)

- Voraussetzung bei den AVM-Kommandos sind jetzt nur noch die Dateien

/bin/testvalue (für die Formaterkennung)
/sbin/update_kernel (für das Löschen von NAND-Partitionen und das Schreiben des Kernels, hier hätte man wahrscheinlich auch die Busybox-Applets nehmen können, aber sicherer sind wohl die AVM-Programme - weil besser "angepaßt", sollte man zumindest unterstellen können)
/bin/showshringbuf (für das Schreiben und Auslesen der Protokolldatei)

- die Platzanforderungen für alle "update"-Aufrufe wurden korrigiert und jeweils auf den "worst case" (4 MB Kernel-Partition, 48 MB Filesystem-Partition als Berechnungsgrundlage) angepaßt und sind nun nicht mehr am "derzeitigen Stand" orientiert

- die Behandlung von SquashFS4-Images beim frischen Download vom AVM-Server sollte jetzt auch funktionieren (möglich, daß ich das schon vorher irgendwo geschrieben hatte)

Solange niemand grundlegende Fehler findet, wird 0.3.4 hier eingefroren und zur 0.4 hin will ich dann wirklich einiges unter der Haube ändern - schon hier konnte ich einfach nicht mehr sämtliche denkbaren Fälle vor der Veröffentlichung testen; es würde schlicht zu lange dauern und so muß ich das nun tatsächlich wieder in kleinere unabhängige Einheiten zerlegen.

- - - Aktualisiert - - -

Ok, sieht so aus als würde vBulletin jetzt selbst Beiträge zusammenfassen, um "schieben" zu verhindern ... das ist in diesem Falle eher unglücklich, aber ich selbst kann damit leben. Unangenehm finde ich nur, daß die originale Zeit des Beitrags nicht erhalten bleibt ... das macht die chronologische Einordnung dann ziemlich schwer bis unmöglich.

 

[Shirocco88]

Nächste Version 0.3.4 (als "Zwischenupdate" zum Abarbeiten der Issues) ...
Änderungen:
- fast alle Aufrufe von Kommandos aus "modfs" heraus erfolgen jetzt direkt über die beigelegte Busybox, nur bei den normalerweise als "shell builtins" bekannten Kommandos (cd, pwd, echo, read, usw.) habe ich auf diesen expliziten Aufruf verzichtet

Hallo PeterPawn,
zuerst mal vielen Dank für das wunderbare Tool modfs!!!

mir sind noch einige Skriptzeilen aufgefallen, die verbessert werden können, um die angesprochene Abhängigkeit zu AVM-Modifikationen aufzulösen:

diff modfs modfs._changed_
--- modfs
+++ modfs._changed_
@@ -667,7 +667,7 @@
                                                unpack_squashfs "$src" "$tmp" 2>&1 >/dev/null
                                                rc=$?
                                                if [ $rc -eq 0 ]; then
-                                                       rmdir "$tmp/wrapperfs"
+                                                       $bb rmdir "$tmp/wrapperfs"
                                                        [COLOR=#0000ff]$bb[/COLOR] mv "$tmp/$squashfsdirname" "$tmp/wrapperfs"
                                                        rc=$?
                                                        $bb rm "$tmp/wrapperfs/$rootfsname"
@@ -2790,7 +2790,7 @@
                                                target="$working_directory/$rootfsname"
                                        fi
                                        progress 1 134
-                                       [ $rc -eq 0 ] && mv "$image_directory/$rootfsname" "$target"
+                                       [ $rc -eq 0 ] && [COLOR=#0000ff]$bb[/COLOR] mv "$image_directory/$rootfsname" "$target"
                                        rc=$?
                                        if [ $rc -ne 0 ]; then
                                                progress 3 97
#

in Subdir modfs-0.3.4/modscripts wären folgende Skripte bzgl. Umstellung auf das eigene modfs/bin/busybox-Binary/-Applets optimierungsfähig:

copy_binaries:
# grep -E "cat |chmod |cp |date |dd |find |ftpget |grep |gunzip |losetup |mkdir |mkfifo |mount |mv |readlink |realpath |rm |rmdir |sed |sh |sort |stat |tar |touch |tr |umount |wget " copy_binaries
                        gunzip -c $srcfile | tar x -C $rootdir
#


dectcmds.modscript:
# grep -E "cat |chmod |cp |date |dd |find |ftpget |grep |gunzip |losetup |mkdir |mkfifo |mount |mv |readlink |realpath |rm |rmdir |sed |sh |sort |stat |tar |touch |tr |umount |wget " dectcmds.modscript
        local line=$(sed -n -e "/^ *https:/=" $hookfile)
        cat >$tmpfile <<EOT
        sed -e "${line}r $tmpfile" -i $hookfile
                grep -q $detect $rootdir/$hookfile 2>/dev/null 1>&2
                grep -q $detect $rootdir/$hookfile 2>/dev/null 1>&2
#


mod_default_show_mac:
# grep -E "cat |chmod |cp |date |dd |find |ftpget |grep |gunzip |losetup |mkdir |mkfifo |mount |mv |readlink |realpath |rm |rmdir |sed |sh |sort |stat |tar |touch |tr |umount |wget " mod_default_show_mac
                grep -q "$unchanged" $check_filename 2>/dev/null 1>&2
                grep -q "$unchanged" $check_filename 2>/dev/null 1>&2
# 


mod_leddisplay:
# grep -E "cat |chmod |cp |date |dd |find |ftpget |grep |gunzip |losetup |mkdir |mkfifo |mount |mv |readlink |realpath |rm |rmdir |sed |sh |sort |stat |tar |touch |tr |umount |wget " mod_leddisplay
                grep -q "$check_trigger" $check_filename 2>/dev/null 1>&2
                grep -q "$check_trigger" $check_filename 2>/dev/null 1>&2
#


mod_mount_by_label:
# grep -E "cat |chmod |cp |date |dd |find |ftpget |grep |gunzip |losetup |mkdir |mkfifo |mount |mv |readlink |realpath |rm |rmdir |sed |sh |sort |stat |tar |touch |tr |umount |wget " mod_mount_by_label
line1="local \$(/sbin/blkid /dev/\\\${1}\\\${3} | sed -n -e 's/^[^ ]* \\\(.*\\\)/\\\1/p');[ \${#LABEL} -gt 0 ] && eval echo \$LABEL && return"
        line="$(sed -n -e "\\%$needle%p" $modfile)"
                        sed -e "$line_rep" -i "$modfile"
                        sed -e "/^nicename/a$line1" -e "/^device_info=/a$line2" -i "$modfile"
#


mod_prefer_fonnumber_name:
# grep -E "cat |chmod |cp |date |dd |find |ftpget |grep |gunzip |losetup |mkdir |mkfifo |mount |mv |readlink |realpath |rm |rmdir |sed |sh |sort |stat |tar |touch |tr |umount |wget " mod_prefer_fonnumber_name
                grep -q "$check_trigger" $check_filename 2>/dev/null 1>&2
                grep -q "$check_trigger" $check_filename 2>/dev/null 1>&2
#


mod_rc_tail_sh:
# grep -E "cat |chmod |cp |date |dd |find |ftpget |grep |gunzip |losetup |mkdir |mkfifo |mount |mv |readlink |realpath |rm |rmdir |sed |sh |sort |stat |tar |touch |tr |umount |wget " mod_rc_tail_sh
        line="$(sed -n -e "\\#$insertline#p" $modfile)"
                        mkdir -p "$tmpdir"
                        cat "$tmpdir/tffs" >"$tmpdir/content" 2>/dev/null
                        rm -r $tmpdir
                sed -e "\$i$insertline" -i "$modfile"
#


mod_show_vpn_on_overview:
# grep -E "cat |chmod |cp |date |dd |find |ftpget |grep |gunzip |losetup |mkdir |mkfifo |mount |mv |readlink |realpath |rm |rmdir |sed |sh |sort |stat |tar |touch |tr |umount |wget " mod_show_vpn_on_overview
                grep -q "$check_trigger" $check_filename 2>/dev/null 1>&2
                grep -q "$check_trigger" $check_filename 2>/dev/null 1>&2
#

ggf. müßte hier zusätzlich noch die bb-Umgebungsvariable durchgereicht oder gesetzt werden

# the name of the busybox to be used, will be changed later
bb="/bin/busybox"
# switch to our own version of Busybox
bb="$(bindir)/busybox"

Bitte nicht falsch verstehen, ist nur ein Verbesserungsvorschlag.

die Binärdateien zum Entpacken und Packen von SquashFS-Images wurden alle durch statisch gelinkte Versionen ersetzt, die jeweils mit dem Freetz-Trunk und den dort möglichen Einstellungen in "make menuconfig" erzeugt wurden

Frage: ich würde gerne die Tools "bin/VR9/unsquashfs4, bin/VR9/unsquashfs3, bin/VR9/mksquashfs4, bin/VR9/mksquashfs3" gerne mal selber compilieren wollen;
ich habe hier nachgesehen https://github.com/PeterPawn/freetz/tree/master/make/squashfs3, https://github.com/PeterPawn/freetz/tree/master/make/squashfs4
konnte aber die Sources/Patches nicht finden; Wie kann ich diese compilieren ? any tips are welcome.

LG Shirocco88

 

[PeterPawn]

@Shirocco88:
Jede Fundstelle im "modfs"-Skript, die ohne "$bb" ist und nicht nur die erwähnten "builtins" betrifft, ist sehr willkommen ... so etwas ist halt ein Arbeitsschritt, bei dem man immer etwas übersehen kann. Ich hatte zwar selbst mit "grep" nach allen möglichen Fundstellen gesucht (gerade bei "sed" in langen Pipes war das anders kaum zu finden), aber dabei wohl "rm" "rmdir" und "mv" vergessen (bzw. überlesen).

Bei den Modscripts hatte ich ein wenig die Lust verloren - da muß man gerade bei den Versionen mit dem "inline patch" so höllisch aufpassen. Dort sorgt einerseits die Auflösung von Shell-Variablen ja dafür, daß die Patch-Ziele in der Datei richtig auf die Brandings aufgelöst werden (durch "$TARGET_BRANDING"), auf der anderen Seite führt jedes Dollar-Zeichen in dem zu patchenden Text dann zu zusätzlicher Arbeit, wenn man es erst "maskieren" muß.

Da ich auf der anderen Seite sichergestellt habe, daß die Modscripts mit einer gesonderten Shell-Instanz aufgerufen werden (Variable $shl) und die Busybox mit CONFIG_FEATURE_PREFER_APPLETS=y erstellt wurde:
Anhang anzeigen 85950
, sollte auch jeder Aufruf ohne $bb vor dem Namen eines Applets in dieser Busybox erst einmal innerhalb der Busybox selbst suchen (am Ende wird ja genau derselbe Mechanismus benutzt beim Aufruf von /proc/self/exe) und erst dann nach externen Kommandos sehen. Das ist beim Aufruf von "modfs" selbst - zumindest unter gewissen Umständen und Ziel hier ist ja identisches Verhalten unter allen Umständen und "Host-Systemen" (das ging ja teilweise schon beim "tar" und "short read" los mit Problemen) - eben noch nicht der Fall, auch wenn ich tatsächlich darüber nachgedacht hatte, anstelle der ganzen "$bb"-Zusätze einfach noch eine neue Shell-Instanz (aus der "eigenen Busybox") für die Ausführung zu verwenden.

Die ursprünglichen Patches für die SquashFS-Tools stehen nicht im GitHub (den Umzug habe ich erst Ende 2015 vorgenommen), sondern irgendwo auf yourfritz.de - wo genau, steht hier irgendwo im Thread (ich tippe mal auf #1).

Da aber die notwendigen Änderungen inzwischen schon lange im Freetz-Trunk enthalten sind (das müßte so Juli/August 2015 gewesen sein), bin auch ich selbst inzwischen ja weg von den eigenen Patches (warum sollte man sich solche Arbeit zweimal machen und solange das in Freetz 1:1 mit allen Funktionen vorhanden ist, nehme ich spätestens für die Veröffentlichung eben auch lieber Freetz - daß das leider nicht immer möglich ist wg. funktioneller Unterschiede, steht auf einem vollkommen anderen Blatt).

Wenn Du also die SquashFS-Tools aus der aktuellen Version nachbauen willst, brauchst Du nur den Freetz-Trunk und da dort die Auswahl an denkbaren Einstellungen nun nicht sooo kompliziert ist (lediglich "statisch linken" wäre zu beachten, wenn dieselben Programme entstehen sollen), habe ich dafür keine gesonderte Anleitung vorgesehen.

Ansonsten hatte ich zu den bisher verwendeten SquashFS-Tools hier etwas geschrieben (und hier zu den Versionen für x86, die auf yourfritz.de zur Verfügung stehen) - während auch dieser Meinungsaustausch mit Eugene ja Teil der Historie ist und es irgendwo eigentlich auch noch einen Beitrag geben müßte, wo ich den Übergang auf die statisch gelinkten Tools für SquashFS4 thematisiere (die hatten ein Dateidatum vom 14.12.2015, dann wird das irgendwann in dem Dreh gewesen sein).

Aber das ist eigentlich alles in diesem Thread enthalten und leider muß/will ich dann darauf verweisen, daß - über die o.a. Erläuterungen zu den aktuellen Binaries hinausgehende - Kommentare zu den verwendeten Binärdateien bitte selbst auszugraben wären.

Ich bin auch immer wieder selbst erstaunt, wie oft ich mich doch wiederhole (sorry dafür) ... ich habe gerade in #113 die Argumentation pro Modularisierung und "unit tests" (von mir selbst geschrieben) gelesen, die ich vor kurzem erst hier wiederholt habe.

 

[Riverhopper]

(b) Anzeige des Namens der (eigenen) Telefonnummer in der Anrufliste für diejenigen, die nicht sofort anhand der (ebenfalls angezeigten) Nummer den "Zweck" zuordnen können

hallo PeterPawn,
Danke für modfs und die Bereitstellung Feature-Enhancements in modfs-0.3.4.

Installation bei FB7490-06.51 hat problemlos funktioniert.
Bei Nutzung modscripts/mod_prefer_fonnumber_name bin ich jedoch an Grenzen gestoßen.
ich möchte in der Anrufliste die Spalte "Eigene Rufnummer" statt den dezimalen VOIP-Nr. die DECT-Namen darstellen lassen;

# ./modfs update FRITZ.Box_7490.113.06.51.image
SNIP
Die Modifikation 'show phone number names' wird verarbeitet ...
Überprüfen der unterstützten Sprachen ... OK
Soll die Modifikation 'show phone number names' mit folgender Beschreibung
Anzeige des Namens einer eigenen Telefonnummer in der Anrufliste
angewendet werden? (j/N) j
Überprüfen der Voraussetzungen für die Modifikation ... OK
Modifikation wird ausgeführt ... OK
patching file usr/lua/foncalls.lua
Überprüfen des Erfolgs der Modifikation ... OK
Die Modifikation 'show phone number names' wurde angewendet, Fehlercode = 0.
SNIP

Leider zeigt die Anrufliste http://fritz.box/?lp=dialLi bzw. http://fritz.box/?lp=calls
bei mir auch nach modfs-0.3.4/modscripts/mod_prefer_fonnumber_name keine DECT-Namen an.

Frage: Mache ich hier etwas falsch ?
funktioniert dies nur bei ISDN-Geräten mit MSN ?
gibt es eine Möglichkeit für VOIP-Geräte die Bezeichnung der Telefongeräte aus http://fritz.box/?lp=telDev in der Anrufliste "Eigene Rufnummer" darzustellen ?

LG Riverhoper

 

[PeterPawn]

@Riverhopper:
Der Patch soll eigentlich nur die den "Eigenen Rufnummern" zugeordneten Namen in der Liste anzeigen ... insofern verstehe ich den Zusammenhang zu Geräten (egal ob es sich um DECT- oder VoIP-/SIP-Telefone handelt) nicht so richtig.

Wenn man eine Rufnummer richtig benennt (eine heißt bei mir z.B. "CallThrough"), dann sollte auch bei einem eingehenden Anruf auf dieser Rufnummer anstelle von derem "platten" numerischen Wert dieser Name, gefolgt von der Nummer in Klammern, angezeigt werden.

Am Ende macht der Patch ja eigentlich nichts anderes, als den Wert von msn_name aus dem Eintrag für den Anruf im foncalls-Objekt zu lesen und bei Vorhandensein eines Wertes (ungleich leer) einen abweichenden Aufbau des Wertes zu erzeugen.

Das geht natürlich prinzipiell auch für jede andere Property so eines Eintrags, daß man da Änderungen vornehmen könnte. Am Ende habe ich aber im Moment nicht einmal eine richtige Vorstellung, was Du da in Deiner Anrufliste zu sehen erwartest ... das macht dann irgendwelche Hinweise, wo man genau suchen sollte (allgemein eben in der foncalls.lua), eher sinnlos.

Anhang anzeigen 85952Anhang anzeigen 85953Anhang anzeigen 85954

 

[Riverhopper]

Anhang anzeigen 85954

Hallo PeterPawn,
Vielen Dank! dies war die Lösung !

nachdem ich das Feld "telcfg:settings/SIP0/Name" befüllt habe, werden nun alle neuen Anrufe in Anrufliste richtig dargestellt.

Old:

# echo "VOIP_NAME_0=telcfg:settings/SIP0/Name" | ./queries.lua
VOIP_NAME_0=""
#

Neu:

# echo "VOIP_NAME_0=telcfg:settings/SIP0/Name" | ./queries.lua
VOIP_NAME_0="DECT_612"
#

LG Riverhopper

EDIT: Text bzgl. Plausibilitätsprüfung herausgenommen

 

[eisbaerin]

"UTF-8"

Jo, danke. Aber das muß mir ja erst mal einer sagen, andere riechen das wahrscheinlich.
In Putty konnte ich es einstellen. Nur im normalen Win-FTP, den ich öfters nutze, gibt es soweit ich gesucht habe keine Möglichkeit, das um zu stellen.

---

Ich hatte ja noch eine dualboot FB vergessen in meiner Analyse (#550). Die 5490!
Für die gibt es komischerweise auch unter dem Unterpfad /deutsch nur eine int. FW:
FRITZ.Box_5490.de-en-es-it-fr-pl.151.06.51.image

Entpacken ging komischerweise mit modfs0.3.3 nicht, Fehler:
(alle 16 anderen FW, auch int. gingen ja)

Im Moment läuft auf der Box die Version: 113.06.51

Die Angabe einer Datei nach dem 'update'-Parameter unterbindet jede Versionprüfung.
Somit ist jeder selbst dafür zuständig, die Kompatibilität der vorhandenen Einstellungen
mit dem verwendeten System sicherzustellen, speziell wenn ein Downgrade ausgeführt wurde
oder ggf. die 'Werkseinstellungen' wiederherzustellen.

Die angegebene Datei '/var/media/ftp/FRITZ.Box_5490.de-en-es-it-fr-pl.151.06.51.image' wird als Quelle für die Aktualisierung genutzt.
Extrahieren des neuen Kernel-Images aus dem Firmware-Image ... [COLOR="#FF0000"]Fehler[/COLOR]
Beim Extrahieren des Kernel-Abbilds aus der Firmware-Datei ist ein Fehler aufgetreten.

(Brauchst du eine Protokolldatei, dann mach ich es extra noch mal)

Ich habe es dann mit modfs 0.3.4 probiert, und da ging es.

Und jetzt darfst du mal raten, aber du kommst eh nicht drauf, in welche der 3 Gruppen aus #550 die FB sich ansiedelt.

Sie gehört in die Gruppe der FB7412. Ich habe es in #550 ergänzt.

 

[PeterPawn]

@eisbaerin:
Dem FTP-Server/-Client dürfte der verwendete Zeichensatz herzlich egal sein, es sei denn, da enthalten Dateinamen entsprechende Sonderzeichen. Genau dafür gibt es ja die passenden Parameter beim Mounten von "exotischen" Dateisystemen wie FAT oder NTFS unter Linux, damit dort eine entsprechende Anpassung vorgenommen werden kann.

Die Tatsache, daß die FRITZ!Boxen inzwischen alle auf UTF-8 setzen (bei neuerer Firmware), sollte sich spätestens mit der Existenz des kleinen Programms namens "conv2utf8" herumgesprochen habe, damit wurde (ob da "wird" stehen müßte, weiß ich nicht genau, mü0te ich erst wieder nachsehen) genau die Konvertierung der event. von älteren Versionen in ISO-Kodierung gespeicherten Dateinamen in das entsprechende UTF-8-Format ausgeführt. Aber das ist bereits vor so langer Zeit passiert (und mindestens so lange müßten dann bei Dir schon die Umlaute und einige andere Zeichen eben genauso falsch dargestellt werden), daß ich mich trotz (oder wegen) meines hohen Alters fast nicht mehr daran erinnern kann.

@Riverhopper:
Ich sehe nicht, welche Plausibilitätsprüfung es da geben könnte ... das fängt schon damit an, daß man bei mehreren Nummern ja nicht jeder einen Namen geben muß (mithin SIP0 als Test untauglich ist) und selbst ein fehlender Name (selbst wenn keine einzige Nummer einen solchen Namen hat) hält die (modifizierte) Firmware ja nicht davon ab, weiterhin problemlos zu funktionieren - da habe ich ja entsprechende Vorsorge getroffen.

 

[eisbaerin]

sollte sich spätestens mit der Existenz des kleinen Programms namens "conv2utf8" herumgesprochen habe,

Nö, was soll ein Windows User damit anfangen? Und bei mir kommt sowieso alles 5-10 Jahre später. (z.B. nutze ich noch WinSCP4.2.5, das nur 1,5MB groß ist, gegenüber dem heutigen WinSCP5.7.6 mit 12MB, ich sehe da keinen Vorteil)

Zu den ersten Zeilen hatte ich eigentlich auch keine Antwort erwartet, da wollte ich dir nur DANKE sagen.

Ich hatte eher eine Reaktion auf den 2. Teil erwartet.

 

[PeterPawn]

@eisbaerin:
Solange ich keine 5490 in freier Wildbahn gesehen haben (zwar habe ich auch gerüchtehalber von dem Feldtest in der Schweiz gehört, aber weder Support-Daten noch irgendwelche anderen Daten jemals gesehen), ist die für mich praktisch nicht existent.

Wenn die sich in die "nur NAND"-Riege einreihen sollte, würde ich das auch noch verstehen ... modernere Prozessoren kommen in der Regel gleich mit dem passenden Controller auch für NAND-Flash, da braucht es dann ggf. nur noch den passenden Chip um sogar diesen NAND-Speicher direkt in den Adressraum einzublenden.

Da das dann fast immer auch noch schneller ist als irgendwelcher SPI-Flash und die Zuverlässigkeit dort ja auch gestiegen ist, braucht es m.E. (das ist nun aber wirklich nichts, wo ich mehr als Hobby-Kenntnisse habe - so ein Geräte-Design ist so gar nicht meine Profession) heutzutage nicht mehr unbedingt NOR-Flash für mehr Schreibzyklen und sichere Speicherung und dann ist es nicht mehr nur ein Kostenfaktor, der in Billig-Geräten zum Fehlen von NOR-/SPI-Flash führt.

Neuere Architekturen (was steckt denn nun drin in der 5490?) bieten da sicherlich bessere/andere Möglichkeiten und wenn irgendwann die "Mono-Kultur" endet (bei anderen Herstellern ist es ja schon länger so, daß da auch unterschiedliche Plattformen verwendet werden - bei AVM waren es bis vor kurzem ja nur 2-3 verschiedene, wenn auch in unterschiedlichen Versionen), dann ist das sicherlich gut auf der einen Seite (wenn ein anderer Hersteller bessere/leistungsfähigere Chipsätze anbietet) und auf der anderen Seite könnte es auch dazu führen, daß AVM aufgrund der mangelnden Erfahrung auf anderen Plattformen ähnliche Fehler unterlaufen, wie anderen Herstellern. Wie so ein "plattformspezifischer Fehler" dann aussehen könnte, war anhand des offenen Ports zur DSL-Diagnose bei den VR9-basierten Geräten bis zur 06.30 ja schön zu sehen ... die "Unverwundbarkeit" der 7390 an dieser Stelle resultierte ja aus dem anderen Chipsatz (und der damit fehlenden Grundlage für den AVM-eigenen Service an dieser Stelle) und nicht auf einem "anderen FRITZ!OS". So etwas gibt es bei anderen Herstellern mit breiterer Produktpalette ja leider zuhauf, daß die Geräte mit dem einen Chipsatz verwundbar sind und die mit einem anderen (mehr oder weniger auch mal zufällig) dann wieder nicht. Wenn das bei AVM auch weiter in die Breite geht, braucht es (meine Meinung) eben auch mehr Leute, die diese ganze Breite dann abdecken können ... da sehe ich eine Gefahr für die Marke, aber das weiß die AVM-GF sicherlich auch und so lasse ich mich da einfach überraschen.

Fazit: Ich wüßte nicht, was ich "nachfragen" sollte ... wenn mich die 5490 jemals interessieren wird, kann ich ja sicherlich ebenso die Firmware vom AVM-Server laden und selbst entpacken. Solange die nicht - wie bei den DOCSIS-Modellen - unter Verschluß gehalten wird (zum Vorgehen ab dem 01.08.2016 in Bezug auf frei verfügbare Firmware-Updates für 6490/6590 habe ich bisher noch nichts Definitives gehört, auch nicht am AVM-Stand in Hannover), ist das ja nicht weiter schwierig.

 

[Riverhopper]

Ich hatte ja noch eine dualboot FB vergessen in meiner Analyse (#550). Die 5490!
Für die gibt es komischerweise auch unter dem Unterpfad /deutsch nur eine int. FW:
FRITZ.Box_5490.de-en-es-it-fr-pl.151.06.51.image
... mit modfs 0.3.4 probiert, und da ging es.

@Riverhopper:
ich denke eine Problemstellung beim "modding" der FB5490 wird sein, wie du die per fwmod geänderte Firmware 151.06.51 auf die Box bekommst;
Web-IF und modfs-Starter wird wohl wg. unisgned-code nicht gehen;
somit bleibt u.U. nur so etwas wie eva_to_memory

LG Riverhopper

EDIT: habe rukt als "möglicher" Kandidat für Flashing vergessen zu erwähnen, jedoch habe ich hier schlechte Erfahrungen mit FB7490 gemacht; hier mußte man ca. 1,5 Jahre warten bis die RUKT-Software im Beta-Status die FB7490 (HW ID 113) nach Verkaufsstart bedienen konnte; und dann noch die Geschichte/Kampf mit dem "Verfallsdatum" der RUKT-Software.

 

[Wäldler.]

und dann noch die Geschichte/Kampf mit dem "Verfallsdatum" der RUKT-Software.

.... und das hat ein bestimmten Grund.Du wirst einer der wenigen sein,der von @skyteddy mal eine Version bekommen hat.
Ich habe mit dem "Verfallsdatum"keine Probleme und kein Kampf.
Ich habe bisher alle gängige FB-Typen mit dem ruKTX getestet.Alles bestens!!!

 

[Riverhopper]

Hallo Wäldler und andere interessierte FB-User,
so wie ich gerade gesehen habe, die Argunemte für und wieder ruKT/ruKTx wurden hier im IPPF schon diskutiert, siehe
http://www.ip-phone-forum.de/showthread.php?t=283039&p=2148622&viewfull=1#post2148622
http://www.ip-phone-forum.de/showthread.php?t=283039&p=2148658&viewfull=1#post2148658
ich sehe hier keine neuen Erkenntnisse, die dem hinzuzufügen wären.

bzgl. dem erwähnten ruktX konnte ich folgenden http://rukerneltoolx.rainerullrich.de/ChangeLog_Long.txt mit abgelaufenem Verfallsdatum 01.03.2016 von ruKTX-V0.7.0.4 finden:

V0.7.0.4, 23.02.2016    -----= Vorab-Version =-----
 - 5490, 6820 LTE, 7560 und 7580 in die Liste der noch nicht flashbaren Router aufgenommen
 - Flash-Support der 7412 und der 7430
 - HWRevisionnummer-Liste modifiziert
 - Firmware-Major-Nummern-Liste modifiziert
 - Erhaltene Flash-Speed-Reports eingearbeitet
 - Kleine Änderungen
 - Testzeitraum bis 01.03.2016, 23:00 Uhr verlängert

V0.7.0.3, 26.01.2016
 - Flash-Support der 3370 und 6840 LTE
 - Erhaltene Flash-Speed-Reports eingearbeitet
 - Info-Links überarbeitet
 - Kleine Änderungen
 - Testzeitraum bis 31.01.2016, 23:00 Uhr verlängert

V0.7.0.2, 16.01.2016
 - Flash-Support der 7362SL
 - Erhaltene Flash-Speed-Reports eingearbeitet
 - Kleine Änderungen
 - Testzeitraum bis 18.01.2016, 23:00 Uhr verlängert

V0.7.0.1, 11.01.2016
 - Programm in der Entwicklungsphase in ruKernelToolX umbenannt
 - Neues temporäres Logo
 - Flash-Support der 7412 (begonnen)
 - Windows-Versionserkennung verbessert
 - Firmware-Erkennung der Sammelliste verbessert 
 - zurück zur Normal-Edition
 - 7zip-Update auf V15.14
 - Kleine Änderungen
 
V0.7.0.0, 31.12.2015
 - 6490 in die Liste der noch nicht flashbaren Router aufgenommen
 - Flash-Support der 7490
 - Viele Code-Änderungen

unklar welche Version Du verwendest,
bzw. wo findet man die URL zum Download-Link dieser ruKTX "alles bestens" Edition ?

Ich habe bisher alle gängige FB-Typen mit dem ruKTX getestet.Alles bestens!!!

hier ist ruKTX IMHO von "Alles bestens" noch weit entfernt oder es ist noch ein weiter Weg anstehend.

LG Riverhopper