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

[splenditnet]

@koyaanisqatsi: Fix ist schon ermittelt, siehe #480

nach Ändern der Zeile:
BRANDINGS="$(get_target_brandings "$target")"
in modfs wird die Umgebungsvariable BRANDINGS
bei deutschem FW-Image dynamisch mit "avm, 1und1"
und bei Int-FW-Image mit "avme" befüllt.
Anschließend wird im weiteren Skriptverlauf BRANDINGS in BRANDING,
bzw. TARGET_BRANDINGS und TARGET_BRANDING "skript-technisch" verarbeitet;

Fehlerursache war, dass die Umgebungsvariable BRANDINGS mit Leerstring befüllt wurde.

 

[splenditnet]

Hallo modfs-0.3.3-User mit int-FW, sowie andere Interessierte,
das Modscipt mod_default_show_mac läuft bei modfs-0.3.3 mit FW 6.36-31667-int in Fehler:

# ./modfs update FRITZ.Box_7490_BETA.en-de-es-it-fr-pl.113.06.36-31667.image
SNIP
Die Modifikation 'unhide MAC by default' wird verarbeitet ...
Überprüfen der unterstützten Sprachen ... OK
Soll die Modifikation 'unhide MAC by default' mit folgender Beschreibung
Anzeige von Heimnetz-Clients mit MAC-Adresse als Standard
angewendet werden? (j/N) j
[COLOR=#ff0000]Überprüfen der Voraussetzungen für die Modifikation ... Fehler (1)
Die Modifikation wurde bereits angewendet oder ist nicht erforderlich.

Die Modifikation 'unhide MAC by default' wurde angewendet, Fehlercode = 1.[/COLOR]

Ursache: die Pattern des Patchskripts aus modfs-0.3.3 passen nicht zur FW 6.36-31667-int

FB7490# cat modfs-0.3.3/modscripts/mod_default_show_mac
SNIP
--- usr/www/$TARGET_BRANDING/net/net_overview.js
+++ usr/www/$TARGET_BRANDING/net/net_overview.js
@@ -59,7 +59,7 @@
 var oldclasses, newclasses, basediv;
 basediv = main.contentBox;
 oldclasses = "port ip mac properties";
-newclasses = "port ip properties four_column";
+newclasses = "port ip mac properties five_column";
 jsl.removeClass(basediv, oldclasses);
 jsl.addClass(basediv, newclasses);
 lib.updateView("name", 1);

Funktion setStartRows in dt. FW 06.51:

FB7490_6.51:/# cat /usr/www/avm/net/net_overview.js
SNIP
function setStartRows() {
var oldclasses, newclasses, basediv;
basediv = main.contentBox;
oldclasses = "port ip mac properties";
newclasses = "port ip properties four_column"
jsl.removeClass(basediv, oldclasses);
jsl.addClass(basediv, newclasses);
lib.updateView("name", 1);
}

==> hier findet Patchskript ein passendes Text-Muster.

Funktion setStartRows in dt. FW 06.36-31667-int:

FB7490_6.36-31667-int:/# cat /usr/www/avme/net/net_overview.js:86
SNIP
function setStartRows() {
var oldclasses, newclasses, basediv;
basediv = main.contentBox;
oldclasses = "port ip mac properties";
//oldclasses = "port ip mac properties ipv6";
newclasses = "port ip properties";
jsl.removeClass(basediv, oldclasses);
jsl.addClass(basediv, newclasses);
lib.updateView("name", 1);
}

==> hier findet Patchskript KEIN passendes Text-Muster.

Die Skript-Statusmeldung ist nicht zutreffend:

Überprüfen der Voraussetzungen für die Modifikation ... Fehler (1)
[COLOR=#ff0000]Die Modifikation wurde bereits angewendet oder ist nicht erforderlich.[/COLOR]

ggf. müsste hier FW-spezifisches Patchskript erstellt werden.

Gruß
Splenditnet

 

[coco722]

@splenditnet Buganalyse und Fixing: modfs-0.3.3 mit FW 6.36-31667-int

Danke vielmals für die Klärung betreffend dem modfs-0.3.3. und dem fixing !


Kann bestätigen, modfs-0.3.3.tgz geht jetzt einwandfrei, nach der kleinen Änderung
im modfs-0.3.3.tgz bzw. im modfs Skript
BRANDINGS="$(get_target_brandings)" ==> BRANDINGS="$(get_target_brandings "$target")"

 

[maulich]

Theoretisch könnte man das auch gleich mit "dropbear" und SSH-Zugriff ebenso machen, aber dazu muß man dann dem "dropbear" erst einmal beibringen, den lokalen Server-Key aus einem X.509-Zertifikat zu lesen und - wenn man es "sicherer" will als bei der Kennwort-Authentifizierung, damit sich dann auch die Frage der AVM-Zugriffsrechte i.V.m. ar7login gar nicht mehr stellt - irgendwo die pubkeys für eine schlüsselbasierte Authentifizierung so zu hinterlegen, daß da nicht einfach jemand weitere Schlüssel hinzufügen kann (jedenfalls nicht leichter als auf anderen Wegen eines "Einbruchs" in die Box). Daß dabei dann wieder die Einbindung als CGI nicht funktioniert und so ein "Start service"-Button wieder die einheitlichere Lösung wäre, macht die Entscheidung für einen Weg zum Starten von SIAB auch nicht gerade einfacher.

So wie ich das sehe, müsste man dann entweder noch OpenSSL übersetzen und mit auf die Box schmeissen, um damit dann aus dem X.509 die passenden Zertifikate zu basteln...oder dropbear umschreiben...beides irgendwie..naja...unschön...Bei OpenSSH hat sich jemand die Arbeit gemacht, daß so zu patchen, daß es mit X.509 umgehen kann (zu finden unter http://roumenpetrov.info/openssh/ ). Ich kann da nix zur Vetrauenswürdigkeit sagen und bin, mangels ausreichender Programmierkenntnisse auch nicht in der Lage den Quellcode zu überprüfen.

Ich habe auf meiner FB dropbear laufen und mir die Zertifikate (nicht X.509) auf nem Linuxrechner erstellt...Das Startskript kopiert dropbear nach /var/tmp und fügt /var/temp/passwd einen Usereintrag für root hinzu. (Ich glaube, daß Skript ist aus diesem Forum - bin mir aber nicht sicher)...das setzt natürlich wieder eben einen Linuxrechner (für die Zertifikate) voraus und ist eine, nicht massenkompatible Bastellösung (für mich aber tauglich, weshalb ich gestehen muss, daß ich SIAB noch gar nicht ausprobiert habe )

Bezüglich der Frage "CGI oder Startbutton" würde ich für letzteres plädieren...zum Einen aus Gründen der Bequemlichkeit (auf Seiten der "User"), zum Anderen wegen der von Dir angesprochenen Vorteile bezüglich der Support-Daten, aber auch - aber daß ist letzlich eine philosophische Frage - weil ich es attraktiv finde, den Service nur dann einzuschalten, wenn er auch gebraucht wird...zwar schmeisst zumindest die FB7490 gefühlt mit Ressourcen um sich, aber..naja...scheint mir irgendwie "ordentlicher"

@maulich:
Es gibt immer zig Wege nach Rom in Shell-Code ... ich separiere bei tar/gzip das inzwischen schon automatisch, weil die AVM-Versionen meines Wissens beim tar-Applet die Behandlung von komprimierten Archiven nicht eingebaut haben und die separate Verwendung mit beiden Versionen klappt, was Nachfragen von Leuten mit einer AVM-Busybox vermeiden sollte. Ansonsten sehe ich das mit dem "Bewußtwerden" der Änderungen ganz genauso, das ist auch der Grund, warum ich bei allen "modscripts" im Download-Archiv das "o+x"-Flag wieder entfernt habe und es somit keine "automatischen Skripte" mehr gibt. Damit müssen die Leute zwar jetzt öfter "j" drücken, aber so kann niemand behaupten, er wisse von einer Änderung nichts.

(Sorry wenn der folgende Teil vielleicht "leicht Off-Topic" ist - es war mir nach rund sechs Jahren eher passiven Konsumierens des Forums ein Anliegen, daß mal zu erwähnen...)

(TL;DR - Habt Spaß am Ausprobieren, habt den Mut, Fehler zu machen & seid nett zueinander.)

Hat halt (wie so oft) Vor- und Nachteile...Wobei ich persönlich eben eher die Vorteile sehe...aber das beißt sich natürlich mit der "all-inclusive"-Haltung Einiger (auch hier im Forum), die daß ganze als Dienstleistung verstehen (am besten noch mit Garantieanspruch). Zusätzlich überrascht mich immer wieder, wie ungeduldig manche werden, wenn etwas nicht auf Anhieb klappt und diese Ungeduld dann nicht dazu führt, daß ein Lernprozess startet, bei dem dann halt vielleicht auch etwas in den Tiefen des Internets gewühlt werden und dann auch gelesen, und immer wieder ausprobiert werden muss, damit dann verstanden werden kann.
Stattdessen richtet sich diese Ungeduld dann gegen diejenigen (und das häufig in einer Form, die der besten Soap-Opera zur Ehre gereichen würde), die viel Zeit investieren, um praktische Ideen umzusetzen und mit uns zu teilen.
Vielleicht wäre es ganz gut, wenn wir alle versuchen würden, nicht jedes Wort auf die Goldwaage zu legen und uns darüber im Klaren sind, daß Kommunikation - besonders wenn sie nur schriftlich erfolgt - auch häufig fehlinterpretiert werden kann. Etwas mehr Gelassenheit wäre schön...

Und auf der einen Seite ist es ja schön, einfache Lösungen - vielleicht auch als Einstiegsmöglichkeit - zu bieten bzw. zu bekommen, andererseits ist es doch auch etwas schade, wenn dann der "Spaß am Gerät" hinten runterfällt, oder?

Apropos "Spaß am Gerät" (und nicht primär als Lobhudelei gedacht - trotzdem Danke!): Mich hat gerade PeterPawns modfs-Projekt dazu animiert, den Staub abzuklopfen und mich mal wieder mehr mit der Fritzbox, Skripten und Rumbasteln, etc. zu beschäftigen, weil ich die (meisten) Sachen im Code gut nachvollziehen kann...Bei so großen Projekten wie z.B. Freetz (vielleicht ein empfindliches Thema(?), aber daß drängte sich mir grad auf) verliere ich immernoch irgendwie den Überblick und gerate da zum reinen Anwender, was ok ist, aber irgendwie auch etwas unbefriedigend...

 

[PeterPawn]

@splenditnet:
modfs ist geändert ... so schön es auch ist, daß Du den Fehler nachgestellt und gefunden hast, für die Zukunft bleibt es dabei, daß ich so etwas nur mit Debug-Log anfassen werde ... dort wäre dann im Klartext abzulesen gewesen, daß eben die falschen Brandings ermittelt wurden, weil durch den fehlenden Parameter der Pfad ausgehend vom Wurzelverzeichnis des aktiven Systems benutzt wurde für das Auslesen - die Aussage mit dem "Leerstring" bei den Brandings (aus #482) sollte aber auch falsch sein. Ein fehlender Wert für "rootdir" in "get_target_brandings" sollte aus dem Pfad "$rootdir/etc" beim "find" den Pfad "/etc" machen und dann sollte das Ergebnis die Liste der Brandings des aktiven Systems sein und kein Leer-String. Oder habe ich Dich da falsch verstanden? Eigentlich spricht aber auch die Fehlermeldung (die ja das erwartete Branding "1und1" bzw. "avm" ausweist anstelle des richtigen "avme") eher gegen eine leere Zeichenkette bei den Brandings.

Dieser Fehler konnte damit nur dann auftreten, wenn die Systeme unterschiedliche Brandings haben ... wie es der falsche Aufruf geschafft hat, auf dem Weg aus dem gui_boot_manager_v0.2 (da stammte die Funktion "get_brandings" ja 1:1 her, inkl. ihres Aufrufs (da noch mit "rootdir" als Parameter) und da war es noch richtig) in das "modfs"-Skript (zum Vermeiden von Redundanzen, weil eben seit der "Multi-Branding"-Tauglichkeit nicht mehr nur das gerade aktive Branding modifiziert werden soll, wie es z.B. bei gui_0.1 noch der Fall war) den ersten Parameter zu verlieren, ist mir zwar ein Rätsel, aber das muß irgendwo hier passiert sein: https://github.com/PeterPawn/modfs/...45d4#diff-da17bd5626b9eaa7559b2ddb10465dfbL30

"mod_default_show_mac" fasse ich trotzdem nicht an, da habe ich #1 in diesem Thread dahingehend geändert, daß es erst ab 06.50 anwendbar ist. Wenn man hingeht und für jede Labor-Version von AVM einen spezifischen Patch einbaut, wird man seines Lebens nicht mehr froh ... auch aus diesem Grund hatte ich ja eigentlich sämtliche GUI-Anpassungen (irgendwo vorher in diesem Thread mal geschrieben) auf die Release-Version verschoben. Da die deutsche Release-Version bereits erschienen ist (und sogar schon ein weitere Update dieser Version), habe ich den Patch eingebaut - allerdings wohl die Tabelle in #1 etwas zu kurz gefaßt, weil ich bei der (bisherigen) Unterscheidung mit 06.36 als "Grenze" dort mehr auf den Unterschied "Kernel 2.6.32 vs. 3.10.73" abstellen wollte und eher nicht damit angedeutet werden sollte, daß GUI-Patches für das "responsive design" ab 06.36 funktionieren müssen. Das war auch in der deutschen Version nach dem Erscheinungsdatum der internationalen Beta noch einigen Änderungen unterworfen, bis es dann mit der Releaseversion einen halbwegs stabilen Stand erreichte.

Daß die internationale Version der deutschen inzwischen so weit nachhängt (die ist irgendwann von Anfang Nov. 2015, wenn ich mich richtig erinnere), ist zwar schade ... aber ich würde fast jede Wette eingehen wollen, daß in der nächsten Labor-Version für die 7490i das dann schon wieder so aussieht, wie in der 06.50/06.51 ... wenn man da den Änderungen hinterherrennen wollte, käme man zu nichts anderem mehr. Also gilt für die GUI-Patches (zumindest für meine), daß sie erst gegen eine Release-Version funktionieren. Wenn jemand unbedingt eine Labor-Version patchen will, muß er/sie das selbst irgendwie regeln.

@koy:
Die Liste der Brandings wird anhand der Unterverzeichnisse von /etc/default.$CONFIG_PRODUKT gebildet, wo jedes Branding sein eigenes Unterverzeichnis haben sollte ... wobei es mit dem "default"-Verzeichnis gerade auch bei der internationalen Version nicht ganz so einfach ist, da das richtige zu finden ... denn dort, wo die deutsche Version nur ein "default.049" parallel zu dem anderen Verzeichnis liegen hat, sind es bei bestimmten internationalen Versionen jede Menge weitere - daher werden alle "default"-Verzeichnisse, die nach dem Punkt nur noch Ziffern haben (für die LKZ) dort noch ausgesiebt. Zwar könnte man für die aktive Box wieder auf $CONFIG_PRODUKT zurückgreifen, dann funktioniert das aber beim Cross-Modifizieren nicht mehr oder man sucht sich "CONFIG_PRODUKT" erst aus der rc.conf im Image. Das ist am Ende alles aufwändiger als einfach davon auszugehen, daß das gesuchte Verzeichnis nach dem Punkt mindestens einen Buchstaben im Namen hat.

Und nochmal @splenditnet:
Das mit den anderen Änderungen hast Du falsch verstanden ... den Patch für LAN2LAN-VPN-Anzeige mache ich schon selbst (der DynDNS-Status ist mir persönlich egal, der wird bei mir ohnehin alle fünf Minuten aktualisiert als "alive"-Signal) und es war keine "Aufforderung", den irgendwie anzubieten ... es sollte im Gegenteil verhindern, daß diese Arbeit doppelt gemacht wird.

@eisbaerin:
Habe ich nie so genau ausgemessen bei der 7490, das letzte Mal ist schon etwas her und war bei der 6360 - ich weiß nicht genau, wann die LEDs bei "led_off" in der ar7.cfg beim Systemstart abgeschaltet werden (ich rate mal und sage, beim Start des "ctlmgr"), aber da dürften dann Statusanzeigen der DSL-Synchronisation auch schon unter den Tisch fallen und die hätten einige (u.a. auch ich) eben noch gerne gesehen, bevor es zappenduster wird - das ist ja auch nur eine zusätzliche Zeile in der led_display.lua (2 Minuten Aufwand), weil man sich um Speichern o.ä. gar keinen Kopf machen muß, denn es wird stur die "value" des ausgewählten Radiobuttons gesetzt.

@maulich:
Es geht auch mit ein paar Zeilen Shell-Code, aus dem binären Zertifikat (DER ist ja auch nur ASN.1-Speicherung und PEM ist nichts anderes als Base64-kodiertes DER) die verwendeten Koeffizienten auszulesen und dann eine passende Datei für den "dropbear" damit zu schreiben - aber das baut man dann besser gleich in den "dropbear" in C-Code mit ein. Beim SIAB ist es ja im Prinzip dasselbe, auch das ist ja angepaßt, damit es das Zertifikat der Box direkt benutzen kann. Wenn es auf der Box schon ein passendes Schlüsselpaar gibt, will ich nicht unbedingt ein weiteres erzeugen müssen ... abgesehen davon ist das eine wegfallende Konfigurationsnotwendigkeit für den "dropbear"-Service, wenn der keinen eigenen Server-Schlüssel (mit der Notwendigkeit irgendeiner Absicherung des privaten Schlüssels - der öffentliche ist ja Bummi, wie eigentlich jeder öffentliche Schlüssel und wie der Name schon sagt) verwendet. Zwar muß man sich nach wie vor überlegen, wie man das Hinzufügen weiterer pubkeys für Auth verhindert, aber man muß nicht darüber nachdenken, wie man das Auslesen dieser pubkeys verhindert.

 

[splenditnet]

... macht es Dir etwas aus, das noch um einen dritten Radiobutton (LED-Anzeige verzögert aus -> Wert 1 -> ar7.cfg-Setting=led_delayed_suspend) zu ergänzen?

Hallo PeterPawn und andere Interessierte,
der Change-Request konnte wie gewünscht im Modskript mod_menu_led_on_off umgesetzt werden und ist bereit für "Community-Review".

cat modscripts/mod_menu_led_on_off
# MODFS_MODSCRIPT
# SUPPORTS precheck postcheck install language(en,de)
# NAME show led display options menu
# DESCRIPTION en
# display menu to enable/disable of LED
# DESCRIPTION de
# Menu mit LED Einschalt-/Ausschalt-Option einblenden
# EOH
#
# process parameters
#
language=$1
rootdir=$2
mode=$3
step=$4
[ ${#4} -eq 0 ] && exit 59 # invalid call
#
# variables
#
rc=0
check_filename="$rootdir/usr/www/$TARGET_BRANDING/menus/menu_data.lua"
changed="\"lua\"\] = \"system\/led_display.lua\","
check_filename_2="$rootdir/usr/www/$TARGET_BRANDING/system/led_display.lua"
#changed_2='lua write_led_selected("2")'
changed_2="lua write_led_selected\(\"2\"\)"
#
# apply
#
patch_file()
{
        local home=$(pwd)
        cd $rootdir
        $home/bin/$HWRevision/busybox patch -p0 2>/dev/null <<EOT
--- usr/www/$TARGET_BRANDING/menus/menu_data.lua
+++ usr/www/$TARGET_BRANDING/menus/menu_data.lua
@@ -498,6 +498,11 @@
 ["lua"] = "system/infoled.lua",
 ["help"] = forLuaOnly and "hilfe_system_infoanzeige"
 } or nil
+pageData["led"] = {
+["show"] = true,
+["lua"] = "system/led_display.lua",
+["help"] = forLuaOnly and "hilfe_system_anzeige"
+} or nil
 pageData["keyLo"] = {
 ["show"] = true,
 ["lua"] = "system/keylock.lua",
EOT
        cd $home
}
#
patch_file_2()
{
        local home=$(pwd)
        cd $rootdir
        $home/bin/$HWRevision/busybox patch -p0 2>/dev/null <<EOT
--- usr/www/$TARGET_BRANDING/system/led_display.lua
+++ usr/www/$TARGET_BRANDING/system/led_display.lua
@@ -85,12 +85,15 @@
 <div class="formular">
 <p>
 <input type="radio" name="led_display" id="uiViewLedDisplay0" value="0" onchange="OnChangeLedDisplay('0')" <?lua write_led_selected("0")?>><label for="uiViewLedDisplay0">{?9839:27?}</label>
+<p class="form_input_explain">Die Anzeige der FRITZ!Box ist in Dauerbetrieb</p>
 </p>
 <p>
-<input type="radio" name="led_display" id="uiViewLedDisplay2" value="2" onchange="OnChangeLedDisplay('1')" <?lua write_led_selected("2")?>><label for="uiViewLedDisplay2">{?9839:655?}</label>
-<p class="form_input_explain">
-{?9839:649?}
+<input type="radio" name="led_display" id="uiViewLedDisplay1" value="1" onchange="OnChangeLedDisplay('1')" <?lua write_led_selected("1")?>><label for="uiViewLedDisplay1">LED-Anzeige verzögert aus</label>
+<p class="form_input_explain">Die Anzeige der FRITZ!Box arbeitet im "led_delayed_suspend" Modus</p>
 </p>
+<p>
+<input type="radio" name="led_display" id="uiViewLedDisplay2" value="2" onchange="OnChangeLedDisplay('2')" <?lua write_led_selected("2")?>><label for="uiViewLedDisplay2">{?9839:655?}</label>
+<p class="form_input_explain">{?9839:649?}</p>
 </p>
 </div>
 </div>
EOT
        cd $home
}
#
# execute steps
#
case $step in
        precheck)
                grep -q "$changed" $check_filename 2>/dev/null 1>&2
                rc=$?
                grep -q "$changed_2" $check_filename_2 2>/dev/null 1>&2
                rc_2=$?
                if [ $rc -eq 0 -o $rc_2 -eq 0 ]; then
                        case "$language" in
                                de)
                                        echo "Die Modifikation wurde bereits angewendet oder ist nicht erforderlich." 1>&2
                                        ;;
                                *)
                                        echo "The startup file is modified already or modification isn't necessary." 1>&2
                                        ;;
                        esac
                        rc=1
                else
                        rc=0
                fi
                ;;
        postcheck)
                grep -q "$changed" $check_filename 2>/dev/null 1>&2
                rc=$?
                grep -q "$changed_2" $check_filename_2 2>/dev/null 1>&2
                rc_2=$?
                if [ $rc -ne 0 -a $rc_2 -ne 0 ]; then
                        case "$language" in
                                de)
                                        echo "Die Modifikation war nicht erfolgreich." 1>&2
                                        ;;
                                *)
                                        echo "The startup file seems to be unmodified." 1>&2
                                        ;;
                        esac
                        rc=1
                else
                        rc=0
                fi
                ;;
        install)
                for TARGET_BRANDING in $TARGET_BRANDINGS; do
                        patch_file
                        patch_file_2
                done
                rc=0
                ;;
        *)
                rc=59
                ;;
