telnet/ssh Zugang auf FB 7390/7590 über UART Konsole einrichten

[noomad]

Hallo,
bis gestern habe ich eine FB 7390 im Einsatz gehabt, die anfangs noch den Telnet Zugang ermöglichte.
Hier im Forum habe ich einen Beitrag gelesen, der über Umwege einen Telnet Zugang zulässt und dadurch Licht am Horizont gesehen.
Seit gestern habe ich eine FB 7590. Der alten FB 7390 habe ich ein paar Pins eingelötet und verfüge nun über einen UART Zugriff auf die Serielle Konsole. Serielle Konsole ist ja schön und gut. Aber ich möchte gern über WLAN auf die Kisten zugreifen. Kann mir jemand sagen was ich für die dauerhafte Aktivierung von telnetd oder besser sshd machen muss wenn ich über einen Konsolenzugang verfüge?

Kannst du mir weiterhelfen?

 

[koyaanisqatsi]

Moin

Auf der seriellen Konsole kannste doch Kommandos ausführen, oder nicht ?
...also auch den telnetd starten.
...oder mit wget nen dropbear nach /var/tmp laden und starten.
...oder, oder, oder.

 

[noomad]

nach einem reboot ist bisher alles weg was ich versucht habe. Die Ideallösung wäre so wie früher via Anruf telnet freischalten und wieder ausschalten. Der Konsolenzugang ist nur Mittel zum Zweck. Ich möchte ja nichte jedesmal das Notebook daneben stellen und die Box aufschrauben oder Kabel zusammen fummeln.

 

[noomad]

bei dem Aufruf von dropbear aus dem Verzeichnis /var erhalte ich die Fehlermeldung:

