[Gelöst] FB 6890 - kein LTE mehr nach Freetz

[PeterPawn]

Hast Du mal den Inhalt der binären Dateien zwischen dem Freetz-Image und dem originalen AVM-Image verglichen? Oder einfach mal die ganzen "modules*"-Dateien aus dem AVM-Original in das Freetz-Image kopiert (das geht wieder nur von Hand)? Solange da keine LKM dazugekommen sind durch Freetz (was bei Minimalkonfiguration nicht der Fall sein sollte), sollten die ja 1:1 übereinstimmen.

 

[koronth]

Kurzes Update: Es scheint an der Freetz-Busybox zu liegen. Verwendet man die AVM-Busybox klappt auch LTE wieder. Dafür aber kaum mehr was von Freetz, da die AVM-Busybox natürlich viele "Applets" nicht einkompiliert hat.

Leider weiß ich nicht, an welchen busybox-Kommandos es nun konkret liegt, die inkompatibel zu sein scheinen. Ich hoffe, ich muss nicht in die Symlink-Hölle, wenn ich im schlimmsten Falle alle Freetz-Busybox-Kommandos auf die zusätzlich mitgeschleppte Freetz-Busybox linken muss :-/.

Edit:
So, ich denke, ich habe den Übeltäter gefunden - glücklicherweise war es nur einer: das Busybox-Applet "/sbin/modprobe". Ich weiß nicht, wo genau da das Problem liegt - hat AVM die Busybox-Sourcen an dieser Stelle geändert?

Nach mehreren Tagen Ärger mit einer LTE-Box, die gefreetzt plötzlich kein LTE mehr konnte, bin ich aber nun bloß froh, daß ich mich nun endlich wieder den eigentlichen Problemen zuwenden kann.

Bis sich die Freetz-Profis des Problems angenommen haben, reicht mir persönlich erstmal die Platzverschwendungs-Holzhammer-Methode, in die Datei fwmod_custom den Abschnitt all() wie folgt zu füllen und dann ganz normal das Freetz-Image mit make zu bauen.

all() {
        freetz_base=$(dirname "$0")
        build_dir="${freetz_base}/build/"
        cp -p ${build_dir}/original/filesystem/bin/busybox ${build_dir}/modified/filesystem/bin/busybox-AVM
        ln -sf ../bin/busybox-AVM ${build_dir}/modified/filesystem/sbin/modprobe
}

Vielen herzlichen Dank an alle, die sich für das Problem Zeit genommen haben!!


Edit #2:

Mit der freundlichen Freetz-ng-Hilfe von opto gab es nun eine noch einfachere Variante, LTE auf der FB 6890 zu kriegen. In der .config von Freetz die folgenden Optionen aktivieren:

FREETZ_BUSYBOX_FEATURE_MODPROBE_BLACKLIST=y
FREETZ_BUSYBOX_FEATURE_MODUTILS_ALIAS=y
FREETZ_BUSYBOX_FEATURE_MODUTILS_SYMBOLS=y

und dann das Freetz-Image erzeugen. Sieht zumindest bei mir sehr gut aus mit LTE und diesen Config-Optionen.

 

[WileC]

Vielen Dank für die schnelle Lösung ich werde das Ganze auch mal auf meiner 6890 ausprobieren.

 

[WileC]

Würde der Patch auch auf "freetz" funktionieren?

 

[NDiIPP]

Ja, sollte.

Also in "menuconfig" unter "Busybox applets -> Linux Module Utilities -> modprobe" die Option "Blacklist support" anhaken sowie etwas weiter unten die Optionen "Support module.aliases file" und "Support module.symbols file" setzen. Man muss also noch nicht einmal die .config manuell bearbeiten.

 

[WileC]

Ah okay, wäre es denn möglich, den Patch auch als PR an freetz zu senden?!

 

[PeterPawn]

