[Info] modfs - SquashFS-Image (AVM-Firmware) ändern für NAND-basierte FRITZ!Boxen
- Ersteller PeterPawn
- Erstellt am
Hello again Peter, and thank you for your reply. I followed your link and read your 2016 post in perfect english with a great online translator named DeepL Translator which I greatly recommend to everybody.
I've been struggling all day long and I have a final report and a few questions for you about the webdav "hanging time":
"rc.usbsema: Break lock /var/USBLOCK_WEBDAV after 100 seconds!"
- I tried to follow /var/post_install commands and found out that /etc/webdav_control start/stop are not responsive as ctlmgr_ctl r webdavclient status/connection_state never changes after the execution
- /etc/webdav_control offline/online work correctly but even the offline condition still leads to the webdav freezing the reboot process.
- I created the following script then and the reboot is fine unless the sleep time is too short ad the reboot freezes again:
ctlmgr_ctl w webdavclient settings/enabled 0
sleep 6
ctlmgr_ctl w logic command/reboot 1
- So I tried to tried setting the ctlmgr_ctl w webdavclient settings/enabled 0 command (followed by the 6 seconds sleep time) at the very beginning of /var/post_install and the reboot freezes again.
So this is not related to post_install script. Do you think this might be an AVM sort of bug?
I did my best trying to understand but I'm afraid my skills are too limited to debug the problem further. I would greatly appreciate another hint about how to shutdown webdav automatically at reboot before the "freezing time" occurs.
Thank you so much,
Virginio
PS Just a curiosity: am I the only user who had this problem with FB7490 and OS 6.83?
Zuletzt bearbeitet:
- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,298
- Punkte für Reaktionen
- 1,760
- Punkte
- 113
I'll try to debug the shutdown process myself later. I did not watch an original sequence for a while.
In neither case it's impossible, that the original firmware also tends to hang for a while during disconnection from a WebDAV service.
If you restart the device using the GUI, it's hard to decide, how long the shutdown process should take and what's a "normal" delay, while running services are terminated.
I would not swear (or even believe), that AVM thoroughly checks these parts of their firmware each time, before a new version is published.
In neither case it's impossible, that the original firmware also tends to hang for a while during disconnection from a WebDAV service.
If you restart the device using the GUI, it's hard to decide, how long the shutdown process should take and what's a "normal" delay, while running services are terminated.
I would not swear (or even believe), that AVM thoroughly checks these parts of their firmware each time, before a new version is published.
- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,298
- Punkte für Reaktionen
- 1,760
- Punkte
- 113
In a first step, you should check the state of the "semaphore" file (created/used by /etc/hotplug/rc.usbsema) with name "/var/USBLOCK_WEBDAV".
This file should not exist, while the system is running and the WebDAV service is ready.
It's only used as a lock against two parallel instances changing the state of this service and it should be deleted automatically, if a control request has finished.
If this file exists at the time, where "post_install" calls "webdav_control stop", this new process waits (up to 100 seconds), whether this file gets deleted anytimes, because another, currently running control request exits. If this does not happen, the new process "breaks" the lock nevertheless ... but there's the 100 seconds delay.
If this file still exists on your system, after the WebDAV service was started successfully (this is done by the "online" trigger, not by a "start" request), further investigations are required, what the reason is.
Looking over the "post_install" file, the only possibility to stop the WebDAV service in front of the (obvious) "/etc/webdav_control stop" request in line 115, seems to be a system, where the WAN interface is using a WLAN connection. Stopping the WLAN in line 29 would trigger an earlier "webdav_control offline" via "multid" (at least I would think so), which could be the source of an existing semaphore file.
But as I wrote above ... it needs an investigation step by step and there are too much opportunities for a failure, to list them all here, without a knowing, where you should look further.
The first question is the state of the semaphore file (and maybe the state and content of the WebDAV log files - simply the presence ("ls -l" command) and content ("cat" command) of any file from "/var/tmp" with a "webdav" string in its name), while the system is up and running and the WebDAV storage is usable.
Acquiring and releasing the lock itself will not be logged - unfortunately (or maybe naturally, because it also prevents two instances to ruin the log file with concurrent (and nested) writes).
EDIT: I can not reproduce any problem with WebDAV ... my service (using my own DAV server) is started and stopped within 3 seconds, also more than once, if I repeat "stop" and "online" requests alternately.
This file should not exist, while the system is running and the WebDAV service is ready.
It's only used as a lock against two parallel instances changing the state of this service and it should be deleted automatically, if a control request has finished.
If this file exists at the time, where "post_install" calls "webdav_control stop", this new process waits (up to 100 seconds), whether this file gets deleted anytimes, because another, currently running control request exits. If this does not happen, the new process "breaks" the lock nevertheless ... but there's the 100 seconds delay.
If this file still exists on your system, after the WebDAV service was started successfully (this is done by the "online" trigger, not by a "start" request), further investigations are required, what the reason is.
Looking over the "post_install" file, the only possibility to stop the WebDAV service in front of the (obvious) "/etc/webdav_control stop" request in line 115, seems to be a system, where the WAN interface is using a WLAN connection. Stopping the WLAN in line 29 would trigger an earlier "webdav_control offline" via "multid" (at least I would think so), which could be the source of an existing semaphore file.
But as I wrote above ... it needs an investigation step by step and there are too much opportunities for a failure, to list them all here, without a knowing, where you should look further.
The first question is the state of the semaphore file (and maybe the state and content of the WebDAV log files - simply the presence ("ls -l" command) and content ("cat" command) of any file from "/var/tmp" with a "webdav" string in its name), while the system is up and running and the WebDAV storage is usable.
Acquiring and releasing the lock itself will not be logged - unfortunately (or maybe naturally, because it also prevents two instances to ruin the log file with concurrent (and nested) writes).
EDIT: I can not reproduce any problem with WebDAV ... my service (using my own DAV server) is started and stopped within 3 seconds, also more than once, if I repeat "stop" and "online" requests alternately.
Zuletzt bearbeitet:
Many thanks for your prompt reply Peter,
I forgot to mention earlier tonight that I'm using the free box.com and hidrive.strato.com services and that I disabled WiFi completely on the unit.
I just finished stressing a little bit the /etc/webdav_control and as you can see in the attachment a few commands were enough to make it unresponsive. And still no /var/USBLOCK_WEBDAV lock was created.
Could you please try to replicate the sequence on your side, with one of the two services I mentioned?
Hope you can reproduce the issue.
If you think there are other tests I should make please let me know and I'll make other tries later.
Have a nice day,
Virginio
EDIT: BTW I've a minor question to ask which I always forget: how can I make permanent the adding of my scripts' path to the $PATH variable? Every test I made by adding commands at boot via /usr/sbin/edit_rcuser doesn't seem to be taken into account.
Zuletzt bearbeitet:
Moin!
Ich habe kürzlich (sprich letzten Freitag, 8.9.17) per git modfs aus dem repository ausgecheckt und damit die aktuelle 06.88-46480 BETA auf meiner FB 7490 installiert. Das hat auch problemlos funktioniert, jedoch wurden beim durchlauf des scripts jede Menge Anmerkungen/Fehler á la "sh: Bad Number" ausgegeben. So ziemlich zwischen jedem Schritt des scripts. Irgendeine Idee, was das sein könnte bzw. ob das langfristig problematisch ist?
Da die Firmware trotzdem mit der git-Version auf meine FB gespielt werden konnte, ist die Frage eher neugieriger Natur...
Und noch eine kurze Frage am Rande...Gibt es Pläne bzw. die Möglichkeit auf Unterstützung der 7590 durch modfs? Habe schon im Forum gesucht, aber keinen Hinweis darauf gefunden, daher hier direkt die Frage.
Irre ich mich, oder hat die 7590 die gleiche Prozessorarchitektur wie die 7580?
Edit (11.9., 19:24): Gerade gesehen, das die 7580 auch (noch?) nicht unterstützt wird!?...ups..
Beste Grüße und bis denn (und natürlich vielen Dank PeterPawn für die anhaltende Arbeit und den Support bezüglich modfs!)
Ich habe kürzlich (sprich letzten Freitag, 8.9.17) per git modfs aus dem repository ausgecheckt und damit die aktuelle 06.88-46480 BETA auf meiner FB 7490 installiert. Das hat auch problemlos funktioniert, jedoch wurden beim durchlauf des scripts jede Menge Anmerkungen/Fehler á la "sh: Bad Number" ausgegeben. So ziemlich zwischen jedem Schritt des scripts. Irgendeine Idee, was das sein könnte bzw. ob das langfristig problematisch ist?
Da die Firmware trotzdem mit der git-Version auf meine FB gespielt werden konnte, ist die Frage eher neugieriger Natur...
Und noch eine kurze Frage am Rande...Gibt es Pläne bzw. die Möglichkeit auf Unterstützung der 7590 durch modfs? Habe schon im Forum gesucht, aber keinen Hinweis darauf gefunden, daher hier direkt die Frage.
Irre ich mich, oder hat die 7590 die gleiche Prozessorarchitektur wie die 7580?
Edit (11.9., 19:24): Gerade gesehen, das die 7580 auch (noch?) nicht unterstützt wird!?...ups..
Beste Grüße und bis denn (und natürlich vielen Dank PeterPawn für die anhaltende Arbeit und den Support bezüglich modfs!)
- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,298
- Punkte für Reaktionen
- 1,760
- Punkte
- 113
@maulich:
Bei der Fehlermeldung mit dem "Bad Number" fehlt mir die Idee ... hattest Du auf der Box denn ein "git", mit dem Du anstelle des Downloads für das Archiv-File direkt aus GitHub auschecken konntest? Oder lief das über irgendeinen Zwischenrechner? Vielleicht war/ist sogar ein Windows-System mit im Spiel?
Ich habe jetzt so lange eigentlich nichts am Skript geändert (einzige lokale Änderung, die noch nicht eingecheckt wurde, ist ein überflüssiger Parameter beim Debug-Aufruf in Zeile 1020), daß ich es mir nur anhand des Weges erklären kann, auf dem das
Skript auf die Box kam. Wenn es dort erst einmal ist, wird ja auch sofort beim Start dafür gesorgt, daß es die eigene BusyBox aus dem Download benutzt für alle weiteren Aufrufe, auch für das "sh"-Applet.
Ich habe auch noch mal den Stand (des Skripts) im Repo mit der Archivdatei (http://yourfritz.de/modfs.tgz) verglichen und da gibt es auch nur den o.a. Unterschied - mir fehlt da halt die Idee, was das sein mag. Wenn es beim direkten Download von yourfritz.de und Auspacken auf der Box (Du kannst ja zuvor irgendwo den Inhalt des Repo mit dem Archiv-Inhalt vergleichen, auch das "diff" in der (MIPS-)BusyBox könnte (mit "-r" aufgerufen) eine Option sein, wenn Du wirklich auf die Box ausgecheckt hast) auch zu dem Fehler kommen sollte, dann ist die Idee bzgl. der Ursache natürlich obsolet und man muß weiter überlegen oder mal den Aufruf mit "-x" "würzen", um die Stelle mit dem Problem zu finden (wobei eben die Shell nochmals "intern" aufgerufen wird und man den Aufruf dort um das "-x" ergänzen müßte oder das SheBang im Skript).
Ja, es wird auch "modfs" für GRX-Boxen geben ... aber nicht "im alten Gewand" mit dem monolithischen Skript, wo alles in einer Datei steht. Warum das (für Linux-System-Besitzer) viel einfacher ist, das extern zur Box zu machen, habe ich oben schon sehr ausführlich geschrieben und mein Ziel ist es bei der neuen Version (neben dem Aufteilen in kleinere Einheiten und der Verwendung der Script-Library, die auch schon gefühlt Jahre in bin/scripts steht), neben der FRITZ!Box auch andere Systeme (x86, RasPi, Windows-Bash) als "Host" für die Modifikation einer "fremden" Firmware zu unterstützen. Das funktioniert in der derzeitigen Version nicht, weil zuviele Einstellungen von der Box abgeleitet werden, auf der das Skript arbeitet - das muß alles auch anders anzugeben sein und dafür muß halt "modfs" wieder in "Funktionseinheiten" zerlegt werden.
Wenn Du das tatsächlich außerhalb der FRITZ!Box angewendet hast, dann stammen die erwähnten Fehlermeldungen vermutlich von den Versuchen, irgendwelche FRITZ!OS-Merkmale aus dem System auszulesen. Es ist tatsächlich auch so, daß man das Skript schon heute auf einem anderen Host verwenden kann (sofern die notwendigen Binaries existieren und zumindest das "unsquashfs" und "mksquashfs" ist inzwischen tatsächlich auch für x86 im "bin"-Verzeichnis irgendwo zu finden - wg. der 6490 auch für das LE-Format), wenn man an die Stelle des Ermittelns von Einstellungen einfach feste Vorgaben in das Skript editiert ... aber das ist dann nicht mehr "modfs" wie bisher.
Bei der Fehlermeldung mit dem "Bad Number" fehlt mir die Idee ... hattest Du auf der Box denn ein "git", mit dem Du anstelle des Downloads für das Archiv-File direkt aus GitHub auschecken konntest? Oder lief das über irgendeinen Zwischenrechner? Vielleicht war/ist sogar ein Windows-System mit im Spiel?
Ich habe jetzt so lange eigentlich nichts am Skript geändert (einzige lokale Änderung, die noch nicht eingecheckt wurde, ist ein überflüssiger Parameter beim Debug-Aufruf in Zeile 1020), daß ich es mir nur anhand des Weges erklären kann, auf dem das
Skript auf die Box kam. Wenn es dort erst einmal ist, wird ja auch sofort beim Start dafür gesorgt, daß es die eigene BusyBox aus dem Download benutzt für alle weiteren Aufrufe, auch für das "sh"-Applet.
Ich habe auch noch mal den Stand (des Skripts) im Repo mit der Archivdatei (http://yourfritz.de/modfs.tgz) verglichen und da gibt es auch nur den o.a. Unterschied - mir fehlt da halt die Idee, was das sein mag. Wenn es beim direkten Download von yourfritz.de und Auspacken auf der Box (Du kannst ja zuvor irgendwo den Inhalt des Repo mit dem Archiv-Inhalt vergleichen, auch das "diff" in der (MIPS-)BusyBox könnte (mit "-r" aufgerufen) eine Option sein, wenn Du wirklich auf die Box ausgecheckt hast) auch zu dem Fehler kommen sollte, dann ist die Idee bzgl. der Ursache natürlich obsolet und man muß weiter überlegen oder mal den Aufruf mit "-x" "würzen", um die Stelle mit dem Problem zu finden (wobei eben die Shell nochmals "intern" aufgerufen wird und man den Aufruf dort um das "-x" ergänzen müßte oder das SheBang im Skript).
Ja, es wird auch "modfs" für GRX-Boxen geben ... aber nicht "im alten Gewand" mit dem monolithischen Skript, wo alles in einer Datei steht. Warum das (für Linux-System-Besitzer) viel einfacher ist, das extern zur Box zu machen, habe ich oben schon sehr ausführlich geschrieben und mein Ziel ist es bei der neuen Version (neben dem Aufteilen in kleinere Einheiten und der Verwendung der Script-Library, die auch schon gefühlt Jahre in bin/scripts steht), neben der FRITZ!Box auch andere Systeme (x86, RasPi, Windows-Bash) als "Host" für die Modifikation einer "fremden" Firmware zu unterstützen. Das funktioniert in der derzeitigen Version nicht, weil zuviele Einstellungen von der Box abgeleitet werden, auf der das Skript arbeitet - das muß alles auch anders anzugeben sein und dafür muß halt "modfs" wieder in "Funktionseinheiten" zerlegt werden.
Wenn Du das tatsächlich außerhalb der FRITZ!Box angewendet hast, dann stammen die erwähnten Fehlermeldungen vermutlich von den Versuchen, irgendwelche FRITZ!OS-Merkmale aus dem System auszulesen. Es ist tatsächlich auch so, daß man das Skript schon heute auf einem anderen Host verwenden kann (sofern die notwendigen Binaries existieren und zumindest das "unsquashfs" und "mksquashfs" ist inzwischen tatsächlich auch für x86 im "bin"-Verzeichnis irgendwo zu finden - wg. der 6490 auch für das LE-Format), wenn man an die Stelle des Ermittelns von Einstellungen einfach feste Vorgaben in das Skript editiert ... aber das ist dann nicht mehr "modfs" wie bisher.
- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,298
- Punkte für Reaktionen
- 1,760
- Punkte
- 113
@Virgus:
I'm in a hurry at this moment ... short answer: Changing (and "export"ing) "PATH" in the rc.user/debug.cfg file affects only software started after this point and each program may decide to provide a "fresh environment" to its children. If you're missing an own PATH setting in /var/post_install ... this is run with such a "clean environment" (mentioned in the 6490 thread somewhere). If you need additional directories here, insert another script with the "dot"-command (.) or insert statements directly into "post_install".
If you're missing an "extended" PATH value in an interactive shell, append to this variable from an own ".profile" file in your home directory and redefine the home directory for "root" first in "/etc/passwd" to a writable location or use my patch to extend "/etc/profile" with an optional file from "/var/custom/profile" (solely from my memory, check the "modscript" description/content yourself please).
Any tests with "webdav_control" have to be shifted (in time) ... but it's anyhow more a special problem unrelated to "modfs" and we should move with this theme to a new thread.
I'm in a hurry at this moment ... short answer: Changing (and "export"ing) "PATH" in the rc.user/debug.cfg file affects only software started after this point and each program may decide to provide a "fresh environment" to its children. If you're missing an own PATH setting in /var/post_install ... this is run with such a "clean environment" (mentioned in the 6490 thread somewhere). If you need additional directories here, insert another script with the "dot"-command (.) or insert statements directly into "post_install".
If you're missing an "extended" PATH value in an interactive shell, append to this variable from an own ".profile" file in your home directory and redefine the home directory for "root" first in "/etc/passwd" to a writable location or use my patch to extend "/etc/profile" with an optional file from "/var/custom/profile" (solely from my memory, check the "modscript" description/content yourself please).
Any tests with "webdav_control" have to be shifted (in time) ... but it's anyhow more a special problem unrelated to "modfs" and we should move with this theme to a new thread.
Sure, I'll do some more tests and then open a new thread. Thanks for all the other information and have a nice day, Peter
@PeterPawn:
Hej Peter,
Vielen Dank für die ausführliche und informative Antwort!
Tatsächlich habe ich das Repo auf meinem Linux-Rechner geklont, es dann mit tar zusammengepackt, auf die Fritzbox kopiert und dort entpackt.
Nun habe ich mal testweise das tgz von yourfritz.de direkt auf die Fritzbox geladen, dort entpackt und ausgeführt und siehe da: Alles läuft sauber durch ohne diese "Bad Number"-Anzeigen.
Ich vermute mal, daß irgendwo auf dem Weg von meinem Linux-Rechner auf die Fritzbox das Encoding durcheinandergeraten ist...Da es aber in beiden Fällen funktionierte, verbuche ich das unter "kosmetisches Problem"
in der Tat zeigt ein diff zwischen den beiden Varianten nur den von Dir angesprochenen Unterschied. Vielleicht komme ich am Wochenende dazu, mir das nochmal genauer anzuschauen - aber wie geschrieben: Es läuft ja in beiden Fällen.
Zu der GRX-Unterstützung: Wow! Das klingt gut. Ich bin gespannt und freu mich schon drauf! ...Wenn es Bedarf gibt, da was "in freier Wildbahn" zu testen - morgen landet eine 7590 bei mir...
Einstweilen: Beste Grüße und Vielen Dank!
(Edit 12.9., 20:13h):
Hier nochmal - der Vollständigkeit halber - ein Auszug der Ausgabe bei der Variante mit dem git clone (wie gesagt: Auf Linuxrechner geklont, dann mit "tar cvf modfs.tar modfs" gepackt, auf die FB kopiert, dort entpackt und schließlich mit "/var/tmp/modfs/modfs update <Name des Images>":
Hej Peter,
Vielen Dank für die ausführliche und informative Antwort!
Tatsächlich habe ich das Repo auf meinem Linux-Rechner geklont, es dann mit tar zusammengepackt, auf die Fritzbox kopiert und dort entpackt.
Nun habe ich mal testweise das tgz von yourfritz.de direkt auf die Fritzbox geladen, dort entpackt und ausgeführt und siehe da: Alles läuft sauber durch ohne diese "Bad Number"-Anzeigen.
Ich vermute mal, daß irgendwo auf dem Weg von meinem Linux-Rechner auf die Fritzbox das Encoding durcheinandergeraten ist...Da es aber in beiden Fällen funktionierte, verbuche ich das unter "kosmetisches Problem"
in der Tat zeigt ein diff zwischen den beiden Varianten nur den von Dir angesprochenen Unterschied. Vielleicht komme ich am Wochenende dazu, mir das nochmal genauer anzuschauen - aber wie geschrieben: Es läuft ja in beiden Fällen.
Zu der GRX-Unterstützung: Wow! Das klingt gut. Ich bin gespannt und freu mich schon drauf! ...Wenn es Bedarf gibt, da was "in freier Wildbahn" zu testen - morgen landet eine 7590 bei mir...
Einstweilen: Beste Grüße und Vielen Dank!
(Edit 12.9., 20:13h):
Hier nochmal - der Vollständigkeit halber - ein Auszug der Ausgabe bei der Variante mit dem git clone (wie gesagt: Auf Linuxrechner geklont, dann mit "tar cvf modfs.tar modfs" gepackt, auf die FB kopiert, dort entpackt und schließlich mit "/var/tmp/modfs/modfs update <Name des Images>":
Code:
Ermitteln der Hardware-Version ... OK
sh: Pr52: bad number
Prüfen, ob die Hardware-Version unterstützt wird ... OK
Suchen der Einstellung zur Umschaltung auf das alternative System ... OK
sh: P50: bad number
Prüfen der aktuell zu startenden Systemversion ... OK
Suchen der aktuellen Kernel-Partition ... OK
Suchen der alternativen Kernel-Partition ... OK
Vergleich der Systeme in den Kernel-Partitionen ...sh: $48: bad number
übersprungen
Suchen der aktuellen Dateisystem-Partition ... OK
Suchen der alternativen Dateisystem-Partition ... OK
sh: Üb65: bad number
Überprüfen des zur Verfügung stehenden Speicherplatzes im RAM ... OK
sh: Üb76: bad number
Überprüfen des freien Speicherplatzes für das Auspacken des Dateisystems ... OK
sh: \n191: bad number
Das System erfüllt die Voraussetzungen zur Modifikation des root-Dateisystems.
Im Moment läuft auf der Box die Version: 113.06.88-46480
sh: A319: unknown operand
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.
sh: D105: bad number
Die angegebene Datei '/var/media/ftp/USB_Platte/Dokumente/FRITZ.Box_7490_Labor.113.06.88-46480.image' wird als Quelle für die Aktualisierung genutzt.
sh: Ü47: bad number
Überprüfen der Signatur der geladenen Datei ... OK
Extrahieren des neuen Kernel-Images aus dem Firmware-Image ... OK
Extrahieren des Flash-Filesystems aus dem Firmware-Image ... OK
Extrahieren des Wurzeldateisystems aus dem Flash-Filesystem ... OK
sh: E58: bad number
Entpacken des root-Dateisystems für die Modifikationen ...
Zuletzt bearbeitet:
wie hast Du die Datei modfs.tar von LINUX-Rechner nach FB kopiert ?
evtl. mit ftp im ascii modus ?
die Windows Rechner führen des öfteren auch "Filename Mangling" durch, d.h. Ändern von Groß-/Kleinschreibung von Datei-/Verzeichnisnamen,
ferner werden Softlinks geändert;
Bitte folgenden Kontrollbefehl nach Kopieren von LINUX auf FB durchführen:
Code:
# find . -type l -exec ls -lad {} \;
lrwxrwxrwx 1 root root 5 Aug 19 13:54 ./bin/156 -> Vx180
lrwxrwxrwx 1 root root 3 Aug 19 13:54 ./bin/193 -> VR9
lrwxrwxrwx 1 root root 26 Aug 19 13:54 ./bin/VR9/mksquashfs3 -> ../common/mksquashfs3.34kc
lrwxrwxrwx 1 root root 21 Aug 19 13:54 ./bin/VR9/mke2fs -> ../common/mke2fs.34kc
lrwxrwxrwx 1 root root 29 Aug 19 13:54 ./bin/VR9/busybox.config -> ../common/busybox.config.34kc
lrwxrwxrwx 1 root root 25 Aug 19 13:54 ./bin/VR9/unsquashfs3 -> ../common/unsquashfs.34kc
lrwxrwxrwx 1 root root 26 Aug 19 13:54 ./bin/VR9/mksquashfs4 -> ../common/mksquashfs4.34kc
lrwxrwxrwx 1 root root 22 Aug 19 13:54 ./bin/VR9/openssl -> ../common/openssl.34kc
lrwxrwxrwx 1 root root 21 Aug 19 13:54 ./bin/VR9/e2fsck -> ../common/e2fsck.34kc
lrwxrwxrwx 1 root root 22 Aug 19 13:54 ./bin/VR9/busybox -> ../common/busybox.34kc
lrwxrwxrwx 1 root root 25 Aug 19 13:54 ./bin/VR9/unsquashfs4 -> ../common/unsquashfs.34kc
lrwxrwxrwx 1 root root 4 Aug 19 13:54 ./bin/226 -> GRX5
lrwxrwxrwx 1 root root 3 Aug 19 13:54 ./bin/203 -> VR9
lrwxrwxrwx 1 root root 3 Aug 19 13:54 ./bin/185 -> VR9
lrwxrwxrwx 1 root root 26 Aug 19 13:54 ./bin/GRX5/mksquashfs3 -> ../common/mksquashfs3.34kc
lrwxrwxrwx 1 root root 21 Aug 19 13:54 ./bin/GRX5/mke2fs -> ../common/mke2fs.34kc
lrwxrwxrwx 1 root root 29 Aug 19 13:54 ./bin/GRX5/busybox.config -> ../common/busybox.config.34kc
lrwxrwxrwx 1 root root 25 Aug 19 13:54 ./bin/GRX5/unsquashfs3 -> ../common/unsquashfs.34kc
lrwxrwxrwx 1 root root 26 Aug 19 13:54 ./bin/GRX5/mksquashfs4 -> ../common/mksquashfs4.34kc
lrwxrwxrwx 1 root root 22 Aug 19 13:54 ./bin/GRX5/openssl -> ../common/openssl.34kc
lrwxrwxrwx 1 root root 21 Aug 19 13:54 ./bin/GRX5/e2fsck -> ../common/e2fsck.34kc
lrwxrwxrwx 1 root root 22 Aug 19 13:54 ./bin/GRX5/busybox -> ../common/busybox.34kc
lrwxrwxrwx 1 root root 25 Aug 19 13:54 ./bin/GRX5/unsquashfs4 -> ../common/unsquashfs.34kc
lrwxrwxrwx 1 root root 3 Aug 19 13:54 ./bin/192 -> VR9
lrwxrwxrwx 1 root root 3 Aug 19 13:54 ./bin/175 -> VR9
lrwxrwxrwx 1 root root 4 Aug 19 13:54 ./bin/225 -> GRX5
lrwxrwxrwx 1 root root 6 Aug 19 13:54 ./bin/213 -> P6ATOM
lrwxrwxrwx 1 root root 3 Aug 19 13:54 ./bin/212 -> VR9
lrwxrwxrwx 1 root root 3 Aug 19 13:54 ./bin/218 -> VR9
lrwxrwxrwx 1 root root 6 Aug 19 13:54 ./bin/220 -> P6ATOM
lrwxrwxrwx 1 root root 25 Aug 19 13:54 ./bin/P6ATOM/mksquashfs3 -> ../common/mksquashfs3.x86
lrwxrwxrwx 1 root root 20 Aug 19 13:54 ./bin/P6ATOM/mke2fs -> ../common/mke2fs.x86
lrwxrwxrwx 1 root root 28 Aug 19 13:54 ./bin/P6ATOM/busybox.config -> ../common/busybox.config.x86
lrwxrwxrwx 1 root root 24 Aug 19 13:54 ./bin/P6ATOM/unsquashfs3 -> ../common/unsquashfs.x86
lrwxrwxrwx 1 root root 25 Aug 19 13:54 ./bin/P6ATOM/mksquashfs4 -> ../common/mksquashfs4.x86
lrwxrwxrwx 1 root root 21 Aug 19 13:54 ./bin/P6ATOM/openssl -> ../common/openssl.x86
lrwxrwxrwx 1 root root 20 Aug 19 13:54 ./bin/P6ATOM/e2fsck -> ../common/e2fsck.x86
lrwxrwxrwx 1 root root 21 Aug 19 13:54 ./bin/P6ATOM/busybox -> ../common/busybox.x86
lrwxrwxrwx 1 root root 28 Aug 19 13:54 ./bin/P6ATOM/mksquashfs4-be -> ../common/mksquashfs4-be.x86
lrwxrwxrwx 1 root root 24 Aug 19 13:54 ./bin/P6ATOM/unsquashfs4 -> ../common/unsquashfs.x86
lrwxrwxrwx 1 root root 28 Aug 19 13:54 ./bin/P6ATOM/unsquashfs4-be -> ../common/unsquashfs4-be.x86
lrwxrwxrwx 1 root root 26 Aug 19 13:54 ./bin/Vx180/mksquashfs3 -> ../common/mksquashfs3.24kc
lrwxrwxrwx 1 root root 21 Aug 19 13:54 ./bin/Vx180/mke2fs -> ../common/mke2fs.24kc
lrwxrwxrwx 1 root root 29 Aug 19 13:54 ./bin/Vx180/busybox.config -> ../common/busybox.config.24kc
lrwxrwxrwx 1 root root 26 Aug 19 13:54 ./bin/Vx180/mksquashfs4 -> ../common/mksquashfs4.24kc
lrwxrwxrwx 1 root root 22 Aug 19 13:54 ./bin/Vx180/openssl -> ../common/openssl.24kc
lrwxrwxrwx 1 root root 21 Aug 19 13:54 ./bin/Vx180/e2fsck -> ../common/e2fsck.24kc
lrwxrwxrwx 1 root root 25 Aug 19 13:54 ./bin/Vx180/unsquashfs -> ../common/unsquashfs.24kc
lrwxrwxrwx 1 root root 22 Aug 19 13:54 ./bin/Vx180/busybox -> ../common/busybox.24kc
lrwxrwxrwx 1 root root 4 Aug 19 13:54 ./bin/221 -> GRX5
#- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,298
- Punkte für Reaktionen
- 1,760
- Punkte
- 113
So ad hoc würde ich - anhand der "bad numbers" und auch anhand der Häufigkeit und Verteilung der Meldungen - auf ein Problem beim Zusammenstellen der lokalisierten Zeichenketten tippen ... das läuft natürlich über mehrfache Substitutionen und Escapes und vermutlich ist da dann etwas schief.
Da ich ja i.d.R. nur in GitHub einchecke, könnte ich mir auch vorstellen, daß beim Auschecken irgendetwas im "locale"-Verzeichnis geändert wird, weil ich keine ".gitattributes" dort liegen habe und das "text"-Handling aus dem Root-Verzeichnis greift oder irgendwelche systemweiten/benutzerdefinierten generellen Settings für "git".
Vielleicht kannst Du ja mal die "locale"-Dateien aus dem Archiv von meinem Server und aus dem Checkout vergleichen ... bei mir gibt es da auch keine Differenzen nach dem Klonen des Repo, aber ggf. wirken irgendwelche systemweiten git-Settings da ja mit. Ansonsten muß man wirklich mal mit Traces nachsehen ... ich habe leider gerade keine Hand frei, um den kompletten Weg mal selbst nachzustellen.
Da ich ja i.d.R. nur in GitHub einchecke, könnte ich mir auch vorstellen, daß beim Auschecken irgendetwas im "locale"-Verzeichnis geändert wird, weil ich keine ".gitattributes" dort liegen habe und das "text"-Handling aus dem Root-Verzeichnis greift oder irgendwelche systemweiten/benutzerdefinierten generellen Settings für "git".
Vielleicht kannst Du ja mal die "locale"-Dateien aus dem Archiv von meinem Server und aus dem Checkout vergleichen ... bei mir gibt es da auch keine Differenzen nach dem Klonen des Repo, aber ggf. wirken irgendwelche systemweiten git-Settings da ja mit. Ansonsten muß man wirklich mal mit Traces nachsehen ... ich habe leider gerade keine Hand frei, um den kompletten Weg mal selbst nachzustellen.
@Pokemon20021:
Ein Windows-Rechner ist - wie ich auch schon geschrieben hatte - bei der Sache nicht beteiligt. Ich halte Peters Vermutung in #1254 für wahrscheinlich...
@PeterPawn:
Werde ich demnächst nochmal anschauen...
Ein Windows-Rechner ist - wie ich auch schon geschrieben hatte - bei der Sache nicht beteiligt. Ich halte Peters Vermutung in #1254 für wahrscheinlich...
@PeterPawn:
Werde ich demnächst nochmal anschauen...
Sure, I'll do some more tests and then open a new thread. Thanks for all the other information and have a nice day, Peter
@PeterPawn I'm realizing that I never asked the question about which are the recommended compiled mips binaries to be used with modfs.
The modfs option "add/replace some binaries at the target system" usually reports that the binaries source files' archive is not found so
I downloaded dropbearmulti from fritzmod.net and I'm currently using dropbearmulti_v2014.63.mips.
I'm not sure if this might contribute to the problems I'm having and that's the reason for two questions:
Which binaries do you recommend?
Is there a link to get the ones that you tested currently working?
Thanks again, good night to everybody.
- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,298
- Punkte für Reaktionen
- 1,760
- Punkte
- 113
@Virgus:
How to use the "copy_binaries" modification?
Please try to find the writing (of mine) here in this thread, in which I've proposed the "right" usage of the "add/replace binaries" modification - I myself did not record all of those links ... the internal search engine should help you nevertheless to locate it.
As a really short repetition: This archive needs a special name and has to mirror the sub-directory structure of the original firmware, to extract each contained file at the right target.
Where can you find usable (pre-compiled) binaries?
The "bin" sub-directory of a "modfs" archive contains at least a statically linked BusyBox binary, which was built on top of a more recent version from upstream (but it's still not the most current - 1.27.x). The OpenSSL command line utility aside this BusyBox binary was also linked statically and may be used without any additional files needed. Obviously these files are running on a FRITZ!Box device - you're using them already, while you're working with "modfs".
There are further files - unsquashfs/mksquashfs to (de-)construct SquashFS images, make and check "extX" file system tools and possibly a command line tool to handle AVMs encipherment of settings. All of these files are a little bit "suspicious", due to the lack of my signature for each single one or all of them together.
Nevertheless you could decide to use them ... as far as I know, the files from fritzmod.net were also never signed.
If you're looking for other files and want to trust my signature, you may have a look onto the "bin" sub-directory of my YourFritz repository on GitHub. There you can find a bunch of signed utilities for MIPS devices - please be aware, that they're assembled in a special branch "binaries" and not visible, as long as the current branch is "master" (the default one).
Because I've never wrote about them in the past (and I've reorganized it a bit some days ago), this writing will now (one more time) get longer, than I planned it.
The files contained therein (at this moment) are the following:
All binaries were built with the idea of an additional "root directory" on "/var/custom" in mind (where I usually mount my own extension image) ... some binaries rely on path names (to locate their settings or other programs) starting there. If you put such files into the root image, you still need to provide a symbolic link (at least for some of them) from a structure beneath "/var/custom" to the file(s) in your SquashFS root image. You should try all of these programs thoroughly, in front of any attempts to incorporate services (based on these files) into your usage of "modfs".
How to use the "copy_binaries" modification?
Please try to find the writing (of mine) here in this thread, in which I've proposed the "right" usage of the "add/replace binaries" modification - I myself did not record all of those links ... the internal search engine should help you nevertheless to locate it.
As a really short repetition: This archive needs a special name and has to mirror the sub-directory structure of the original firmware, to extract each contained file at the right target.
Where can you find usable (pre-compiled) binaries?
The "bin" sub-directory of a "modfs" archive contains at least a statically linked BusyBox binary, which was built on top of a more recent version from upstream (but it's still not the most current - 1.27.x). The OpenSSL command line utility aside this BusyBox binary was also linked statically and may be used without any additional files needed. Obviously these files are running on a FRITZ!Box device - you're using them already, while you're working with "modfs".
There are further files - unsquashfs/mksquashfs to (de-)construct SquashFS images, make and check "extX" file system tools and possibly a command line tool to handle AVMs encipherment of settings. All of these files are a little bit "suspicious", due to the lack of my signature for each single one or all of them together.
Nevertheless you could decide to use them ... as far as I know, the files from fritzmod.net were also never signed.
If you're looking for other files and want to trust my signature, you may have a look onto the "bin" sub-directory of my YourFritz repository on GitHub. There you can find a bunch of signed utilities for MIPS devices - please be aware, that they're assembled in a special branch "binaries" and not visible, as long as the current branch is "master" (the default one).
Because I've never wrote about them in the past (and I've reorganized it a bit some days ago), this writing will now (one more time
) get longer, than I planned it.The files contained therein (at this moment) are the following:
- a BusyBox binary ... usually created with the same settings as the BusyBox from "modfs" archives; call "busybox bbconfig" to get a copy of the .config file used to build it
- a utility to handle various aspects of decipherment for AVMs encrypted settings (from https://github.com/PeterPawn/decoder)
- a 'dropbearmulti' binary, which may be used as a server and client for SSH connections; this one is a little bit "crippled" and was built from my Freetz fork (https://github.com/PeterPawn/freetz/tree/YourFritz/make/dropbear/patches/yourfritz) with very special changes - nevertheless it's usable with any SSH client or server, as long as the contained (very limited, but secure) cipher selections are supported by the other side (it needs additional symbolic links - for the contained parts - in the file system)
- a SFTP server extension usable with 'dropbearmulti' (please note later comments regarding path name requirements)
- an OpenSSL command line utility to provide crypto technology and secure network connections for other programs or scripts; together with this binary, the BusyBox (from above) applet 'wget' may be used to download files from HTTPS sources, too (it's not possible with AVMs version of BusyBox)
- a Shell-In-a-Box binary, which uses the internal certificate from FRITZ!OS (self-signed or user-provided)
- a 'stunnel' binary - it's a TLS wrapper for unencrypted (TCP) connections of any kind and may be used to provide more security for such connections or to add own "secure service(s)" to a device (e.g. gathering/providing some information with shell scripts on a FRITZ!OS device), which use(s) client certificates, to limit use of such services to a bunch of authorized hosts - this program may also use the certificate and key from FRITZ!OS for its own connections
- tools to assemble/disassemble a SquashFS image with AVMs format
- the shell scripts from the "signimage" sub-directory, which were described (of mine - take this as a hint to limit search results) in a different thread, which regards AVMs firmware signing process
- various "helper" scripts for TFFS handling (from the "tffs" sub-directory in the repository)
- and last, but not least some very (very) simple shell scripts (more 'one-liners') to repeat often needed tasks ... reset the 'tainted' flag for the firmware, wait for an established internet connection (works only with devices in router mode) or wait until a valid date/time was set after the device was booted shortly ago
All binaries were built with the idea of an additional "root directory" on "/var/custom" in mind (where I usually mount my own extension image) ... some binaries rely on path names (to locate their settings or other programs) starting there. If you put such files into the root image, you still need to provide a symbolic link (at least for some of them) from a structure beneath "/var/custom" to the file(s) in your SquashFS root image. You should try all of these programs thoroughly, in front of any attempts to incorporate services (based on these files) into your usage of "modfs".
Zuletzt bearbeitet:
Dear PeterPawn, I'm really grateful for all the information you always provide. I learn always a lot from your replies.
I read everything and I'll dig into the details of your last reply in the next days.
Besides thanking you I wanted to report that I finally wrote to AVM support mentioning the webdav "100 seconds" reboot issue and decided to downgrade to OS 6.52.
No more problems now. I'll wait for a new OS release hoping they will have a look and solve the issue. The risk of having a box that won't reboot properly worried me a bit, so I suppose this was the best choice for now.
Have a nice weekend, all of you,
V.
- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,298
- Punkte für Reaktionen
- 1,760
- Punkte
- 113
So, ich habe mich auch mal dem Thema mit den "bad number"-Fehlern beim "modfs" gewidmet und das Problem auf die Zeilen:
eingegrenzt.
Bei der im Moment mit "modfs" ausgelieferten BusyBox führt das Ermitteln der Länge bestimmter Zeichenketten (welche genau das sind, muß ich erst noch prüfen) zu einem falschen Ergebnis ... anstelle der reinen Zahl mit der Länge werden irgendwelche Zeichen noch davor ausgegeben. Die Zeichenkette an sich ist dabei allerdings richtig ... sie enthält exakt das, was zu erwarten ist.
Als Workaround habe ich das erst einmal auf einen Zeichenkettenvergleich umgestellt, denn das funktioniert hier ebenfalls. Was die Ursache dafür ist und was innerhalb einer solchen Zeichenkette dann dazu führt, daß für diese eine falsche Länge ausgegeben wird (m.E. sind nicht alle Zeichenketten davon betroffen, wobei ich das noch mal systematisch testen muß), ist noch reichlich unklar.
Jedenfalls habe ich diese Änderung jetzt auch gleich noch zum Anlaß genommen, die Versionsnummer zu erhöhen und neue Dateien bereitzustellen. Dabei habe ich noch den älteren Boot-Manager entfernt und ein paar kosmetische Änderungen vorgenommen bzw. in die (immer noch nicht genutzten) Dateien der Script-Library einen anderen "expr"-Aufruf eingearbeitet, der auch ohne die - von dem "expr" in der BusyBox bisher nicht unterstützten - doppelten Bindestriche vor dem ersten Argument auskommt und trotzdem bis inkl. zur NetBSD-Variante von "expr" (und auch unter MacOS X) portabel sein sollte.
Ab sofort gibt es auf dem Server unter yourfritz.de auch nur noch die Variante mit dem Namen "modfs.tgz", die immer auf die aktuellste Version verweist. Alle anderen Links (modfs-0.4.6.tgz als Beispiel für die aktuelle Version) werden auf eine Datei "modfs-old-version.tgz" umgeleitet, die eine entsprechende "README.md"-Datei (in Englisch) enthält und wo das "modfs"-Skript lediglich diese Datei anzeigt. Wer unbedingt eine ältere Version benutzen möchte, kann sich jederzeit selbst das GitHub-Repository mit einem früheren Stand auschecken und daraus dann selbst ein passendes Archiv bauen oder die Dateien irgendwie anders auf die Box bringen.
Der direkte Download von GitHub über HTTPS funktioniert aber mit der AVM-Version der Firmware nicht ... auf einem bereits zuvor modifizierten System mit der BusyBox und "openssl" aus dem "modfs"-Archiv beherrscht dann allerdings auch das "wget"-Applet der BusyBox den Download von HTTPS-URLs und man könnte anstelle der Archiv-Datei von http://yourfritz.de/modfs.tgz auch direkt das Repository von https://github.com/PeterPawn/modfs/archive/master.zip laden.
Code:
msg="$($bb sed -n -e "/^$msgno=/s/^[0-9]*=\(.*\)/\1/p" $lcfile | $bb sed -e "s/%{error}/\${msgtext_error}/g" | $bb sed -e "s/%{ok}/\${msgtext_ok}/g" | $bb sed -e "s/%{warning}/\${msgtext_warning}/g" | $bb sed -e "s/%{bold}/\${msgtext_bold}/g" | $bb sed -e "s/%{normal}/\${msgtext_normal}/g" | $bb sed -e "s/%{highlight}/\${msgtext_highlight}/g")"
if [ ${#msg} -eq 0 ]; then
[...]
else
[...]
fiBei der im Moment mit "modfs" ausgelieferten BusyBox führt das Ermitteln der Länge bestimmter Zeichenketten (welche genau das sind, muß ich erst noch prüfen) zu einem falschen Ergebnis ... anstelle der reinen Zahl mit der Länge werden irgendwelche Zeichen noch davor ausgegeben. Die Zeichenkette an sich ist dabei allerdings richtig ... sie enthält exakt das, was zu erwarten ist.
Als Workaround habe ich das erst einmal auf einen Zeichenkettenvergleich umgestellt, denn das funktioniert hier ebenfalls. Was die Ursache dafür ist und was innerhalb einer solchen Zeichenkette dann dazu führt, daß für diese eine falsche Länge ausgegeben wird (m.E. sind nicht alle Zeichenketten davon betroffen, wobei ich das noch mal systematisch testen muß), ist noch reichlich unklar.
Jedenfalls habe ich diese Änderung jetzt auch gleich noch zum Anlaß genommen, die Versionsnummer zu erhöhen und neue Dateien bereitzustellen. Dabei habe ich noch den älteren Boot-Manager entfernt und ein paar kosmetische Änderungen vorgenommen bzw. in die (immer noch nicht genutzten) Dateien der Script-Library einen anderen "expr"-Aufruf eingearbeitet, der auch ohne die - von dem "expr" in der BusyBox bisher nicht unterstützten - doppelten Bindestriche vor dem ersten Argument auskommt und trotzdem bis inkl. zur NetBSD-Variante von "expr" (und auch unter MacOS X) portabel sein sollte.
Ab sofort gibt es auf dem Server unter yourfritz.de auch nur noch die Variante mit dem Namen "modfs.tgz", die immer auf die aktuellste Version verweist. Alle anderen Links (modfs-0.4.6.tgz als Beispiel für die aktuelle Version) werden auf eine Datei "modfs-old-version.tgz" umgeleitet, die eine entsprechende "README.md"-Datei (in Englisch) enthält und wo das "modfs"-Skript lediglich diese Datei anzeigt. Wer unbedingt eine ältere Version benutzen möchte, kann sich jederzeit selbst das GitHub-Repository mit einem früheren Stand auschecken und daraus dann selbst ein passendes Archiv bauen oder die Dateien irgendwie anders auf die Box bringen.
Der direkte Download von GitHub über HTTPS funktioniert aber mit der AVM-Version der Firmware nicht ... auf einem bereits zuvor modifizierten System mit der BusyBox und "openssl" aus dem "modfs"-Archiv beherrscht dann allerdings auch das "wget"-Applet der BusyBox den Download von HTTPS-URLs und man könnte anstelle der Archiv-Datei von http://yourfritz.de/modfs.tgz auch direkt das Repository von https://github.com/PeterPawn/modfs/archive/master.zip laden.
- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,298
- Punkte für Reaktionen
- 1,760
- Punkte
- 113
Zusätzlich zu der Änderung aus #1259 habe ich die BusyBox-Version im "modfs"-Archiv noch gegen eine getauscht, die nun doch wieder ohne aktivierte Unicode-Unterstützung arbeitet und damit aber wenigstens Zahlen als Längenangabe liefert.
Zur eigentlichen Ursache: https://www.ip-phone-forum.de/threads/busybox-1-24-2-aus-der-freetz-toolchain.296827/
Das sollte noch rechtzeitig vor der Release-Version für die 7490 sein ... da werden sicherlich wieder einige "modfs"-Benutzer aktiv werden, wenn AVM irgendwann mal soweit ist.
Damit ist das Thema dann für mich erst einmal durch und das "bad number" ad acta gelegt ... sowohl die Ursache ist jetzt klar als auch ein Workaround im Skript implementiert, der auch bei fehlerhafter BusyBox und aktiviertem Unicode das erwartete Ergebnis liefert.
Zur eigentlichen Ursache: https://www.ip-phone-forum.de/threads/busybox-1-24-2-aus-der-freetz-toolchain.296827/
Das sollte noch rechtzeitig vor der Release-Version für die 7490 sein ... da werden sicherlich wieder einige "modfs"-Benutzer aktiv werden, wenn AVM irgendwann mal soweit ist.
Damit ist das Thema dann für mich erst einmal durch und das "bad number" ad acta gelegt ... sowohl die Ursache ist jetzt klar als auch ein Workaround im Skript implementiert, der auch bei fehlerhafter BusyBox und aktiviertem Unicode das erwartete Ergebnis liefert.
Neueste Beiträge
-
-
[Sammlung] AVM-Gateway-kompatible Zigbee-Geräte
- Letzte: H´Sishi
-
[Frage] 5590 Fiber und 1200AX - Wlan Frage- Letzte: maik005
-
1und1 online.de Emailadresse "befreien"
- Letzte: superpapa
-
[Frage] Freepbx mit Telekom und Aufzeichnung
- Letzte: duffy6
-
5690 Pro Datenraten Problem 5ghz und 6ghz- Letzte: Jstessi