esac
exit $rc
#

Nutzung dieses Skripts ist analog zu Modskript mod_mount_by_label auf German Firmware beschränkt.


Test "LED-Anzeige an":

# ctlmgr_ctl w box settings/led_display 0

# grep -A 5 ^led /var/flash/ar7.cfg
led {
        infoled_reason = 11;
        control = led_on;
        button_events_disable = yes;
}

Test "LED-Anzeige verzögert aus":

# ctlmgr_ctl w box settings/led_display 1

# grep -A 5 ^led /var/flash/ar7.cfg
led {
        infoled_reason = 11;
        control = led_delayed_suspend;
        button_events_disable = yes;
}

Test "LED-Anzeige aus":

# ctlmgr_ctl w box settings/led_display 2

# grep -A 5 ^led /var/flash/ar7.cfg
led {
        infoled_reason = 11;
        control = led_off;
        button_events_disable = yes;
}
#

Beschreibung zum "on-idle" aka. "led_delayed_suspend" Mode siehe: http://www.ip-phone-forum.de/showthread.php?t=283774&p=2143484&viewfull=1#post2143484
sowie http://www.ip-phone-forum.de/showthread.php?t=283774&p=2143486&viewfull=1#post2143486


Hinweis: bei LUA Skript led_display.lua scheint sich seitens AVM eine Placebo-Funktion namens OnChangeLedDisplay "eingeschlichen" zu haben:

