Das ist auch irgendwie blöd - da sind die statisch gelinkten Binaries dann u.U. sogar die bessere Lösung.
Worin denkbare Ursachen liegen, ist schon klar ... aber daß es keine "echte" Exception gibt (und auch keine Fehlermeldungen vom LD), ist eben schon etwas komisch. Auch die Tatsache, daß ältere Versionen mit dynamischer Library-Nutzung (die squashfs3-Utilities in modfs stammen vom 03. Sept. 2014 und stützen sich auf den damals aktuellen Freetz-Trunk, denn das war der erste Vorschlag für diese "target tools" von mir) klaglos funktionieren, macht da einen Unterschied in der uClibc, der sich erst anschließend "eingeschlichen" hat, plausibel. Aber worin er nun wirklich liegt, habe ich nicht getestet ...
Für mich heißt das am Ende nur, daß Du vermutlich mit der Bereitstellung von Freetz für die 06.35 doch wenigstens noch so lange warten mußt (oder eben raten und probieren), bis wenigstens die Kernel- und uClibc-Konfiguration von AVM veröffentlicht wurde oder Du nimmst komplett eigene Libs für die Freetz-Pakete - meines Wissens momentan nicht der Fall oder ich bin wieder mal nicht auf dem Laufenden.
Mal angenommen Freetz würde Binaries ohne RPATH erstellen oder Du würdest ein dynamisch gelinktes Binary von sonst wo bekommen.
Ich meinte tatsächlich einen konfigurierbaren RPATH. Diese eine Variable im Basis-Makefile ist neu für mich ... wenn die über alle Packages auch tatsächlich durchgezogen wurde und nicht mehr direkt "vor Ort" angegeben wird (als ich damit begann, war das m.E. noch so, zumindest partiell), dann ist damit eines meiner Probleme tatsächlich Geschichte, ohne daß ich es bemerkt hätte.
Aber eben auch nur das der Suchreihenfolge nach Libraries ... die diversen anderen "Freetz-Patches", die z.B. die Config-Pfade usw. fest auf /mod/etc/irgendwas festtackern (m.W. ist "dropbear" das einzige Paket, das einen "externen" Einsatz explizit unterstützt und auch da wird dann eben ein Pfad /tmp/irgendwas fest gesetzt, was das Freetz-GUI wieder gar nicht kann), sind weitere Stellen, wo man bei einem "make" für "non-Freetz" eingreifen muß.
Wie gesagt, das ist ja vollkommen legitim und "gutes Recht" von Freetz ... wenn jemand das Build-System "mißbrauchen" will, muß er eben etwas mehr Aufwand treiben.
Aber teilweise würden schon winzige Änderungen (die ich gerne anhand von zwei oder drei Paketen konkret vorschlagen kann als Patch) zu einer erhöhten "Universalität" führen können, z.B. indem man kleine Include-Files in die mk-Files zieht, die im Normalfall nichts ändern (praktisch leer sind oder irgendeine "customized"-Variable setzen/enthalten oder sogar die sinnvoll zu ändernden Variablen als "Freetz-Standard" zusammenfassen), wo aber der Nutzer seine eigenen Einstellungen hinterlegen kann, ohne am mk-File herumdoktern zu müssen.
Dann hat man auch beim "svn update" nicht unbedingt ein "merge problem", denn die eigenen Einstellungen zum Überschreiben der Standards liegen ja dann unabhängig vom mk-File vor und dort ggf. vorgenommene Änderungen (das geht ja bei jedem Version-Bump schon los) führen nicht zu einem Konflikt - wenn so ein Include-File "M" ist, entsteht ja noch nicht automatisch auch ein Merge-Konflikt, solange die Upstream-Variante nicht auch neuer ist.
Und so kann man dann eben auch das "originale Freetz-Buildsystem" benutzen, um sich die ganzen Pakete, die in Binärform durch das Internet schwirren (von Busybox bis Apache mit PHP) und häufig genug bei den Boxen mit NAND-Storage unter /var/media/ftp auch direkt von dort gestartet werden, so zu konfigurieren, daß die Pfade zur eigenen FRITZ!Box passen - läßt man diese "custom configuration" weg, wird eben für Freetz "gebaut". Im Moment ist man jedenfalls ziemlich erschossen, wenn es um solche Fragen wie eine einheitliche Konfiguration der Pfade geht, weil das teilweise über Patch-Files und teilweise über Anweisungen im mk-File gehandhabt wird. Das kann man zwar sicherlich auch in die komplette Konfiguration einbauen (also für "make *config" zusätzliche Punkte daraus machen), aber das wäre dann für mich wieder Overkill, weil das auch nur einmal geändert wird vom Nutzer.
Aber wie weiter oben geschrieben ... wenn es inzwischen tatsächlich diese eine Make-Variable gibt (die man ja dann auch nur für einzelne Pakete gezielt ändern kann während des "make"), mit der man ein eigenes Verzeichnis an die Stelle von /usr/lib/freetz setzen kann, dann schaue ich mir bei den mir wichtigen Paketen demnächst den Inhalt des "make"-Verzeichnisses noch einmal an. Vielleicht kann ich da auch einige sehr alte Patches inzwischen "abschaffen" und durch einfachere Wege ersetzen (zumindest beim Relinken).
Aber wenn ich mir meine Liste der Pakete so ansehe, braucht eigentlich trotzdem jedes Paket mit einkompilierten Pfaden (dropbear ist da nur ein Beispiel und verwendet nicht einmal configure), die normalerweise beim "configure" gesetzt werden, seinen eigenen Patch ... meiner für das Dropbear-Paket sähe z.B. im Moment so aus (ein akuelles diff zwischen meinem Build-Verzeichnis und dem Freetz-Source-Verzeichnis, beschränkt auf die "options.h" - wo dropbear konfiguriert wird):
Code:
--- options.h
+++ options.h
@@ -24,21 +24,21 @@
#ifndef DB_NONFREETZ
#define DSS_PRIV_FILENAME "/mod/etc/ssh/dss_host_key"
#else
-#define DSS_PRIV_FILENAME "/var/tmp/dss_host_key"
+#define DSS_PRIV_FILENAME "/var/custom/services/secureshell/etc/dss_host_key"
#endif
#endif
#ifndef RSA_PRIV_FILENAME
#ifndef DB_NONFREETZ
#define RSA_PRIV_FILENAME "/mod/etc/ssh/rsa_host_key"
#else
-#define RSA_PRIV_FILENAME "/var/tmp/rsa_host_key"
+#define RSA_PRIV_FILENAME "/var/custom/services/secureshell/etc/rsa_host_key"
#endif
#endif
#ifndef ECDSA_PRIV_FILENAME
#ifndef DB_NONFREETZ
#define ECDSA_PRIV_FILENAME "/mod/etc/ssh/ecdsa_host_key"
#else
-#define ECDSA_PRIV_FILENAME "/var/tmp/ecdsa_host_key"
+#define ECDSA_PRIV_FILENAME "/var/custom/services/secureshell/etc/ecdsa_host_key"
#endif
#endif
@@ -64,7 +64,7 @@
several kB in binary size however will make the symmetrical ciphers and hashes
slower, perhaps by 50%. Recommended for small systems that aren't doing
much traffic. */
-#define DROPBEAR_SMALL_CODE
+//#define DROPBEAR_SMALL_CODE
/* Enable X11 Forwarding - server only */
//#define ENABLE_X11FWD
@@ -112,7 +112,7 @@
/* Enable CBC mode for ciphers. This has security issues though
* is the most compatible with older SSH implementations */
-#define DROPBEAR_ENABLE_CBC_MODE
+//#define DROPBEAR_ENABLE_CBC_MODE
/* Enable "Counter Mode" for ciphers. This is more secure than normal
* CBC mode against certain attacks. This adds around 1kB to binary
@@ -141,7 +141,7 @@
#define DROPBEAR_SHA1_96_HMAC
#define DROPBEAR_SHA2_256_HMAC
#define DROPBEAR_SHA2_512_HMAC
-#define DROPBEAR_MD5_HMAC
+//#define DROPBEAR_MD5_HMAC
/* You can also disable integrity. Don't bother disabling this if you're
* still using a cipher, it's relatively cheap. If you disable this it's dead
@@ -153,7 +153,7 @@
* Removing either of these won't save very much space.
* SSH2 RFC Draft requires dss, recommends rsa */
#define DROPBEAR_RSA
-#define DROPBEAR_DSS
+//#define DROPBEAR_DSS
/* ECDSA is significantly faster than RSA or DSS. Compiling in ECC
* code (either ECDSA or ECDH) increases binary size - around 30kB
* on x86-64 */
@@ -164,7 +164,7 @@
with badly seeded /dev/urandom when systems first boot.
This also requires a runtime flag "-R". This adds ~4kB to binary size (or hardly
anything if dropbearkey is linked in a "dropbearmulti" binary) */
-#define DROPBEAR_DELAY_HOSTKEY
+//#define DROPBEAR_DELAY_HOSTKEY
/* Enable Curve25519 for key exchange. This is another elliptic
* curve method with good security properties. Increases binary size
@@ -202,7 +202,7 @@
/* The MOTD file path */
#ifndef MOTD_FILENAME
-#define MOTD_FILENAME "/etc/motd"
+#define MOTD_FILENAME "/var/custom/services/secureshell/etc/motd"
#endif
/* Authentication Types - at least one required.
@@ -299,7 +299,7 @@
* OpenSSH), set the path below. If the path isn't defined, sftp will not
* be enabled */
#ifndef SFTPSERVER_PATH
-#define SFTPSERVER_PATH "/usr/lib/sftp-server"
+#define SFTPSERVER_PATH "/var/custom/services/secureshell/bin/sftp-server"
#endif
#endif
@@ -309,7 +309,7 @@
#define _PATH_SSH_PROGRAM "/usr/bin/ssh"
#else
/* ssh is expected to be in PATH */
-#define _PATH_SSH_PROGRAM "ssh"
+#define _PATH_SSH_PROGRAM "/var/custom/services/secureshell/bin/ssh"
#endif
/* Whether to log commands executed by a client. This only logs the
@@ -352,7 +352,7 @@
#define DEFAULT_IDLE_TIMEOUT 0
/* The default path. This will often get replaced by the shell */
-#define DEFAULT_PATH "/usr/bin:/bin:/var/bin"
+#define DEFAULT_PATH "/var/custom/bin:/usr/bin:/bin"
/* Some other defines (that mostly should be left alone) are defined
* in sysoptions.h */
Am Ende führt so eben jede Änderung im Freetz, die den Ausgangszustand für diesen zusätzlichen Patch verändern würde (wenn man den mal als 900-irgendwas.patch ins make/<package>/patches gelegt hätte), zu Problemen ... da sich (bleiben wir mal bei diesem Beispiel mit dem dropbear) diese Werte auch außerhalb von "options.h" per -D beim gcc-Aufruf setzen ließen, wäre das eben ein solcher Fall, wo man mit einem Include-File für das mk-File anstelle eines Patches eine größere Flexibilität erreicht; von der Möglichkeit, da ein "Basisverzeichnis" zu verwenden - in meinem Falle eben "/var/custom(services/secureshell" anstelle von "/mod" beim Freetz - könnte man ja auch profitieren.
Wie gesagt, es gibt eine sehr enge "Verzahnung" zwischen den (vier) Teilen von Freetz, die sicherlich historisch gewachsen ist. Das ist weder verwerflich noch auf einen Schlag zu ändern ... aber u.a. solche Punkte meinte ich auch im Januar, als ich in der Mailingliste vom "Blick über den Tellerrand" geschrieben habe. Freetz war (und ist) sicherlich ein nettes Cross-Build-System, eine Quellcode-/Patch-Verwaltung für zusätzliche Pakete und sogar ein funktionierendes Tool zum Modifizieren von Stock-Firmware.
Was Freetz vielleicht einmal war (und es heute aber in meinen Augen nicht mehr ist), wäre eine moderne (und sichere) Oberfläche für die Verwaltung von Erweiterungen auf der FRITZ!Box. Da schlägt jedes NAS-GUI auch Freetz um Längen und selbst AVM hat beim GUI Freetz in meinen Augen lange abgehangen.
Das ist immer noch eine "Konfiguration für Spezialisten", was zum Zeitpunkt der Entstehung von Freetz sicherlich gerechtfertigt war, aber im Zeitalter von graphischen Oberflächen allerorten einfach nicht mehr so richtig zeitgemäß ist - genauso wenig wie die "starre Konfiguration" des Funktionsumfangs der Box zum Compile-Zeitpunkt.
Das mag auch für ältere FRITZ!Box-Modelle nicht ohne weiteres zu ändern sein ... aber für neue Modelle kann/muß man eben auch neue Wege gehen. Niemand erwartet von einer 7170, daß sie DECT kann ... warum sollte man erwarten, daß diese Box einfach per Download aus einem Repository einen OpenVPN-Server oder -Client "nachrüsten" kann? Für eine moderne 7490 oder 3490 ist das aber machbar (und heute irgendwie auch "erwartbar") und da muß man sich dann eben (meine Meinung) auch mental von solchen alten Schätzchen verabschieden und einfach mal sagen, man macht einen (begründeten(!), das ist ja keine Willkür) Schnitt.
Und solchen Möglichkeiten steht eben Freetz mit der "Fixierung" (nochmal, ich kann die auch verstehen, aber man darf sie ja trotzdem kritisieren) auf die Erstellung von Binaries für ein "Freetz-Image" ein klein wenig "im Wege".
Man wird sicherlich die Stock-Firmware immer in einem gewissen Umfang modifizieren müssen, um solche "dynamischen Pakete" verwirklichen zu können. Aber in erster Linie beim Skript-Code, um die diversen "Hooks" da irgendwo so einzubauen, daß die nachgerüsteten Erweiterungen von wichtigen Events benachrichtigt werden und eine Chance zur Reaktion erhalten.
Ansonsten würde sich so ein modifiziertes System eben ohne dynamische Pakete erst einmal 1:1 wie die Stock-Firmware verhalten ... das ist ein entscheidender Unterschied zum bisherigen Freetz-Ansatz. Daß selbst das bisherige Vorgehen in Freetz so seine Tücken hat und auch von einer einzigen AVM-Änderung schon kräftig durchgeschüttelt werden kann, brauche ich Dir ja nicht zu sagen ... die komplette Mount-Behandlung in Freetz ist eben sogar im Vergleich zur AVM-Implementierung ein echtes Monster, weil da sowohl ältere als auch neue Firmware-Versionen berücksichtigt werden sollen/müssen - von den "remove"-Patches funktionieren einige auch schon länger nicht mehr so, wie es früher einmal war (und sind größtenteils bei den NAND-Modellen ohnehin nicht notwendig, zumindest beim derzeitigen Umfang des root-FS).
Da ist eben auch Freetz auf den AVM-Weg eingeschwenkt (monolithische Software, die erst zum Ausführungszeitpunkt die konkrete Umgebung berücksichtigt und ggf. (bei AVM jedenfalls) auf der konkreten Box gar nicht verwendet werden kann) ... das ist aber kein Naturgesetz, daß man so vorgehen muß. Wenn es für einige Modelle eben "Spezialpakete" gibt (was sind heute wohl die Modelle in freier Wildbahn, die > 90% der FRITZ!Boxen ausmachen?), die nur die konkreten Gegebenheiten der jeweiligen Box berücksichtigen (wer wissen will, was ich damit meine, kann ja mal in der Firmware einer 7490 nach "DOCSIS" suchen - 248 Fundstellen bei der 7490), kann man einiges mit weit weniger Aufwand realisieren und muß nicht bei der nächsten größeren Änderung wieder eine zusätzliche "Sonderlocke" einbauen.
Für viele "normale Benutzer" ist vermutlich schon Freetz zu überladen ... wenn ich nur den Bedarf habe, einen OpenVPN-Client auf der Box nachzurüsten (und den auch per Knopfdruck wieder zu entsorgen), dann ist eben das Erstellen eines Freetz-Images für "geübte Linux-User" kein großes Problem, für viele andere aber schon.
Ich möchte auch nicht wissen, wieviele Freetz-Images schon sehr lange ihren Dienst tun, weil die Besitzer der Boxen die notwendigen Arbeiten bei einer Aktualisierung von Komponenten scheuen (eben die Erstellung eines kompletten neuen Images, möglichst noch mit einer VM, die zuletzt beim Erscheinen der 06.20 benutzt wurde) und mehr nach Artikel 3 des Rheinischen Grundgesetzes mit einer veralteten Installation leben.
Auch hier wäre eben ein modernerer Ansatz auf der Basis des Austauschs/der Erneuerung einzelner Pakete ein echter "Sicherheitsgewinn" ... ich sehe das bei meinen Kunden. Da stehe ich auch jedesmal (bei NOR-Modellen) vor der Frage, ob ich ein neues Image mit der gerade aktuellen OpenSSL-Version oder dem Version-Bump des OpenSSH-Pakets erzeuge oder bis zum nächsten Update warte. Kann ich das auch dynamisch austauschen (bei 7390 und Modellen mit NAND-Flash für das System ziemlich leicht zu realisieren), stellt sich die Frage nicht ... von der wesentlich leichteren Möglichkeit beim Test solcher Änderungen mal abgesehen.
Zwar kann man das theoretisch auch auf der Basis eines "external"-Images machen, aber auch das ist eben ein wesentlich höherer Aufwand als der gezielte Austausch eines einzelnen Pakets oder sogar nur einer Datei. Aber das ist am Ende tatsächlich eher "Philosophie", ob man da "external" und "einzelne Pakete" gleichsetzen will beim Austausch durch "fachkundiges Personal" ... das Ziel muß/soll es aber sein, solche Aktionen auch dem "weniger technikaffinen Benutzer" zu ermöglichen.
Die beliebtesten Erweiterungen dürften zweifellos ein SSH-Server, OpenVPN und meinetwegen noch dnsmasq sein ... damit hat man m.E. schon die Hälfte aller "Freetzer" bedient. Schon bei Asterisk dünnt das erheblich aus ... und alles andere sind dann ohnehin eher "Spezialfälle", wo sich der daran Interessierte sowieso entsprechend kundig machen muß.
Wenn man dann noch ein Apache-Paket - am besten auch noch PHP bzw. Perl, jeweils als gesondertes Paket - für entsprechend potente Boxen anbietet (das ist dann aber schon "hohe Schule"), fängt man auch noch einige Erweiterungen wie SaS und/oder FHEM wieder ein, von solchen Sachen wie der Wiedererweckung anderer Pakete (z.B. LCR) ganz zu schweigen. Daß man am Ende nicht allen Bedarf befriedigen kann, ist auch klar ... aber das machen nicht einmal "richtige Distributionen", daß sie für jeden erdenklichen Fall das passende Paket liefern.
Schon wenn man auf der Freetz-Seite eine Möglichkeit hätte, nur die OpenSSL-Libraries auf Knopfdruck auszutauschen, wäre das ein erheblicher Sicherheitsgewinn für viele Boxen (meine Meinung). Seitdem AVM da nicht mehr auf die eigenen Bibliotheken setzt (bzw. die höchstens noch als Wrapper zu den OpenSSL-Libs dienen), kann man auch durch den Austausch der SSL-Bibliotheken die Sicherheit der Stock-Firmware selbst verbessern, falls AVM für einen OpenSSL-Patch keine neue Firmware-Version auflegen will (was sicherlich auf absehbare Zeit noch jeweils nur bei anderen Änderungen miterledigt werden wird). Eigentlich hatte ich ja mal die Hoffnung, daß AVM beim Sprung auf einen 3er-Kernel so weit "hüpft", daß da gleich noch das OverlayFS auf Kernelebene mit drin ist (ab 3.18 m.W.) ... dann wäre das gezielte Ersetzen von SquashFS-Dateien ja schon mal "gegessen" (macht m.W. fast jedes "Live-System" heute so).
Wenn es aber am Ende wenigstens eine definierte Schnittstelle für "Freetz-Pakete" gäbe, mit denen man diese auch dynamisch nachrüsten kann (und da pfeife ich dabei auch darauf, wenn da ein paar Bibliotheken doppelt bzw. in jedem "Erweiterungspaket" vorhanden sind - notfalls hilft ja auch ein Symlink zum "AVM-Original" in /lib, wenn das gefunden wurde, damit da "sharing" funktioniert wg. des geringeren RAM-Bedarfs) ... dann gäbe es auch wieder eine Perspektive für Freetz und die "neue Nutzergeneration".
Die will eben eine FRITZ!Box eher so konfigurieren können wie das eigene Smartphone oder Tablet und hat zum größten Teil nicht mal eine Ahnung, was Linux eigentlich ist. Der Router ist aus der "Computer-Versteher-Ecke" eben auch heraus und wenn er daheim die Basis für das "Internet der Dinge" werden soll, dann muß er selbst vom "dummen Kunden" sehr einfach zu bedienen sein und weitgehend gegen Fehlkonfigurationen immunisiert werden.
Dem steht der derzeitige Ansatz mit einem kompletten Freetz-Image aber diametral entgegen ... AVM macht sich nach meinem Verständnis auf den Weg zu einem "Consumer-Gerät" (immer mehr Assistenten und aufgeräumte Interfaces, solange man "Standardansicht" verwendet) und das ist auch richtig so. Will man dann so eine Box nur ein kleines bißchen aufrüsten, braucht man im Moment aber noch "Spezialkenntnisse" und das zieht eben genau am anderen Ende des Stranges - vom abschreckenden Umfang der Freetz-"Erste Schritte"-Doku mal ganz zu schweigen. Die liest eben auch nur der Nerd, der seine Box tatsächlich unbedingt modifizieren will und neben dem Ehrgeiz auch die dazu notwendige Zeit zu investieren bereit ist - jeder normale Benutzer ist davon bereits verschreckt.
Das geht nicht gegen die Qualität und/oder den Umfang des Freetz-Wikis, das sind einfach "Zitate" von Leuten, denen ich die Verwendung von Freetz ans Herz gelegt habe und die schon bei der Installation eines VMware-Players auf ihrem Windows-PC die Segel streichen (selbst wenn der Hyper-V könnte). Im derzeitigen Zustand ist eben Freetz etwas für Nerds oder Geeks ... wenn es nichts weiter sein will, muß man da auch nichts ändern. Wenn es aber eine Perspektive geben soll und man eine breitere Nutzerbasis anstrebt (da kann man sogar die Leute einfangen, die vom Ausbau der debug.cfg und/oder des Telnet-Daemons betroffen sind), dann muß man sich eben der Masse der Nutzer annähern und darf nicht auf dem "von Geeks für Geeks"-Niveau verharren.
So, genug philosophiert ... vom hier schreiben entsteht ja nicht eine Zeile neuer Code und so bringt diese Diskussion - hoffentlich/wenigstens/vielleicht - neue Einsichten und/oder Mitstreiter oder auch mal einige andere Meinungen zu diesem Thema. Natürlich würde mich da in erster Linie die Meinung von Leuten interessieren, die die damit verbundene Arbeit einschätzen können und ggf. auch mitmachen wollen. Die Meinung der "Nur-Anwender" kenne ich bereits (aus Befragungen auch außerhalb des IPPF) ... wenn es so etwas gibt, nutzt man es auch.
Und da ich auch nicht zu den Leuten gehöre, die das Rad jedesmal neu erfinden müssen/wollen, wäre eines meiner Anliegen eben auch eine etwas größere Flexibilität des Freetz-Buildsystems (nicht auf einen Schlag - aber immer im Hinterkopf bei weiteren Änderungen) ... womit sich der Kreis dann wieder schließt und ich meine Gedanken doch wieder eingefangen hätte.
