[Sammlung] Wie modifiziere ich die originale Firmware vom Hersteller und wie installiere ich meine eigene dann auf der FRITZ!Box?

eisbaerin

IPPF-Promi
Mitglied seit
29 Sep 2009
Beiträge
8,004
Punkte für Reaktionen
392
Punkte
83
Ich habe mal die SquashFS-Tools für "armv7l" auch mit der Freetz-Toolchain (genauer mit meinem Fork) gebaut und statisch gelinkt.
Danke, gehen auch auf der 7530.

Gestern/Heute hatte ich Probleme beim Modifizieren.
Ich mache das ja immer auf der 7580. Ging auch bisher mit FW 7.12 sehr gut.
Jetzt hat die 7580 aber vor kurzem die FW 7.19 bekommen und da gehen einige modscrips plötzlich nicht mehr.
Konkret sind es die, welche "patch" verwenden. z.B. mod_prefer_fonnumber_name
Der Befehl "$home/bin/$HWRevision/busybox patch" klappt nicht mehr.
Wenn ich dort das ganze Vorgeplänkel weg lasse und nur "patch" schreibe geht es bei mir.
Dann habe ich mich auf die Fehlersuche begeben.
Erst dachte ich es liegt an der Variblen $home, weil ich das ganze modfs jetzt in den NAS verschoben habe, damit ich es nicht bei jedem Neustart neu runter laden muß. (ich will ja deinen Zähler nicht überlasten ;) )
Aber das war es nicht.
Nach langem Suchen habe ich gefunden, daß die Variable $HWRevision dort 000 hat.
Mit 000 wird dann aber /bin/busybox aufgerufen, welche aber das Applet patch nicht hat.
Auf der Console zeigt die Variable aber korrekt 225, nur in dem modscript kommt es falsch.
Irgend etwas muß sich da wohl mit dem neuen Kernel verändert haben.
Wenn du noch ein paar Tests/Auskünfte brauchst, mache ich das gerne.

EDIT:
Jetzt weiß ich ich warum es mit der FW 7.12 ging.
Das war ja ein freetz, und da hatte die /bin/busybox das patch mit drin.
Ich mache jetzt in dem run_modscripts ein "#" vor die Zeile:
export HWRevision="000"
Das sollte gehen, sonst schreibe ich die 225 da fest rein.
Warum setzt du da die Variable auf 000?

BTW:
Einige andere Scripts mußte ich bei mir auch ändern.
Das "local" darf seit der 7.20 nicht mehr einfach so in einem Script stehen, nur noch in einer Funktion.

##########################################################

Anschließend ruft man /var/install auf und betet, daß alles gut gehen möge ...
Ich habe das heute mal so bei einer 7490 gemacht.
30 min gebetet, aber es passierte nichts. Im gui_bootmanager sah ich aber schon die neue FW in der inaktiven Partition.
Also Stecker gezogen und neu booten lassen.
Sie war aber immer noch auf der alten FW. Also selber auf die andere Partition umgestellt und neu gebootet.
Dann erst kam sie mit der neuen FW hoch.

Ist das normal so?
Ich dachte, das macht sie alles alleine, genau so wie bei einem normalen Update.
 
Zuletzt bearbeitet:

PeterPawn

IPPF-Urgestein
Mitglied seit
10 Mai 2006
Beiträge
13,169
Punkte für Reaktionen
1,039
Punkte
113
Das "local" darf seit der 7.20 nicht mehr einfach so in einem Script stehen, nur noch in einer Funktion.
Das ist eine Änderung in der BusyBox-Shell - mit neuer AVM-Version kommt auch eine neue(re) BusyBox.

Das ist einer der Gründe, warum es im "modfs"-Paket immer noch ziemlich alte Versionen gibt - ich habe keine Lust, alte Skript-Dateien noch einmal anzupassen, weil sich die "ash"-Syntax geändert hat.

Neue berücksichtigen das gleich - ein "local" ist eben nicht Bestandteil des POSIX-Standards und da, wo man es tatsächlich brauchen würde, setze ich dann eben nicht auf einen "Block" (das ist eine Funktion, deren Body in geschweifte Klammern eingeschlossen wird und die mittels "return" (zumindest bei explizitem Aufruf) enden kann), sondern auf eine "Sub-Shell" - hierbei wird der Body in runde Klammern eingeschlossen und quasi in einer eigenen Shell-Instanz ausgeführt, wo alle Variablen automatisch lokal sind.

