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

[KingTutt]

Herzlichen Dank für die Hilfestellungen: Ich habe mir als erstes Deinen Patchvorschlag vorgenommen

++ sh -x ../../tools/yf/bootmanager/add_to_system_reboot.sh
+ '[' -z 1und1 ']'
+ '[' -z . ']'
+ TargetDir=./filesystem/
+ JsFile=usr/www/1und1/system/reboot.js
+ LuaFile=usr/www/1und1/system/reboot.lua
++ expr . : '[0-9]*\.0*\([1-9]*[0-9]\)\.[0-9]*'
+ major=0
++ expr . : '[0-9]*\.[0-9]*\.0*\([1-9]*[0-9]\)'
+ minor=0
+ check_version 0 0 7 8
++ expr 0 : '0*\([1-9]*[0-9]\)'
+ local major=0
++ expr 0 : '0*\([1-9]*[0-9]\)'
+ local minor=0
++ expr 7 : '0*\([1-9]*[0-9]\)'
+ local wanted_major=7
++ expr 8 : '0*\([1-9]*[0-9]\)'
+ local wanted_minor=8
+ '[' 0 -lt 7 ']'
+ return 0
+ printf '      Patching file '\''%s'\'' ...\n' usr/www/1und1/system/reboot.lua
      Patching file 'usr/www/1und1/system/reboot.lua' ...
+ getLuaPatchText_pre0708
+ cat
+ sed -f /home/stefan/tmp/tmp.Kcz5YYUcxU/gui_bootmanager_0_6_tmp -i ./filesystem/usr/www/1und1/system/reboot.lua
+ rm /home/stefan/tmp/tmp.Kcz5YYUcxU/gui_bootmanager_0_6_tmp
++ set +x
    adding boot-manager front end to branding "avm"
++ TARGET_BRANDING=avm
++ TARGET_SYSTEM_VERSION=.
++ TARGET_DIR=./filesystem
++ TMP=/home/stefan/tmp/tmp.Kcz5YYUcxU
++ sh -x ../../tools/yf/bootmanager/add_to_system_reboot.sh
+ '[' -z avm ']'
+ '[' -z . ']'
+ TargetDir=./filesystem/
+ JsFile=usr/www/avm/system/reboot.js
+ LuaFile=usr/www/avm/system/reboot.lua
++ expr . : '[0-9]*\.0*\([1-9]*[0-9]\)\.[0-9]*'
+ major=0
++ expr . : '[0-9]*\.[0-9]*\.0*\([1-9]*[0-9]\)'
+ minor=0
+ check_version 0 0 7 8
++ expr 0 : '0*\([1-9]*[0-9]\)'
+ local major=0
++ expr 0 : '0*\([1-9]*[0-9]\)'
+ local minor=0
++ expr 7 : '0*\([1-9]*[0-9]\)'
+ local wanted_major=7
++ expr 8 : '0*\([1-9]*[0-9]\)'
+ local wanted_minor=8
+ '[' 0 -lt 7 ']'
+ return 0
+ printf '      Patching file '\''%s'\'' ...\n' usr/www/avm/system/reboot.lua
      Patching file 'usr/www/avm/system/reboot.lua' ...
+ getLuaPatchText_pre0708
+ cat
+ sed -f /home/stefan/tmp/tmp.Kcz5YYUcxU/gui_bootmanager_0_6_tmp -i ./filesystem/usr/www/avm/system/reboot.lua
+ rm /home/stefan/tmp/tmp.Kcz5YYUcxU/gui_bootmanager_0_6_tmp
++ set +x
    adding boot-manager back end script

dann habe ich noch einmal einen diff auf die beiden Dateien gemacht:

diff fwmod_kernel-113.07.11M/original/filesystem/usr/www/avm/system/reboot.lua fwmod_kernel-113.07.11M/modified/filesystem/usr/www/avm/system/reboot.lua
75a76,80
> if box.post.linux_fs_start then
> local linux_fs_start = string.gsub(box.post.linux_fs_start, "'", "")
> local branding = box.post[linux_fs_start.."_branding"] ~= nil and string.gsub(box.post[linux_fs_start.."_branding"], "'", "") or ""
> os.execute("/usr/bin/gui_bootmanager switch_to '"..linux_fs_start.."' '"..branding.."'")
> end

Die Dateien reboot.js sind identisch, also muss irgendetwas schon beim patchen schiefgehen.
Aus dem Bauch heraus würde ich sagen, das Problem steckt in der Zeile "getLuaPatchText_pre0708" da die Firmware 07.11 etwas alla 0708orlater" sein müsste?

Ein schneller Blick in die add_to_system_reboot.sh lässt mich vermuten, dass die TARGET_SYSTEM_VERSION vermutlich nicht korrekt gesetzt wird. <-- OK, während ich bearbeitet habe, bestätigt der folgende Post das schon...

 

[PeterPawn]

Ne, das Problem liegt hier:

++ TARGET_SYSTEM_VERSION=.

, denn das ist keine vernünftige Versionsnummer.

Stellt sich als Nächstes die Frage, warum bei Dir die Variablen "AVM_FW_MAJOR" und "AVM_FW_VERSION" nicht gesetzt sind: https://github.com/Freetz/freetz/blob/master/fwmod#L652

