@flak65:
Ich denke mal, Du hast mich falsch verstanden und auch das, von anderen zuvor Geschriebene, nicht wirklich verarbeitet.
Ja, klar kriegt man das hin ... aber eben durch vorherige, eingehende Recherche/Überprüfung, wie die Firmware tatsächlich aussieht und nicht durch "lockeres Probieren".
Jetzt wird zwar das Dateisystem-Format korrekt erkannt, aber die 7581/7582 verwendet dann wohl doch eher wieder eine Speicherung des Systems in NAND-Flash mit zwei, alternierend eingesetzten Versionen (würde ich bei 512 MB NAND-Flash jedenfalls mal unterstellen als "Arbeitshypothese") - das ist bei der 4040 (wohl schon aus Kostengründen, denn die sollte ja "billig, billiger, am billigsten" sein) schon mal deutlich nicht der Fall.
Die 4040 hat 32 MB SPI-Flash an Bord, darin speichert sie ihren Kernel und ihr Dateisystem, aber offenbar/vermutlich nur eine einzelne Version.
Was haben denn Deine eigenen Recherchen im Vorfeld ergeben? Über welche "Leistungsmerkmale" verfügt denn die 7582? Und wo hast Du diese Informationen gefunden? Das Minimum, mit dem man das Sammeln von Informationen beginnen kann, ist schon mal die Support-Datei einer solchen Box, die man auch mit der "stock firmware" problemlos erhält.
BTW ... das sind alles auch nicht wirklich Fragen meinerseits (falls sich jetzt jemand "helfend einschalten" will) - das dient zur Verdeutlichung dessen, was man bei solchen Aktionen (also der "Analyse" einer unbekannten Firmware) an den Beginn stellen sollte (nein: stellen müßte).
Es hat Gründe, warum diese Modelle (noch?) nicht in Freetz unterstützt werden ... das ist nicht nur ein "unbekanntes" Format der Firmware. Auch der (ab Version 7) bei diesen Geräten verwendete Kernel und die C-Library (hier wieder die "glibc" anstelle von "musl" oder "uClibc[-ng]") werden in Freetz (und m.W. auch in Freetz-NG) bisher nicht unterstützt. Es wird also ohne eigene Kenntnisse, wie man eine Cross-Compile-Toolchain baut bzw. aus den von AVM bereitgestellten Paketen (die für die 07.01 der beiden Modelle gibt es ja bereits seit 8-9 Monaten bei AVM) sich eine solche zurechtzimmert, ziemlich schwer, passende Binaries zu erstellen.
Denn es ist ja nicht so, daß man die AVM-Pakete nur noch auspacken und dann ein Shell-Skript aufrufen müßte ... das ist richtig Arbeit, das in eine funktionierende Toolchain zu überführen, vor allem deshalb, weil es praktisch keine "Beschreibung" gibt und man sich die einzelnen Versatzstücke erst mühsam aus dem Wust von Dateien heraussuchen muß, der sich in einem solchen, von AVM bereitgestellten, Archiv tatsächlich verbirgt. Es ist zwar schon deutlich besser geworden, was die "Überfrachtung" mit irgendwelchem uralten Scheiß in diesen Archiven angeht (vermutlich deshalb, weil bei AVM selbst auch keiner mehr den richtigen Durchblick hatte, was da nun für welches Modell benötigt wird und was nicht), aber das ist von "gut" noch ein ganzes Stück entfernt.
Aber das muß niemanden davon abhalten, sich die Firmware zu schnappen, sie zu entpacken und ein wenig zu modifizieren und danach wieder ein SquashFS-Image zu erstellen (z.B. eben mit dem Start eines Telnet-Daemons, denn im Gegensatz zu anderen Binaries wird sicherlich auch in der BusyBox der 7581/7582 das "telnetd"-Applet mit dem AVM-Patch zur Abfrage des Symlinks enthalten sein), das man dann auf die Box bringt (vermutlch wieder mit einer automatischen Installation nach dem Start aus dem RAM, aber das ermittelt man mit dem Paketmitschnitt eines Recovery-Laufs, wie das weiter vorne auch schon angetextet wurde).
Spätestens wenn es aber um Fragen wie OpenVPN auf der Box oder SSH oder ähnliches geht, wird man um das Erweitern eines der Freetz-Forks für Kernel 4.1.irgendwas und "glibc" als Library nicht mehr herumkommen - man muß sich als "Laie" eben die Frage stellen, was man eigentlich erreichen will und wenn das ohne zusätzliche Binaries nicht zu realisieren ist, sollte man schon einigermaßen gute Kenntnisse in Build-Systemen haben (schon um eine Toolchain auf der Basis des AVM-Pakets zu bauen) und am Ende muß man auch von Freetz (egal für welchen Fork man das machen wollte) genug wissen, um das dort integrieren zu können. Das ist definitiv auch keine "rocket science" und kann sogar eine gute Übung oder ein Einstieg in das Thema (Cross-Compiliing, gcc, bintools, etc.) sein. Nur sollte man sich am Beginn erst mal klarmachen, worauf man sich einläßt ... das ist nichts, was man (erst recht nicht als Laie und auch nicht als "interessierter" (Laie), der ggf. sogar zusätzliche Pakete für die von ihm verwendete Linux-Distro erstellen kann, solange die Paketverwaltung des Systems ihm das alles (Compiler, Source-Files, System-Konfiguration) passend bereitstellt) mal eben so "nebenbei" erledigt.
@NDiIPP:
Siehste ... die 7520/7530 als 4040-Ableger hatte ich glatt vergessen bei der Überlegung, welches unterstützte Modell denn mit SQFS4, xz und LE arbeiten könnte. Das will ich aber gleich noch einmal zum Anlaß für eine Warnung nehmen, daß man für diese Modelle erstellte Binaries (zumindest dynamisch gelinkte, bei statischen könnte es klappen, wenn die Kernel-Konfigurationen (insb. die Syscalls) passen) nicht ohne weiteres auf die 7581/7582 übertragen kann, denn diese verwenden (wie oben geschrieben) die "glibc" (2.23) als Basis:
Code:
vidar:/tmp/FB7582_07.01/fs $ ls -l lib/libc*.so
-rwxrwxrwx 1 root root 1222256 Nov 9 2018 lib/libc-2.23.so*
vidar:/tmp/FB7582_07.01/fs $ strings lib/libc-2.23.so | grep glibc
glibc 2.23
@flak65:
Als kleine Hilfestellung meinerseits hier noch die Ausgabe eines meiner Skripte (allerdings eines unveröffentlichten) zum Entpacken/Analysieren solcher Firmware-Dateien:
Code:
Device uses NAND flash to store kernel and filesystem.
SquashFS version used: 4
SquashFS compression used: xz
SquashFS endianess used: little
>>>>> Output of 'extract_version_values' <<<<<
Model="Fritz_Box_HW228"
Product="FRITZ!Box 7582"
Date="09.11.2018 15:43:47"
Version="156.07.01"
Subversion="-63190"
Buildnumber="63190"
Buildtype="1"
Brandings="avm avme"
Release="1"
BetaRelease="0"
LaborName=""
DirtyBuild=""
InstallType="brcm_128MB_xilinx_4geth_1ab_pots_wlan_usb_host_dect_gfast_minhwsub3_06753"
KernelVersion="4.1.38"
LibraryProject="musl"
LibraryVersion="(undetectable)"
LibraryIdent="musl-undetected"
BootType="rc.S"
PublicKey1="00f29bf5a052e1a4c1f79e3bb102ef64e1ded3569932b603fe9dc54e2e953793d62abe11ac6904cef9ab3744570d39153f914a007a40898b54270370954064af1b73770ed06fbfaebaba673ecc9811fe854fb12b4a269e89f02197730fc366889d7572bd1b107690507fdeae5fc35c5529fdaa5e0abe63d2e63c7c659f18c0ea47"
PublicKey2="00b5d925778d9111cf28073e0d46d14a0eaae58194e099bfa931082976d0f720acab043cbd4ed52ecde5045fe25b8efeafa575c50a01e8198b8bd9a7635edd2c09480f083252de3345d3c850e1607f9c41bafd57ce504d17911fc4dc8d5681328e7bbe1d13f26f0c6cd5dc681ef2d417ba3edd4b17808f02c7d370a1c5eb799f21"
PublicKey3="00f2ee9ffd8556211f5644da48a252b107124b330d4c20dcf3b9bac892924cabaa4df4f53e1c62e3f2aa12a23eb1d770df1520a998078738407e6a71b077f73ba976363836b880b0dd88741bc3b83ab061691226e823404b7fc88ed278d8130fe5336eb925c78f2f8ad7cb87d9586286f768ab3236fa8fb51ae7c4bbe1e041d849"
>>>>> ================================== <<<<<
The unpacked filesystem structure may be found at:
/tmp/tmp.SRzYf7VvKb/13687_rebuild_image/fs
You may change anything below this point, until you're satisfied by the result.
Please use another terminal session to make any changes and if you think, your changes are complete, answer the question below.
Do you want to continue with packing the new image or re-display the used directory names or terminate without packing a new image?
Enter 'continue' (full word needed) or 'r' (re-display) or 'x' / 'q' (eXit/Quit):
Das hat mich auch gleich noch darauf aufmerksam gemacht, daß die Erkennung der C-Library unvollständig ist und eine Erkennung der "glibc" nachzurüsten wäre ... allerdings sind das bisher tatsächlich eher "Exoten" (bis hin zur 6591, iirc), bei denen AVM diese Library verwendet hat.