# cat /usr/www/avm/system/led_display.lua
SNIP
function OnChangeLedDisplay(val)
{
}

somit ist Parameter onchange="OnChangeLedDisplay('1')" m.W. eigentlich nutzlos.
Lustig, dass man dies auch mal in "freier Wildbahn" sieht ;-)


Gruß
Splenditnet

 

[PeterPawn]

Trotzdem noch eine Rückfrage dazu ... welchen Grund gibt es, das Patchen auf zwei verschiedene Funktionen zu verteilen? Die werden ja nie unabhängig voneinander ausgeführt, damit kann das doch problemlos mit einem einzelnen Patch-Kommando erledigt werden.

Ansonsten würde/werde ich noch die Satzzeichen in den Erläuterungstexten ergänzen (braucht es den für "LEDs an" wirklich?) und die Beschreibung "led_delayed_suspend" ist zwar technisch richtig, aber kein Aas kann sich etwas darunter vorstellen.

Ich würde da eher auch die korrekte Beschreibung "mit einer Verzögerung von 90 Sekunden" (so jedenfalls bei mir gestoppt) verwenden und beim ersten Punkt auf die Erläuterung verzichten - "an" braucht wohl wirklich keine, jedenfalls nach meiner Meinung (und offensichtlich auch der von AVM) und irgendwie kann ich die AVM-Beschreibung "Stromsparmodus" für "aus" auch nicht so richtig nachvollziehen - aber alle fünf gleichzeitig leuchtenden LEDs bringen es sicherlich auf 5 x 10 mA bei ~ 2V (für grün) und somit auf 100 mW - immerhin weit mehr 1% der von AVM im Handbuch angegebenen durchschnittlichen Leistungsaufnahme von 9,3 W (wobei da praktisch viel eingeschaltet ist (DSL, WLAN, DECT, 1x LAN), aber nichts davon wirklich genutzt wird (kein WLAN-Client aktiv, 1 DECT-MT angemeldet, aber ebenfalls nicht aktiv, 1 LAN-Client angeschlossen, aber auch keine Datenübertragung - damit ist dann wohl auch auf der WAN-Seite das DSL-Modem eher "lazy").

Bei jeder tatsächlichen Aktivität steigt dann allerdings die Leistungsaufnahme so an, daß es wohl nicht mehr für 1% des Gesamtverbrauchs reicht. Damit würde ich das noch eher als "do not disturb me/us with blinking lights" verstehen fürs Schlafzimmer bei empfindlichen Zeitgenossen oder fürs Wohnzimmer bei Ästheten, die "Technik" nicht als "sehenswert" einstufen - insofern halte ich es sogar für vertretbar, die AVM-"Beschreibung" zu korrigieren.

 

[splenditnet]

ist plausibel, Freigabe von meiner Seite ;-)

 