Für Freetz-NG wurde das (unreflektierte) Ausschalten aller Optionen in der BusyBox (https://github.com/Freetz/freetz/blob/master/make/busybox/generate.sh#L67), die danach zum Teil wieder eingeschaltet werden und spätestens hier dann auf die Bedürfnisse von Freetz zugeschnitten werden, inzwischen ja korrigiert: https://github.com/Freetz-NG/freetz-ng/commit/7abd80e5d4089cc12bfac16d1c29393c00f47aec

Aber generell "versaut" das blinde Setzen auf "default n" in der "generate.sh" ja die Zusammenhänge für die BusyBox-Settings (so wird zwar "MODPROBE_SMALL" entfernt, was sicherlich gut ist, gleichzeitig aber eben auch der Alias- und Blacklist-Support für die Applets, die ohne das "MODPROBE_SMALL" genutzt werden) - ein Grund, warum ich schon länger nur mit eigener BusyBox-Konfiguration unterwegs bin (auch die vorkompilierten Versionen aus meinem Repo verwenden diese eigene). Kommen beim Vorgehen in Freetz neue Optionen hinzu, die besser auch eingeschaltet werden bzw. bleiben, muß man das genau analysieren und diese wieder von Hand aktivieren - ein ziemlich fehlerträchtiges Vorgehen in meinen Augen.

Schlauer wäre es vermutlich gleich, wenn man anstelle alles auf "default n" zu ändern, nur die Einstellungen anfaßt, die auch das Erzeugen eines Applets auswählen und nicht solche, die Features ein- oder ausschalten.

Auch dieses "Wiedereinschalten" verteilt sich bei Freetz auf mehrere Stellen - einiges wird z.B. in der "make/mod/Config.in" wieder aktiviert (https://github.com/Freetz/freetz/blob/master/make/mod/Config.in), obwohl dieses Paket "mandatory" ist und gar nicht abgewählt werden kann. Wenn man sich da an die Arbeit macht und versucht die Zusammenhänge zu erkennen, kann man schon mal gehörig ins Fluchen geraten - zumindest für mich ist "logisch" etwas anderes und Dokumentation dazu sucht man halt auch vergeblich.

Daher stellt sich für mich die Frage, ob Änderungen auf dem bisherigen Weg überhaupt noch sinnvoll wären ... ein kleines Skript, was tatsächlich nur die Einstellungen für "Applet ja/nein" ändert und da nur für Applets alles erst einmal auf "aus" stellt, wäre leichter und noch einfacher wäre es, damit tatsächlich noch die jeweilige AVM-Konfiguration für die BusyBox zu "mischen" und somit sicherzustellen, daß die "Ausgangslage" bei den BusyBox-Optionen mit der von AVM übereinstimmt.

Schaut man sich die BB-Konfigurationen bei AVM über die (sinnvollen) Plattformen, die auch in Freetz unterstützt sind, an (bis zu 07.1x - vor der Labor-Reihe - waren da in den OSS-Paketen auch noch die Konfigurationen für alle Plattformen enthalten mit entsprechenden Namen), sind es ohnehin nur wenige Applets, die man mit der Konfiguration für ein "Super-Set" zusätzlich einschließen müßte ... das "sendarp", was AVM in der BB für die 7581 und 7582 erfunden hat, ist da noch ein Sonderfall, aber vermutlich auch nicht ohne jeden Grund enthalten und auch wenn Freetz-NG z.B. für sich die Unterstützung dieser Modelle reklamiert (allerdings "UNTESTED"), ist der dazu notwendige Patch für die BusyBox (der findet sich bei AVM im Quelltext-Paket als "0002-busybox-1.24.2.brcma9.diff") nicht vorhanden.

Einzig die BB-Konfigurationen für die Puma-Boxen haben signifikante Unterschiede (jenseits von "taskset") zu den anderen aufzuweisen ... aber auch da könnte man die von AVM eingebauten Applets alle problemlos in die Freetz-BusyBox übernehmen, denn heutzutage (und in aktuellen Versionen) ist sicherlich eher die Kompatibilität ein entscheidender Gesichtspunkt, als das Sparen von ein paar wenigen Byte bei der BusyBox. Sooo eng ist es im Flash bei aktuellen Geräten nun wirklich nicht.

Insgesamt ist es halt ein leidiges Problem mit der BusyBox und den verschiedenen Versionen - aber wenn man bei den AVM-Settings bleibt (bzw. die als Ausgangspunkt nimmt) und nur eigene Applets/Features hinzufügt, sollte das ja keine Auswirkung auf die Funktionsfähigkeit der BusyBox für die AVM-Komponenten haben ... denn wenn die ein Applet nicht erwarten, werden sie es auch nicht benutzen. Einstellungen, die das Format erwarteter Ausgaben ändern, sind eher selten bei der BusyBox und auch von daher droht eigentlich keine Gefahr. Üblicherweise ändert sich auch zwischen BusyBox-Versionen das Verhalten von Applets nicht (das "wget" ist da mal die berühmte Ausnahme von der Regel, wenn das künftig in der Standardeinstellung die Zertifikate bei HTTPS prüfen wird, was es zuvor nicht tat/tut) und damit ist auch die Gefahr bei einem Update auf eine neuere BusyBox-Version eigentlich überschaubar.

Aufpassen muß man aber noch an anderen Stellen. So gab es bei der 1.24 noch die Option "SWAPONOFF", die bei AVM auch gesetzt ist - mit der 1.26 verschwand diese aber und wurde durch einzelne Optionen direkt im Applet ersetzt: https://git.busybox.net/busybox/tree/util-linux/swaponoff.c?h=1_26_stable

Letztlich stellt man sich einfach einmal die eigene "Wunschkonfiguration" für die BusyBox zusammen und dann kann/sollte man die (solange es keinen Grund zur Änderung gibt) auch für alle Modelle (viele haben mittlerweile ja mehr als eine FRITZ!Box und häufig eben auch unterschiedliche Modelle, weil die alten im Mesh weiterverwendet und nicht mehr verkauft werden) verwenden, so daß man diesen Aufwand tatsächlich nur ein einziges Mal betreiben muß.

Außerdem kann/sollte man dann auch gleich noch das "bbconfig"-Applet einschließen lassen - damit hat man die Möglichkeit (ähnlich wie bei "/proc/config.gz" für die Konfiguration beim Build des Linux-Kernels), sich jederzeit die verwendete Konfiguration für den Build wieder ausgeben zu lassen, auf das man sie erneut verwenden kann. Die paar Byte zusätzlich, die für die (komprimierte) Speicherung dieser Informationen im Binär-File benötigt werden, machen den Kohl heutzutage wirklich nicht fett - im "Ernstfall" sparen sie aber sehr, sehr viel Zeit und ich spreche da aus Erfahrung, wenn ich behaupte, daß es ziemlich langwierig ist, sich die eigene BusyBox-Konfiguration so zusammenzustellen, daß da nichts fehlt und trotzdem nichts enthalten ist, was auf einer FRITZ!Box keinen oder nur einen sehr begrenzten Sinn ergibt (sonst könnte man auch gleich die "volle Dröhnung" mit allen Applets nehmen).

 

[WileC]

Ui, das klingt kompliziert...

 

[PeterPawn]

Ist es nicht wirklich ... und bei Freetz-NG ist das inzwischen auch schon wieder ganz anders, weil es in den letzten Tagen da jede Menge Änderungen gab (habe ich so nebenbei mitbekommen).

 

[WileC]

Ich Blick da eh nimmer so ganz durch ... was wo wie geändert wird.

-- Zusammenführung Doppelpost gemäß Boardregeln by stoney

Also müsste irgendwo in der ../make/busybox/Config.in bei "mandatory" folgender Teil "fest" eingetragen werden?

FREETZ_BUSYBOX_FEATURE_MODPROBE_BLACKLIST
FREETZ_BUSYBOX_FEATURE_MODUTILS_ALIAS
FREETZ_BUSYBOX_FEATURE_MODUTILS_SYMBOLS

Würde das nur auf die LTE-Boxen Sinn machen oder gleich für alle Boxen ?!

 

[PeterPawn]

Alle - die Erkennung vieler USB-Geräte basiert u.a. auf der Auswertung von Alias-Namen, wenn's um die Suche nach passenden Treibern geht.

 

[WileC]

Also die o.g. drei Zeilen in die Config.in der Busybox eintragen, fertig, läuft. Habe ich das so richtig verstanden?

 

[PeterPawn]

Wenn der Rest stimmt: Ja.

Es scheiterte wohl nur daran, die Aliasnamen der "cdc_acm.ok“ (das sind die Namen, für die das LKM zuständig ist) zu berücksichtigen bei der Suche nach dem passenden Treiber für die ACM-Ports.

 

[WileC]

Welcher Rest?

 

[PeterPawn]

Na wenn der Rest vom Freetz für die gewünschte FRITZ!OS-Version vorhanden ist und funktioniert. Hier geht es zwar (vermutlich) um eine 6890 und deren Release-Version, aber auch die hat ja eine Labor-Version erhalten und wer z.B. versucht, diese mittels des (alten) Freetz-Repos mit einem Image zu beglücken, fällt garantiert auf die Nase. Bei Freetz-NG vielleicht/wohl auch - da gibt es zwar erste Ansätze, die Version zu unterstützen (schon seit Ende Januar waren da erste, zaghafte Schritte zu sehen), aber parallel auch Meldungen über Bootloops.

Nun such' Dir was aus ... aber auch hier gilt weiterhin: Probieren geht über studieren - zumindest wenn man eine (halbwegs plausible) Theorie hat, wo die Probleme herkamen oder liegen (wie immer bestätigen halt Ausnahmen nur eine Regel).

 

[WileC]

@cuma und @PeterPawn vielen lieben Dank für Eure Worte auf dem Freetz-NG-Repo ... Gottseidank bin ich nach einem Issue auf Freetz_NG ein notorischer Melder. Und weil ich einen Lösungsansatz aufgreife und mit Hinweis auf den Ersteller verändere (vor gut zwei bis drei Jahren = alte Kamelle) ... auch öfters auffällig. Schade ists, dass der jeweilige Author es nicht schaft, den PR weiterzusteuern ... sodass nicht nur ein Repo was von der Entwicklung hat...

Wenn sich natürlich der eine Author nur seinem eigenen Repo widmen will, ist das natürlich für mich voll legitim, allerdings sollte man sich auch nicht wundern, wenn man öffentliche Ideen aufgreift und in ein anderes Repo steuert...

Aber @cuma danke für Deine Stellungnahme ich bin froh um jede Kritik