[Frage] Telnet auf der Fritzbox mit OS 07.12

[95Marcel95]

Guten Abend,

erstmals entschuldige ich mich, dass ich zu dem Thema ein Beitrag erstelle, aber ich finde leider auch unter der Suche keine richtige Anleitung wie ich auf der Fritzbox 6890 LTE Telnet aktiviere gefunden.
Über das Telefon ist dies ja leider dank den neuen Versionen nicht mehr möglich.

An der Fritzbox ist eine nagelneue 500GB SSD angesteckt .
Ich bin grade neu in dem Bereich.

Bitte um eine kleine Hilfe,

Danke

 

[NDiIPP]

Bspw.:

[Info] - FRITZ!Box 7580 - Firmware 153.06.90 - Telnet-Service freischalten (geht auch für 7560 und 7590)

EDIT 11.02.2020: Achtung: Die Struktur im Repo hat sich etwas geändert (schon im Okt. 2018) und damit sieht das Kommando zum Auschecken aus GitHub jetzt anders aus und die bereitgestellten Binaries haben andere Namen und eine zusätzliche Verzeichnisebene (die Ausgabe von "uname -m" für die...

www.ip-phone-forum.de

Oder auch Freetz im "no freetz" Modus:

help/howtos/development/repack_fw – Freetz

freetz.github.io

 

[95Marcel95]

Dafür bräuchte ich ja ein Linux System.
Geht das auch über ne VM und wenn ja welche Version von Linux muss ich da nehmen, weil da steht man braucht eine anständige Shell ?

Bspw.:

[Info] - FRITZ!Box 7580 - Firmware 153.06.90 - Telnet-Service freischalten (geht auch für 7560 und 7590)

EDIT 11.02.2020: Achtung: Die Struktur im Repo hat sich etwas geändert (schon im Okt. 2018) und damit sieht das Kommando zum Auschecken aus GitHub jetzt anders aus und die bereitgestellten Binaries haben andere Namen und eine zusätzliche Verzeichnisebene (die Ausgabe von "uname -m" für die...

www.ip-phone-forum.de

Oder auch Freetz im "no freetz" Modus:

help/howtos/development/repack_fw – Freetz

freetz.github.io

 

[NDiIPP]

Geht das auch über ne VM

Na klar.

und wenn ja welche Version von Linux muss ich da nehmen, weil da steht man braucht eine anständige Shell ?

Geschmackssache. Die einen nehmen was Debian basiertes (wie Debian direkt oder Ubuntu), andere wiederum (Open)SuSE und wieder andere (wie bspw. ich) Arch Linux. Usw. usf... Oder aber man verwendet das Windows Subsystem for Linux.

 

[95Marcel95]

Vollzitat von darüber entfernt by stoney

Vielen Dank.

Habe jetzt aber leider ein anderes Problem.


freetz@freetz-linux:/tmp/yourfritz$ sudo yf/bin/unsquashfs filesystem.image
[sudo] password for freetz:
sudo: yf/bin/unsquashfs: command not found
freetz@freetz-linux:/tmp/yourfritz$ sudo yf/bin/x86/unsquashfs filesystem.image
sudo: yf/bin/x86/unsquashfs: command not found
freetz@freetz-linux:/tmp/yourfritz$

Leider findet er das nicht und auch bei https://github.com/PeterPawn/YourFritz existiert der x86 Pfad gar nicht.

Bin ist aktuell leer bei mir


freetz@freetz-linux:/tmp/yourfritz$ cd yf
freetz@freetz-linux:/tmp/yourfritz/yf$ git checkout binaries
error: pathspec 'binaries' did not match any file(s) known to git
freetz@freetz-linux:/tmp/yourfritz/yf$

 

[PeterPawn]

Einfach mal alles lesen und nicht nach dem ersten Eindruck gleich loslegen ... die Beschreibung dort in #1 ist halt älter und es gab danach gute Gründe, die Organisation im Repo zu ändern.

https://www.ip-phone-forum.de/threa...ht-auch-für-7560-und-7590.296678/post-2301475 zeigt dann, wie es auch heute noch gehen sollte.

 

[95Marcel95]

Vielen Dank dafür.

Mache wohl irgendwas immer noch falsch.

freetz@freetz-linux:~$ git clone --recurse-submodules http://github.com/PeterPawn/YourFritz.git
Cloning into 'YourFritz'...
warning: redirecting to https://github.com/PeterPawn/YourFritz.git/
remote: Enumerating objects: 446, done.
remote: Counting objects: 100% (446/446), done.
remote: Compressing objects: 100% (287/287), done.
remote: Total 3210 (delta 241), reused 277 (delta 156), pack-reused 2764
Receiving objects: 100% (3210/3210), 4.13 MiB | 1.72 MiB/s, done.
Resolving deltas: 100% (1953/1953), done.
Submodule 'bin' (git@git:/srv/git/yf_bin.git) registered for path 'bin'
Submodule 'first_aid' (https://github.com/PeterPawn/first_aid.git) registered for path 'first_aid'
Cloning into '/home/freetz/YourFritz/bin'...
ssh: Could not resolve hostname git: Temporary failure in name resolution
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.
fatal: clone of 'git@git:/srv/git/yf_bin.git' into submodule path '/home/freetz/YourFritz/bin' failed
Failed to clone 'bin'. Retry scheduled
Cloning into '/home/freetz/YourFritz/first_aid'...
remote: Enumerating objects: 38, done.
remote: Total 38 (delta 0), reused 0 (delta 0), pack-reused 38
Cloning into '/home/freetz/YourFritz/bin'...
ssh: Could not resolve hostname git: Temporary failure in name resolution
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.
fatal: clone of 'git@git:/srv/git/yf_bin.git' into submodule path '/home/freetz/YourFritz/bin' failed
Failed to clone 'bin' a second time, aborting

 

[PeterPawn]

Nein, diesmal ist das mein Problem ... ich habe keinen Schimmer, wieso da schon wieder eine SSH-URL für die Submodules in den Unterverzeichnissen steht.

Ich korrigiere das gleich ... der Commit wird dann im GitHub angezeigt.

EDIT:
Ja, mein Fehler ... dieser Commit sollte nie in das Repo bei GitHub gelangen, das funktioniert nur bei mir lokal - daher auch der Kommentar im Commit.

EDIT2:
Korrigiert ... Du mußt allerdings noch einmal von Beginn an auschecken.

 

[95Marcel95]

Vielen Dank fürs beheben, leider kommt bei mir immer noch nen Error

freetz@freetz-linux:/tmp/yourfritz/yf$ cd -
/tmp/yourfritz
freetz@freetz-linux:/tmp/yourfritz$ git clone --recurse-submodules http://github.com/PeterPawn/YourFritz.git
Cloning into 'YourFritz'...
warning: redirecting to https://github.com/PeterPawn/YourFritz.git/
remote: Enumerating objects: 449, done.
remote: Counting objects: 100% (449/449), done.
remote: Compressing objects: 100% (293/293), done.
remote: Total 3213 (delta 242), reused 275 (delta 153), pack-reused 2764
Receiving objects: 100% (3213/3213), 4.13 MiB | 1.72 MiB/s, done.
Resolving deltas: 100% (1954/1954), done.
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/YourFritz/bin'...
remote: Enumerating objects: 352, done.
remote: Counting objects: 100% (352/352), done.
remote: Compressing objects: 100% (216/216), done.
remote: Total 781 (delta 85), reused 311 (delta 65), pack-reused 429
Receiving objects: 100% (781/781), 46.96 MiB | 2.74 MiB/s, done.
Resolving deltas: 100% (175/175), done.
Cloning into '/tmp/yourfritz/YourFritz/first_aid'...
remote: Enumerating objects: 38, done.
remote: Total 38 (delta 0), reused 0 (delta 0), pack-reused 38
error: Server does not allow request for unadvertised object 24b2a6e6a80ea9cdd74c23a1816f96afd9971ebf
Fetched in submodule path 'bin', but it did not contain 24b2a6e6a80ea9cdd74c23a1816f96afd9971ebf. Direct fetching of that commit failed.

 

[PeterPawn]

Du warst schneller als ich beim Beheben (nachträglich festgestellter Probleme) ... der Commit, den er da aus "yf_bin" auschecken will, war nur intern bei mir vorhanden - inzwischen sind alle Repos aktualisiert (vieles von dem, was ich vorerst nur intern gespeichert hatte, ist jetzt im GitHub-Repo angekommen) und er sollte irgendwas mit einer 7 vorne aus "yf_bin" auschecken wollen: https://github.com/PeterPawn/yf_bin/tree/7cd06e296f58f95eb9aa3ca616fd3765cea58c56

 

[PeterPawn]

Normalerweise pushe ich viele aktuelle Änderungen gar nicht nach GitHub ... damit bleibt dort i.d.R. ein älterer, aber funktionierender Stand bestehen, bis ich alles beisammen habe und es auf einen Schlag veröffentlichen kann.

Dazu gehört es eben auch, daß ich die "submodules"-Be- und Verarbeitung lokal teste und dafür muß ich die Quelle für diese Submodules umschalten, weil eben das GitHub-Repo nur den älteren Stand enthält.

Commits · PeterPawn/YourFritz

dynamic package management for AVM routers. Contribute to PeterPawn/YourFritz development by creating an account on GitHub.

github.com

Einer dieser Commits zum "Umschalten" auf lokale Repos (der letzte hier war schon vom 13.07.2019 und seine Vorgänger wurden davor von mir eigentlich immer ordentlich ausgeblendet, wenn es ums Veröffentlichen in GitHub ging, so z.B. dieser hier auch am 17.07.2019) hat aber durch meine Unaufmerksamkeit am 14.11.2019 doch seinen Weg in die Öffentlichkeit gefunden und dabei sowohl den Hash des letzten Commits als auch die URL für den Zugriff auf "yf_bin" im "bin"-Verzeichnis so verstellt, daß das aus GitHub heraus gar nicht funktionieren kann.

 

[95Marcel95]

Hat funktioniert, Vielen Dank

Ich melde mich falls noch was ist.

 

[95Marcel95]

Guten Morgen,

leider komme ich jetzt an der nächsten Stelle nicht weiter.

freetz@freetz-linux:/tmp/yourfritz$ ls -in
total 83784
4072635 -rw-r--r--  1 1000 1000 37822472 Jan 12 11:44 filesystem.image
4065796 -rw-r--r--  1 1000 1000 43202560 Sep 20 12:20 FRITZ.Box_6890_LTE-07.12.image
4072636 -rw-r--r--  1 1000 1000  4754440 Jan 12 11:45 kernel.image
4065797 drwxr-xr-x 28 1000 1000     4096 Jan 11 22:44 yf
4068888 drwxr-xr-x 28 1000 1000     4096 Jan 12 02:11 YourFritz
freetz@freetz-linux:/tmp/yourfritz$ sudo YourFritz/bin/squashfs/unsquashfs filesystem.image
[sudo] password for freetz:
sudo: YourFritz/bin/squashfs/unsquashfs: command not found
freetz@freetz-linux:/tmp/yourfritz$ ls -in YourFritz/bin/squashfs
total 20
4203432 drwxr-xr-x 2 1000 1000 4096 Jan 12 02:12 armv7l
4203445 drwxr-xr-x 2 1000 1000 4096 Jan 12 02:12 i686
4203458 drwxr-xr-x 2 1000 1000 4096 Jan 12 02:12 mips
4203471 -rw-r--r-- 1 1000 1000  111 Jan 12 02:12 unsquashfs
4203472 drwxr-xr-x 2 1000 1000 4096 Jan 12 02:12 x86_64
freetz@freetz-linux:/tmp/yourfritz$ ^C

 

[PeterPawn]

Das Unterverzeichnis für die Plattform, auf der man das "unsquashfs" ausführen will, muß man im Namen selbst mit angeben ... bei "freetz-linux" ist das wohl eine VM und damit wäre "x86_64" vermutlich das richtige. Da finden sich dann auch die Programme - die zusätzliche Verzeichnisebene wurde notwendig, um die FRITZ!Boxen (MIPS + i686) und den RasPi (armv7l), parallel zu 64-Bit-Linux auf Intel-Basis, zu unterstützen.

Die Shell-Datei "unsquashfs" sollte mal die automatische Auswahl der richtigen Plattform übernehmen, der fehlen aber merkwürdigerweise ein paar Zeilen am Ende - keine Ahnung, wo die geblieben sind.

ACHTUNG: Die Namen der Dateien haben sich auch (minimal) geändert ... einfach ein Listing machen und die richtige Datei für die SquashFS-Version und die Speicherform (BigEndian vs. LittleEndian) wählen - wobei das Auspacken mit dem "unsquashfs" für Version 4 und "little endian" eigentlich für alle Formate (von Version 3 bis zu BE) funktionieren sollte. Nur beim Einpacken muß man das richtige Programm selbst wählen.

 

[95Marcel95]

Bin leider relativ neu bei sowas und habe es jetzt damit versucht

Welches davon benötige ich ?

freetz@freetz-linux:/tmp/yourfritz$ ls -in YourFritz/bin/squashfs/x86_64/       total 1204
4203473 -rwxr-xr-x 1 1000 1000 154536 Jan 12 02:12 mksquashfs3-multi
4203474 -rw-r--r-- 1 1000 1000    566 Jan 12 02:12 mksquashfs3-multi.sig
4203475 -rwxr-xr-x 1 1000 1000 268000 Jan 12 02:12 mksquashfs4-be
4203476 -rw-r--r-- 1 1000 1000    566 Jan 12 02:12 mksquashfs4-be.sig
4203477 -rwxr-xr-x 1 1000 1000 263904 Jan 12 02:12 mksquashfs4-le
4203478 -rw-r--r-- 1 1000 1000    566 Jan 12 02:12 mksquashfs4-le.sig
4203479 -rwxr-xr-x 1 1000 1000 105624 Jan 12 02:12 unsquashfs3-multi
4203480 -rw-r--r-- 1 1000 1000    566 Jan 12 02:12 unsquashfs3-multi.sig
4203481 -rwxr-xr-x 1 1000 1000 201088 Jan 12 02:12 unsquashfs4-be
4203482 -rw-r--r-- 1 1000 1000    566 Jan 12 02:12 unsquashfs4-be.sig
4203483 -rwxr-xr-x 1 1000 1000 201088 Jan 12 02:12 unsquashfs4-le
4203484 -rw-r--r-- 1 1000 1000    566 Jan 12 02:12 unsquashfs4-le.sig
freetz@freetz-linux:/tmp/yourfritz$

 

[PeterPawn]

Eine 6890 verwendet wohl (wenn diese ein Ableger der GRX-Reihe ist) Version 4 und BE-Speicherung. Wobei das in der Ausgabe des "unsquashfs" ja auch alles stehen würde und da habe ich oben ja geschrieben, daß JEDES der Binaries für Version 4 eigentlich zum Auspacken verwendet werden kann. Da sieht man dann (beim Aufruf mit Option "-s") auch, welches Format das Ausgangsimage hat und welche Parameter man beim Einpacken besser wieder berücksichtigt. Die Verwendung des "usage screens" eines Linux-Programms gehört auch zum "kleinen Einmaleins", was man beherrschen sollte, wenn man sich auf die Suche nach einem Shell-Zugang für seine FRITZ!Box macht.

Die ganz Vorsichtigen vergleichen am Ende sogar die Ausgabe von "unsquashfs4-be -s <file>" für das selbst erzeugte Image noch einmal mit dem von AVM und versuchen, sich event. (bzw. garantiert) vorhandene Abweichungen irgendwie zu erklären - findet man keine plausible Erklärung für einen festgestellten Unterschied, hat man wohl etwas falsch gemacht (entweder beim Einpacken oder bei der Suche nach ebendieser Erklärung).

 

[95Marcel95]

Ich habe leider folgenden Befehl vergessen bevor ich es ausgeführt habe

dd if=kernel.image of=kernel.bin bs=256 count=$(( $(stat -c %s kernel.image) / 256 ))

Jetzt wollte ich den Ordner squashfs-root wieder löschen aber er verweigert es da dort ein Schreibschutz drauf liegt.
Selbst mit Chmod bekomme ich es nicht gelöscht.

 

[PeterPawn]

sudo rm -rf squashfs-root/
Das Firmware-Image enthält halt Dateien, die "root" gehören (eigentlich nur solche) und daher beim Auspacken mittels "sudo unsquashfs..." auch diese UID/GID erhalten. Die darf dann ein "normaler Benutzer" halt nicht mehr löschen ... aber erneut: Das ist eigentlich Basiswissen für jeden Linux-Benutzer und wer mit einer Shell auf seiner FRITZ!Box herumspielen will, der sollte sich damit auch auskennen oder sich zunächst diese Grundlagen erarbeiten.

Meine "Anleitung" sollte eigentlich auch eher dem Erklären von Zusammenhängen dienen und zum eigenen Experimentieren anregen (war also eher Illustration, denn Rezept), aber sie war eigentlich niemals nur zum "Abtippen" gedacht ... da bin ich dann irgendwann auch der falsche Ansprechpartner.

 

[hsz]

4203471 -rw-r--r-- 1 1000 1000 111 Jan 12 02:12 unsquashfs

unsquashfs ist nicht ausführbar
chmod +x YourFritz/bin/squashfs/unsquashfs
sollte das beheben

 

[PeterPawn]

1. Freetz checkt per se einen älteren Stand von "YourFritz" aus und das - wenn ich mich richtig erinnere - auch noch ohne die Submodules, also auch ohne "bin" (bzw. "yf_bin" als Repo).

2. Die Datei "[yf_]bin/squashfs/unsquashfs" war ursprünglich mal als Wrapper für die automatische Auswahl des zur Plattform passenden Tools gedacht ... ist aber in keinster Weise fertig. Daher habe ich die heute auch wieder komplett gelöscht, weil ich in neueren Skript-Files ohnehin die Auswahl noch erweitern mußte, um auch (neue) Formate mit "hidden root" (z.B. bei der 4020) nun doch wieder zu unterstützen, nachdem ich zuvor schon der Ansicht war, das letzte Modell mit diesem Aufbau, um das man sich kümmern müßte, wäre die 7390 gewesen.

3. Nachdem AVM dann irgendwann mehrere Kernel-Versionen und mehrere C-Libraries verwendete (was auch Auswirkungen auf die Tools in "[yf_]bin/squashfs" hat, die auf einer Box ausgeführt werden sollen, z.B. die MIPS-Varianten) und ich auch mehrere Plattformen unterstützen wollte (u.a. die Intel-Welt mit x86 und x86_64 und ARM-Prozessoren (bspw. auf den RasPis) mit ARMv7), wurde die Dateisystemstruktur unterhalb von "squashfs" und "target" halt noch einmal überarbeitet und es gibt dort jetzt jeweils ein Verzeichnis, was mit der Ausgabe von "uname -r" "uname -m" auf den unterstützten Plattformen übereinstimmen sollte.

4. Zusätzlich haben sich (als immer mehr Formate dazukamen) die Namen der SquashFS-Tools geändert (auch in der Freetz-Toolchain) ... aber man braucht ja nur ein "ls" auf das passende Verzeichnis loslassen, um sich die aktuell verwendeten Namen der Binaries anzeigen zu lassen - und die sind dann auch wieder in jedem Unterverzeichnis für die Plattformen (das "mips"-Verzeichnis ist noch weiter unterteilt, da kommt noch eine Ebene mit dem Kernel und der C-Library dazu) dieselben, denn auch meine Skript-Dateien müssen sich jeweils erst einmal die passenden Tools für das Entpacken und Packen für das jeweils verwendete SquashFS-Format heraussuchen.

5. Allerdings kann man das Entpacken für die SquashFS-Version 4 (also "unsquashfs4-be" und "unsquashfs4-le") mit den passenden Parametern (meist sicherlich "-stat -scan") auch problemlos benutzen, um sich Informationen über das vorliegende SquashFS-Format zu verschaffen, da bei "-stat" auch abweichende Endianess und ältere Formate bzw. Kompressionsverfahren erkannt und berichtet werden. Erst dann, wenn es um das Auspacken geht, braucht man noch das korrekte Tool für die Endianess - aber auch hier interessiert es nicht, wenn das Image ein SquashFS3-Format verwendet und man das mit dem Tool für Version 4 entpacken läßt.

6. Allerdings muß man dann zum Einpacken schon wieder die passenden Tools nehmen (also auch "mksquashfs3-multi" für das ältere SquashFS-Format) ... das muß man dann halt anhand des Inhalts der "Vorlage" ermitteln.