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

[PeterPawn]

Ich meinte auch eher, daß durch das Gedimme jetzt wieder mal jemand auf diese Seite geschaut hat und daher diese Änderung durchgezogen wurde.

Am Ende bewirkt sie ja lediglich, daß auch beim "Wiederaufbau" der Seite nach einem POST-Request zum Ändern der Einstellung nicht einfach der Wert angezeigt wird, den die Box setzen sollte, sondern durch die (nunmehr unbedingte) erneute Abfrage des tatsächlich eingestellten Wertes auch das angezeigt wird, was im Ergebnis des POST-Requests jetzt wirklich aktiv ist. Das muß ja nicht zwangsläufig mit dem übereinstimmen, was gesetzt werden sollte ... z.B. dann, wenn das ein ungültiger Wert ist/war.

Ansonsten finden sich die Einstellungen zum Dimmen in der "infoled.lua" ... dort gibt es dann auch die passenden Einstellungen beim "ctlmgr" (z.B. "led_dim_brightness"). Welche Texte da aber genau stehen? Keine Ahnung ... dafür müßte ich auch erst die Zeichenkettenersetzung mal über die 7590-Firmware laufen lassen. Jedenfalls sind die notwendigen Zeichenketten (z.B. "4893:147") in anderer Firmware m.W. auch nicht enthalten. Im Gegensatz zu vielen anderen Stellen ist diese "infoled.lua" tatsächlich eine Datei, die in der Firmware für verschiedene Modelle unterschiedliche Inhalte hat und wo nicht nur anhand einer Variablen aus dem "festen Teil" der Firmware eine Funktion ein- oder ausgeblendet wird und das gilt offenbar auch für die zusätzlichen Übersetzungen in der "htmltext.db".

 

[eisbaerin]

die Einstellungen zum Dimmen in der "infoled.lua"

Danke, das schau ich mir mal an.
Vielleicht bekomme ich ja die 7580 auch gedimmt? Hat das schon mal einer probiert?

 

[Virgus]

Hello Peter Pawn & everybody,
I'm having a problem with one of my Fritz!Fon and AVM asked me to do a recovery af the FritzBox ( as they wrote "the support data reveals that the firmware of the FRITZ!Box is not present as expected") so I did a full recovery and now I applied the modfs again. What a waste of time for a simple handset antenna fault!