Das hat Vor- und Nachteile, so kann man auf diesem Weg eben auch keine Variablen in der aufgerufenen Funktion setzen, die man später erst auslesen will - daher geben die dann fast immer etwas auf STDOUT zurück, was einer Variablen im Aufrufer-Kontext zugewiesen wird: var="$(function arg1 arg2)". Die Verwendung von geschweiften oder runden Klammern um den Body so einer Funktion ist also auch nicht "frei Schnauze", das ist schon mit Bedacht gewählt, vor allem, weil man aus einer Sub-Shell besser mittels exit n ein negatives Resultat signalisiert, als mit return.

Ansonsten mault eben die "ash" seit einiger Zeit herum, wenn es außerhalb einer Funktion ein "local" gibt, während es innerhalb noch klaglos akzeptiert wird (von vielen Shells, selbst von der "dash", die sich sonst praktisch 1:1 am POSIX-Standard entlanghangelt) und auch den gewünschten Effekt hat.

Wenn Du die Liste der Fundstellen hast (da reicht auch ein "diff" Deiner Korrekturen gegen die originalen Dateien), patche ich das aber gerne noch in die vorhandenen Dateien hinein - nur will ich da jetzt nicht nach allen Vorkommen von "local" schauen, ob die nun Probleme machen oder nicht.

Denn wenn ich versuche, das mit der "ash" automatisch finden zu lassen:
Rich (BBCode):
vidar:/home/GitHub/modfs/modscripts $ for f in *; do ../../busybox/busybox.desktop ash -n $f; done
vidar:/home/GitHub/modfs/modscripts $ ../../busybox/busybox.desktop ash -n -c "set +o"
set +o errexit
set +o noglob
set +o ignoreeof
set +o monitor
set -o noexec
set +o xtrace
set +o verbose
set +o noclobber
set +o allexport
set +o notify
set +o nounset
set +o vi
set +o pipefail
vidar:/home/GitHub/modfs/modscripts $ ../../busybox/busybox.desktop
BusyBox v1.33.0.git (2020-07-19 16:05:11 CEST) multi-call binary.
BusyBox is copyrighted by many authors between 1998-2015.
Licensed under GPLv2. See source distribution for detailed
copyright notices.

Usage: busybox [function [arguments]...]
   or: busybox --list[-full]
   or: busybox --show SCRIPT
   or: busybox --install [-s] [DIR]
   or: function [arguments]...

        BusyBox is a multi-call binary that combines many common Unix
        utilities into a single executable.  Most people will create a
        link to busybox for each function they wish to use and BusyBox
        will act like whatever it was invoked as.