Zwar werden die beiden Werte tatsächlich nicht mit "export" für Kindprozesse verfügbar gemacht, aber die Patch-Skripte werden in "fwmod" ja auch mit dem "source"-Kommando eingebunden und verwenden daher exakt dieselbe Umgebung, wie das "fwmod"-Skript selbst: https://github.com/Freetz/freetz/blob/master/fwmod#L851

Wie kommt man also an die Zeile 851 für die Datei "patches/scripts/800-modfs_boot_manager.sh", ohne zuvor die Zeile 652 passiert zu haben? Denn aus diesen beiden Variablen wird dann ja im Patch-Skript das Environment für mein eigenes Shell-Skript zum Patchen der Dateien gebildet: https://github.com/Freetz/freetz/blob/master/patches/scripts/800-modfs_boot_manager.sh#L13

 

[KingTutt]

Ich bin keine Experte, allerdings wäre es vermutlich hilfreicher gewesen, wenn ich auch den Teil vorher mitgepostet hätte. Der bootmanager wird über fwmod_custom installiert, erkenntlich an der Ausgabe "invoking custom script":

./fwmod -p -s -d fwmod_kernel-113.07.11M ~/software/AVM/FritzBox/firmware/fbf-wlan-7490/FRITZ.Box_7490-07.11.image
detected firmware 7490_de 113.07.11 rev68718 (22.05.2019 10:47:40)

STEP 3: PACK/SIGN
WARNING: Modifications (STEP 2) and this step should never
         ever be run with different configurations!
         This can result in invalid images!!!
WARNING: firmware does not seem to be modified by the script
invoking custom script
  applying webmenu signed patch
    patching ./filesystem/usr/www/1und1/home/home.js
    patching ./filesystem/usr/www/1und1/home/home.lua
    patching ./filesystem/usr/www/1und1/system/diagnosis.lua
    patching ./filesystem/usr/lua/retrieve_data.lua
    patching ./filesystem/usr/www/avm/home/home.js
    patching ./filesystem/usr/www/avm/home/home.lua
    patching ./filesystem/usr/www/avm/system/diagnosis.lua
    patching ./filesystem/usr/lua/retrieve_data.lua
  adding modfs boot-manager
...
...
...

Die Frage ist also, ob an den Funktionsaufruf "invoke_fwmod_custom" welche im Unterverzeichnis tools/freetz_functions definiert ist, die Variablen "AVM_FW_MAJOR" und "AVM_FW_VERSION" übergeben werden, wenn sie nicht mit "export" für Kindprozesse verfügbar gemacht werden?

 

[PeterPawn]

Dann sehe ich diese Möglichkeiten:

1. Den Weg über "make" und den "no-freetz"-Modus nehmen: https://freetz.github.io/wiki/help/howtos/development/repack_fw.html

2. Die Variablen selbst exportieren, nachdem sie in "fwmod" ermittelt wurden. Zur generellen Thematik, was von "fwmod" an "fwmod_custom" (oder andere Hooks) an Werten übergeben wird und was nicht, hatte ich mich mit @er13 mal "unterhalten": https://github.com/Freetz/freetz/issues/171 - m.W. müßtest Du im Moment den Export noch selbst einbauen, weil von "fwmod" nichts in dieser Richtung bereitgestellt wird.

3. Du rufst gar nicht das "800-modfs_boot_manager.sh" auf aus Deiner "fwmod_custom": https://github.com/Freetz/freetz/blob/master/patches/scripts/800-modfs_boot_manager.sh - sondern direkt das Skript zum Patchen: https://github.com/PeterPawn/YourFritz/tree/master/bootmanager ... aber auch dem mußt Du dann irgendwie die Version des Zielsystems mit auf den Weg geben. Das wäre wahrscheinlich nur dann eine sinnvolle Option, wenn Du den Rest der Freetz-Dateien unangetastet lassen willst und Deine Änderungen auf die "fwmod_custom" beschränken möchtest. Wenn Du allerdings sicher bist, daß Du künftig nur noch Versionen jenseits der 07.08 bauen wirst, kannst Du die Versionsnummer ja auch fest verdrahten (es gibt nur die Unterscheidung "vor 07.08" und "danach" in meinem Skript zum Patchen) und mußt sie nicht erst ermitteln.

4. Du änderst tatsächlich das Freetz-Skript (800-modfs_boot_manager.sh) so, daß die Versionsnummer fix gesetzt wird.

Bestimmt gibt es auch noch andere "Mischformen" ... aber wie auch immer Du Dich entscheidest, die vier Angaben, die meinem Patch-Skript "von außen" übergeben werden müssen (das wird ja auch von "modfs" in exakt dieser Form eingesetzt, daher stammen auch die Namen der Variablen), habe ich in der "README.md" im "bootmanager"-Verzeichnis des "YourFritz"-Repos aufgeführt (Link steht oben schon mal).

 

[er13]