[eisbaerin]

Bitte noch das ö in verzögert ändern, kommt bei mir falsch.

 

[KingTutt]

Neue Version 0.3.3 mit folgenden Änderungen:

- es gibt neue Parameter beim Aufruf (install, installfs, installroot), die das danach angegebene Image ohne weitere Modifikationen einfach nur installieren und zwar (in der vorne angeführten Reihenfolge) "Kernel, Wrapper-Partition und Root-Image", "Wrapper-Partition und Root-Image" oder "nur Root-Image"

Zu den neuen Parametern hätte ich noch einmal einige Nachfrage, um sicher zu gehen, dass ich alles richtig verstanden habe:
1) Wenn ich mal eine originale AVM Firmware als Beispiel nehme, dann könnte man mit 'installroot' das im AVM Image enthaltene 'kernel.image' flashen, mit 'installfs' das 'filesstem.image' und mit 'install' könnte ich einfach das von AVM herunter geladenen image flashen.
Oder muss man beim Aufruf mit 'install' evtl. zuvor selbst eine einzige Datei (z.B. mit cat) aus dem 'kernel.image' und 'filesystem.image' bauen?

2) Wenn das modfs ohne Modifikationen arbeitet, benötigt man dann trotzdem einen USB-Stick mit ext-Dateisystem oder reicht in diesem falls (wo ja nichts entpackt werden muss) auch der normale Speicher der Box aus?

 