Currently defined functions:
        [, [[, acpid, add-shell, addgroup, adduser, adjtimex, arch, arp, arping, ash, awk, base64, basename, bc, beep, blkdiscard, blkid, blockdev, bootchartd, brctl, bunzip2, bzcat, bzip2, cal, cat, chat, chattr, chgrp, chmod, chown,
        chpasswd, chpst, chroot, chrt, chvt, cksum, clear, cmp, comm, conspy, cp, cpio, crond, crontab, cryptpw, cttyhack, cut, date, dc, dd, deallocvt, delgroup, deluser, depmod, devmem, df, dhcprelay, diff, dirname, dmesg, dnsd,
        dnsdomainname, dos2unix, dpkg, dpkg-deb, du, dumpkmap, dumpleases, echo, ed, egrep, eject, env, envdir, envuidgid, ether-wake, expand, expr, factor, fakeidentd, fallocate, false, fatattr, fbset, fbsplash, fdflush, fdformat,
        fdisk, fgconsole, fgrep, find, findfs, flock, fold, free, freeramdisk, fsck, fsck.minix, fsfreeze, fstrim, fsync, ftpd, ftpget, ftpput, fuser, getopt, getty, grep, groups, gunzip, gzip, halt, hd, hdparm, head, hexdump, hexedit,
        hostid, hostname, httpd, hush, hwclock, i2cdetect, i2cdump, i2cget, i2cset, i2ctransfer, id, ifconfig, ifdown, ifenslave, ifplugd, ifup, inetd, init, insmod, install, ionice, iostat, ip, ipaddr, ipcalc, ipcrm, ipcs, iplink,
        ipneigh, iproute, iprule, iptunnel, kbd_mode, kill, killall, killall5, klogd, last, less, link, linux32, linux64, linuxrc, ln, loadfont, loadkmap, logger, login, logname, logread, losetup, lpd, lpq, lpr, ls, lsattr, lsmod, lsof,
        lspci, lsscsi, lsusb, lzcat, lzma, lzop, makedevs, makemime, man, md5sum, mdev, mesg, microcom, mim, mkdir, mkdosfs, mke2fs, mkfifo, mkfs.ext2, mkfs.minix, mkfs.vfat, mknod, mkpasswd, mkswap, mktemp, modinfo, modprobe, more,
        mount, mountpoint, mpstat, mt, mv, nameif, nanddump, nandwrite, nbd-client, nc, netstat, nice, nl, nmeter, nohup, nologin, nproc, nsenter, nslookup, ntpd, nuke, od, openvt, partprobe, passwd, paste, patch, pgrep, pidof, ping,
        ping6, pipe_progress, pivot_root, pkill, pmap, popmaildir, poweroff, powertop, printenv, printf, ps, pscan, pstree, pwd, pwdx, raidautorun, rdate, rdev, readahead, readlink, readprofile, realpath, reboot, reformime,
        remove-shell, renice, reset, resize, resume, rev, rm, rmdir, rmmod, route, rpm, rpm2cpio, rtcwake, run-init, run-parts, runlevel, runsv, runsvdir, rx, script, scriptreplay, sed, sendmail, seq, setarch, setconsole, setfattr,
        setfont, setkeycodes, setlogcons, setpriv, setserial, setsid, setuidgid, sh, sha1sum, sha256sum, sha3sum, sha512sum, showkey, shred, shuf, slattach, sleep, smemcap, softlimit, sort, split, ssl_client, start-stop-daemon, stat,
        strings, stty, su, sulogin, sum, sv, svc, svlogd, svok, swapoff, swapon, switch_root, sync, sysctl, syslogd, tac, tail, tar, taskset, tc, tcpsvd, tee, telnet, telnetd, test, tftp, tftpd, time, timeout, top, touch, tr,
        traceroute, traceroute6, true, truncate, ts, tty, ttysize, tunctl, ubiattach, ubidetach, ubimkvol, ubirename, ubirmvol, ubirsvol, ubiupdatevol, udhcpc, udhcpc6, udhcpd, udpsvd, uevent, umount, uname, unexpand, uniq, unix2dos,
        unlink, unlzma, unshare, unxz, unzip, uptime, users, usleep, uudecode, uuencode, vconfig, vi, vlock, volname, w, wall, watch, watchdog, wc, wget, which, who, whoami, whois, xargs, xxd, xz, xzcat, yes, zcat, zcip
, passiert da gar nichts, obwohl das eine brandneue 1.33.0 ist, die ich vor drei Tagen erst übersetzt habe.

Beim Aufruf mit "-n" sollte einfach die Syntax gecheckt werden - offenbar wird dabei die Frage, ob da ein "local" außerhalb einer Funktion steht, aber nicht bemängelt (wenn's das in den Skripten gibt, was Du ja schreibst).

Warum setzt du da die Variable auf 000?
Weil ja nicht gesagt ist, daß das Skript auf einer FRITZ!Box aufgerufen wird, wo "HWRevision" dann den Weg zu einer "gültigen" BusyBox weist - und das ist nun mal Bestandteil des verwendeten Dateinamens für die BusyBox. Also wird das - nur bei Verwendung von "run_modscripts" - auf "000" gesetzt und der Benutzer ist dafür zuständig, dafür zu sorgen, daß die automatisch gefundene BusyBox (a) zur vorhandenen Plattform paßt und (b) den notwendigen Umfang an Kommandos kennt. Die von mir bereitgestellten BusyBox-Binaries geben alle ihre Konfiguration preis und zusätzlich liegt i.d.R. (auch beim "modfs": https://github.com/PeterPawn/modfs/tree/master/bin/common) diese als Textdatei auch noch einmal neben den Binärdateien, so daß man sich problemlos die eigene bauen kann, die auch alles Notwendige enthält.

Und selbst wenn das Skript auf einer FRITZ!Box läuft, wo HWRevision gesetzt ist ... erstens muß die automatisch gefundene BusyBox nicht den notwendigen Funktionsumfang haben (so erging es Dir ja dann) und zweitens ist gar nicht sicher, daß diese HWRevision auch in der "modfs"-Verzeichnisstruktur enthalten ist - so sind z.B. die Dateien für x86 (Puma6->ATOM) und Vx180 (7390) zwar als Link vorhanden in der Struktur, aber die Dateien, auf die sie zeigen würden, fehlen - sie würden das Archiv nur unnötig aufblähen (das machen eigentlich die unterschiedlichen Versionen für 3.10.73 und 3.10.104/107 schon zur Genüge und häufig auch unnötigerweise).

Ich zitiere mich mal wieder selbst (die Hervorhebung fehlt im Original):
Ich habe mich jetzt mal breitschlagen lassen und ein Beispiel für ein Skript eingecheckt (das findet sich auch im TGZ-File, das man von yourfritz.de laden kann - es heißt "run_modscripts"), was als ersten Parameter den Verzeichnisnamen der entpackten AVM-Firmware erwartet und dann ALLE "modscript"-Files, die es in "modscripts/*" findet, in alphabetischer Folge der Dateinamen auf die entpackte Struktur losläßt und zwar ohne Berücksichtigung irgendwelcher "precheck"- oder "postcheck"-Aktionen und auch ohne Ansicht der Person (aka "x-flags") oder einer event. vorhandenen "custom_modscripts"-Datei.

Das Skript erwartet, daß es sich in der üblichen Verzeichnisstruktur befindet, die beim Auspacken der TGZ-Datei von yourfritz.de oder beim Klonen des GitHub-Repos entstehen würde - und zusätzlich muß noch eine aktuelle "BusyBox"-Implementierung verfügbar sein (weil die BB-Kommandos teilweise andere Syntax verwenden, als die "großen Versionen") und über den Suchpfad gefunden werden. Für diese BusyBox wird dann ein Symlink unter "bin/000/busybox" angelegt und danach wird diese für die Applets in den "modscript"-Files verwendet.
Wenn die "offizielle" BusyBox auf dem verwendeten System nichts taugt, würde ich auch nicht hingehen und an den Skript-Dateien ändern (schon aus Prinzip nicht, weil ein Fehler dabei schnell mal zu "falschen Verdächtigungen" führt - was peinlich sein kann) - stattdessen würde ich mir ein Verzeichnis anlegen an einer "beschreibbaren" Stelle, da einen Symlink zur gewünschten BusyBox eintragen und dann dieses Verzeichnis in der PATH-Variablen beim Aufruf (einfach PATH="<my_dir>:$PATH" vor allem anderen in die Zeile schreiben) angeben - dann sollte exakt diese BusyBox gefunden werden beim "command -v busybox" und der Rest funktioniert dann wieder von alleine. Das gilt selbst dann, wenn das eine Box ist, für die passende Binaries in "modfs" vorliegen ... dann verwendet man einfach das passende VR9- oder GRX5-Verzeichnis unterhalb von "bin" in der PATH-Variablen (https://github.com/PeterPawn/modfs/tree/master/bin).

Das "run_modscripts" testet zwar noch einige Punkte, anstatt nur blind Kommandos aufzurufen, aber es war ja auch (s.o.) wieder nur als ein "Beispiel" gedacht. Wenn mir jemand die Zeilen liefert (es sind nur wenige, aber eine schöne Übung), mit denen eine vorhandene HWRevision-Variable direkt genutzt wird (wenn sie unterhalb von "bin" zu finden ist) und ansonsten das gefundene BusyBox-Binary (mit "--list" aufrufen für die Liste der enthaltenen Applets) erst mal auf das Vorhandensein der entscheidenden Applets abgeklopft wird (welche verwendet werden in den "modscripts", ist auch nicht schwierig zu ermitteln, ggf. sogar automatisch), übernehme ich das gerne auch noch in die "run_modscripts". Nur sind das eben "Randfälle" (mal von der Frage des Beispiels vollkommen abgesehen) und da fehlt mir tatsächlich der Antrieb - außerdem gibt es genug anderes zu tun.
 
3CX

Statistik des Forums

Themen
235,914
Beiträge
2,067,823
Mitglieder
356,955
Neuestes Mitglied
LiamDobczinski