I have two questions (one of which is related to modfs):
1) would the reset_tainted.image in the yourfritz/first-aid/ folder will avoid this kind of requests in the future? How exactly should I apply the image to my current installation?
2) I'm having an error with reboot (please see the snapshots) and I had to remove gui_boot_manager_v0.4 from the modscripts folder prior to applying modfs to be able to reboot the fritz from the web interface. I had no problems with the previous version in august: is there a way to download it somewhere? I tried to follow the instructions in modfs-old-version.tgz but didn't make it :-(

Thanks and have a nice day,
Virginio

PS: The installed os is the 6.52 with the latest modfs (I'm waiting for the international version of the 6.92 to upgrade).
The reboot command is not executed and I the browser shows the first login page after a couple of seconds.

 

[Shirocco88]

I had no problems with the previous version in august: is there a way to download it somewhere?

IMHO: You can check out an older version of modfs/modscripts/gui_boot_manager_v0.4
https://github.com/PeterPawn/modfs/commits/master/modscripts/gui_boot_manager_v0.4
or complete modfs version from github:
modfs-0.4.4-250320170037
modfs-0.4.5-170820171407
modfs-0.4.5-300320172215
modfs-0.4.6-190920172210


these are the last 3 commits of modfs/modscripts/gui_boot_manager_v0.4:
Commits on Aug 17, 2017
fix some boot-manager problems
https://github.com/PeterPawn/modfs/...fcddc02#diff-43008ebacd6962d158e8d5385083ea1f

Commits on Aug 10, 2017
some older changes waiting to be committed
https://github.com/PeterPawn/modfs/...c9aafa8#diff-43008ebacd6962d158e8d5385083ea1f

Commits on May 14, 2017
adapt bootmanager to Puma6 new architecture
https://github.com/PeterPawn/modfs/...83da126#diff-43008ebacd6962d158e8d5385083ea1f

 

[PeterPawn]

As mentioned above, you may use the history of changes from GitHub to create yourself an own copy of older versions (at a whole or with selected older files). The only problem could be, that you can't download it directly to a running FRITZ!OS version (original firmware from vendor), because you would need TLS support to access GitHub and AVM's own implementation (httpsdl) doesn't work for GitHub. At least, I'm unable to load from GitHub with it.

If the difference between FRITZ!OS versions installed gets substantial, it's not as easy to consider all circumstances on further changes. The missing function "is_puma_na" was introduced in summer 2016 (by AVM) to distinct between the "old" and "new" architecture on Puma6-based devices (DOCSIS boxes). If you want to use the updated boot manager "modscript" with a pre-06.80 version, you have to add the missing functions to "/etc/puma6_helper.sh" yourself. The following patch has to be applied to the file-system manually (EDIT: It was a patch for the wrong direction, I've removed it.) or you simply copy the whole file "/etc/puma6_helper.sh" from a newer version to the resulting directory structure prior to packing.

I don't know, whether using the "reset_tainted.image" would solve AVMs "problem" with your installation ... I've no idea, what you did show from your device. There are many spots in a "support data file", where an attentive observer could detect changes by the owner and there are two ways to circumvent it: First you could install an original version from vendor (and keep your version in the other partition intact), after you've reset the "tainted flag". Or you could edit the support-data, to hide own processes and changed files.

If you want to use the "reset_tainted.image" file to reset the flag, you have to boot the device with this image once ... that's all. The only change from this action will be the purge of TFFS node 87, where this flag is stored (and here it survives firmware updates and factory-resets). But it's much simpler to run a command:

echo clear_id 87 >/proc/tffs

from a shell instance ... this also purges to mentioned file. As long as you don't log-in again, the flag will not be set again ... it's the result of using "ar7login" to be able to use the FRITZ!OS accounts to login. As an alternative, you can use the https://github.com/PeterPawn/YourFritz/blob/master/tools/resetsigned script to reset the flag only, if it's really set ... and you could use this script on a regular basis (e.g. at boot time) to reset an earlier marker.

 

[BurningCrash]

Und kann jemand schon was zum Update 06.92 sagen mit der Bearbeitung mit modFS?

 

[eisbaerin]

Reicht #1278 nicht?:

Modfs läuft auch mit der 06.92 für die 7490 mit allen modscripts ohne angezeigten Fehler durch

 

[Virgus]

As an alternative, you can use the https://github.com/PeterPawn/YourFritz/blob/master/tools/resetsigned script to reset the flag only, if it's really set ... and you could use this script on a regular basis (e.g. at boot time) to reset an earlier marker.

Thanks Peter! And thanks to Shirocco information also!
I tried part of what suggested but unfortunately AVM was not satisfied with the information I provided and requested me an 6.83 recovery with new support data. I have to waste more time on a 99% hardware problem but that's the only condition for returning my Fritz!Fon for RMA.

I will soon test the rest of all the valuable information you provided after all this...

Have a nice day,
V.

 

[Shirocco88]

I tried part of what suggested but unfortunately AVM was not satisfied with the information I provided and requested me an 6.83 recovery with new support data.

could you please give us more detail;
why was AVM not satisfied ?
did you tell them what you have done ?
is a factory reset also sufficient or are there any indication showing an issue with your rootfs ?

@PeterPawn: is there a timestamp in support data indicating last recovery date to AVM ?

 

[BurningCrash]

Reicht #1278 nicht?:

UUPPPPSSSSS... sorry ;-)

Danke

 

[PeterPawn]

As far as I know, it's impossible to detect the (correct) time of a recovery ... the TFFS device nodes do not carry an own date/time stamp and all other files don't survive a recovery. Some TFFS text files contain a date/time information in their (readable) header ... rather old values here are a sign for an older installation, because this value will be updated on import (afaik).