[eisbaerin]

Erstmal zu 2.:
Bei einer 7490 habe ich bisher noch nie einen USB-Stick angesteckt, natürlich muß im NAS genügend Speicher frei sein.

Es wird entpackt, aber ob in den RAM oder NAND weiß ich nicht.

zu 1.:
"install" habe ich jetzt mal mit 113.06.05 benutzt, weil ich mir eine Partition zerschossen hatte.
Hat geklappt!

Ich hätte auch recover machen können, aber da hätte es mir den NAS gelöscht und ich wollte mal das neue ausprobieren. Und das schönste: Die Konfiguration war auch noch da, obwohl es ein downgrade war 113.06.51->113.06.05.

 

[PeterPawn]

install -> kernel.image in die Kernel-Partition und filesystem.image in die Filesystem-Partition schreiben (platt gesagt), das root-FS als Bestandteil der wrapper-Partition wird dabei implizit mit installiert

installfs -> kernel.image wird nicht installiert, ansonsten wie oben

installroot -> es wird nur das root-FS aus dem "filesystem.image" extrahiert (nicht entpackt!) und in die vorhandene (inaktive) wrapper-Partition kopiert, deren Inhalt ansonsten nicht verändert wird

Eine Option, nur den Kernel zu installieren, gibt es nicht ... dafür fiele mir kein Verwendungszweck ein und für die sehr sehr seltenen Gelegenheiten, wo das notwendig sein könnte, nimmt man eben direkt das "update_kernel" von AVM zum Schreiben ins NAND.