Sowohl beim Entwickeln von ae5db378 als auch beim Mergen wurde übersehen, dass 800-modfs_boot_manager.sh auch im "no-freetz"-Modus aufgerufen wird. Dass man etwas manuell exportieren muss... so ist es natürlich nicht gedacht.

 

[PeterPawn]

Sowohl beim Entwickeln von ae5db378 als auch beim Mergen wurde übersehen, dass 800-modfs_boot_manager.sh auch im "no-freetz"-Modus aufgerufen wird.

Ja, das funktioniert dann tatsächlich nur wie erwartet, wenn es im Rahmen der Patches zur Modifikation der Firmware aufgerufen wird. Dabei hatte ich extra noch nachgesehen, daß der Aufruf in "fwmod_custom" ebenfalls über "source" erfolgt, wie auch in "fwmod". Damit entfällt dann Punkt 1 oben als mögliche Lösung.

Denn mir war bewußt, daß es auch im "no-freetz"-Modus enthalten ist bzw. aufgerufen wird, aber auf die Idee, daß der Aufruf desselben Skript-Files (alles noch innerhalb des Spielraums, den einem das "originale" Freetz läßt) mit demselben Konstrukt (source) auf zwei unterschiedlichen Wegen erfolgt und dabei dann auch eine komplett andere Umgebung vorliegen kann (bis hin zu den gesetzten Variablen), muß man auch erst mal kommen (selbst wenn ich es in Grenzen nachvollziehen kann, warum man das macht) - das sind ja praktisch zwei getrennte Interfaces und das überrascht (die meisten) dann schon.

