Fritzbox 7560 Fritz!OS 6.90 telnet / shell zugriff

[1f5]

Also ich habe es nochmal auf einem x86-Tumbleweed Live-Stick versucht, leider mit dem gleichen Ergebnis. Der Rechner ist ein Lenovo x230t. Ich bin leider jetzt ziemlich am Ende mit meinen Lösungsansätzen. Ich dachte erst, dass es an Ubuntu liegen könnte, aber das scheint nicht der Fall zu sein.

Ich habe mich an eine Kombination aus dieser und dieser Anleitung gehalten.

Hier ist der komplette Output mit allen Befehlen, die ich eingegeben habe. Ich habe lediglich den Output von wget, zypper und git zur besseren Lesbarkeit entfernt, diese laufen aber korrekt und ohne Fehler durch. Habe ich irgendwas vergessen oder übersehen?

linux@localhost:~> cat /etc/os-release
NAME="openSUSE Tumbleweed"
# VERSION="20181018"
ID="opensuse-tumbleweed"
ID_LIKE="opensuse suse"
VERSION_ID="20181018"
PRETTY_NAME="openSUSE Tumbleweed"
ANSI_COLOR="0;32"
CPE_NAME="cpe:/o:opensuse:tumbleweed:20181018"
BUG_REPORT_URL="https://bugs.opensuse.org"
HOME_URL="https://www.opensuse.org/"
linux@localhost:~> mkdir /tmp/yourfritz
linux@localhost:~> cd /tmp/yourfritz
linux@localhost:/tmp/yourfritz> wget ftp://ftp.avm.de/fritzbox/fritzbox-7560/deutschland/fritz.os/FRITZ.Box_7560.149.07.01.image
[wget output entfernt, läuft korrekt durch]
linux@localhost:/tmp/yourfritz> sudo zypper install git-core
[zypper output entfernt, läuft korrekt durch]
linux@localhost:/tmp/yourfritz> git clone https://github.com/PeterPawn/YourFritz.git yf
[git output entfernt, läuft korrekt durch]
linux@localhost:/tmp/yourfritz> cd yf
linux@localhost:/tmp/yourfritz/yf> git submodule update --init --remote --force
Submodule 'bin' (https://github.com/PeterPawn/yf_bin.git) registered for path 'bin'
Submodule 'first_aid' (https://github.com/PeterPawn/first_aid.git) registered for path 'first_aid'
Cloning into '/tmp/yourfritz/yf/bin'...
Cloning into '/tmp/yourfritz/yf/first_aid'...
Submodule path 'bin': checked out 'b5182b93b830fc9d7e51e7c757108a5759bababe'
Submodule path 'first_aid': checked out 'ce0c9048aff117625ce398b1096e645c0da7d5f3'
linux@localhost:/tmp/yourfritz/yf> cd ..
linux@localhost:/tmp/yourfritz> tar -x -f FRITZ.Box_7560.149.07.01.image -O ./var/tmp/filesystem.image >filesystem.image
linux@localhost:/tmp/yourfritz> tar -x -f FRITZ.Box_7560.149.07.01.image -O ./var/tmp/kernel.image >kernel.image
linux@localhost:/tmp/yourfritz> dd if=kernel.image of=kernel.bin bs=256 count=$(( $(stat -c %s kernel.image) / 256 ))
16547+0 records in
16547+0 records out
4236032 bytes (4.2 MB, 4.0 MiB) copied, 0.0440729 s, 96.1 MB/s
linux@localhost:/tmp/yourfritz> sudo yf/bin/x86/unsquashfs4-avm-be filesystem.image
Illegal instruction
linux@localhost:/tmp/yourfritz> sudo yf/bin/x86/unsquashfs4-avm-be
SYNTAX: yf/bin/x86/unsquashfs4-avm-be [options] filesystem [directories or files to extract]
    -v[ersion]        print version, licence and copyright information
    -d[est] <pathname>    unsquash to <pathname>, default "squashfs-root"
    -n[o-progress]        don't display the progress bar
    -no[-xattrs]        don't extract xattrs in file system (default)
    -x[attrs]        extract xattrs in file system (unsupported)
    -u[ser-xattrs]        only extract user xattrs in file system.
                Enables extracting xattrs
    -p[rocessors] <number>    use <number> processors.  By default will use
                number of processors available
    -i[nfo]            print files as they are unsquashed
    -li[nfo]        print files as they are unsquashed with file
                attributes (like ls -l output)
    -l[s]            list filesystem, but don't unsquash
    -ll[s]            list filesystem with file attributes (like
                ls -l output), but don't unsquash
    -f[orce]        if file already exists then overwrite
    -s[tat]            display filesystem superblock information
    -e[f] <extract file>    list of directories or files to extract.
                One per line
    -da[ta-queue] <size>    Set data queue to <size> Mbytes.  Default 256
                Mbytes
    -fr[ag-queue] <size>    Set fragment queue to <size> Mbytes.  Default
                256 Mbytes
    -r[egex]        treat extract names as POSIX regular expressions
                rather than use the default shell wildcard
                expansion (globbing)
    -exit-on-error        treat normally ignored errors as fatal
    -scan or -k        treat filesystem as a combined image
                (kernel+SquashFS) and scan it to locate the superblock
                and the NMI vector gap

Decompressors available:
    xz
linux@localhost:/tmp/yourfritz> ldd yf/bin/x86/unsquashfs4-avm-be
    not a dynamic executable
linux@localhost:/tmp/yourfritz> file yf/bin/x86/unsquashfs4-avm-be
yf/bin/x86/unsquashfs4-avm-be: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, stripped

 

[PeterPawn]

Das "illegal instruction" kann ich auf einer Ubuntu-Installation (Bionic Beaver) nachvollziehen ... merkwürdigerweise aber tatsächlich erst dann, wenn es "tiefer" in das Programm geht, denn das generelle Format wird sehr wohl noch verstanden, wie die Anzeige des "usage screen" zeigt.

Auf den ersten Blick ist das eine "movbe"-Instruktion, wo es kracht ... warum die unter x64 jetzt nicht funktionieren will (bzw. woran das ggf. liegt), muß ich selbst erst mal schauen. Vielleicht sind irgendwelche Optimierungen schuld ... ich weiß es noch nicht.

Frühere Versionen liefen jedenfalls selbst in der W10-bash ... und da die nur auf x64-Windows angeboten wurde, eben auch auf x64-Systemen als 32-Bit-Version, wenn die notwendigen Libs installiert waren (das hatten wir mal, als es um Kali-Linux ging).

Allerdings könnten das tatsächlich noch dynamisch gellinkte Programme gewesen sein ... ggf. mag ein x64-System die statisch gelinkte uClibc nicht und der Einfachheit halber sind das eben die Binaries für den ATOM-Core der 6490/6590, die da im Repo stehen. Die Benutzung unter einem "echten" Linux-System war eher ein angenehmer Nebeneffekt.

Die korrekte Funktion des "unsquashfs" aus dem "x86"-Zweig (auch der BE-Version) beim Entpacken der "filesystem.image" aus der 149.07.01 habe ich gerade noch einmal auf einem ATOM-Core einer 6490 überprüft ... daran liegt es also auch nicht wirklich. Bleibt noch die Erklärung, daß eine "movbe"-Instruktion irgendeine ATOM-Spezialität wäre (und darauf ist das halt optimiert, weil es aus einem Puma6-Build stammt) ... da muß ich mir erst mal eine Aufstellung der x86-Assembler-Instruktionen besorgen im Netz.

Die alternative Idee wäre das Bereitstellen der Programme auch in einer x64-Version - mal sehen, was ich da mache. Die früheren Binaries für x86 könnten (s.o.) aus der Freetz-Toolchain gewesen sein ... das weiß ich nicht mehr und im Zuge der Reorganisation mit den "submodules" ist das auch komplett entsorgt worden, daher kann ich da nicht mal mehr nachsehen. Aber die (schon erwähnte) Abhängigkeit von weiteren Bibliotheken deutet eher darauf hin, daß das früher dynamisch gelinkte Programme waren und dann kamen die eher aus der Toolchain als aus dem Puma6-Build.

 

[1f5]

Vielen Dank für die schnelle und ausführliche Antwort.
Eine Sache hatte ich vergessen zu erwähnen: Ich habe das 32-bit Tumbleweed genommen (i586). Ich denke also nicht, dass irgendwelche 32-bit Libraries fehlen. (Außer ich müsste sowieso welche installieren).

Was bedeutet das aktuell für mich? Soll ich das auf einem ATOM-Rechner laufen lassen oder habe ich irgendwelche wichtigen Befehle nicht ausgeführt? Alles was ich auf dem Live-System getan habe , steht in meinem letzten Post.
Oder soll ich es mit einer älteren Version ausprobieren?

 

[PeterPawn]

Ja, "movbe" ist tatsächlich nur in einigen Prozessoren implementiert (siehe "cat /proc/cpuinfo") und damit funktioniert ein mit "-march=atom" übersetztes Programm wohl nicht auf CPUs, die das nicht unterstützen. Ich werde wohl eines erzeugen, wo tatsächlich "-march=i386" verwendet wird - der Freetz-Fork soll ja als Build-System für die bereitgestellten Binaries herhalten. [ Ich muß mal nachsehen, ob das "atom" (und damit die ATOM-spezifischen Instruktionen) schon bei @f-666 vorhanden war oder erst mit der Integration in die Freetz-Toolchain jetzt Einzug gehalten hat und vorher war es noch "i386". ]

Wenn Du ein ATOM-basiertes System zur Hand hast, kannst Du meine Theorie da tatsächlich im Handumdrehen überprüfen.

Das erklärt aber in Teilen auch, warum ich das Problem bei mir bisher nicht nachstellen konnte, denn ich hatte halt einem ATOM-Prozessor:

processor       : 3
vendor_id       : GenuineIntel
cpu family      : 6
model           : 28
model name      : Intel(R) Atom(TM) CPU D525   @ 1.80GHz
stepping        : 10
microcode       : 0x107
cpu MHz         : 1795.775
cache size      : 512 KB
physical id     : 0
siblings        : 4
core id         : 1
cpu cores       : 2
apicid          : 3
initial apicid  : 3
fpu             : yes
fpu_exception   : yes
cpuid level     : 10
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts nopl aperfmperf eagerfpu pni dtes64 monitor ds_cpl tm2 ssse3 cx16 xtpr pdcm movbe lahf_lm dtherm
bogomips        : 3591.55
clflush size    : 64
cache_alignment : 64
address sizes   : 36 bits physical, 48 bits virtual
power management:

in einem wichtigen Test-System.

EDIT: Der Vollständigkeit halber noch die Intel-Dokumentation dazu: https://software.intel.com/sites/default/files/managed/39/c5/325462-sdm-vol-1-2abcd-3abcd.pdf - Volume 2B, Seite 4-54 beschreibt dann die "movbe"-Instruktion und das zugehörige Bit in der CPUID-Ausgabe.

 

[1f5]

Ich habe es nun mal auf einem ATOM-Rechner laufen lassen, den ich leihweise bekommen habe. Da läuft es ohne Probleme durch. Ob das Image, das ich erzeugt habe, auch tatsächlich auf der Fritzbox funktioniert, kann ich leider erst am Montag testen.

Ich denke es wäre angemessen, an einer geeigneten Stelle in der Anleitung zu erwähnen, dass man aktuell ein ATOM-System benötigt.

Ich werde auch versuchen, meine eigene Version von unsquashfs auf einem i5 zum komplilieren. Sehe ich das richtig, dass ich dazu die Patches von hier auf die Sourcen von hier anwenden muss?

 

[PeterPawn]

Nein, meine zusätzlichen Ergänzungen zu den SquashFS-Tools sollten mal dazu dienen, die auch unter der Windows-bash zu nutzen, als "special files" noch nicht entpackt werden konnten.

Ich habe ohnehin eine Änderung in "yf_bin" in Arbeit - die README.md dafür ist schon fertig, es fehlen nur noch zwei Skript-Dateien.

# Binaries for shell scripts from YourFritz repository

This repository contains pre-compiled binaries (for different platforms), that are needed for some scripts from the YourFritz repository.

All of them are built with my fork of the Freetz project, which may be found on GitHub, too.

They are separated now from the other repository, to keep checkouts as small as possible.

This repository has been integrated into the original one as `bin` sub-directory and has to be updated after the first checkout with the command:

```shell
git submodule update --init --remote --force bin
```

In the future you may refresh the content of your `bin` sub-directory (if necessary) with the command from above.

## Tree structure

```text
/                                              - license, README.md, PGP public key, other info
|
+- squashfs -+-                                - shell scripts to detect the needed architecture of SquashFS binaries and to call them
|            |
|            +- armv7l                         - unpack/pack binaries for ARMv7 (LE) architecture (e.g. Raspberry Pi)
|            |
|            +- i686                           - unpack/pack binaries for Intel 80386 architecture (nearly each Intel or AMD processor with 32-bit support)
|            |
|            +- mips                           - unpack/pack binaries for MIPS32r2 (BE) architecture (most FRITZ!Box devices with Lantiq/Intel or Ikanos processor)
|            |
|            +- x86_64                         - unpack/pack binaries for Intel-compatible 64-bit architecture
|
-- target ---+- mips ---+- 3.10.73             - precompiled binaries for MIPS-based devices with 3.10.73 kernel (up to FRITZ!OS version 07.0x)
             |          |
             |          +- 3.10.107 / 3.10.104 - precompiled binaries for MIPS-based devices with 3.10.10x kernel (starts with FRITZ!OS 07.0x)
             |
             +- i686                           - precompiled binaries for PUMA6-based devices (only for their ATOM)
```

The binaries for target devices are (usually) linked statically, to make them usable without any further prerequisites. For MIPS architectures there're two different branches, because AVM starts to use the uClibc-ng instead of the older uClibc (0.9.3x) from FRITZ!OS version 07.0x on.

The binaries for SquashFS handling are linked statically only for the MIPS architecture, all other architectures need the correct libraries (glibc (or a compatible one) and libz), too.

Damit gibt's die SquashFS-Tools dann auch in einer generischen x86-Form ... ich kann das ja mal als neuen Branch schon einchecken.

EDIT: Steht jetzt erst einmal als Branch "next" in "yf_bin" ... wie gesagt, es fehlen noch die Skripte für die automatische Auswahl der richtigen SquashFS-Tools anhand des Hosts. Wenn das fertig ist, wird auch so weit "aufgeräumt", daß die alten Binärdateien entsorgt werden. "git" ist ohnehin nicht so toll für die Verwaltung von Binaries ... aber immerhin gibt es den Support dafür und es steht damit auch noch aller Welt zum Download offen.