To get the time of last modification, the "boot manager" uses (on devices with a "/wrapper" partition) the date/time of the SquashFS image for the real root file-system. But this value isn't visible from support data.

On devices without a wrapper (that's the YAFFS2 partition for "filesystem" entries and GRX5 models use UBIFS here), an additional file "/etc/.modfs_version" (it contains the "modfs" version used to create the root file-system) and its modification date/time is used ... but content of "/etc" isn't listed in the support data file.

Summary: It's possible to find hints or conclude (or at least to get an idea), whether a system has been recovered, but there's no (known) time-stamp for this. There are multiple signs to detect other changes ... it's really not easy "to hide" them in the output of support data, but it's possible and a malware author would take the efforts.

 

[Shirocco88]

Thanks for the explanation!

 

[Chatty]

Hi, also ich habe:

1. meine 7490 per Recover auf 06.50 gebracht
2. Dann SIAB als manuelles Update installiert
3. die aktuelle Beta aufs NAS geladen
4. ./modfs update /var/media/ftp/FRITZ.Box_7490.113.06.98-48032.image ausgeführt
5. die telnetd-Modifikation war nicht erfolgreich
6. die Übersichtsseite ist leer
7. SIAB ist weg

//edit stoney: Deeplink entfernt

 

[PeterPawn]

Solange es noch keine halbwegs offizielle Version davon gibt, werde ich an "modfs" nichts ändern.

AVM hat in dieser Version den Sprung von Version 1.22.1 auf 1.24.2 bei der BusyBox vollzogen und auch bei der verwendeten C-Library hat man den Sprung von der 0.9.irgendwas auf die 1.0.14 (also die uClibc-ng) "gewagt".

Warum das (zumindest dem Anschein nach) jetzt auch schon wieder eine alte Version ist (die aktuelle 1.0.27 ist zwar vom 27.11.2017, aber die 1.0.26 gibt es seit Ende Juli 2017), weiß wohl nur AVM allein ... aber im Ergebnis sind für alle nicht-statisch gelinkten Programme komplette Updates erforderlich, wobei die Programme dann auch gegen die korrekte Version gelinkt wurden.

Da es vermutlich erst sehr lange nach dem Erscheinen einer neuen Version auch die dafür verwendeten Quellen geben wird, bleibt einem nichts als Raten bzw. RE (reverse engineering) beim Ermitteln der korrekten Konfiguration für die verwendeten Komponenten (buildroot, uclibc, busybox), wenn man das schon vor der Veröffentlichung der Quellen in Angriff nehmen will.

Ich vermute mal, das wird sich auch beim Freetz-Projekt niemand antun (ich auch nicht für "modfs" oder "yourfritz") und damit kann/sollte man diesen Zweig erst mal vergessen, wenn man das nicht selbst tun will/kann und gleichzeitig eigene Änderungen an der Firmware vornehmen will. Es ist zwar theoretisch auch möglich, die uClibc sowohl in der 0.9.33.2 als auch die uClibc-ng parallel in einem Image zu haben (die kurzen Symlinks beinhalten m.W. auch alle die Versionsnummer, also mindestens die "0" bei der alten) und damit auch Programme zu verwenden, die mit der alten C-Library arbeiten wollen ... aber es muß/sollte schon mit einigen Problemen gerechnet werden.

Zwar wird es auch hierfür von AVM früher oder später die Quellen geben (die "ng" steht auch unter LGPL 2.1-Lizenz), aber die bisherigen Erfahrungen zeigen halt, daß das dauern kann ... wir hatten auch schon ein halbes Jahr zwischen Beginn einer Labor-Reihe und der Veröffentlichung der Sourcen für die daraus entstandenen Release-Versionen.

Es ist auch nicht so, daß AVM jetzt gleich mit fliegenden Fahnen mal alle alten Bibliotheken entrümpeln würde (oder vielleicht kommt das ja noch im Verlauf), denn die OpenSSL-Version ist auch in dieser "inoffiziellen" Version nach wie vor die 1.0.1t aus dem Mai 2016.

Die leere Übersichtsseite kann höchstens vom Patch für die Anzeige der VPN-Verbindungen in der Übersicht kommen (wenn es seine Ursachen in einem Patch hat), dort wird vermutlich irgendwo ein Syntaxfehler entstehen oder die erzeugte JSON-Datei aus der "overview.lua" hat ein falsches Format oder was weiß ich.

Da man außer einigen Patches (deren fortbestehende Notwendigkeit und/oder Funktionsfähigkeit man auch erst mal abklären müßte) bisher an dieser Version nur mit zusätzlichem eigenem Aufwand und Wissen etwas bewirken kann, bin ich keineswegs "happy" mit dem Gedanken, da zeitnah selbst zu testen - aber schon gar nicht, solange es nicht wenigstens eine offizielle Labor-Version gibt. Zumal es ja hier nur "begrenzten Bedarf" gibt ... diese Version sollte selbst beim Shell-Zugriff noch den Zugang über die Support-Seite anbieten - zumindest ist "shellinaboxd" als Programm im Image enthalten.

 

[eisbaerin]

diese Version sollte selbst beim Shell-Zugriff noch den Zugang über die Support-Seite anbieten

Da bin ich mir nicht sicher, da die /usr/www/avm/lua/shellinabox.lua fehlt.

Aber telnet sollte IMO gehen.

 

[PeterPawn]

Da bin ich mir nicht sicher, da die /usr/www/avm/lua/shellinabox.lua fehlt.

Es sieht so aus, als hätte AVM den Start von Shell-In-A-Box in den "ctlmgr" verschoben ... laß mal ein "grep shellin" über die entpackte Firmware laufen.

 

[PeterPawn]

Kurz mal die Änderungen, die - bei mir - zu Problemen mit drei Patches geführt haben:

1. "own files" scheitert ggf. daran, daß auch ein neuer Linux-Kernel (3.10.107) verwendet wird und der Name der zu entpackenden Archiv-Datei diese Kernel-Version enthält -> die Datei wird ohne passende Vorbereitungen nicht gefunden

2. "enable telnetd" braucht es (konkret in der 113.06.98-48153) gar nicht, weil der Symlink "/usr/sbin/telnetd" bereits existiert ... deshalb "denkt" das Skript auch, der Patch wurde bereits angewendet.

3. "swapoff" findet dann die Ankerzeilen für den Patch in der "/etc/hotplug/usb.pandu" nicht, weil da einiges geändert wurde (wohl auch im Zuge der Integration der Änderungen für die 6890) - hier würde ggf. schon das Ändern einer Zeile (und das Entfernen einer weiteren) dazu führen, daß das Skript wieder funktioniert.

Ich habe allerdings für kein einziges "modscript" tatsächlich probiert, ob das Ergebnis auch in den 06.98-Intern-Versionen paßt ... hier ging es mir nur um die sofort bei der Verarbeitung des Images mit "modfs" sichtbaren Probleme mit diesen drei Änderungen.

Bei "swapoff" werde ich wohl (in Kürze bzw. noch "in dieser Woche" - und ich darf/kann/will auch am Sonntag arbeiten) die oben erwähnte Änderung mal antesten, damit wäre dann Punkt 3 schon erledigt. Den zweiten Punkt braucht man eigentlich nicht (also einfach weglassen beim Update) und den ersten muß auch der "modfs"-Benutzer ohnehin selbst behandeln, denn das Skript versucht nur die Datei mit dem abgeleiteten Namen zu entpacken ... gibt es die nicht, scheitert es halt.

Wie schon weiter oben geschrieben, kann man vermutlich auch noch ältere Binaries verwenden, erst recht dann, wenn die entweder statisch gelinkt sind oder man die C-Bibliotheken ebenfalls noch dazupackt. Am fehlenden Platz sollte es bei den VR9-Modellen ja eigentlich nicht scheitern, da ist i.d.R. noch genug Luft in den YAFFS2-Partitionen, auch für ein größeres SquashFS-Image - sofern man den nicht anderweitig verwendet.

 

[eisbaerin]

4. "mod_leddisplay" das ähnliche Problem aus #1278
IMO mit noch mehr Änderungen an der led_display.lua.

Hier mal der diff zur 06.83:

--- led_display.lua83
+++ led_display.lua98
@@ -3,22 +3,23 @@
 g_page_title = ""
 g_page_help = "hilfe_system_anzeige.html"
 dofile("../templates/global_lua.lua")
-require("val")
 g_back_to_page = http.get_back_to_page( "/system/led_display.lua" )
 g_errmsg = nil
-g_val = {
-prog = [[
-]]
-}
 g_led_display="0"
 function read_box_values()
-g_led_display =box.query("box:settings/led_display")
+g_led_display = box.query("box:settings/led_display")
 end
+local function check_val(val)
+if val~="0" and val~="1" and val~="2" then
+return "0"
+end
+return val
+end
 function refill_user_input_from_post()
-g_led_display =box.post.led_display
+g_led_display = check_val(box.post.led_display)
 end
 function refill_user_input_from_get()
-g_led_display =box.get.led_display
+g_led_display = check_val(box.get.led_display)
 end
 if next(box.post) then
 if box.post.apply then
@@ -37,9 +38,8 @@
 http.redirect(href.get(g_back_to_page))
 return
 end
-else
-read_box_values()
 end
+read_box_values()
 function write_led_selected(current)
 if (g_led_display==current) then
 box.out([[checked="checked"]])
@@ -52,26 +52,17 @@
 <style type="text/css">
 </style>
 <script type="text/javascript">
-<?lua
-val.write_js_globals_for_ip_check()
-val.write_js_error_strings()
-?>
 function OnChangeLedDisplay(val)
 {
 }
 function uiDoOnMainFormSubmit()
 {
-var ret;
-<?lua
-val.write_js_checks(g_val)
-?>
 return true;
 }
 function init()
 {
 return true;
 }
-ready.onReady(val.init(uiDoOnMainFormSubmit, "apply", "main_form" ));
 ready.onReady(init);
 </script>
 <?include "templates/page_head.html" ?>

 

[Chatty]

Erneute Bitte um Aktualisierung, jetzt wo die 6.98-48254 BETA draußen ist.

 

[eisbaerin]

Die "mod_show_vpn_on_overview" habe ich mal aktualisiert. Bin gerade fertig damit.
Da sind nur 4 Zeilen zu ändern. Am besten folgende Änderungen machen:

--- mod_show_vpn_on_overview
+++ mod_show_vpn_on_overview
@@ -134,7 +134,7 @@
 --- usr/www/$TARGET_BRANDING/home/home.lua
 +++ usr/www/$TARGET_BRANDING/home/home.lua
 @@ -548,6 +548,90 @@
- end
+ d.callsToday = tostring(foncalls.count_today()) or "0"
  return d
  end
 +local function get_vpn_connections(data)
@@ -221,9 +221,9 @@
 +    end
 +    return vpn
 +end
- local function unknown()
- return [[ — ]]
- end
+ local function get_tamcalls(data)
+ if not config.FON then return nil end
+ if (not config.TAM_MODE or config.TAM_MODE==0)then return nil end
 --- usr/www/$TARGET_BRANDING/home/home.lua
 +++ usr/www/$TARGET_BRANDING/home/home.lua
 @@ -1371,6 +1455,7 @@

Dann sollte es von FW 06.83 bis 06.98 (ich hoffe sogar noch bei der 07.xx) klappen. Noch nicht überprüft.

Peter kann das ja auch übernehmen.

An die "mod_swapoff" trau ich mich nicht ran. Das müßte Peter oder ein anderer machen.
Die "usb.pandu" ist dabei das kleinere Problem, aber die "storage".

Was fehlt dir sonst noch?