Für jede der oben angeführten Varianten wird aber ein vollständiges Firmware-Image benötigt ... das wäre bei einer NAND-Box ein tar-Archiv mit einer Datei "kernel.image" (wenn die geschrieben werden soll beim "install") und einer Datei "filesystem.image" (bei den beiden anderen Parametern), die jeweils unter dem Pfad "./var/tmp" eingepackt werden müssen.

Eine "Zusammenstellung" aus Kernel und Filesystem in Form einer einzelnen Datei (das erwähnte "cat") macht nur dann Sinn (bei NAND-Boxen wohlgemerkt, bei NOR-Boxen ist das wieder das "natürliche Format"), wenn man dieses System per EVA in den Speicher laden und starten will.

Ich hoffe, daß diese Erläuterungen Konfusionen an dieser Stelle ausräumen ... bitte nichts durcheinanderwerfen, da nur sehr rudimentäre Gültigkeitsprüfungen stattfinden (eigentlich bei einer "kernel.image"-Datei nicht einmal deren Größe getestet wird) und alles, was die stattfindenden Vorgänge beim "untar" und "unsquashfs" ohne Fehler enden läßt, wird auch in die Box geschrieben ... allerdings eben beim "modfs" immer in die inaktive Partition, so daß man (bis zum Neustart) jederzeit noch tätige Reue zeigen kann, wenn man etwas falsch gemacht hat.