# ./cfg_dropbear -v install
total used free shared buffers
Mem: 107068 91064 16004 0 11064
-/+ buffers: 80000 27068
Swap: 16376 0 16376
installing dropbear (http://www.spblinux.de/fbox/26) ...
Executing: _fct wgetx@http://www.spblinux.de/fbox/26:/var:freeramdisk:rd.ko
Executing: _fct wgetx@http://www.spblinux.de/fbox:/var:cfg.customize
Executing: _fct rdsk@start
insmod: can't insert '/var/rd.ko': invalid module format
rdsk: failed to load ramdisk kernel module

Hat noch wer einen Tipp für mich? Auf der 7390 läuft die Original 6.83.

 

[PeterPawn]

Bau Dir eine aktuelle Version des "dropbear" ... die Software, die Du da gerade verwenden willst, hat fast 10 Jahre auf dem Buckel.

Dafür kann man problemlos die Freetz-Toolchain verwenden und dort findet man dann auch gleich die Unterstützung für das Modifizieren der AVM-Firmware, um solche eigenen Änderungen persistent auszuführen (von Beginn an).

Auf diesem Weg kann man sowohl die 7390 als auch die 7590 mit einem Shell-Zugang versehen - das Löten mag zwar Vergnügen bereiten (und ist bei der Fehlersuche nach Änderungen am Kernel sicherlich auch sehr hilfreich), aber für einen Shell-Zugang ist es absolut unnötig ... erst recht dann, wenn man es nur als "Initialzündung" für einen Shell-Zugang benutzen will.

 

[Andre]

Wenn die Telnet-Konsole nur Mittel zum Zweck ist: Zu welchem Zweck denn?
Heute kann man doch fast alle Funktionen und Konfigurationen via TR-64 ansprechen. Ich habe mir früher auch nicht vorstellen können, auf Telnet (oder SSH) zu verzichten; inzwischen komme ich ganz gut ohne aus.

Modifizieren der Firmware hat den Nachteil, dass freetz den Firmwareupdates immer etwas hinterher hinkt. An die serielle Konsole kann man doch einen Arduino oder ähnliches anschließen. Z.B. eine NodeMCU (3,20€ mit Versand aus China). Damit könntest Du die serielle Schnittstelle im Netz verfügbar machen - oder beim Neustart automatisch telnet starten lassen (der Mikrocontroller sendet einfach die Eingaben, die Du ansonsten per Hand eingeben würdest)

 

[PeterPawn]

Heutzutage muß man nicht mehr automatisch auch die "Freetz"-Mods nutzen, wenn der Begriff "Freetz" ins Spiel kommt. Man kann praktisch jede AVM-Firmware direkt vor dem (oder sogar beim) Update erst modifizieren, da gibt es also kein "Hinterherhinken".

Ich stelle mal die These auf, daß dem größten Teil der Interessenten an einem Shell-Zugang zu einer FRITZ!Box rein softwarebasierte Lösungen (solange sie für den angestrebten Einsatzzweck dasselbe Ergebnis liefern - daß man mit einem erst im Init-Verlauf gestarteten Shell-Service keinen Kernel debuggen kann, versteht sich von selbst) näher liegen als Erweiterungen der Hardware.

Bei Verwendung einer NodeMCU hätte man m.E. auch entweder ein Henne/Ei-Problem (wenn man "wifi" im "sta"-Mode betreibt und das WLAN der FRITZ!Box nutzen will) oder der Benutzer muß sich (relativ zügig, wenn man die Versorgung von NodeMCU und FRITZ!Box aus einer Spannungsquelle unterstellt und man den (ersten) Bootvorgang auf der Seriellen sehen will) mit dem von der NodeMCU bereitgestellten AP (bei "wifi" im "ap"-Mode) verbinden.

Ich finde die kleinen IoT-Boards auch faszinierend ... aber für den Shell-Zugang zu einer FRITZ!Box (und leider gibt es eben nicht alles auf den TR-064-Schnittstellen, das geht z.B. beim "on/off" für das Gäste-WLAN los, soweit ich weiß) würde ich so etwas jetzt nicht als allererste Wahl ansehen. Aber als (programmierbarer) "Tastendrücker" für die Fernkonfiguration ist das wirklich eine spannende Lösung - allerdings in der Regel auch mit Hardware-Basteleien verbunden (die nicht jedem liegen, schon gar nicht bei einer "brandneuen" Box wie der 7590).

 

[Andre]

Hinterherhinken gibts spätestens beim nächsten Kernel...

Alles kann man noch nicht per TR64 schalten, das ist richtig. Bevor man aber auf Teufel komm raus versucht, Telnet zu aktivieren, sollte man schon prüfen, wofür man das braucht und ob es nicht Alternativen gibt. Sicherheitstechnisch ist telnet ja nicht gan ohne, es gibt einen Grund, warum es nicht mehr normal aktivierbar ist. DenGastzugang kann man meiner Erinnerung nach über die AVM-Mobilteile schalten, ebenso WLAN. Auch über BoxToGo Pro von außerhalb ist das schaltbar. Telnet scheint mir also dafür nicht zwingend.

Das Henne/Ei-Problem betrifft letztlich nur den Bootvorgang oder wenn WLAN aus ist. Da es hier um Dinge geht, die sonst per Telnet (also bei gebooteter Box) gemacht werden, ist letztlich nur die Frage, ob WLAN geschaltet werden soll. Wenn ja: Arduino mit LAN nehmen, nicht WLAN...

Die serielle Konsole muss man nicht anlöten. Dafür gibts Pogo-Pins, das ist völlig reversibel.

Insgesamt bin ich lange Zeit Nutzer von Freetz gewesesen; vorher schon vom dsmod. Bei den älteren Boxen nutze ich es auch noch gerne. Bei den aktuellen habe ich da deutlich weniger Bedarf - ein Grund sind schlicht einerseits Raspberrys und Konsorten, die es nicht mehr erforderlich machen, alle möglichen Extras direkt auf der Box laufen zu lassen, andererseits die Schnittstellen (TR64 und Callmonitor), die viele Eingriffe auf Kommandozeile oder in Form von Firmwareänderungen überflüssig machen. Ergänzend noch der FBEditor, um ar7 und voip.conf zu editieren. Da bleibt für weitere Anpassungen der Box bei mir wenig Bedarf.

Auf Knopfdruck Konfigurationen schalten per NodeMCU geht bei aktivem WLAN ohne Basteleingriffe in die Box (eben Dank TR64). Ich habe mir da bisher Rundruf (alle Telephone klingeln auf Tastendruck - z.B. Türklingel) und das Ein-/Ausschalten einer DECT200 realisiert. Genauso ginge das Schalten von Rufumleitungen, AB on/off usw. Die einzige Hardwarebastelei: Taste(n) und LEDs an NodeMCU anschließen.

Natürlich gibt es immer noch Dinge, die gehen nur von der Konsole aus: Fritzbox-Name mit Punkten drin oder ISDN- und Analogeingang gleichzeitig (bei 7490 nicht möglich, aber bei 7390 via Telnet einzurichten und funktionsfähig). Das ist aber eher 'Einmalig einrichten" und benötigt keinen ständig bereiten Zugang.

 

[PeterPawn]

Teile kann ich "unterschreiben" ... aber

Hinterherhinken gibts spätestens beim nächsten Kernel...

eben nicht. Das impliziert ja, daß für jede Anpassung der Firmware von AVM an die eigenen Bedürfnisse (das geht ja bis zu Änderungen im GUI und die macht man dann nicht mehr per TR-064) ein Ersetzen des Kernels notwendig wäre und das ist nun mal falsch.

Ich schreibe/schrieb auch absichtlich immer von "Shell-Zugang" (oder Shell-Service) und (wenn ich mich nicht vertan habe) nie von "Telnet-Zugang". Es gibt genug Alternativen, wie man so einen Shell-Zugriff auch auf einem sicher(er)en Weg realisieren kann, von "Shell in a Box" bis zum SSH-Server (den hier @noomad ja offenbar auch verwenden will).

Die serielle Konsole muss man nicht anlöten. Dafür gibts Pogo-Pins, das ist völlig reversibel.

Aber auch das wird bei geschlossenem Gehäuse zur Herausforderung und schon das "Disassemblieren" eines solchen Gerätes stellt - so jedenfalls meine Erfahrungen im Umkreis - eine Hürde dar, die von den Leuten ganz allgemein seltener "genommen" wird als eine einfache Änderung von Software (letztere wäre nicht einmal bei einem "fremden" Gerät ein Problem, solange sie reversibel ist).

Ich breche hier also auch nicht unbedingt eine Lanze für einen Telnet-Zugang zu einer FRITZ!Box (und es gibt auch tatsächlich genug andere Wege als direkt auf einer Box ausgeführte Kommnandos für bestimmte Intentionen), aber es gibt nach wie vor noch genug Bedarf für eigene Änderungen am FRITZ!OS ... alles weit jenseits von den Möglichkeiten, die einem (derzeit) TR-064 bietet.

Warum reagiere ich hier so vehement? Ich will einfach verhindern, daß irgendwie der Eindruck entsteht, man könne tatsächlich alles auch per TR-064 machen.

Das Einschalten des Gast-WLANs war meinerseits nur als ein (Gegen-)Beispiel gedacht (und eine Funktion der Box, die m.W. keine flankierende TR-064-Funktion hat - nur die Abfrage über "X_AVM-DE_GetWLANExtInfo" kenne ich an dieser Stelle) und wenn das von BoxToGo unterstützt wird, muß das - meines Wissens jedenfalls, welches ich gerne erweitere, wenn ich falsch liegen sollte - über eine Browser-Emulation (bzw. über passende HTTP-Requests für das GUI - und nicht über die Benutzung einer TR-064-Funktion) erfolgen.

Auch die Tatsache, daß man irgendwelche WLAN-Funktionen über ein AVM-DECT-MT (de-)aktivieren kann, bringt in diesem Zusammenhang keinen nennenswerten Vorteil ... es soll tatsächlich noch FRITZ!Box-Besitzer geben, die sich keine FRITZ!Fon-MTs zugelegt haben. Gerade für Deine ganzen Ideen und Vorschläge mit den "WLAN-Buttons" auf Arduino-Basis (einer davon könnte ja auch das Gäste-WLAN für die nächsten 30 Minuten aktivieren) braucht es eben auch die passenden Schnittstellen ... und die kann man dann problemlos (auf der LAN-Seite) einer FRITZ!Box selbst nachrüsten, wenn sie fehlen. Aber selbst dazu braucht man die Modifikation der Firmware - allerdings (zugegebenermaßen und nach Abschluß der "Entwicklung") nicht unbedingt einen Shell-Zugang.

Die Möglichkeit, das FRITZ!OS damit auch weiterhin an die eigenen Vorstellungen anzupassen (mit entsprechenden Tools oder eigenen Kenntnissen), bleibt das Entscheidende ... erweckt man hier den Eindruck, es ginge alles auch "irgendwie anders", dann wäre in der Konsequenz diese Möglichkeit/Notwendigkeit obsolet - das ist ein "Eindruck", den ich in jedem Falle vermeiden möchte.

 

[Andre]

Die Überschrift beinhaltet aber eben auch Telnet. Bevor man dies nutzt, sollte man alle Alternativen geprüft haben.
Gegen ssh mit Authorisierung über Schlüssel habe ich nichts; allerdings setzen viele eher die Anmeldung über Nutzer/Passwort ein.
Für mich stellt sich daher immer die Frage: Kann ich zunächst eine vorhandene Funktion nutzen, oder muss ich ins System eingreifen?

Was Kernelwechsel angeht, so impliziert das keineswegs, dass das bei jedem Firmwareupdate passiert. Im Gegenteil, sie sind selten - alle paar Jahre. Wenn einer passiert, hat man aber schnell das Problem, dass Erweiterungen nicht mehr laufen. Das ist ein Argument dafür, erst die offiziellen Funktionen auszuschöpfen.

Also kurz:
1. prüfen, obs per TR-064 geht
2. prüfen, obs per lua geht
3. wenn beides nicht geht: ssh mit Authorisierung über asymmetrische Schlüssel verwenden oder serielle Konsole verbinden.

Ich bin vehement dagegen, zuerst die Firmwaremodifikation zu probieren, auch wenn man sie nicht braucht. Das hat nichts damit zu tun, dass ich grundsätzlich die Möglichkeit, Firmware anzupassen, als notwendig ansehe. Bei EOS-Boxen wie 7170, 7270, die im heimischen Netz betrieben werden setze ich gerne freetz ein. Auf Boxen, die direkt an der DSL-Leitung hängen, tue ich das eher nicht.

 

[PeterPawn]

Ja, das hast Du richtig festgestellt ... die Überschrift beinhaltet auch "telnet". Aber schon danach geht es dem Fragesteller in #4 ja ganz eindeutig um die Installation von "dropbear" und davor findet sich die Frage, wie man den Start so eines Services persistent im System verankert (das ist - wenn auch grob - die Zusammenfassung von #1 bis #4).

Die "Abschwächung" Deiner Meinung bzgl. Freetz (es kann passieren, ist aber eher selten - zumindest beim Wechsel des Kernels, der nur alle Jubeljahre mal passiert) verträgt sich in meinen Augen zwar nicht mit der zuvor getätigten Aussage:

Modifizieren der Firmware hat den Nachteil, dass freetz den Firmwareupdates immer etwas hinterher hinkt.

(Hervorhebung durch mich), aber das müssen wir auch nicht unbedingt vertiefen.

Wenn das Hinterherhinken nur "alle paar Jahre" auftritt, kann man es sicherlich in den Skat drücken. Es gibt - gerade bei den "embedded devices" - auch genug andere Hürden, die sich vor jemandem auftürmen können, der seinerseits über die serielle Schnittstelle einen Zugriff auf eine FRITZ!Box erlangen will ... bei einem Puma6-Prozessor scheitert das (meines Erachtens/Wissens) schon an einem einzelnen Bit auf einem Port, über den die serielle Konsole wohl verriegelt wird (die genaue Stelle müßte ich erst wieder raussuchen, war irgendwo beim "setup" des Kernels).

Den echten Vorteil einer Authentifizierung über SSH-Keys ggü. einer Anmeldung mit Benutzername und Kennwort verstehe ich zwar per se ... aber hier im Zusammenhang mit der FRITZ!Box finde ich das alles andere als einleuchtend, wie Du argumentierst. Eine - über eine bereits gesicherte Verbindung erfolgende - Authentifizierung über Benutzername und Kennwort hat in meinen Augen keinerlei Sicherheitsmanko ggü. einer TR-064-Authentifizierung innerhalb einer TLS-Verbindung zum "upnpd". Wenn ich da irgendetwas Entscheidendes übersehen sollte (wir diskutieren aber bitte nicht über SSH1, sondern nur über den "Stand der Technik" und da gehört SSH1 schon lange nicht mehr dazu), lasse ich mir das gerne erklären.

Gerade unter dem "Sicherheitsaspekt" ist dann aber auch ein Arduino für die serielle Schnittstelle, der seinerseits irgendwo "im Netz" hängt, noch einmal eine ganz andere Nummer. Hier hast Du zumindest vergessen zu erwähnen, daß dann der Arduino für die komplette Sicherheit verantwortlich zeichnet und sich um Verschlüsselung (sonst ist das kaum besser als "telnet") und Authentifizierung selbst kümmern muß. Auf der Box wird nämlich für die serielle Schnittstelle in der Regel nur eine ganz normale Shell (ohne jede Notwendigkeit einer Anmeldung) gestartet (über "askfirst", also mit einmal zusätzlichem "Enter") und so etwas sollte man nun erst recht nicht ungeschützt in das eigene Netz hängen.

Und auch meinerseits noch einmal ... es braucht tatsächlich nicht für jedes Problem einen Shell-Zugang zu einem Gerät mit FRITZ!OS (da rennt man bei mir ja nun wirklich sperrangelweit offen stehende Scheunentore ein), aber es geht lange nicht alles ohne einen solchen Zugang (z.B. erst recht nicht die Entwicklung neuer Software/Lösungen). Solange sich eine passende Schnittstelle für das Lösen der eigenen Probleme findet (und da gehört auch für mich nur TR-064 dazu und schon bei Requests für das "normale GUI" habe ich Vorbehalte - weil das eben im Gegensatz zu TR-064 nicht stabil ist), sollte man logischerweise diese benutzen.

Aber hier war eigentlich gar keine konkrete Anwendung für irgendwelche Modifikationen vom Fragesteller "vorgebracht" ... es ging deutlich um die Frage, wie man den Shell-Zugang erhält und zwar in einer Form, daß der auch nach einem Reboot wieder verfügbar ist.

Auch gehst Du offenbar bei Deiner Argumentation immer davon aus, daß man etwas "extern" zur FRITZ!Box machen will. Das mag zwar in vielen Fällen auch funktionieren (besonders wenn man zusätzliche Funktionen nachrüsten will), aber es gibt durchaus auch Ambitionen, die AVM-Firmware zu "korrigieren" oder auch Funktionen auf der Box selbst nachzurüsten (z.B. eben einen OpenVPN-Service oder auch SSH für einen Tunnel), die man ansonsten auf zusätzlicher Hardware "nachrüsten" müßte.

Nun mag das heutzutage auf einem RasPi (oder anderen Einplatinen-Rechnern, der RasPi ist nun mal außerhalb von "Steuerrechnern" wie dem Arduino der populärste) auch problemlos gehen, aber auch um einen solchen Rechner muß man sich zusätzlich kümmern und mit ~ 50 EUR - für einen 3er mit allem drum und dran - ist das auch eine andere "Hausnummer" bei der Investition. Warum sollte sich der GRX350 einer 7580/7590 eigentlich "langweilen", wenn der problemlos die OpenVPN-Verbindung für das Syncen mit irgendeinem Cloud-Speicher oder die VNC-Verbindung zum heimischen Desktop-PC noch stemmen kann?

Ich bin auch strikt für eine bestmögliche Absicherung der FRITZ!Box für den "normalen Kunden" ... aber wenn jemand weiß, was er will und was er da tut (oder es ihm entsprechende Tools verwehren, da allzuviel Unsinn anzurichten), dann bin ich auch gegen die "Bevormundung" des Besitzers einer FRITZ!Box.

Spätestens bei der Frage, ob man einen - bisher nicht als TR-064-Funktion vorhandenen - Punkt über den Zugriff auf das GUI von AVM oder über einen eigenen Service realisiert, scheiden sich ohnehin die Geister. Du würdest wahrscheinlich für das "scraping" und die HTTP-Requests votieren ... ich hingegen für einen eigenen Service, den man zwar in jedes Firmware-Update erneut "einarbeiten" muß, der aber - je nachdem, wie da die "Verteilung" der Zuständigkeiten und der Umfang der Programmierung aussieht, kann das mehr als lohnend sein - wieder ein stabiles Interface "nach außen" garantieren kann und die Besonderheiten der FRITZ!Box genau da kapseln kann, wo sie existieren ... nämlich auf der Box selbst.

 

[noomad]

Vielen Dank erstmal an PeterPawn und Andre für die interessanten Hinweise.
@PeterPawn
Dem Ansatz dropbear per crosscompiler mit der freetz toolchain selbst zu erstellen bin ich gefolgt.
Die toolchain funktioniert soweit, das Hello World Programm läuft auf der Fritzbox. Aus den unterschiedlichen Quellen habe ich mir die diversen Schritte zusammengesucht. Weil es bestimmt noch andere Technikenthusiasten wie mich gibt, derren Skill-Level noch nicht so hoch sind und die auf der Suche nach dem vollständigen Weg zum erstellen von dropbear sind , führe ich meine Schritte mal auf:

1. Linux (in meinem Fall Ubuntu 17.04) als normaler Benutzer starten (nicht root).

2. In $home umask setzen mit
umask 022

3. Ein paar Pakete installieren die benötigt werden
sudo apt-get install zlib1g-dev libncurses-dev bison libecj-java bison libtool libtool-bin flex

4. Freetz (stable) herunterladen
svn co http://svn.freetz.org/branches/freetz-stable-2.0

5. In das freetz Verzeichnis wechseln
cd freetz-stable-2.0

6. Freetz (Toolchain) konfigurieren
make menuconfig

7. Toolchain bauen und libs bauen
make toolchain
make libs

8. Toolchainpfade setzen
export PATH=/home/sven/freetz-stable-2.0/toolchain/target/bin:$PATH
export CC=/home/sven/freetz-stable-2.0/toolchain/target/bin/mips-linux-uclibc-gcc
export LDFLAGS=-L/home/sven/freetz-stable-2.0/toolchain/target/lib
export CFLAGS=-I/home/sven/freetz-stable-2.0/toolchain/target/include
export CPP=/home/sven/freetz-stable-2.0/toolchain/target/bin/mips-linux-uclibc-cpp
export CROSS_COMPILE=mips-linux-uclibc-
export ARCH=mips-linux

9. Dropbear herunterladen
svn co https://github.com/mkj/dropbear

10. In das dropbear Verzeichnis wechseln
cd dropbear

11. Es fehlt die Datei "configure", erstellen mit
autoconf

12. Es fehlt die Datei "config.h.in", erstellen mit
autoheader

13. Anschließend configure mit diversen Optionen durchlaufen lassen (vorher mal in die Datei INSTALL schauen), in meinem Fall
./configure --target=mipsel-linux --host=mips-linux --disable-zlib --disable-lastlog

14. Danach die benötigten Programme kompilieren (in meinem Fall mit dem Schalter "-j4")
make -j4 PROGRAMS="dropbear dbclient dropbearkey dropbearconvert scp"

15. Die Programme installieren
sudo make PROGRAMS="dropbear dbclient dropbearkey dropbearconvert scp" install

Irgendwo ist der Wurm drin. Er bricht ab mit der Fehlermeldung:

/home/sven/freetz-stable-2.0/toolchain/target/bin/mips-linux-uclibc-gcc -I./libtomcrypt/src/headers/ -I. -I. -I/home/sven/freetz-stable-2.0/toolchain/target/include -fno-strict-overflow -fPIE -fstack-protector --param=ssp-buffer-size=4 -D_FORTIFY_SOURCE=2 -DDROPBEAR_SERVER -DDROPBEAR_CLIENT -c -o dbutil.o dbutil.c
In file included from includes.h:136:0,
from dbutil.c:64:
compat.h:43:7: error: conflicting types for '__xpg_basename'
/home/sven/freetz-stable-2.0/toolchain/build/mips_gcc-4.6.4_uClibc-0.9.32.1/mips-linux-uclibc/bin/../lib/gcc/mips-linux-uclibc/4.6.4/../../../../mips-linux-uclibc/include/libgen.h:35:14: note: previous declaration of '__xpg_basename' was here
<eingebaut>: die Regel für Ziel „dbutil.o“ scheiterte
make: *** [dbutil.o] Fehler 1

Was habe ich falsch gemacht?

 

[PeterPawn]

1. Die "stable-2.0"-Version ist uralt, am besten immer den Trunk nehmen.

2. Es gibt ein komplettes "dropbear"-Paket im Freetz, da braucht man nur noch nach den passenden Einstellungen für das Paket (und einige andere rundherum, wobei man m.W. auch im normalen Freetz schon eine statisch gelinkte Version von "dropbear" erstellen kann) dann sein "make" aufrufen und sich die Dateien in aller Ruhe aus den Ergebnissen zusammensuchen. Je nachdem, wie weit man das "make" automatisiert arbeiten läßt, kann man sich an verschiedenen Stellen bedienen - theoretisch (wenn alle Abhängigkeiten sauber aufgelöst sind) sollte schon ein "make dropbear-precompiled" das gewünschte Ergebnis irgendwo in "target...irgendwas" liefern.

Es gibt auch noch ein paar "dropbear"-Patches für die (ausschließliche) Benutzung auf einer FRITZ!Box ohne Freetz (z.B. für das Verwenden des RSA-Keys aus der Box-Identität als SSH-Host-Key) - die findet man aber ggf. auf GitHub in Forks von Freetz (und an die letzten "dropbear"-Versionen habe ich den auch noch nicht angepaßt).

PS: Momentan scheint "freetz.org" gerade mal wieder nicht zu antworten ... es gibt auch eine Kopie des Trunks im GitHub (auch wenn SVN als Master fungiert).

 

[PeterPawn]

So, freetz.org sollte wieder funktionieren ...

 

[noomad]

Habe mir die für die 7390 angepasste Version mal gezogen. Nach dem make menuconfig funktionierte ein make. Ein anschließendes make toolchain bricht ab.
Hier der output:

~/freetz-devel_r7390$ make toolchain
 downloading...tools/freetz_download dl/fw "fritz_box_fon_wlan_7390_source_files.04.91.tar.gz" "[USER=169279]@AvM[/USER]/fritz.box/fritzbox.fon_wlan_7390/x_misc/opensrc" "2cad066e0e57aa3e58bf784b396ee676"

--2017-07-12 16:09:11--  ftp://ftp.avm.de/fritz.box/fritzbox.fon_wlan_7390/x_misc/opensrc/fritz_box_fon_wlan_7390_source_files.04.91.tar.gz
           => »dl/fw/fritz_box_fon_wlan_7390_source_files.04.91.tar.gz«
Auflösen des Hostnamens »ftp.avm.de (ftp.avm.de)« … 212.42.244.98, 213.61.47.146, 212.42.244.7, ...
Verbindungsaufbau zu ftp.avm.de (ftp.avm.de)|212.42.244.98|:21 … verbunden.
Anmelden als anonymous … Angemeldet!
==> SYST ... fertig.    ==> PWD ... fertig.
==> TYPE I ... fertig.  ==> CWD (1) /fritz.box/fritzbox.fon_wlan_7390/x_misc/opensrc ... fertig.
==> SIZE fritz_box_fon_wlan_7390_source_files.04.91.tar.gz ... fertig.

==> PASV ... fertig.    ==> RETR fritz_box_fon_wlan_7390_source_files.04.91.tar.gz ...
Die Datei »»fritz_box_fon_wlan_7390_source_files.04.91.tar.gz«« existiert nicht.

Download failed - ftp://ftp.avm.de/fritz.box/fritzbox.fon_wlan_7390/x_misc/opensrc/fritz_box_fon_wlan_7390_source_files.04.91.tar.gz  ->  error code 8

--2017-07-12 16:09:11--  http://download.avm.de/fritz.box/fritzbox.fon_wlan_7390/x_misc/opensrc/fritz_box_fon_wlan_7390_source_files.04.91.tar.gz
Auflösen des Hostnamens »download.avm.de (download.avm.de)« … 194.109.20.244, 212.42.224.71, 212.42.244.98, ...
Verbindungsaufbau zu download.avm.de (download.avm.de)|194.109.20.244|:80 … verbunden.
HTTP-Anforderung gesendet, auf Antwort wird gewartet … 404 Not Found
2017-07-12 16:09:11 FEHLER 404: Not Found.

Download failed - http://download.avm.de/fritz.box/fritzbox.fon_wlan_7390/x_misc/opensrc/fritz_box_fon_wlan_7390_source_files.04.91.tar.gz  ->  error code 8

--2017-07-12 16:09:11--  ftp://service.avm.de/fritz.box/fritzbox.fon_wlan_7390/x_misc/opensrc/fritz_box_fon_wlan_7390_source_files.04.91.tar.gz
           => »dl/fw/fritz_box_fon_wlan_7390_source_files.04.91.tar.gz«
Auflösen des Hostnamens »service.avm.de (service.avm.de)« … 212.42.244.81
Verbindungsaufbau zu service.avm.de (service.avm.de)|212.42.244.81|:21 … verbunden.
Anmelden als anonymous …
Der Server verweigert die Anmeldung.
Erneuter Versuch.

--2017-07-12 16:09:13--  ftp://service.avm.de/fritz.box/fritzbox.fon_wlan_7390/x_misc/opensrc/fritz_box_fon_wlan_7390_source_files.04.91.tar.gz
  (Versuch: 2) => »dl/fw/fritz_box_fon_wlan_7390_source_files.04.91.tar.gz«
Verbindungsaufbau zu service.avm.de (service.avm.de)|212.42.244.81|:21 … verbunden.
Anmelden als anonymous …
Der Server verweigert die Anmeldung.
Erneuter Versuch.

--2017-07-12 16:09:16--  ftp://service.avm.de/fritz.box/fritzbox.fon_wlan_7390/x_misc/opensrc/fritz_box_fon_wlan_7390_source_files.04.91.tar.gz
  (Versuch: 3) => »dl/fw/fritz_box_fon_wlan_7390_source_files.04.91.tar.gz«
Verbindungsaufbau zu service.avm.de (service.avm.de)|212.42.244.81|:21 … verbunden.
Anmelden als anonymous …
Der Server verweigert die Anmeldung.
Aufgegeben.

Download failed - ftp://service.avm.de/fritz.box/fritzbox.fon_wlan_7390/x_misc/opensrc/fritz_box_fon_wlan_7390_source_files.04.91.tar.gz  ->  error code 4

--2017-07-12 16:09:17--  http://freetz.magenbrot.net/fritz_box_fon_wlan_7390_source_files.04.91.tar.gz
Auflösen des Hostnamens »freetz.magenbrot.net (freetz.magenbrot.net)« … 31.172.113.113
Verbindungsaufbau zu freetz.magenbrot.net (freetz.magenbrot.net)|31.172.113.113|:80 … verbunden.
HTTP-Anforderung gesendet, auf Antwort wird gewartet … 404 Not Found
2017-07-12 16:09:17 FEHLER 404: Not Found.

Download failed - http://freetz.magenbrot.net/fritz_box_fon_wlan_7390_source_files.04.91.tar.gz  ->  error code 8

--2017-07-12 16:09:17--  http://freetz.3dfxatwork.de/fritz_box_fon_wlan_7390_source_files.04.91.tar.gz
Auflösen des Hostnamens »freetz.3dfxatwork.de (freetz.3dfxatwork.de)« … 31.172.113.113
Verbindungsaufbau zu freetz.3dfxatwork.de (freetz.3dfxatwork.de)|31.172.113.113|:80 … verbunden.
HTTP-Anforderung gesendet, auf Antwort wird gewartet … 404 Not Found
2017-07-12 16:09:18 FEHLER 404: Not Found.

Download failed - http://freetz.3dfxatwork.de/fritz_box_fon_wlan_7390_source_files.04.91.tar.gz  ->  error code 8

--2017-07-12 16:09:18--  http://freetz.wirsind.info/fritz_box_fon_wlan_7390_source_files.04.91.tar.gz
Auflösen des Hostnamens »freetz.wirsind.info (freetz.wirsind.info)« … 188.165.115.52
Verbindungsaufbau zu freetz.wirsind.info (freetz.wirsind.info)|188.165.115.52|:80 … verbunden.
HTTP-Anforderung gesendet, auf Antwort wird gewartet … 404 Not Found
2017-07-12 16:09:18 FEHLER 404: Not Found.

Download failed - http://freetz.wirsind.info/fritz_box_fon_wlan_7390_source_files.04.91.tar.gz  ->  error code 8
make/linux/kernel.mk:19: die Regel für Ziel „dl/fw/fritz_box_fon_wlan_7390_source_files.04.91.tar.gz“ scheiterte
make: *** [dl/fw/fritz_box_fon_wlan_7390_source_files.04.91.tar.gz] Fehler 1

Habs mehrmals probiert. Die Server sind nicht erreichbar oder verweigern die Anmeldung.

Shell Ausgabe in CODE Tag gesetzt - HabNeFritzbox

 

[PeterPawn]

Da stimmt so einiges aber nicht ... warum sollte der Trunk versuchen, die Version 04.91 für die 7390 zu laden?

Das Bauen der Toolchain ist auch so weit automatisiert, daß man es nicht gesondert aufrufen muß. Es gibt sogar die Möglichkeit, die Toolchain gar nicht selbst erstellen zu müssen, sondern eine "pre-built"-Variante davon zu laden (einstellbar im untersten Block, wenn "Experte" ausgewählt ist).

Wenn Du tatsächlich meinen Rat beherzigt und den Entwicklerzweig von Freetz geladen hast, mußt/solltest Du das natürlich in ein neues Verzeichnis machen. Da verstehe ich dann absolut nicht mehr, wie irgendwelche Einstellungen für Uralt-Versionen (hier eben die 04.91, die inzwischen bestimmt 6 Jahre alt ist) das überleben sollten in der ".config".

 

[noomad]

Ich habe es bei freetz.org wie unter http://freetz.org/wiki/common/source_code beschrieben mit

svn co http://svn.freetz.org/trunk freetz-devel_r7390 -r 7390

geholt.
Eine grep Suche nach .04.91 ergab folgendes Ergebnis:

~/freetz-devel_r7390$ grep -r -n .04.91
Config.in:1051:   default "fritz_box_fon_wlan_7390_source_files.04.91.tar.gz"   if   FREETZ_AVM_VERSION_7390_04_90
Config.in:1066:   default "cad33bda041910e2aae01f027465162b"       if   FREETZ_AVM_VERSION_04_87
Config.in:1267:   default "FRITZ.Box_Fon_WLAN_7390.84.04.91.image"       if   FREETZ_TYPE_FON_WLAN_7390 && \
Config.in:1274:   default "FRITZ.Box_Fon_WLAN_7570_vDSL.en-de-fr.75.04.91.image"   if   FREETZ_TYPE_FON_WLAN_7570
.config:384:FREETZ_DL_KERNEL_SOURCE="fritz_box_fon_wlan_7390_source_files.04.91.tar.gz"
.config:387:FREETZ_DL_SOURCE="FRITZ.Box_Fon_WLAN_7390.84.04.91.image"
make/ltrace/patches/100-add-sysdep.patch:3:--- Makefile.in   2009-10-23 22:06:08.130304691 -0700
make/ncftp/ncftp.mk:3:$(PKG)_SOURCE_MD5:=b05c7a6d5269c04891f02f43d4312b30
.svn/pristine/68/6825339ced1024c77903181cd8e02d5d8b67da26.svn-base:3:--- Makefile.in   2009-10-23 22:06:08.130304691 -0700
.svn/pristine/31/3193006c971787d0a44b289641019ffe8bca1efe.svn-base:3:$(PKG)_SOURCE_MD5:=b05c7a6d5269c04891f02f43d4312b30
.svn/pristine/7d/7d41103997df911f1755d2ff496850c5eadfa4a6.svn-base:5: newFWver=04.91
.svn/pristine/7d/7d41103997df911f1755d2ff496850c5eadfa4a6.svn-base:12: # Versioninfo:   75.04.91
.svn/pristine/ff/ffcc9f31e39379ab3ca8f19648cb2fb5cb48b3b0.svn-base:1051:   default "fritz_box_fon_wlan_7390_source_files.04.91.tar.gz"   if   FREETZ_AVM_VERSION_7390_04_90
.svn/pristine/ff/ffcc9f31e39379ab3ca8f19648cb2fb5cb48b3b0.svn-base:1066:   default "cad33bda041910e2aae01f027465162b"       if   FREETZ_AVM_VERSION_04_87
.svn/pristine/ff/ffcc9f31e39379ab3ca8f19648cb2fb5cb48b3b0.svn-base:1267:   default "FRITZ.Box_Fon_WLAN_7390.84.04.91.image"           if   FREETZ_TYPE_FON_WLAN_7390 && \
.svn/pristine/ff/ffcc9f31e39379ab3ca8f19648cb2fb5cb48b3b0.svn-base:1274:   default "FRITZ.Box_Fon_WLAN_7570_vDSL.en-de-fr.75.04.91.image"       if   FREETZ_TYPE_FON_WLAN_7570
.svn/pristine/b1/b1e4cab5f36373d197bf9f6d9a4e528f77ece39c.svn-base:45:* Fritz!Box Fon WLAN 7390: 84.04.91
.svn/pristine/b1/b1e4cab5f36373d197bf9f6d9a4e528f77ece39c.svn-base:48:* Fritz!Box Fon WLAN 7570 (Multi-Language, Annex A/B): 75.04.91
Übereinstimmungen in Binärdatei .svn/wc.db
FIRMWARES:45:* Fritz!Box Fon WLAN 7390: 84.04.91
FIRMWARES:48:* Fritz!Box Fon WLAN 7570 (Multi-Language, Annex A/B): 75.04.91
.config.old:384:FREETZ_DL_KERNEL_SOURCE="fritz_box_fon_wlan_7390_source_files.04.91.tar.gz"
.config.old:387:FREETZ_DL_SOURCE="FRITZ.Box_Fon_WLAN_7390.84.04.91.image"
patches/cond/install-7570_HN.patch:5: newFWver=04.91
patches/cond/install-7570_HN.patch:12: # Versioninfo:   75.04.91

Shell Ausgabe in CODE Tag gesetzt - HabNeFritzbox

 

[eisbaerin]

Da stimmt so einiges aber nicht

Richtig!
Wer schon in #4 versucht MIPSEL Dateien auf einer MIPS Box auszuführen.

Ick wunder mir über jarnischt mehr

 

[noomad]

@eisbaerin ja, den Fehler habe ich erkannt. Hast du auch etwas konstruktives beizutragen? Es gibt ja genügend Beiträge hier in denen bashing betrieben wird. Da können wir hier im thread vielleicht ausnahmsweise mal drauf verzichten. Ich gebe ja zu dass ich soetwas noch nicht oft gemacht habe. Aktuell hängt es bei freetz wie du sicher erkannt hast.

Meine bisher einzige crosscompiler Erfahrung war vorletztes Jahr, als ich für mein Synology DS213 etwas selbstbauen musste. Dank guter Anleitung von der toolchain bis zum Paket welches ich drauf haben wollte hat es beim ersten Versuch funktioniert.

 

[koyaanisqatsi]

Hm, MIPS/MIPSEL, LE/BE, dass ist aber auch verzwickt.


Ach, ich würde es auch nicht selbst kompilieren wollen.
...ich würde erstmal beim @radislav vorbeischauen: http://www.fritzmod.net/de/modification/ssh-sftp/installation/

Was die debug.cfg angeht, dafür brauchste schon freetz und fwmod
https://freetz.org/wiki/help/howtos/development/repack_fw
(Insbesondere: Verwendung von fwmod im "no freetz"-Modus)
Allerdings braucht es eine passende Impffirmware, wegen dem: Signaturproblem