Mir ist jedenfalls bisher auch keine Datei in Freetz bekannt, in der auf diesen Umstand hingewiesen wird, damit man beim Schreiben neuer Patches dann auch weiß, worauf man achten muß. Das Inkludieren der ganzen anderen Variablen und Funktionen (freetz_functions, freetz_patch (hier würde dann "freetz_functions" auch automatisch geladen: https://github.com/Freetz/freetz/blob/master/tools/freetz_patch#L235), .config) ist ja auch in "fwmod_custom" im "no-freetz"-Teil enthalten - hier wäre die letztens angerissene Frage, was da noch alles aus "fwmod" "ausgelagert" werden kann/sollte und was andere (inkl. "fwmod_custom") dann nachnutzen können, vielleicht erneut zu stellen.

--------------------------------------------------------------

Ich sehe jedenfalls keinen anderen, gangbaren Weg, als das anhand der Versionsnummern zu entscheiden (denn genau dasselbe Skript "add_to_system_reboot.sh" wird auch von "modfs" aus genutzt und ich habe keinen Bock, da mehr als eine Version zu verwalten) ... alles andere, was mir noch einfallen würde (z.B. die Existenz irgendeiner Datei abzufragen, die erst ab Labor 07.08 vorhanden ist), um die Versionen zu trennen, ist beim nächsten Update genauso in der Gefahr, nicht länger zu funktionieren ... während die nächste und jede künftige Versionsnummer immer noch > 07.08 sein wird und damit nur bei Änderungen von AVM am JS-Code erneut eingegriffen werden müßte mit einem weiteren "Zweig".

Vielleicht wäre es ja doch keine soo schlechte Idee, auch dem "fwmod_custom"-Skript (und allen anderen Hooks - quasi im Vorbeigehen - dann eben auch) eine definierte Umgebung zur Verfügung zu stellen. Ich sehe jedenfalls nicht, wie die Aufgabenstellung hier ohne die Versionsnummer (sicher) funktioniert ... woher die beim Aufruf aus der "800-modfs_boot_manager.sh" am Ende kommt und ob sie wirklich stimmt, interessiert mich gar nicht wirklich.

Das kann meinetwegen also eine exportierte Variable sein oder es gibt dann doch die bereits irgendwo "angeregte" Library, aus der "fwmod" aufgebaut wird und die dann u.a. auch die Funktionen zum Ermitteln der Versionsnummer des Zielsystems bereitstellt - denn es macht sicherlich weniger Sinn, wenn jedes Skript, das für mehr als eine bestimmte FRITZ!OS-Version funktioniert und trotzdem zwischen diesen Versionen unterscheiden muß, das für sich selbst ermitteln soll.

Ich fände es jedenfalls plausibel, wenn die "freetz_functions" - die nach meiner Ansicht im Moment ein wenig ein ähnlicher "Gemischtwarenladen" ist, wie "firmwarecfg" bei AVM - nach "Verwendungszweck" aufgesplittet und dabei auch erweitert würde um Funktionen, die User-Scripts genauso benötigen wie "fwmod" selbst ... eben auch das Ermitteln der Version des Zielsystems.

Bisher mag das in Freetz wegen der anderen Philosophie kein Thema (gewesen) sein ... in Freetz wird dann eben für eine neue Version irgendwo wieder ein neues Unterverzeichnis angelegt ... und so fächert sich das immer weiter auf und sei es nur mit entsprechenden Symlinks, die von einer Version zur nächsten zeigen, wenn sich eine solche Datei nicht ändert.

--------------------------------------------------------------

Die Option, das wieder unterhalb irgendwelcher versionsspezifischer Verzeichnisse in Freetz abzulegen, gäbe es sicherlich auch ... nur klappt das dann eben nicht mehr in der Form, wie ich es in "modfs" verwende und diese habe ich bewußt gewählt. Bis zu diesem Commit (https://github.com/PeterPawn/YourFritz/commit/abad8702106a16eff5243c3c1eb86953fdf6f0a7) gab es tatsächlich noch die Idee zweier getrennter Skript-Dateien zum Modifizieren der AVM-Files - das habe ich dann aber verworfen, als ich feststellte, wie unhandlich das in anderen Situationen (konkret unter "modfs"-Bedingungen) am Ende ist. Der derzeitige Ansatz (und Aufbau) des Patch-Skripts gestattet auch den Ausbau, wenn es eine dritte, vierte, fünfte, usw. Variante in Abhängigkeit von der FRITZ!OS-Version geben sollte.

Wer das also in Freetz ohne "add_to_system_reboot.sh" realisieren will, kann das gerne machen ... ggf. reicht es ja sogar wieder, dort zwei Versionen der "800-modfs_boot_manager.sh" in den "patches/devices"-Verzeichnissen zu verwalten, von denen das eine die Versionsnummer fix auf < 07.08 setzt und die andere auf den "ab 07.08"-Zweig setzt. Dann könnten weiterhin beide dieser Dateien die "add_to_system_reboot.sh" aufrufen ... vielleicht ist das ja eine Lösung.

Ich will/werde jedenfalls bei mir (gerade weil der ganze neue JS-Teil ab 07.08 in der Datei auch schlecht zu lesen/editieren ist, weil ich Mimikry im Hinblick auf den AVM-Style betreibe und das auch ganz bewußt) keine zusätzlichen Patch-Files verwalten, damit das in Freetz auch ohne eine bereitgestellte Versionsnummer entschieden werden kann. Da ist der Weg, dann einfach diese Information bereitzustellen, der deutlich einfachere (und nebenbei auch plausiblere).

--------------------------------------------------------------

Für @KingTutt habe ich eine denkbare Lösung (fixer Wert) skizziert, die halt nur mit der "fwmod_custom" arbeitet ... das geht natürlich bei allen anderen Nutzern ebenso. Vor allem dann, wenn man die "fwmod_custom" ohnehin als "user file" betrachten will und der Ansicht ist, für diese Datei und ihren Inhalt unter dem jeweils verwendeten Freetz-Checkout ist ausschließlich der Benutzer zuständig (ich denke mal, das gibt Deinen Standpunkt aus https://github.com/Freetz/freetz/issues/171 korrekt wieder?). Dann muß er da eben zwei Dateien (mit unterschiedlichen Werten für "TARGET_SYSTEM_VERSION") verwenden.

Es bringt jedenfalls auch nichts, wenn ich die Patches aus "add_to_system_reboot.sh" auf zwei getrennte Dateien verteile ... das verschiebt lediglich den Punkt, an dem die Entscheidung für die richtige Version getroffen werden muß.

 

[ThAlex]

Habe jetzt die 7.11 installiert. Telnet lief zunächst, habe es dann über das Telefon deaktiviert, jetzt geht es nicht mehr, obwohl am Telefon die Meldung kommt "telnet ein", wenn ich #96*7* wähle. Merkwürdig.

Shell-in-a-Box ist jetzt nicht mehr aktiv. Muss ich das jedesmal neu injizieren?

Immerhin könnte ich auf die letzte Version zurück! Das hat geklappt.

Gruß
Thomas

 

[PeterPawn]

Muss ich das jedesmal neu injizieren?

Nein, das bleibt natürlich so lange erhalten, bis man ein Update in dem Partitionset macht, in dem man das installiert hatte. AVM konnte sich bisher wohl noch nicht dazu durchringen, das als "offiziellen Vorschlag" für die Firmware zu betrachten und eine eigene Version damit zu veröffentlichen. Dort bietet man SIAB nur in Form der Inhouse-Versionen an - da muß man es dann aber auch nicht erneut installieren nach einem Update (obwohl man es könnte, denn beide Installationen nutzen unterschiedliche Ports).

EDIT:
Das Verhalten bei der telefonischen (De-)Aktivierung des Telnet-Daemons ist mehrfach beschrieben. Nach einer Deaktivierung braucht es erst wieder einen Neustart der Box, damit der Code erneut funktioniert.

 

[ThAlex]

Nein, das bleibt natürlich so lange erhalten, bis man ein Update in dem Partitionset macht, in dem man das installiert hatte.

Das meinte ich ja, nach dem Update ist SIAB nicht mehr aktiv.

 

[PeterPawn]

nach dem Update ist SIAB nicht mehr aktiv.

Das meinte ICH ja ... wer hätte jemals etwas anderes behauptet und wo wäre das dann gewesen (damit man es nachlesen kann)?

Ich habe ganz im Gegenteil immer wieder betont, daß diese Installation nur bis zum nächsten Update reicht (der ursprüngliche Name war auch "modfs-Starter" und nicht "auf immer und ewig") und daß man - so man sie wieder loswerden möchte, was auch ein legitimes Ziel für manch anderen Interessenten ist - nur ein solches Update ausführen müsse, um sie wieder von der Box zu tilgen.

 

[ThAlex]

wer hätte jemals etwas anderes behauptet und wo wäre das dann gewesen

Das Problem ist doch, gelegentlich muss man ein Update durchführen und mit modfs geht das ohne größere Probleme, ich muss auch die Box nicht stromlos machen (Vielen Dank dafür an Dich!!). Danach bin ich aber darauf angewiesen, dass Telnet wieder läuft, wenn ich bei Bedarf das nächste Update wieder mit modfs durchführen möchte.
Gibt es Schwierigkeiten mit Telnet - und das ist mir ja schon mal passiert -, so muss ich erneut mit einem Recovery-Programm ran, mir einen Switch zulegen oder Windows das Mediasensing abgewöhnen (früher war das ja wesentlich einfacher, als noch nicht alles automatisiert ablief und man die IP-Konfiguratio immer selbst eingeben musste, da hat der PC selbst gleich die FritzBox gefunden) und dann SIAB über ein Image neu einpflanzen.
Wenn ich dazu eine Alternative hätte, wäre ich für einen Hinweis darauf sehr dankbar. Es kostet leider sehr viel Zeit alle Foren darauf hin durchzusuchen, zumal die alten Links auf Forumsbeiträge nur noch auf die Foren-Startseite führen.

Gruß
Thomas

EDIT:
Vielen Dank für den Hinweis auf das Verhalten von Telnet!

 

[PeterPawn]

Wenn ich dazu eine Alternative hätte,

Ich wüßte halt nicht, wie diese Alternative aussehen sollte ... diese Form der Installation von SIAB dient nur als "erster Schritt", damit man überhaupt erst einmal mittels "modfs" die Firmware auf den unterstützten Modellen ändern kann - ggf. auch mit einem Update bei einer solchen Modifikation.

Wenn man im modifizierten Image weiterhin SIAB haben will, kann man entweder die Aktionen, die vom Ergebnis von build_shellinabox_implant_image ausgeführt werden, von Hand selbst noch einmal über die Shell ausführen [1] oder muß sich etwas überlegen, wie man SIAB in das eigene Image einbaut. Dafür gibt es von mir (zumindest bisher, wobei ich die Notwendigkeit noch nicht verstanden habe) auch kein passendes "modscript" (auf eine Möglichkeit komme ich nachher noch einmal zurück) - ebensowenig wie für einen SSH-Service oder ähnliches. "modfs" ist immer noch ein "framework", welches für das Einbinden eigener Modifikationen durch den Benutzer gedacht ist und die mitgelieferten "modscripts" sind mehr oder weniger nur Vorlagen für eigene Experimente, zu denen ich die Benutzer anregen will.

[1] Ob man das dann anhand des "/wrapper"-Verzeichnisses macht - nach einem passenden "remount" mit Schreibzugriff - oder anhand eines anderen Mountpoints, hinter dem sich - nach dem passenden "mount"-Kommando - dann die YAFFS2-Partition des inaktiven Systems verbirgt ("/wrapper" ist ja die des aktiven), entscheidet dann wieder darüber, welches der beiden Systeme SIAB "erlernt".

Ich habe bereits vor sehr langer Zeit auch die "E99-custom" bereitgestellt ... mit dieser kann man sich sein eigenes Erweiterungsimage bauen (das kann man dann auch unter "/var/media/ftp" ablegen und für beide Systeme verwenden, wenn die Versionen zueinanderpassen) und aus dem heraus kann man alles das anstellen, was einem sonst noch so einfallen könnte.

Ich habe schon vor längerem mal ein "Inhaltsverzeichnis" eines Erweiterungsimages gezeigt, das bei mir praktisch immer auf den Boxen vorhanden ist und über die "E99-custom"-Modifikation gestartet wird - aus diesem heraus wird bei mir sowohl SIAB als auch SSH gestartet (weil beide halt deutlich sicherer sind als Telnet).

Sich so ein Erweiterungsimage selbst zu erstellen, ist auch kein Hexenwerk ... in "E99-custom" wird davon ausgegangen, daß jedes Image für sich die Verzeichnisse nach LSB (Linux Standard Base - nicht mit "Least Significant Byte" zu verwechseln) enthält und damit unter dem Mountpoint dieses Images im Verzeichnis "/etc/init.d" die Script-Files für die Dienste stehen (Aufruf ebenfalls wieder nach LSB), die nach dem Mounten des Images zu starten sind.

Nur ist so ein Image eben i.d.R. etwas sehr "Persönliches", denn jeder hat andere Anforderungen daran, was dort enthalten sein sollte und wie das konfiguriert sein müßte. Damit ist das ganz deutlich "nicht mein Tisch" und ein Beispiel für ein solches "custom image", welches genau wieder den SIAB-Service starten kann, gibt es auch schon wieder sehr, sehr lange (und zwar samt Beschreibung hier im IPPF, die dann wohl irgendwie aus der Zeit der "Vorstellung" dieses Images stammen wird und da auch zu suchen wäre): https://github.com/PeterPawn/YourFritz/blob/master/addons/VR9/shellinabox.squashfs

Dieses Image enthält alles, was es braucht, um über "E99-custom" einen SIAB-Service zu starten:

root@FB7490:~ $ wget -O /tmp/siab.image https://github.com/PeterPawn/YourFritz/raw/master/addons/VR9/shellinabox.squashfs
Connecting to github.com (140.82.118.4:443)
Connecting to raw.githubusercontent.com (151.101.112.133:443)
siab.image           100% |***********************************|   492k  0:00:00 ETA
root@FB7490:~ $ unsquashfs -lls /tmp/siab.image
Filesystem on /tmp/siab.image is xz compressed (4:0)
Parallel unsquashfs: Using 2 processors
2 inodes (23 blocks) to write

drwxr-xr-x root/root                48 2016-04-02 19:59 squashfs-root
drwxr-xr-x root/root                29 2015-12-15 13:05 squashfs-root/etc
drwxr-xr-x root/root                38 2018-01-03 15:56 squashfs-root/etc/init.d
-r-xr-xr-x root/root              6668 2018-01-03 15:56 squashfs-root/etc/init.d/rc.shellinaboxd
drwxr-xr-x root/root                 3 2018-01-03 15:56 squashfs-root/lib
drwxr-xr-x root/root                26 2015-12-15 10:24 squashfs-root/usr
drwxr-xr-x root/root                35 2018-01-03 15:56 squashfs-root/usr/bin
-rwxr-xr-x root/root           1434260 2018-01-03 15:56 squashfs-root/usr/bin/shellinaboxd
root@FB7490:~ $

Das Image ist sogar signiert und wenn ich mir das Datum der ausführbaren Datei so ansehe, ist das vermutlich (obwohl ohnehin statisch gelinkt) auch noch eine Version für die uClibc-ng und einen Kernel 3.10 - ich wüßte im Moment nicht, was ich da von meiner Seite aus "vergessen" hätte ... und das gilt inkl. Beschreibung der jeweiligen Skripte, deren Funktion und deren Fundort.

-----------------------------------------------------------------------------------------------

Daß sich das nicht alles an einer einzelnen Stelle "versammelt", ist einfach der Tatsache geschuldet, daß das nicht alles auf einen Schlag fertig wurde - ich leite aber aus nachträglichen Änderungen keine "Pflicht" für mich ab, das in älteren Beschreibungen jeweils anzupassen (da käme ich gar nicht mehr hinterher). Ich halte es für legitim und zumutbar, daß man sich - wenn man "modfs" benutzen möchte - auch so weit damit beschäftigt, daß man es dann eben von Beginn an liest - i.d.R. muß man ja auch nicht jede (fremde) Frage komplett lesen (es gibt ja auch so etwas wie "querlesen", wobei das für Fragen sicherlich schlauer ist, als wenn man das auch bei Antworten meinerseits anwendet, denn es kann schon mal vorkommen, daß eine entsprechende Erläuterung aus der Antwort auf die Frage eines anderen entstanden ist) und damit sind sogar mehr als 1600 Beiträge noch "verarbeitbar", weil vielleicht max. 1/3 von mir stammt und sich davon vielleicht noch einmal die Hälfte mit "einmaligen Themen" befaßt und nicht nur die Wiederholung zuvor bereits gegebener Antworten oder das Aufzeigen konkreter Fehler im Umgang mit "modfs" beinhaltet.

Was wäre denn die Alternative? Ich müßte mich alle drei, sechs oder zwölf Monate (da will ich mich gar nicht festlegen) erneut hinsetzen und das alles von vorne beschreiben. Das KANN (für mich ist das jedenfalls mehr als offensichtlich) nicht die Lösung sein ... ich finde mich max. noch dazu bereit, 1x im Halbjahr etwas ausführlicher auf solche Fragen zu antworten (wie ich es hier gerade mache). Aber der Nachteil für den Nächsten springt sicherlich auch Dir ins Auge ... der muß jetzt nämlich bei seiner eigenen Lektüre der > 1600 Beiträge in diesem Thread auch diese Antwort noch lesen, obwohl sie ggf. mit seinem eigenen Problem gar nichts zu tun hat.

Was wäre denn Dein Vorschlag für den Ausweg aus diesem Dilemma?

-----------------------------------------------------------------------------------------------

Daß die internen Links über "showthread.php" seit dem letzten Update nicht mehr funktionieren, habe ich versucht zu thematisieren: https://www.ip-phone-forum.de/threads/forum-ansicht-style-verändert.303612/post-2331233 - leider bisher ohne Reaktion (aber es war ja auch Wochenende).

Ich hoffe mal ganz stark, daß dieses Problem zeitnah wieder korrigiert wird, denn ansonsten funktionieren tatsächlich die Links aus der vBulletin-Zeit gar nicht mehr und das wäre dann (zumindest für mich persönlich) der Tod des gesamten Boards.

Neue, umfangreichere Beschreibungen würde ich schon heute nur noch dort veröffentlichen, wo einerseits die altbekannten Gestaltungsmöglichkeiten vorhanden sind (inkl. "Kolorieren" von CODE-Blöcken) und ich andererseits die Verlinkung (und deren einwandfreie Funktion) selbst unter Kontrolle habe - mal ganz zu schweigen vom 50.000-Zeichen-Limit, welches es mir seit dem Wechsel auf Xenforo auch permanent verwehrt, bestimmte Beiträge (die halt dieses Limit reißen) noch zu aktualisieren oder gar zu korrigieren.

Diese nicht funktionierenden Links sollten jedenfalls als "Problem" die nächste Woche nicht überleben ... bis dahin mußt Du Dir halt mit "Link basteln" (wie das für einen Thread-Link aussieht, kann man im verlinkten Beitrag ableiten - für Beiträge funktioniert das ähnlich, nur halt mit "posts/<number>") selbst helfen.

 

[PeterPawn]

@KingTutt:

Ich habe mal etwas in meinen Freetz-Fork eingecheckt, was Dein Problem ebenfalls lösen könnte. Das befindet sich im Branch "bootmanager_install".

Der Ansatz war es nun doch, für "TARGET_SYSTEM_VERSION" auch den Wert "autodetect" zuzulassen, wenn parallel dazu noch eine Variable "TARGET_SYSTEM_VERSION_DETECTOR" auf ein Skript gesetzt ist, was mit einem identischen Interface zu diesem Skript: https://github.com/PeterPawn/YourFritz/blob/master/signimage/database/extract_version_values (also auch mit dem - ggf. ignorierten - Parameter "-m") in der Lage ist, eine Zeichenkette Version="..." auf STDOUT auszugeben, die im Anschluß mit "sed" nach der Versionsnummer durchsucht werden kann.

Da ich dieses Skript ohnehin schon hatte und das nichts weiter braucht, als das Basisverzeichnis eines FRITZ!OS-Trees als Parameter und sich dann die verschiedenen Angaben schon zusammensucht, habe ich das noch so angepaßt, daß es auch auf der FRITZ!Box im Rahmen von "modfs" eingesetzt werden könnte, so daß der Aufruf von "add_to_system_reboot.sh" auch überall dann mit der Versionsnummer oder eben mit "autodetect" erfolgen kann.

------------------------------------------------------------------------------

Wenn Du das bei Dir ausprobieren möchtest, kannst Du Dir die Änderungen ggü. dem Freetz-Master mit dem folgenden Kommando in Deinen Build-Tree importieren:

git pull https://github.com/PeterPawn/YourFreetz.git bootmanager_install

oder noch einmal von Beginn an (also ab dem Klonen des Freetz-Masters) im Kontext:

freetz@vidar:~> cd /tmp/
freetz@vidar:/tmp> git clone https://github.com/freetz/freetz.git bm_install
Cloning into 'bm_install'...
remote: Enumerating objects: 13, done.
remote: Counting objects: 100% (13/13), done.
remote: Compressing objects: 100% (12/12), done.
remote: Total 142731 (delta 1), reused 6 (delta 1), pack-reused 142718
Receiving objects: 100% (142731/142731), 33.62 MiB | 8.73 MiB/s, done.
Resolving deltas: 100% (94902/94902), done.
freetz@vidar:/tmp> cd bm_install/
freetz@vidar:/tmp/bm_install> git pull https://github.com/PeterPawn/YourFreetz.git bootmanager_install
remote: Enumerating objects: 11, done.
remote: Counting objects: 100% (11/11), done.
remote: Compressing objects: 100% (4/4), done.
remote: Total 11 (delta 7), reused 10 (delta 7), pack-reused 0
Unpacking objects: 100% (11/11), done.
From https://github.com/PeterPawn/YourFreetz
* branch                bootmanager_install -> FETCH_HEAD
Updating 274a186f8..836edeb3d
Fast-forward
patches/scripts/800-modfs_boot_manager.sh   | 3 ++-
tools/make/yourfritz-host/yourfritz-host.mk | 2 +-
2 files changed, 3 insertions(+), 2 deletions(-)
freetz@vidar:/tmp/bm_install>

 

[ThAlex]

Wenn man im modifizierten Image weiterhin SIAB haben möchte...

Danke für die ausführlichen Erläuterungen.
Ich bin jetzt schneller geworden und habe heute früh SIAB über das EVA-Powershell-Script in 10 Minuten integriert.

Das Verhalten bei der telefonischen (De-)Aktivierung des Telnet-Daemons ist mehrfach beschrieben. Nach einer Deaktivierung braucht es erst wieder einen Neustart der Box, damit der Code erneut funktioniert.

Es war übrigens so, dass Telnet nach dem Neustart bereits aktiviert war (evtl. weil ich zuletzt den Aktivierungscode geschickt habe?), Über Shellinabox kann ich es nun selbst reaktivieren:

telnetd -l /sbin/ar7login

Gruß
Thomas

 

[PeterPawn]

@ThAlex:
Der Aktivierungszustand des Telnet-Daemons wird in der "fx_conf" vermerkt (irgendwo habe ich auch beschrieben, an welchem Offset in der Datei das Flag steht) und der wird auch tatsächlich jedesmal geändert, wenn man den Telefoncode verwendet. Nur der Start des Daemons klappt nach dem Deaktivieren bis zum nächsten Neustart nicht mehr - das Flag wird weiterhin geändert und dessen Wert beim nächsten Neustart legt dann fest, ob der Telnet-Daemon gestartet wird oder nicht.

@KingTutt:
Die Änderungen sind bereits im Freetz-Master angekommen, Du kannst also auch ohne das Zusammenmischen erneut probieren, ein passendes Image mit "no-freetz"-Modus zu erstellen.

 

[Micha0815]

Die Änderungen sind bereits im Freetz-Master angekommen,

Danke dafür an die Macher. Patch passt nach einem kurzen git pull.

LG

 

[KingTutt]

@PeterPawn
Danke für die Hilfestellung, hatte die letzten Tage etwas viel um die Ohren, um Feedback zu geben. Hatte auf die Schnelle in in der fwmod_custom die beiden Variablen "AVM_FW_MAJOR" und "AVM_FW_VERSION" einfach gesetzt, aber das werde ich dann die Tage wieder raus nehmen (hardcoded stuff ist immer anfällig für zukünftige Fehler). Nachdem die Variablen gesetzt waren, wurde auch der richtige Patch angewendet. Der Screenshot von @Micha0815 bei der 7590 sieht zwar etwas anders aus als bei meiner 7490 (wie im Screenshot zu sehen, steht bei mir noch ein Zusatzstring zur letzten Modifikation, wobei am Ende zwischen den beiden "" früher noch ein Freetz stand) aber die Funktionalität ist dadurch nicht beeinträchtigt.

 

[PeterPawn]

Das mit dem "abwesenden" Kennzeichen für die Änderungen durch "Freetz" ist ein Problem - zwar wird in der Version, die in Freetz verwendet wird, tatsächlich noch ein zusätzlicher Patch verwendet, aber der bezieht sich nur auf die Frage, ob das Branding fix in der "rc.conf" gesetzt wurde oder nicht. Die Ermittlung, welches "Framework" da für Änderungen verwendet wurde (bzw. ob überhaupt geändert wurde, was in der alternativen Partition ja nicht zwingend ist), sollte davon nicht beeinflußt werden: https://github.com/PeterPawn/YourFritz/blob/master/bootmanager/gui_bootmanager#L131 - zumal das an der bloßen Existenz von Dateien festgemacht wird.

Kannst Du mal bitte die Ausgabe von "gui_bootmanager get_values nocache" und "gui_bootmanager debug" posten? Es geht mir erst mal darum zu ermitteln, ob schon das Eruieren der Werte nicht paßt oder ob es "nur" die korrekte Anzeige ist, die hier nicht erscheinen will.

 

[sulihari]

Ich habe die aktuelle modfs Version (http://yourfritz.de/modfs.tgz) auf einer 7490 mit dem FW image 7.11 laufen lassen. USB Stick mit Swap war aktiv und alles lief ohne Fehlermeldung durch, Beim Versuch, per Telefon telnet zu aktivieren passiert aber nichts. Es wurden mehrere Versuche gemacht, immer von 6.93 aus.
Jetzt habe ich die 7.01 genommen. Damit hat es auf Anhieb funktioniert. Frage gibt es aktuell ein bekanntes Problem, welches bei 7.11 die Aktivierung von telnet verhindert?

 

[ThAlex]

@PeterPawn nochmal zu

Ich wüßte halt nicht, wie diese Alternative aussehen sollte

Was ich mir vorstellen würde ist, dass ich in einem Schritt modfs auf eine neue Firmware-Version anwenden kann und zugleich SIAB in der neuen Version aktiviere. Wenn ich recht verstanden habe, müsste ich mir dazu überlegen, wie ich das in ein eigenes Image einbauen kann.
Ich würde mir das so vorstellen: man schaut zunächst nach, ob SIAB bereits integriert ist und kopiert es dann in das neu erstellte alternative System - wobei ich nicht weiß, kann es in ein modifiziertes Firmware-Image überhaupt eingebaut werden oder könnte das erst nach dem Start der Box in der neuen Version erfolgen bzw. kann ich das mit Hilfe der "E99-custom" erledigen - es ist ja im modfs.tgz enthalten.
Du schreibst:

Ich habe schon vor längerem mal ein "Inhaltsverzeichnis" eines Erweiterungsimages gezeigt, das bei mir praktisch immer auf den Boxen vorhanden ist und über die "E99-custom"-Modifikation gestartet wird - aus diesem heraus wird bei mir sowohl SIAB als auch SSH gestartet (weil beide halt deutlich sicherer sind als Telnet).

Wie kommt denn die Modifikation bei Dir auf die Box?

Frage gibt es aktuell ein bekanntes Problem, welches bei 7.11 die Aktivierung von telnet verhindert?

Dazu ist mir nichts bekannt und Telnet läuft bei mir mit 7.11. Hast Du denn beim Aktivieren über das Telefon einen Bestätigungs-Ton erhalten?
Den bekomme ich nämlich beim Aktivieren - und auch beim Abschalten. Er kommt auch, wenn ich nach dem Abschalten Telnet wieder aktivieren will, aber Telnet läuft dann trotzdem nicht s.o. Erst nach einem Neustart der Box ist es wieder aktiv.

Gruß
Thomas