Für das Entpacken eines Images wird ein Arbeitsverzeichnis benötigt, der dafür erforderliche Platz wird aber nur "geschätzt" und ist vordefiniert ... die Reihenfolge der Suche nach einer passenden Stelle ist auch festgelegt (https://github.com/PeterPawn/modfs/blob/master/modfs#L2835). Da gibt es aber tatsächlich eine Ungereimtheit ... die Anforderung von 32 MB bei vorhandenem Image ist eigentlich bereits zu wenig für die (älteren) neuen Parameter.

Beim nacheinander erfolgenden Aufruf von "extract_kernel", "extract_filesystem" und "extract_rootfs_from_wrapper" kann der angeforderte Speicherplatz von 32 MB (extract_space_needed) nicht ausreichen. Das wären bei einer 7490 derzeit (06.51) 2,4 MB für den Kernel, 21,6 MB für das Dateisystem und noch einmal 18,4 MB für das enthaltene Wurzeldateisystem (da das erst einmal herauskopiert wird) und im schlechtesten Fall - wenn die notwendigen Applets der Busybox fehlen, also bei Firmware >= 06.36 und fehlendem "losetup" - wird der Platz für das Dateisystem kurzzeitig doppelt benötigt. Da kämen also 2,4 + 2x 21,6 Megabyte zusammen anstelle der von mir angegebenen 32 ... ich gehe bei Gelegenheit noch einmal sämtliche Fälle durch und ändere ggf. noch etwas am Skript.

Am Beginn wurde immer recht schnell wieder "abgeräumt", was nicht länger benötigt wurde ... die neuen Parameter haben das etwas verschoben, schon beim Entpacken im "download_update"-Modus stimmt die gesamte Berechnung nicht mehr, weil die "Zwischenergebnisse" (kernel.image und filesystem.image) nicht mehr sofort gelöscht werden (weil extract_rootfs_from_wrapper diese nicht entfernt, im Gegensatz zum vorher verwendeten extract_rootfs_from_firmware).

Bis zu einer Korrektur muß man sich eben selbst helfen (ggf. "extract_space_needed" größer definieren) oder gleich dafür sorgen, daß im tmpfs bereits genug Platz vorhanden ist. 48 MB sollten ausreichen, solange nichts entpackt wird - das Entpacken funktioniert aber nicht einmal auf einer 7490 mehr ins tmpfs, weil das entpackte Dateisystem (je nach Anzahl der Brandings) noch einmal oberhalb von 50 MB benötigt (ich habe irgendwo schon 78 MB entpackt gesehen, könnte aber auch eine 7390 mit vier Brandings gewesen sein).

 

[eisbaerin]

Hallo Peter!

Mit der neuen FW 06.50 für die FB7412 klappt was nicht. Hat da AVM wieder eine neue Hürde eingebaut?

7490:$(pwd)# ./modfs update /var/media/ftp/FRITZ.Box_7412.137.06.50.image /var/media/ftp/FRITZ.Box_7412.137.06.50.mod
Ermitteln der Hardware-Version ... OK
Prüfen, ob die Hardware-Version unterstützt wird ... OK
Suchen der Einstellung zur Umschaltung auf das alternative System ... OK
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 ... übersprungen
Suchen der aktuellen Dateisystem-Partition ... OK
Suchen der alternativen Dateisystem-Partition ... OK
Ãberprüfen des zur Verfügung stehenden Speicherplatzes im RAM ... OK
Ãberprüfen des freien Speicherplatzes für das Auspacken des Dateisystems ... OK

Das System erfüllt die Voraussetzungen zur Modifikation des root-Dateisystems.

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

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

Die angegebene Datei '/var/media/ftp/FRITZ.Box_7412.137.06.50.image' wird als Quelle für die Aktualisierung genutzt.
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 ...Segmentation fault
 [COLOR="#FF0000"]Fehler[/COLOR]
Fehler beim Ermitteln des Dateisystemtyps der Image-Datei.
7490:$(pwd)#

Du schreibst immer etwas von einem DEBUG Modus, der angeblich in #1 beschrieben ist.
Ich habe schon 'zig mal danach gesucht. Bitte zeige mir wo es steht oder wie es genau geht, dann schicke ich dir gerne auch den.

 

[eisbaerin]

Hallo eisbaerin,
wie soll das gehen, eine Firmware von der FB7412 auf de FB7490 installieren ?

Doch, das geht, sogar wunderbar, nur ein Problem: Die FB7490 startet dann nicht mehr.

Du verstehst leider Bahnhof.
Ich installiere nicht (auch das geht, damit habe ich mir gestern eine Partition auf der FB7490 zerschossen), sondern ich erzeuge nur eine Datei für die FB7412.
Und das ging mit der 137.06.30 wunderbar.

 

[PeterPawn]

Ab Version 0.3.1 (ich habe jetzt mit einer sichtbaren Nummerierung begonnen) unterstützt das Skript eine Protokollierung im Hintergrund. Die Einzelheiten dazu stehen in #190 in diesem Thread. Auch weitere Informationen (u.a. zu den jetzt enthaltenen squashfs-tools) sind dort zu finden.

Also müßte das irgendwo um #190 sein ... ob die Nummerierung noch stimmt, weiß ich nicht, aber in #1 ist ein Link vorhanden. Ich mache den Text dazu demnächst mal noch rot, dann findet man ihn leichter - im Moment geht er etwas unter.

Woher der "SEGV"-Fehler kommt, weiß ich nicht ... vermutlich sollte ich rein statisch gelinkte SquashFS-Tools dazupacken; die derzeit verwendeten sind nach meiner Erinnerung noch teilweise statisch. Ich habe im Moment aber gerade keine Zeit, das mal schnell selbst auf der 7490 zu entpacken - irgendwas mit "blkid" oder "losetup" stimmt wohl nicht. Wenn Du das Debug-Log erzeugst, schreibe mal bitte noch dazu, woher die Busybox stammt und welche Version sie hat ... das nehme ich demnächst in die Protokollierung mit auf, aber im Moment muß man es noch "dazusagen".

EDIT: Neugierig geworden, habe ich (hatte ich allerdings doch schon vorgestern gemacht, war mir nur über die Rahmenbedingungen nicht 100%ig sicher) nun doch noch mal schnell eine 06.50 für die 7412 auf der 7490 (06.51, BB 1.24.1) erstellen lassen ... dabei hat auch das Auspacken problemlos funktioniert. Es braucht also tatsächlich das Debug-Protokoll, damit man erst einmal etwas genauer eingrenzen kann, bei welcher "Unteraktion" das Problem auftritt.

 

[eisbaerin]

Danke.
Ja es war eine ältere blkid 2.22.2 (30.308 Byte), die aber bisher immer ging.
Selbst die 113.06.51 konnte ich damit erstellen (auf einer 113.06.05).
Mit der neuen blkid 2.24.2 (62.672 Byte) geht es.

BTW: Wenn du in #1 von Protokollierung sprichst, sonst aber immer nach debug fragst, dann kann ich lange in #1 nach debug suchen.

 

[eisbaerin]

Es ist vollbracht:
Die FB7412 läuft mit 137.06.50 und LED-Steuerung und telnet und rc.user und damit auch mit dropbear.
Ich schätze das ist die erste FB7412 mit modfs und 137.06.50 und wird wohl auch lange Zeit die einzige bleiben, denn es ist nicht einfach. (Ja ich weiß, Peter macht das in 5min)
Anhang anzeigen 85748

Riesigen Dank nochmal an Peter, daß du diese Funktion (für mich?) mit eingebaut hast.

 

[KingTutt]

Eine "Zusammenstellung" aus Kernel und Filesystem in Form einer einzelnen Datei (das erwähnte "cat") macht nur dann Sinn (bei NAND-Boxen wohlgemerkt, bei NOR-Boxen ist das wieder das "natürliche Format"), wenn man dieses System per EVA in den Speicher laden und starten will.

Ich hoffe, daß diese Erläuterungen Konfusionen an dieser Stelle ausräumen ...

Danke für Deine Ausführungen!
Ich war mir nicht mehr sicher, wo ich das mit dem "cat" gelesen hatte. War also beim Flashen via EVA.
Zusammenfassen kann man also sagen, wenn man Dein Script zum Flashen via EVA benutzt will, um z.B. ein Freetz image auf die Box zu bekommen, muss man aus dem von Freetz erstellen .image (tar Archiv) erst die Dateien kernel.image und filesystem.image extrahieren und anschließend mit "cat" in einer einzigen Datei vereinen. Nimmt man hingegen modfs (welches ja in einer Shell ausgeführt wird) hat man es einfachen und kann gleich eine komplette Firmware Datei übergeben.

 

[PeterPawn]

Im Prinzip richtig, aber bei Zusammenkopieren mit "cat" muß man sich noch um die Prüfsumme am Ende des "kernel.image" kümmern ... eine event. vorhandene Prüfsumme am Ende von "filesystem.image" sollte man (bei Präparieren einer Datei für EVA) aber auch entfernen - ich habe nie probiert, wie der Kernel mit "krummen Adressen" umgehen würde. Ich würde immer mindestens an einer 4K-Grenze "alignen" und da stören die Prüsummen entscheidend. Der Scanner-Code im Kernel findet kein Dateisystem, wenn die SquashFS-Signatur an einem Offset mit einer "8" am Ende der Hex-Adresse steht, weil er nur bei einem Vielfachen von 256 beginnt und dann in 256-Byte-Schritte weiter sucht:

if((ifx_ram_resource[0].start & ((1 << 8) - 1))) {
    pos = ((ifx_ram_resource[0].start & ~((1 << 8) - 1)) + 256) - ifx_ram_resource[0].start;
    /*--- printk(KERN_ERR "[%s:%d] Use offset of 0x%x to search squashfs magic.\n", __func__, __LINE__, (unsigned int)pos); ---*/
}

 

[BurningCrash]

Hallo PeterPawn,

kurze Frage, ist folgender Fehler (rot markiert) bekannt bzw. interessant?

Ermitteln der Hardware-Version ... OKPrüfen, ob die Hardware-Version unterstützt wird ... OK
Suchen der Einstellung zur Umschaltung auf das alternative System ... OK
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 ... OK
Suchen der aktuellen Dateisystem-Partition ... OK
Suchen der alternativen Dateisystem-Partition ... OK
Überprüfen des zur Verfügung stehenden Speicherplatzes im RAM ... OK
Überprüfen des freien Speicherplatzes für das Auspacken des Dateisystems ... OK


Das System erfüllt die Voraussetzungen zur Modifikation des root-Dateisystems.


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


Als Ausgangspunkt dieser Modifikationen wird ein SquashFS-Image benötigt.
Dafür stehen drei Möglichkeiten zur Auswahl:


a - das root-Dateisystem des laufenden Systems benutzen
b - ein neues root-Dateisystem aus einem Firmware-Download vom FTP-Server des Herstellers verwenden
c - ein an anderer Stelle im Dateisystem abgelegtes Image verwenden
q - keine Änderungen vornehmen


Bitte den Buchstaben des gewünschten Punktes eingeben : b


Download eines aktuellen Firmware-Images vom FTP-Server des Herstellers ... OK
Extrahieren des root-Dateisystems aus dem Firmware-Image ...[B][COLOR=#ff0000]mount: mounting /dev/loop1 on /var/tmp/5794_1456788564 failed: Invalid argument[/COLOR][/B]
 Fehler


Das extrahierte 'äußere Dateisystem' kann nicht eingebunden werden.

Wie man sieht möchte ich ein neues Root-System vom FTP nehmen. Box ist eine 7490 auf 6.51.

Gruß
BC