[Frage] Telnet auf der Fritzbox mit OS 07.12

Bin nach der Anleitung vorgegangen
Build Umgebung: Ubuntu 18.04 auf VM (IP 192.168.68.99)
Fritz!Box: 7590 OS7.12 (IP 192.168.68.1)
und konnte das Image auf die Box spielen mit
Code:
root@ubuntu-18-04:~/YourFritz/eva_tools# eval $(sudo ./eva_discover INTERFACE=eth0 FROM=192.168.68.99 TO=192.168.68.1 BLIP=1 HOLD=0); echo "EVA_FOUND=$EVA_FOUND"; echo "EVA_IP=$EVA_IP"; [ "$EVA_FOUND" = "1" ] && ./eva_to_memory ../var/tmp/telnetimage.bin $EVA_IP
EVA_FOUND=1
EVA_IP=192.168.68.1
Found AVM bootloader: AVM EVA Version 1.3258 0x0 0x46409
Found hardware revision: 226
Memory size is 0x08000000 (128 MB)
Memory size limited to 128 MB
Image size is 0x1976a00 (25 MB)
Setting temporary memory size to: 0x06689600
Setting temporary kernel args to: mtdram1=0x86689600,0x88000000
Image uploaded to device.

leider springt der telnetd nicht an wenn ich versuche ihn über "#96*7*" zu aktivieren obwohl er vorhanden ist

Code:
root@ubuntu-18-04:~/YourFritz# find var/tmp/squashfs-root/ -name "telnet*" -ls
   278489      0 lrwxrwxrwx   1 root     root           17 Feb 11 21:38 var/tmp/squashfs-root/usr/sbin/telnetd -> ../../bin/busybox

Gibt es eine einfachen Weg, über die Oberfläche zu prüfen, ob das mein Image ist, das gerade läuft?
Ich denke da an eine Datei, die im DocumentRoot des Server liegt. Leider bin ich mir nicht sicher welches Verzeichniss nun tatsächlich genutzt wird (tippe mal auf /usr/www/avm).
Die Datei /etc/fritzbox_diagnose.html scheint auch ein guter Kandidat zu sein, wenn nichts dagegen spricht, die Datei zu ändern.

PS: bin gerade durch Zufall auf /usr/bin/system_status gestoßen, das in einem Kommentar folgende rät
Code:
# Im file /etc/version koennt ihr die Variable FIRMWARE_SUBVERSION modifizieren
# hier koennt ihr eurer eigenen Subversion einen Namen geben
#
# export FIRMWARE_SUBVERSION=-Fritz-Build-77
 
Nun ... in dem anderen Thread findet sich halt auch dieser Beitrag: https://www.ip-phone-forum.de/threa...ht-auch-für-7560-und-7590.296678/post-2325261 - und ich kann ja auch nichts dafür, daß AVM das geändert hat.

Welche Alternativen es jetzt immer noch für den Start des Telnet-Daemons gäbe, ist in aller Ausführlichkeit im "modfs"-Thread abgehandelt ... das geht vom "privaten Modus" für den "telefon"-Daemon (der dann die Telefon-Codes auch wieder "scharfschaltet") bis zum Start anstelle von "dtrace" (die Codes funktionieren nämlich noch), vom expliziten Start im Rahmen der Systeminitialisierung (rc.S vor 07.19, systemd seitdem) bis zum Start nach dem Aufruf von "system_status", wie es auch das "modscript" für die VR9-Modelle vormacht: https://github.com/PeterPawn/modfs/blob/master/files/telnetd_by_avm i.V.m. https://github.com/PeterPawn/modfs/blob/master/modscripts/mod_telnet_enable - was man davon jetzt bevorzugt bzw. ob man überhaupt Telnet nimmt und nicht besser gleich SSH, kann ich kaum entscheiden.

Die "Anleitung" dient ja eigentlich eher zur Illustration des richtigen Vorgehens, wenn man die Firmware "von Hand" ändern möchte und da ist der Einbau bzw. das "Wiedererwecken" des Telnet-Daemons ja nur der Aufhänger bzw. das konkrete Beispiel.

Wer dabei auch gleich noch den "gui_bootmanager" einbauen läßt (https://github.com/PeterPawn/YourFritz/tree/master/bootmanager), der sieht auch, welches System da gerade gestartet wurde - auch dafür gibt es in "modfs" ein passendes Skript und auch wenn "modfs" selbst halt nur auf VR9-Modelle zielt, kann man die dort enthaltenen Aktionen ja von Hand ausführen bzw. das Skript sogar (mit passender Umgebung) auch auf das entpackte Dateisystem von GRX-Boxen loslassen.
 
Mir ging es zuerst darum, sicher zu stellen, daß das geänderte Image läuft. Im Nachgang (und als Ziel) soll dann ein ssh server (evtl. dropbear) und ein check_mk_agent script drauf, damit die Box ins Monitoring Daten liefert. Ich wollte nicht gleich mit modfs auf den Spatzen schießen.
 
Peters systemd-Methode seit 7.19 habe ich hier beschrieben (setzt aber voraus, dass der Symlink /usr/sbin/telnetd existiert).
 
"modfs" ginge bei GRX-Boxen ja auch gar nicht, denn es funktioniert dort prinzipiell nicht (es fehlt die Wrapper-Partition). Aber "modfs" ist eben auch nur ein "Framework" zum Entpacken, Ändern, Packen und Installieren und die eigentlichen Änderungen übernehmen zusätzliche, einzelne Shell-Dateien, die in den entpackten Dateien "wüten". Diese Dateien kann man entweder komplett "nachnutzen" oder sich die in ihnen ausgeführten Änderungen ansehen und sie "von Hand" vornehmen.

Wer sich tatsächlich "check_mk_agent" einbauen will, der sollte zuvor mal einen Blick auf die vorhandenen Dateien werfen ... denn die Mechanismen zu dessen Start sind auch bei AVM schon vorhanden und es fehlen am Ende nur die ausführbaren Dateien und deren Konfiguration.
 
super Hinweis: bin/inetdctl hat tatsächlich schon check_mk vorbereitet. Ich werd mal sehen ob ich das nicht nutzen kann. Evtl. brauch ich dann auch keinen sshd, wenns über SSL/TLS auch geht.

-- Zusammenführung Doppelpost by stoney

Um nochmal auf #1 zurückzukommen: der Vorschlag von chatty in #25 hat funktioniert. Ich konnte mich mit dem Webpasswort anmelden, nachdem ich den telnetd in S85-apps eingetragen habe.
FRITZ!Box 7590 154.07.12 Buildnumber:69995
Code:
# cat /etc/init.d/S85-apps
#!/bin/sh
/usr/sbin/telnetd -l /sbin/ar7login
 
Zuletzt bearbeitet von einem Moderator:
Ich bin inzwischen schon wieder etwas näher am Ziel. Manuel installiert läuft jetzt dropbear und check_mk (über ssh).
Erfreulicherweise sind die Binaries von meiner alten Fritz!Box 7272 kompatibel. Als nächstes kommt der Aufruf der dropbear statt telnetd in S85-apps (die genaue Konfiguration ist hier wohl "out of scope". Die Sourcen sind u.A. auf https://matt.ucc.asn.au/dropbear/dropbear.html zu finden)
Code:
/usr/bin/dropbear -r /etc/dropbear/rsa_host_key -S /usr/bin/sftp-server
und der angepaßte check_mk agent nach /usr/bin/check_mk_agent.sh
Bleibt eigentlich nur die Frage offen wo inetdctl enable check_mk am besten aufgehoben ist?
 
Zuletzt bearbeitet:
Peter hat hier aktuelle dropbears abgelegt. Für meine 7490 ist es v2019.78 - für alle anderen targets sicher die gleiche Version.
 
einziger Nachteil ist, daß die Version u.a. auf das Argument "-0" "stripped" ist, sodaß nur root sich anmelden kann. Ich brauche aber einen eigenen Monitoring user, der dann automatisch den check_mk_agent aufruft. Das wird in der authorized_keys des users definiert. Die anderen options passen, oder man kann sie überschreiben. Bleibt nur dropbear ein zweites mal mit einem anderen Port zu nutzen oder ein anders binary zu finden bzw. zu erzeugen.
 
Ich brauche aber einen eigenen Monitoring user, der dann automatisch den check_mk_agent aufruft.
Das ist bei einem FRITZ!OS im derzeitigen Aufbau reine Augenwischerei. Erstens arbeitet das gesamte FRITZ!OS im "root"-Kontext (also tatsächlich JEDER Daemon, der dort enthalten ist) und ist - außer ab 07.19 dann der "nqcs" - auch nicht weiter gesichert und zweitens hält einen ja niemand davon ab, mehr als einen Public-Key für die Authentifizierung zu verwenden und den automatischen Aufruf von Programmen (über eine "command=..."-Option für einen solchen Key) für einen solchen speziellen Key zu konfigurieren.

Wenn man irgendeinen zusätzlichen Daemon in einem anderen Kontext als "root" starten will, muß man beim FRITZ!OS eben noch deutlich mehr machen. Das geht beim Hinzufügen passender Konten zur "/etc/passwd" bereits los, denn da gibt es per se eben auch nur den "root" und dann generiert der "ctlmgr" bei seinem Start die passenden zusätzlichen Eintragungen für FRITZ!Box-Benutzer (als "boxusrXX") und für Apps per TR-064-Interface (als "appXX"). Mit der nächsten Version (bzw. der aktuellen Labor-Reihe) kommen dann noch Konten für "smb" und "asec" hinzu - ob eine "SMB-Session" jetzt tatsächlich in einem "smb"-Kontext ablaufen würde, habe ich noch nicht getestet.

Wie das am Ende aber auch ausgehen kann mit eigenen Änderungen an der "/etc/passwd", kann man aktuell hier nachlesen: https://www.ip-phone-forum.de/threa...ws-with-duplicate-entries.305910/post-2357685 - ich bin sogar der Überzeugung, daß irgendwo in der Freetz-Behandlung dieser zusätzlichen Konten noch ein Bug steckt, der durch die Einführung der "appXX"-Konten bei AVM (die erst vor ein paar Versionen erfolgte, als auch das entsprechende TR-06x-Interface aus der Taufe gehoben wurde) getriggert wurde.

Will man also am Ende tatsächlich einen Prozess in einem anderen Kontext starten lassen, hält einen ja auch niemand davon ab, diesen Start in ein passendes Wrapper-Skript zu verpacken und darin zuvor die passenden Credentials zu setzen, wobei das bei "anständigen" Daemons ja i.d.R. ohnehin beim Start über entsprechende Parameter zu regeln ist ... auch wenn einen das nicht davon befreit, noch die passenden Konten zuvor einzurichten.

Das Hinzufügen weiterer öffentlicher Schlüssel mit "command=..."-Option funktioniert jedenfalls auch mit der für YourFritz angepaßten Variante des "dropbear" - und solange keine Lücken bekannt werden, die eine Beschränkung auf das in der "authorized_keys" vorgegebene Kommando umgehen lassen bzw. keine Änderung des dabei aufgerufenen Skripts möglich ist, sehe ich auch nicht, wie da jemand "ausbrechen" sollte aus dem Laufstall, den man ihm vorgegeben hat.

Ich habe diese "zwangsweise" Option "-0" (die ja besagt, daß sich ausschließlich "root" per SSH anmelden darf) hier auch absichtlich verwendet ... es erspart einem nämlich auch, andere Konten aus der "/etc/passwd" im Auge behalten zu müssen und auch wenn dort i.d.R. "/home-not-used" als Home-Verzeichnis gesetzt wird für die AVM-Konten und es nicht so einfach ist, dort eine andere "authorized_keys" einzuschmuggeln, kann man sich bei der Absicherung am Ende auf eine einzige Stelle konzentrieren, wenn andere Benutzer sich gar nicht erst anmelden dürfen.

Der skizzierte Fall (Ausführen eines speziellen Kommandos für einen Key - ggf. auch noch unter einem anderen Konto) ist jedenfalls auch mit "dropbear" und meinen Patches realisierbar ... da am Ende im FRITZ!OS ohnehin alles bei "root" landet (die zaghaften Versuche mit anderen "Dienstkonten" sind ja neu bei AVM seit der 07.19-Laborreihe), sehe ich da keine zusätzlichen Lücken. Das Einzige, was etwas kompliziert zu realisieren ist, wäre der SFTP-Zugriff ausschließlich auf die NAS-Verzeichnisse und da auch noch so, daß die vorhandenen Benutzerrechte berücksichtigt werden. Da das bei AVM in allen anderen Fällen (SMB, FTP, NAS-GUI) über die "libavmacl2" geregelt wird, müßte man den SFTP-Server ebenfalls darauf umstellen, wenn man die AVM-Benutzerverwaltung verwenden wollte - das überlasse ich als Übung dem interessierten Benutzer (der dafür aber auch programmieren können sollte).
 
Hier meine Kurzanleitung für den ssh Zugang statt dem Link von busybox auf telnetd.
Meine Systemumgebung: Ubuntu 18.04 in einer VM. Das YourFritz Repo ist im home von root gecloned und das filesystem von FRITZ.Box_7590-07.12.image ist unter var/tmp/squashfs-root/ entpackt (siehe Anleitung aus #23)
Code:
cd ~/YourFritz
mkdir var/tmp/squashfs-root/.ssh/
chmod 700 var/tmp/squashfs-root/.ssh/
echo 'ssh-rsa AAA...public_root_sshKey...Ix rootAccess' >>var/tmp/squashfs-root/.ssh/authorized_keys
chmod 600 var/tmp/squashfs-root/.ssh/authorized_keys
cp bin/target/mips/3.10.107/dropbearmulti var/tmp/squashfs-root/usr/sbin/
ln -s dropbearmulti var/tmp/squashfs-root/usr/sbin/dropbear
cp bin/target/mips/3.10.107/sftp-server var/tmp/squashfs-root/usr/bin/
echo "/usr/sbin/dropbear -j -k -S /usr/bin/sftp-server" >>var/tmp/squashfs-root/etc/init.d/S85-apps
"AAA...public_root_sshKey...Ix" ist der public key im openssh Format und muß natürlich mit dem korrekten Wert aus z.B. ~/.ssh/id_rsa.pub ersetzt werden (für Putty Nutzer hilft puttygen den Wert zu konvertieren).
Danach das Image nach Anleitung aus #23 packen und installieren.
"-j -k" beim Aufruf von dropbear verhindert port forwarding und kann bei Bedarf auch weggelassen werden.

Um check_mk zum laufen zu bringen muß zuerst der agent für linux angepaßt werden. Ich verwende die Version 1.2.8p16-1ubuntu0.1 aus dem Repositiry apt install check-mk-agent. Dann liegt das Script unter /usr/bin/check_mk_agent. Das Script braucht eine aktuelle busybox. Die wird in /usr/local/bin bereitgestellt. Der Code ab Zeile 748 wird entfernt (plugins, runas Executor und local scripts), die ash in Zeile 1 gesetzt und die unbekannten "export -f" auskommentiert.
Code:
mkdir -p var/tmp/squashfs-root/usr/local/bin
cp bin/target/mips/3.10.107/busybox var/tmp/squashfs-root/usr/local/bin
ln -s busybox var/tmp/squashfs-root/usr/local/bin/ash
ln -s busybox var/tmp/squashfs-root/usr/local/bin/timeout
head -748 /usr/bin/check_mk_agent >var/tmp/squashfs-root/usr/bin/check_mk_agent.sh
sed -i -e '1s/bin\/bash/usr\/local\/bin\/ash/' -e 's/export -f/#export -f/' var/tmp/squashfs-root/usr/bin/check_mk_agent.sh
chmod +x var/tmp/squashfs-root/usr/bin/check_mk_agent.sh
Zu guter letzt entweder das script über ssh aufrufen, indem in .ssh/authorized_keys die Zeile eingefügt wird
Code:
command="/usr/bin/check_mk_agent.sh" ssh-rsa AAA...public_monitor_sshKey...Ix monitorAccess
oder per inetd auf dem std. Port 6556 (unverschlüsselt). Dazu muß /bin/inetdctl angepaßt werden und in /etc/init.d/S85-apps gestartet werden
Code:
sed -ie 's/\/bin\/sh sh \/usr\/bin\/check_mk_agent.sh/\/usr\/bin\/check_mk_agent.sh/' var/tmp/squashfs-root/bin/inetdctl
echo "inetdctl enable check_mk" >>/var/tmp/squashfs-root/etc/init.d/S85-apps
 
Vollzitat entfernt (gerne selbst mit Maß neu zitieren) by stoney

Hi@PeterPawn !

Ich habe mich jetzt mal durchgeschlagen und insbesondere versucht nach deiner verlinkten Anleitung (Telnet auf 7580-153.06.90-Kombi in Verbindung mit dem Änderungshinweis des Verweises auf die Möglichkeit mit FB 7590 gleiches zu tun! ) und diesem Thread hier, Telnet zu aktivieren und bin leider bei einem Zwischschritt hängen geblieben. Ich selber habe vorher noch keine customizte FritzBox-Firmware installiert. Damit du oder die anderen Foren-User meine Gedankengänge besser nachvollziehen können, versuche ich es mal so strukturiert wie möglich! Da dies mein erster Post ist und ich schon ordentlich Zeit investiert habe, bitte bei Fehlern freundlich darauf hinweisen. :)

VORGEHENSSKIZZE

1583764908207.png

CODE AUS DER KOMMANDOZEILE

yourfritz-Verzeichnis
erstellen
Code:
debian@DESKTOP:/tmp$ mkdir /tmp/yourfritz
debian@DESKTOP:/tmp$ cd yourfritz
debian@DESKTOP:/tmp/yourfritz$ wget http://ftp.avm.de/fritz.box/fritzbox.7580/firmware/deutsch/FRITZ.Box_7580.153.06.90.image
--2020-03-09 10:14:01--  http://ftp.avm.de/fritz.box/fritzbox.7580/firmware/deutsch/FRITZ.Box_7580.153.06.90.image
Resolving ftp.avm.de (ftp.avm.de)... 217.110.95.228, 212.42.224.73, 217.110.95.227, ...
Connecting to ftp.avm.de (ftp.avm.de)|217.110.95.228|:80... connected.
HTTP request sent, awaiting response... 404 Not Found
2020-03-09 10:14:01 ERROR 404: Not Found.

FritzBox-Image 154.07.12 für Modell 7590 von Windows-Ordner in Linux-Ordner kopieren
Code:
debian@DESKTOP:/mnt/c/users/<username>/downloads/FritzBox Modifikation/Original Image$ ls -la
total 27740
drwxrwxrwx 1 debian debian     4096 Feb 29 00:38 .
drwxrwxrwx 1 debian debian     4096 Mar  8 20:06 ..
-rwxrwxrwx 1 debian debian 28364800 Feb 29 00:36 FRITZ.Box_7590-07.12.image
-rwxrwxrwx 1 debian debian    38573 Feb 29 00:36 info_de.txt

debian@DESKTOP:/tmp/yourfritz$ ls -la
total 0
drwxrwxrwx 1 debian debian 4096 Mar  9 10:04 .
drwxrwxrwt 1 root   root   4096 Mar  9 10:04 ..

debian@DESKTOP:/tmp/yourfritz$ cp /mnt/c/users/<username>/downloads/"fritzbox modifikation"/"original image"/fritz.box_7590-07.12.image /tmp/yourfritz
debian@DESKTOP:/tmp/yourfritz$ ls -la
total 27776
drwxrwxrwx 1 debian debian     4096 Mar  9 11:32 .
drwxrwxrwt 1 root   root       4096 Mar  9 10:04 ..
-rwxrwxrwx 1 debian debian 28364800 Mar  9 11:32 fritz.box_7590-07.12.image

YourFritz-Repository von GIT ins eigene yourfritz-Verzeichnis kopieren
Code:
debian@DESKTOP:/tmp/yourfritz$ git clone --recurse-submodules http://github.com/PeterPawn/YourFritz.git yf
-bash: git: command not found

debian@DESKTOP:/tmp/yourfritz$ sudo apt-get install git
Reading package lists... Done
Building dependency tree
Reading state information... Done
E: Unable to locate package git

debian@DESKTOP:/tmp/yourfritz$ sudo apt-get update
Ign:1 http://deb.debian.org/debian stretch InRelease
Get:2 http://security.debian.org/debian-security stretch/updates InRelease [94.3 kB]
Get:3 http://deb.debian.org/debian stretch-updates InRelease [91.0 kB]
Get:4 http://deb.debian.org/debian stretch Release [118 kB]
Get:5 http://deb.debian.org/debian stretch Release.gpg [2,410 B]
Get:6 http://deb.debian.org/debian stretch-updates/main amd64 Packages [27.9 kB]
Get:7 http://deb.debian.org/debian stretch-updates/main Translation-en [11.9 kB]
Get:8 http://security.debian.org/debian-security stretch/updates/main amd64 Packages [520 kB]
Get:9 http://deb.debian.org/debian stretch/main amd64 Packages [7,083 kB]
Get:10 http://security.debian.org/debian-security stretch/updates/main Translation-en [230 kB]
Get:11 http://deb.debian.org/debian stretch/main Translation-en [5,381 kB]
Fetched 13.6 MB in 25s (534 kB/s)
Reading package lists... Done

debian@DESKTOP:/tmp/yourfritz$ sudo apt-get install git
Reading package lists... Done
Building dependency tree
Reading state information... Done
.
.
.
Running hooks in /etc/ca-certificates/update.d...
done.

debian@DESKTOP:/tmp/yourfritz$ git clone --recurse-submodules http://github.com/PeterPawn/YourFritz.git yf
Cloning into 'yf'...
remote: Enumerating objects: 518, done.
remote: Counting objects: 100% (518/518), done.
remote: Compressing objects: 100% (333/333), done.
remote: Total 3282 (delta 285), reused 331 (delta 181), pack-reused 2764
Receiving objects: 100% (3282/3282), 4.15 MiB | 968.00 KiB/s, done.
Resolving deltas: 100% (1997/1997), 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/yf/bin'...
remote: Enumerating objects: 396, done.
remote: Counting objects: 100% (396/396), done.
remote: Compressing objects: 100% (248/248), done.
remote: Total 825 (delta 102), reused 345 (delta 77), pack-reused 429
Receiving objects: 100% (825/825), 58.69 MiB | 767.00 KiB/s, done.
Resolving deltas: 100% (192/192), done.
Cloning into '/tmp/yourfritz/yf/first_aid'...
remote: Enumerating objects: 38, done.
remote: Total 38 (delta 0), reused 0 (delta 0), pack-reused 38
Submodule path 'bin': checked out '7cd06e296f58f95eb9aa3ca616fd3765cea58c56'
Submodule path 'first_aid': checked out '7650642cad199cbd4c8a91eec41a191fc9e04b1b'

debian@DESKTOP:/tmp/yourfritz$ ls -la
total 27776
drwxrwxrwx 1 debian debian     4096 Mar  9 12:44 .
drwxrwxrwt 1 root   root       4096 Mar  9 12:40 ..
-rwxrwxrwx 1 debian debian 28364800 Mar  9 11:32 fritz.box_7590-07.12.image
drwxrwxrwx 1 debian debian     4096 Mar  9 12:44 yf

debian@DESKTOP:/tmp/yourfritz$ cd yf
debian@DESKTOP:/tmp/yourfritz/yf$ ls -la
total 48
drwxrwxrwx 1 debian debian  4096 Mar  9 12:44 .
drwxrwxrwx 1 debian debian  4096 Mar  9 12:44 ..
drwxrwxrwx 1 debian debian  4096 Mar  9 12:44 addons
drwxrwxrwx 1 debian debian  4096 Mar  9 12:44 autoupdate
drwxrwxrwx 1 debian debian  4096 Mar  9 12:44 avm_kernel_config
drwxrwxrwx 1 debian debian  4096 Mar  9 12:46 bin
drwxrwxrwx 1 debian debian  4096 Mar  9 12:44 bootmanager
drwxrwxrwx 1 debian debian  4096 Mar  9 12:44 csharp
drwxrwxrwx 1 debian debian  4096 Mar  9 12:44 customconfig
drwxrwxrwx 1 debian debian  4096 Mar  9 12:44 eva_tools
drwxrwxrwx 1 debian debian  4096 Mar  9 12:44 export
drwxrwxrwx 1 debian debian  4096 Mar  9 12:46 first_aid
drwxrwxrwx 1 debian debian  4096 Mar  9 12:44 framework
drwxrwxrwx 1 debian debian  4096 Mar  9 12:44 .git
-rw-rw-rw- 1 debian debian   461 Mar  9 12:44 .gitattributes
-rw-rw-rw- 1 debian debian    26 Mar  9 12:44 .gitignore
-rw-rw-rw- 1 debian debian   169 Mar  9 12:44 .gitmodules
drwxrwxrwx 1 debian debian  4096 Mar  9 12:44 helpers
drwxrwxrwx 1 debian debian  4096 Mar  9 12:44 juis
drwxrwxrwx 1 debian debian  4096 Mar  9 12:44 led
-rw-rw-rw- 1 debian debian 18092 Mar  9 12:44 LICENSE
drwxrwxrwx 1 debian debian  4096 Mar  9 12:44 luavar
-rw-rw-rw- 1 debian debian   969 Mar  9 12:44 mitmproxy-ca.pem
drwxrwxrwx 1 debian debian  4096 Mar  9 12:44 patch_kernel
-rw-rw-rw- 1 debian debian  7373 Mar  9 12:44 PeterPawn.asc
-rw-rw-rw- 1 debian debian    61 Mar  9 12:44 PSScriptAnalyzerSettings.psd1
-rw-rw-rw- 1 debian debian  3644 Mar  9 12:44 README.md
drwxrwxrwx 1 debian debian  4096 Mar  9 12:44 reported_threats
drwxrwxrwx 1 debian debian  4096 Mar  9 12:44 scriptlib
drwxrwxrwx 1 debian debian  4096 Mar  9 12:44 signimage
drwxrwxrwx 1 debian debian  4096 Mar  9 12:44 squashfs
drwxrwxrwx 1 debian debian  4096 Mar  9 12:44 tffs
drwxrwxrwx 1 debian debian  4096 Mar  9 12:44 toolbox
drwxrwxrwx 1 debian debian  4096 Mar  9 12:44 tools
drwxrwxrwx 1 debian debian  4096 Mar  9 12:44 tr-064
drwxrwxrwx 1 debian debian  4096 Mar  9 12:44 update_yaffs2
-rw-rw-rw- 1 debian debian   266 Mar  9 12:44 YourFritz.asc
-rw-rw-rw- 1 debian debian  3129 Mar  9 12:44 yourfritz_icon.png
-rw-rw-rw- 1 debian debian  3359 Mar  9 12:44 yourfritz_logo.png

Binaries prüfen
Code:
debian@DESKTOP:/tmp/yourfritz/yf/bin/squashfs/x86_64$ git checkout binaries
error: pathspec 'binaries' did not match any file(s) known to git.

Platform prüfen
Code:
debian@DESKTOP:/tmp/yourfritz/yf/bin/squashfs/x86_64$ uname -r
4.4.0-17763-Microsoft


FRAGEN
  1. Was mache ich beim checkout für die Binaries noch falsch?
  2. Wie kann ich jetzt feststellen, ob die von mir unter WSL installierte Distro die C-Library für 32bit-Programme enthält?
  3. In wie weit sagt mir 4.4.0-17763-Microsoft etwas über den richtigen Ordner für die richtige squashfs-Binary für das aus- und einpacken? Ich denke mal, dass ich dafür die Binary aus dem Ordner bin/squashfs/x86_64 nehmen muss, wobei ich nicht weiß, ob le oder be bei mir die richtige Version ist (FB 7590, 154.07.12)?! Bevor ich das mit der Prüfung der Binaries aber nicht hinbekommen habe, mache ich am besten sowieso nicht weiter!
Ich freue mich über Antworten und danke schon jetzt dafür. Um auch etwas zurückzugeben, habe ich hier mal alles was ich bisher gemacht habe, sauber dokumentiert, damit auch andere User vll. ggf. etwas mit nehmen können. Dafür ist der Beitrag leider ein bisschen lang geraten. Sorry!

Viele Grüße,
fly
 
Zuletzt bearbeitet von einem Moderator:
Ich habe das jetzt nur überflogen auf der Suche nach dem Problem, weil ich die (vermutlich richtigen) Schritte davor nicht noch einmal lesen wollte.

1. Ein gesonderter Checkout für "binaries" sollte nicht erforderlich sein, wenn man das Repo inkl. Submodules geklont hat - was Du ja nach dem Gezeigten getan hast. In dem Verzeichnis, wo Du das "git checkout binaries" versuchst, sollten die Dateien bereits liegen und zwar dieselben, wie unter diesem Link: https://github.com/PeterPawn/yf_bin/tree/7cd06e296f58f95eb9aa3ca616fd3765cea58c56/squashfs/x86_64

2. Lassen sich die "mksquashfs*"- und/oder "unsquashfs*"-Binaries (such Dir eins aus) aufrufen und zur Anzeige des Hilfebildschirms überreden, ist die 32-Bit-Unterstützung wohl installiert - ich weiß aktuell auch nicht, was in den Linux-Versionen für die WSL (aus dem Windows-App-Store - es gibt ja mehr als eine Distro inzwischen und ich bin per se nicht wirklich ein Ubuntu-Fan ... das war nur damals die erste (und einzige) Version, die es gab, als ich die Beiträge schrieb) installiert ist und nachinstalliert werden kann aus irgendwelchen anderen (RPM-)Repos. Funktionieren die Programme, ist alles gut - erst wenn das nicht der Fall ist, muß man nach der Ursache dafür suchen.

3. Da liegst Du richtig ... habe ich irgendwo tatsächlich (dann irrtümlich und ohne daß ich es bemerkt hätte) ein uname -r anstelle des korrekten uname -m (https://pubs.opengroup.org/onlinepubs/9699919799/utilities/uname.html) verwendet in einer Beschreibung? Wenn ja, wüßte ich gerne, wo das war, damit ich es korrigieren kann.

EDIT: Ggf. noch der Hinweis, daß man einige Kommandos als "root" ausführen muß, weil die (vermutlich) beschriebenen Skripte sich nicht darum kümmern, ob da nun noch ein "sudo" vor ein Kommando gehört oder nicht - das ist bei Debian-Abkömmlingen ja manchmal "unerwünscht". Ich würde hier trotzdem (mit dem Gedanken im Hinterkopf, daß das besser kein produktiv genutztes System sein sollte, auf dem man die ersten Schritte (auch wenn das nur für dieses konkrete Thema wäre) unternimmt) einfach mit einem sudo bash beginnen und diese Shell auch erst dann wieder verlassen, wenn alles erledigt ist. Das ist zwar ein Security-Risiko ... aber es geht eben schon beim Entpacken der Firmware (immerhin ist die selbst ein komplettes OS) los, daß man da auch Dateien entpacken muß, die Bestandteil des OS und dem Zugriff "normaler Benutzer" üblicherweise entzogen sind - das gilt besonders für "special nodes" für alle möglichen Devices.

EDIT2: Ich bin nicht mal sicher, daß die Versionen aus "x86_64" die 32-Bit-Unterstützung überhaupt (noch) brauchen ... möglicherweise beziehen sich ältere Beiträge, in denen das eine Rolle spielte, auch auf eine Version, die für den ATOM-Prozessor der Puma6-Boxen gedacht war. Nachdem ich dann aber irgendwann mal mit der Nase darauf gestoßen wurde, daß dieser ATOM-Prozessor ein paar spezielle Instruktionen bereithält und "i686" und "ATOM" eben nicht zwangsläufig wechselseitig funktionieren, habe ich die 64-Bit-Versionen dazugepackt (aus dem Gedächtnis) ... zumal heute ja viele Distros gar keinen 32-Bit-Support mehr bieten, ohne daß der Benutzer erst ein paar Verrenkungen macht.

================================================================================================

Und noch ein Hinweis, der Dich aber nicht von der "Installation" eines Shell-Zugangs abhalten soll ... das Einrichten mehr als eines DynDNS-Accounts ist auch möglich, indem man nur die "ar7.cfg" in einer Export-Datei modifiziert und diese - nach Korrektur der Prüfsumme - wieder zurückspielt.

Ich betreibe schon seit Jahren eine solche Konfiguration ... auch mit "selbstdefinierten" zusätzlichen Einträgen in der Liste der Provider. Das geht aber auch mit mehreren "userdefined"-Einträgen und ist - wenn der DynDNS-Provider auch HTTPS-Requests unterstützt - auch die bessere Wahl, weil HTTPS in den selbstdefinierten Einträgen (wo nur der Servername und nicht die URL konfiguriert wird) nicht unterstützt wird.

Code:
ddns {
        accounts {
                enabled = yes;
                domain = "$$$$46ONWKA1GYY332IMILLBKFOVDBA6H36IYUPFJWJBKFM2ITOHFIC3SFJAMWDZY622ZZKCBPHA6SL5HXK4YXS2K22XBNGEOFWTTB4GE3DW";
                username = "$$$$DBWEOR4DNLGTI33GNNADGWGE3QMFMDH6GDUZY5ER1UT5M1CDK56BD6MPXAQU4ZBJHOTJOKHSFGGVZBGR";
                passwd = "$$$$NKDP2MUSS1DOZBDYR3WMJRTFLLQEYWKFYSQIF2FFSKA5ZUYR13TVZUI1KSIAATWHTNV2ACLUSYZGGJPGK65F64T2XO6S3NOCHXD6ERZ2";
                ddnsprovider = "meinservice2";
        } {
                enabled = yes;
                domain = "$$$$FCTBD1IHUWMOHHIQBYZZCWVVH6TCBNYOF5NL1GTKCMCEFH5MM1UMXFXVSB1ZOSXL2K4UXVO62HHKF1AXYBQMMLWJOG4WNRQ6F5XA4NJ2";
                username = "$$$$3W4VPZJOQ2YCO32S51WG4ALK1GWIBM6SIPUL642VEOMPNXCFCJW2QP5LCUBJVVISAPK4JER5OLE2HYKO";
                passwd = "$$$$P6YS31M1WWK44XZW3PJNJUWPVYWFMJL2CDXHXXOFFC1FXXVSVWJU2I1RTH562NB155QLMECDM2V5A6LSS4RCABCIAYKIL6OHIWZX6VAD";
                ddnsprovider = "meinservice1";
        }
        types {
                type = "dyndns";
                url = "/nic/update?system=dyndns&hostname=<domain>&myip=<ipaddr>&wildcard=NOCHG";
        } {
                type = "dyndns-custom";
                url = "/nic/update?system=custom&hostname=<domain>&myip=<ipaddr>&wildcard=NOCHG";
        } {
                type = "dyndns-statdns";
                url = "/nic/update?system=statdns&hostname=<domain>&myip=<ipaddr>&wildcard=NOCHG";
        } {
                type = "noip";
                url = "/ducupdate.php?update=<b64>username=<username>&pass=<pass>&h[]=<domain>&ip=<ipaddr></b64>";
        } {
                type = "dns4biz_premium";
                url = "/nic/update?system=dyndns&hostname=<domain>&myip=<ipaddr>&wildcard=&mx=&backmx=&offline=NO";
        } {
                type = "dns4biz_business";
                url = "/nic/update?system=dyndns&hostname=<domain>&myip=<ipaddr>&wildcard=&mx=&backmx=&offline=NO";
        } {
                type = "selfhost";
                url = "/nic/update?myip=<ipaddr>&host=<domain>&textmodi=1&http_status=1";
        } {
                type = "strato";
                url = "/nic/update?hostname=<domain>";
        } {
                type = "TZO";
                url = "/webclient/tzoperl.html?TZOName=<domain>&Email=<username>&TZOKey=<pass>&IPAddress=<ipaddr>&system=tzodns&info=1";
        } {
                type = "namemaster";
                url = "/dyn.php?username=<username>&password=<pass>&hostname=<domain>&dual=<dualstack>";
        } {
                type = "anydns";
                url = "/update.php?user=<username>&password=<pass>&host=<domain>&ip=<ipaddr>&ip6=<ip6addr>";
        } {
                type = "ms2";
                url = "/update?ip4=<ipaddr>&ip6=<ip6addr>&ip6p=<ip6lanprefix>&ds=<dualstack>&mail=1&notify=1";
        } {
                type = "ms1";
                url = "/update?ip4=<ipaddr>&ip6=<ip6addr>&ip6p=<ip6lanprefix>&ds=<dualstack>&mail=1&notify=1";
        } {
                type = "userdefined";
                url = "";
        } {
                type = "dyndnsfree";
                url = "/dyn.php?username=<username>&password=<pass>&hostname=<domain>&dual=<dualstack>";
        }
        provider {
                name = "dyndns.org";
                type = "dyndns";
                livedelay = 0w;
                touchtime = 30d;
                server = "members.dyndns.org";
                ip6server = "";
                infourl = "http://www.dyndns.org/";
                ddnsmode = ddns_both;
        } {
                name = "dyndns.org-custom";
                type = "dyndns-custom";
                livedelay = 0w;
                touchtime = 30d;
                server = "members.dyndns.org";
                ip6server = "";
                infourl = "http://www.dyndns.org/";
                ddnsmode = ddns_both;
        } {
                name = "dyndns.org-statdns";
                type = "dyndns-statdns";
                livedelay = 0w;
                touchtime = 30d;
                server = "members.dyndns.org";
                ip6server = "";
                infourl = "http://www.dyndns.org/";
                ddnsmode = ddns_both;
        } {
                name = "No-IP.com";
                type = "noip";
                livedelay = 4m;
                touchtime = 30d;
                server = "dynupdate.no-ip.com:8245";
                ip6server = "";
                infourl = "http://www.no-ip.com/";
                ddnsmode = ddns_v4;
        } {
                name = "DNS4BIZ.DE Premium";
                type = "dns4biz_premium";
                livedelay = 0w;
                touchtime = 0w;
                server = "au-eu.dns4biz.de";
                ip6server = "";
                infourl = "http://www.dns4biz.com/services_avm.php3";
                ddnsmode = ddns_v4;
        } {
                name = "DNS4BIZ.DE Business";
                type = "dns4biz_business";
                livedelay = 0w;
                touchtime = 0w;
                server = "au-eu.dns4biz.biz";
                ip6server = "";
                infourl = "http://www.dns4biz.com/services_avm.php3";
                ddnsmode = ddns_v4;
        } {
                name = "selfhost.de";
                type = "selfhost";
                livedelay = 0w;
                touchtime = 0w;
                server = "carol.selfhost.de";
                ip6server = "";
                infourl = "http://www.selfhost.de";
                ddnsmode = ddns_v4;
        } {
                name = "STRATO AG";
                type = "strato";
                livedelay = 4m;
                touchtime = 0w;
                server = "dyndns.strato.com";
                ip6server = "";
                infourl = "http://www.strato.de/webhosting/index.html";
                ddnsmode = ddns_v4;
        } {
                name = "TZO.com";
                type = "TZO";
                livedelay = 0w;
                touchtime = 0w;
                server = "rh.tzo.com";
                ip6server = "";
                infourl = "http://www.tzo.com";
                ddnsmode = ddns_v4;
        } {
                name = "namemaster.de";
                type = "namemaster";
                livedelay = 0w;
                touchtime = 0w;
                server = "dynup.de:443";
                ip6server = "ipv6.dynup.de:443";
                infourl = "http://www.namemaster.de";
                ddnsmode = ddns_both;
        } {
                name = "meinservice2";
                type = "ms2";
                livedelay = 3m;
                touchtime = 3d;
                server = "dyndns.somewhereelse.de";
                ip6server = "dyndns.somewhereelse.de";
                infourl = "http://dyndns.somewhereelse.de/info";
                ddnsmode = ddns_both_together;
        } {
                name = "meinservice1";
                type = "ms1";
                livedelay = 3m;
                touchtime = 3d;
                server = "dyndns.somewhere.de";
                ip6server = "dyndns.somewhere.de";
                infourl = "http://dyndns.somewhere.de/info";
                ddnsmode = ddns_both_together;
        } {
                name = "<userdefined>";
                type = "userdefined";
                livedelay = 4m;
                touchtime = 0w;
                server = "";
                ip6server = "";
                infourl = "";
                ddnsmode = ddns_v4;
        } {
                name = "AnyDNS";
                type = "anydns";
                livedelay = 0w;
                touchtime = 0w;
                server = "anydns.info";
                ip6server = "";
                infourl = "http://www.anydns.info";
                ddnsmode = ddns_both_together;
        } {
                name = "Dyndnsfree.de";
                type = "dyndnsfree";
                livedelay = 1m;
                touchtime = 30d;
                server = "dynup.de:443";
                ip6server = "ipv6.dynup.de:443";
                infourl = "http://www.dyndnsfree.de";
                ddnsmode = ddns_both;
        }
}

Das (also die Änderung in der "ar7.cfg") ist auch gleichzeitig der einzige mir bekannte Weg, auf dem man den DynDNS-Client der Box überreden kann, für die "benutzerdefiniert"-Einträge einen anderen Wert als die vorgegebene "touchtime" von "0w" zu verwenden - dann faßt der Client solche Einträge/Accounts nämlich gar nicht mehr an, solange sich nichts ändert ... manchmal möchte man aber eine "regelmäßige Bestätigung", daß das schon noch die richtige Box ist hinter der DynDNS-Adresse, auch nach drei Tagen (meine Einstellung oben). Allerdings hängt diese Einstellung eben wieder am "provider"-Eintrag und damit gibt es da nur einen gemeinsamen Wert, wenn man gleichzeitig noch HTTPS verwenden will.

Daher benutze ich die gezeigten "provider"-Einträge auch i.d.R. nur zum Test und verwende ansonsten auf Produktiv-Boxen eher HTTPS mit einem "benutzerdefiniert"-Eintrag, weil der DynDNS-Client per se schon "basic auth" verwendet und daher die verwendeten Credentials eigentlich immer (nur mäßig "verschleiert" durch die verwendete Base64-Kodierung) im Klartext durch die Gegend brüllt. Dabei kommt der Server gar nicht mehr dazu, seinerseits "digest auth" anzufordern bzw. der Client interpretiert das dabei dann verwendete "Unauthorized" gleich direkt als systematischen Fehler - das ist also praktisch unbenutzbar nach meinen Tests, wenn man auch nur im Ansatz einen Wert auf Sicherheit legt.

Wenn jemandem bei "benutzerdefiniert" die Aktualisierung zu lange dauern sollte nach einem Neustart, kann man bei "livedelay" die Zeit auch noch herunterdrehen ... die sorgt halt dafür, daß nicht bei jedem Neustart der Box, der ja auch bei "Installationsorgien" deutlich mehr als einmal in kurzen Abständen erfolgen kann, auch der DynDNS-Server aktualisiert wird ... mancher Service hat/hatte auch Beschränkungen, wieviele Updates in einem Zeitintervall erlaubt sind/waren.

Beim "ddnsmode" kann man dann - nach meiner Erfahrung jedenfalls - konfigurieren, ob der Provider IPv4 und IPv6 oder nur eines unterstützt und ob bei DS-Anbindung die Aktualisierung von IPv4- und IPv6-Adressen in einem gemeinsamen Request oder einzeln erfolgen soll ... was aber - bei entsprechend konfigurierter URL - nicht heißt, daß nicht die Infos für das jeweils andere Protokoll auch in dem Request enthalten wären. Hier können dann aber "server" und "ip6server" auch wieder unterschiedliche Ziele adressieren - zumindest in den selbst hinzugefügten "provider"-Einträgen.
 
Zuletzt bearbeitet:
Guten Abend!

Erst einmal vielen lieben Dank für diese sehr ausführliche und dann auch noch schnell erfolgte Antwort! Ich bin begeistert.
3. Da liegst Du richtig ... habe ich irgendwo tatsächlich (dann irrtümlich und ohne daß ich es bemerkt hätte) ein uname -r anstelle des korrekten uname -m (https://pubs.opengroup.org/onlinepubs/9699919799/utilities/uname.html) verwendet in einer Beschreibung? Wenn ja, wüßte ich gerne, wo das war, damit ich es korrigieren kann.

Ich habe hier mal nachgeschaut und gleich in dem Text in grün, mit dem du die ursprünglich verlinkte Anleitung zur Aktivierung von Telnet auf einer 7580 (von meinem ersten Post: Telnet auf 7580-153.06.90-Kombi) beschrieben hast, den Hinweis auf "uname -r" gefunden. Sollte ich das nochmal an einer anderen Stelle sehen, bei meinen Versuchen und der Recherche, dann sage ich dir gerne nochmal Bescheid!

================================================================================================

Und noch ein Hinweis, der Dich aber nicht von der "Installation" eines Shell-Zugangs abhalten soll ... das Einrichten mehr als eines DynDNS-Accounts ist auch möglich, indem man nur die "ar7.cfg" in einer Export-Datei modifiziert und diese - nach Korrektur der Prüfsumme - wieder zurückspielt.

Ich betreibe schon seit Jahren eine solche Konfiguration ... auch mit "selbstdefinierten" zusätzlichen Einträgen in der Liste der Provider. Das geht aber auch mit mehreren "userdefined"-Einträgen und ist - wenn der DynDNS-Provider auch HTTPS-Requests unterstützt - auch die bessere Wahl, weil HTTPS in den selbstdefinierten Einträgen (wo nur der Servername und nicht die URL konfiguriert wird) nicht unterstützt wird.

Jetzt habe ich beim Wahn, unbedingt Telnet aktivieren zu wollen, doch glatt vergessen, dass ich, wenn ich schon eine modifizierte Firmware erstelle, auch gleich die DynDNS-Einträge in der modifizierten Variante hinterlegen kann und daher gar kein Telnet mehr brauche (richtig?). Vor allem, wenn das ein Sicherheitsrisiko darstellt. Wenn ich die Einträge dann aber nochmal ändern möchte, muss ich dann immer wieder eine Firmware erstellen oder sollte ich genau dafür den Shellzugriff auf die FritzBox einrichten? Das würde mich nochmal interessieren. Wenn ich den Shellzugriff nach wie vor brauche, dann mache ich wie in der Anleitung weiter, nur dass ich kein Telnet danach aktiviere?

Wenn ich mal ein Binary prüfen müsste, wie wäre da dann der gangbare Weg? Ich habe da ja offenbar sowieso etwas verkehrt gemacht bei dem Versuch, unabhängig davon, dass ich das eigentlich gar nicht brauche...^^

Ich mache auf jeden Fall mit deinen super Infos weiter. Kann sein, dass ich da nochmal eine Frage dazu habe. Dann melde ich mich auf jeden Fall sowieso nochmal in diesem Thread!

VG,
fly!

EDIT: Rechtschreibkorrekturen für bessere Lesbarkeit.
 
Zuletzt bearbeitet:
FB-Editor könnte ein probates Werkzeug sein für Dein Vorhaben ;) falls damit die gewünschten Zusätze/Veränderungen "erschlagbar" sind.
LG
 
Prüfen, für welche Plattform ein Binary gedacht ist: file <dateiname>
Prüfen, ob alle notwendigen Bibliotheken vorhanden sind (bei dynamisch gelinkten Binaries): ldd <dateiname>

Klarstellung: Es braucht GAR KEINE modifizierte Firmware für die geplanten Änderungen, die bisher beschrieben wurden ... die "DynDNS-Provider" stehen ebenfalls direkt in der "ar7.cfg" und diese hat mit der installierten Firmware (egal ob modifiziert oder nicht) nichts zu tun. Das sind "reine Einstellungen", die man dann auch - wie geschrieben - über deren Export mit nachfolgendem Import (nach dem Editieren) ändern kann, wenn man nach dem Editieren noch das "Dateiformat" korrigiert ... hier eine Prüfsumme am Ende der Datei ersetzen läßt, wofür es mehrere Werkzeuge gibt. Dafür muß man also gar keine eigene Firmware erstellen, weder mit noch ohne Telnet-Zugang. Aber wie geschrieben ... das muß Dich nicht davon abhalten, das weiterhin zu probieren mit dem Shell-Zugang und sei es nur, um das Prinzip zu verstehen/zu trainieren.

Den falschen Aufruf an der von Dir beschriebenen Stelle (witzig ... ich schreibe ja zu dem "-r" auch noch, daß es die "Plattform" (also die Hardware, auf der das läuft) sein soll) habe ich korrigiert ... den hatte ich ohnehin erst vor kurzem hinzugefügt, nachdem wieder mal Unklarheiten aufkamen bzw. jemand die ganz alten Kommandos und Beispiele zu wörtlich genommen hat und darin eher ein Rezept als eine Prinzipbeschreibung sah - ich weiß aber inzwischen schon längst nicht mehr, was/wer/wo das war, es könnte aber tatsächlich mit #20 in diesem Thread im Zusammenhang stehen.

EDIT: Wenn ich den Text hier: https://www.ip-phone-forum.de/threa...ht-auch-für-7560-und-7590.296678/post-2239701 (also den in rot, wo es um die Frage "x86 mit 32-Bit-Support" geht) noch einmal lese, war das damals halt tatsächlich nur ein 32-Bit-Binary für die Intel-/AMD-Architektur und eines für MIPS. Das hat sich ebenfalls geändert (siehe EDIT2 weiter oben) und damit kann man die Frage des 32-Bit-Supports auch als "überlebt" abhaken. Aus dem dort noch benutzten "x86" ist dann halt (im Zuge der zusätzlichen Verzeichnisebene auf der Basis von uname -m - jetzt aber richtig) ein "i686" geworden, weil das der standardisierte Name dieser Plattform ist.
 
Zuletzt bearbeitet:
FB-Editor könnte ein probates Werkzeug sein für Dein Vorhaben ;) falls damit die gewünschten Zusätze/Veränderungen "erschlagbar" sind.
LG

Moin Micha,

der FB-Editor sagt mir jetzt gar nichts. Ist das ein eigens Windows- oder Linux-Programm? Ich kann die normale Konfigrationsdatei, die ich mir als Sicherung der Einstellung in der FritzBox exportieren kann, ja auch in Windows mit dem ganze einfachen Editor öffnen und bearbeiten.

VG,
fly

-- Zusammenführung Doppelpost by stoney

Prüfen, für welche Plattform ein Binary gedacht ist: file <dateiname>
Prüfen, ob alle notwendigen Bibliotheken vorhanden sind (bei dynamisch gelinkten Binaries): ldd <dateiname>

Klarstellung: Es braucht GAR KEINE modifizierte Firmware für die geplanten Änderungen, die bisher beschrieben wurden ... die "DynDNS-Provider" stehen ebenfalls direkt in der "ar7.cfg" und diese hat mit der installierten Firmware (egal ob modifiziert oder nicht) nichts zu tun. Das sind "reine Einstellungen", die man dann auch - wie geschrieben - über deren Export mit nachfolgendem Import (nach dem Editieren) ändern kann, wenn man nach dem Editieren noch das "Dateiformat" korrigiert ... hier eine Prüfsumme am Ende der Datei ersetzen läßt, wofür es mehrere Werkzeuge gibt. Dafür muß man also gar keine eigene Firmware erstellen, weder mit noch ohne Telnet-Zugang. Aber wie geschrieben ... das muß Dich nicht davon abhalten, das weiterhin zu probieren mit dem Shell-Zugang und sei es nur, um das Prinzip zu verstehen/zu trainieren.

Ok, das hört sich schon mal sehr gut an. Ich lerne wie gesagt gerade erst richtig viel zu Linux und Co., habe mir kürzlich meine erste (Next)Cloud auf einem Raspi aufgesetzt und daher auch schon mit sudo, Benutzerrechten und Co. auf einem Linux-Debian Fork von Raspberry "herumgespielt". Ich hatte mir sicherheitshalber schon die Sicherungsdatei für die Einstellungen exportiert. Nur nochmal dür Dummies: Die Datei hat eine .export-Endung und ich sehe auch nicht in den Metadaten unter Windows, dass dies eine "ar7.cfg" (steht offenbar für configuration file?!) ist. Gleich mal mit dem normalen Editor geöffnet und dann auch den Bereich gefunden, den du per Code-Snipet in deinem vorletztem Post schon gepostet hast.

Damit ich das auf jeden Fall schon vor einer neuen Firmware mit Shell testen kann:

  • "Dateiformat" korrigieren => .export-Endung der Export-Datei (über die Weboberfläche der FB generiert) mit ? (= .cfg??) ersetzen?
  • Ich soll eine Prüfsumme ersetzen. Damit ich das auch machen kann, wäre es total super, wenn du einen Tipp für ein Tool oder eine Seite hättest, wo ich das gut nachlesen kann, wie das funktioniert.

Den falschen Aufruf an der von Dir beschriebenen Stelle (witzig ... ich schreibe ja zu dem "-r" auch noch, daß es die "Plattform" (also die Hardware, auf der das läuft) sein soll) habe ich korrigiert ... den hatte ich ohnehin erst vor kurzem hinzugefügt, nachdem wieder mal Unklarheiten aufkamen bzw. jemand die ganz alten Kommandos und Beispiele zu wörtlich genommen hat und darin eher ein Rezept als eine Prinzipbeschreibung sah - ich weiß aber inzwischen schon längst nicht mehr, was/wer/wo das war, es könnte aber tatsächlich mit #20 in diesem Thread im Zusammenhang stehen.

Das ist aber auch gar nicht so ohne, dass nicht sprichwörtlich zu nehmen, wenn man noch nicht so erfahren ist und noch nicht so viel mit Konsole oder Linux Distro gearbeitet hat. Inzwischen kann man ja sogar aus der WSL heraus einen Windows Explorer (in der geöffneten Kommando-Zeile "explorer.exe ." eintippen) von der WSL Distro öffnen und dann ziemlich angenehm durch die Verzeichnisse klicken, wenn man nicht gerade eh GIT auf hat und das Verzeichnis schon kopiert hat.

EDIT: Wenn ich den Text hier: https://www.ip-phone-forum.de/threads/fritz-box-7580-firmware-153-06-90-telnet-service-freischalten-geht-auch-für-7560-und-7590.296678/post-2239701 (also den in rot, wo es um die Frage "x86 mit 32-Bit-Support" geht) noch einmal lese, war das damals halt tatsächlich nur ein 32-Bit-Binary für die Intel-/AMD-Architektur und eines für MIPS. Das hat sich ebenfalls geändert (siehe EDIT2 weiter oben) und damit kann man die Frage des 32-Bit-Supports auch als "überlebt" abhaken. Aus dem dort noch benutzten "x86" ist dann halt (im Zuge der zusätzlichen Verzeichnisebene auf der Basis von uname -m - jetzt aber richtig) ein "i686" geworden, weil das der standardisierte Name dieser Plattform ist.

Heißt also, dass in ich in meinem Fall (WSL Debian Distro unter Windows 10 Home Premium 64bit) für das Entpacken die im Verzeichnis YourFritz/bin/squashfs/x86_64/ die unsquashfsf-be oder unsquashfsf-le nehmen kann, beim einpacken dann aber auf die richtige Endung achten muss. Bisher weiß ich noch nicht, welche das bei mir ist.
 
Zuletzt bearbeitet von einem Moderator:
Ja, wie ich schrieb: Beim Scannen eines SquashFS-Images verstehen die Versionen für SquashFS 4 beide Endianess-Varianten und zeigen das entsprechend an in der Ausgabe.

Damit kann man also auch leicht selbst ermitteln, welches Format für die Endianess (und welche Version des SquashFS-Formats) das eigene Modell benutzt und welches Programm man damit zum Einpacken verwenden müßte.

Bei einem BE-Format sieht das bei Verwendung des "unsquashfs4-be -k -s <image>" dann in etwa so aus (ohne die Hervorhebungen):
Rich (BBCode):
vidar:/home/GitHub/YourFritz $ tar -x -f /home/FritzBox/FB7590/FRITZ.Box_7590-07.19-74611-LabBETA.image -C /tmp -O ./var/tmp/filesystem.image >/tmp/fs.avm
vidar:/home/GitHub/YourFritz $ bin/squashfs/x86_64/unsquashfs4-be -k -s /tmp/fs.avm
Found a valid superblock at offset 0x00000000 while scanning /tmp/fs.avm.
Found TI checksum (0xB15144FE) at the end of the image.
Found a valid big endian SQUASHFS 4:0 superblock on /tmp/fs.avm.
Creation or last append time is not available because of modified AVM-format (mkfs_time == bytes_used)
Filesystem size 25259.20 Kbytes (24.67 Mbytes)
Compression xz
Block size 65536
Filesystem is exportable via NFS
Inodes are compressed
Data is compressed
Fragments are compressed
Always-use-fragments option is not specified
Xattrs are not stored
Duplicates are removed
Number of fragments 382
Number of inodes 8038
Number of ids 1
vidar:/home/GitHub/YourFritz $ bin/squashfs/x86_64/unsquashfs4-le -k -s /tmp/fs.avm
Unable to find something looking like a SquashFS superblock in /tmp/fs.avm.
vidar:/home/GitHub/YourFritz $ bin/squashfs/x86_64/unsquashfs4-le -s /tmp/fs.avm
Found TI checksum (0xB15144FE) at the end of the image.
Reading a different endian SQUASHFS filesystem on /tmp/fs.avm
Filesystem on /tmp/fs.avm is (4:0), which is a later filesystem version than I support!
vidar:/home/GitHub/YourFritz $

EDIT: Beispiel getauscht - das hier braucht auch noch kein "sudo", weil nichts wirklich entpackt wird. Warum das bei "-s" für "different endian" schiefgeht, wenn gleichzeitig "-k" angegeben ist, muß ich bei Gelegenheit mal erkunden ... ich bin ja irgendwann (bei den von mir "veröffentlichten" Versionen) mal von den eigenen Patches auf die Benutzung der Patches aus den Freetz-Tools umgestiegen und da klappt diese Kombination offenbar nicht - da ist dann bei der Übernahme der Patches nach Freetz offenbar doch etwas (Entscheidendes) anders/verändert worden.

================================================================

Es gibt mehrere Möglichkeiten, die Prüfsumme am Ende der Export-Datei zu korrigieren (das ist die Zeile, die mit "END OF EXPORT" beginnt), nachdem man darin Änderungen vorgenommen hat - ich persönlich verwende dazu mein Programm, das auch die in der Export-Datei enthaltenen, verschlüsselten Daten in Klartext "übersetzen" kann: https://github.com/PeterPawn/decoder

Das dort enthaltene Applet (Unterkommando) "checksum" berechnet auch die Prüfsumme neu und tauscht die vorhandene (mit den richtigen Optionen aufgerufen und das Programm selbst und jedes Applet hat auch einen Hilfebildschirm (--help), in dem das erklärt wird) in der Ausgabedatei gegen die neu berechnete aus, wenn diese nicht übereinstimmen.

Die Export-Datei muß man natürlich nicht umbenennen ... wenn man mal einen Blick dort hinein riskiert, sieht man auch, daß die nichts weiter als eine Abfolge von verschiedenen Konfigurationsdateien ist (eine davon ist auch die "ar7.cfg", deshalb ist der von mir gezeigte "ddns"-Abschnitt da auch zu finden), die eigentlich nur zwei Formate verwenden.

Die kann man sich - wenn man will - mit dem "decoder"-Projekt auch in einzelne Dateien zerlegen lassen (das Applet dazu heißt "split_export"), wenn das mit der gesamten Datei zum Nachlesen und Verstehen zuviel ist. Allerdings gibt es (bisher) noch kein Applet, was aus den einzelnen Dateien wieder eine "export"-Datei macht ... das wäre immer noch Handarbeit und da kann man dann auch gleich in der kompletten Datei (also ohne diese Zerlegung) editieren, bevor man sie dann durch "checksum" jagt.

In dem "decoder"-Repo finden sich im "bin"-Ordner auch direkt die fertig kompilierten Versionen für x64 (mittlerweile auch eine, die das neue Format ab 07.19 versteht), wobei es auch kein Kunststück ist, sich die selbst zu übersetzen, wenn das eigene System nur die notwendigen Tools (gcc, C-Library) bereithält - ist alles ausführlich im Repo dokumentiert.
 
Zuletzt bearbeitet:
der FB-Editor sagt mir jetzt gar nichts.
Hier https://www.ip-phone-forum.de/threads/fbeditor-braucht-man-den-denn-Überhaupt-noch.275634/ wirst Du fündig. (0.7.05/06-Version läuft ordentlich). Decoden kann er nicht, aber die checksum berechnen.
Generell sollte man statt auf Windowseditoren besser auf Linuxkompatible wie notepad++ hinweisen bei der Bearbeitung einer *.export-Datei.
Was es mit diesem Hinweis
...mittlerweile auch eine, die das neue Format ab 07.19 versteht..
aufsich hat, kann ich nicht beurteilen (da nicht zuhause und zum ersten Mal davon lese).

Die yf-Tools sind sicherlich umfangreicher (gerade in Bezug auf das decoden in der export) und ich möchte Deine beachtliche hier gezeigte Lernkurve nicht behindern ;) ... nur mag nicht jede/r für kleine+schnelle Änderungen gleich das große Besteck auspacken.
LG
 
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.