Ich verwende grundsätzlich weder Freetz-NG, noch Freetz oder meinen Fork des Projekts (zumindest nicht den Teil, der hinter
make/mod steckt) und modifiziere meine Firmware "von Hand" bzw. selbst.
Also lautet die Antwort eigentlich: Nein, mit Freetz-NG habe ich das
nicht noch nie probiert.
Meine 6490 zum Testen hat für beide Systeme passende USB-Adapter verbaut und wenn man die Initialisierung der Kernelparameter (
mute=0) passend patcht (über den Bootloader schaffe ich es auch nicht, den
mute-Parameter zu übergeben - bei Puma6 - der wird vom Loader "ausgefiltert"), kriegt man da auch seine Shell.
Ich dachte, ich hätte ein passendes
strace bei meinen vorkompilierten Binaries dabei (
https://github.com/PeterPawn/yf_bin/tree/master/target), aber das ist wohl nicht der Fall.
Aber die Kernel-Version beim Puma6 hat sich seit Jahren nicht geändert und falls in Freetz-NG die Möglichkeit inzwischen fehlen sollte (da bin ich seit drei Monaten auch "lesend" raus), dann sollte es mit einem anderen Fork immer noch funktionieren, sich das Binary statisch gelinkt zu erstellen und es einfach auf die Box zu kopieren für die Ausführung.
Vielleicht findest Du auch bei
@fesc das passende Binary in seinem Bitbucket-Repo.
Ist Dir eigentlich schon mal aufgefallen, daß bei AVM selbst auch nur noch das
rpc-Kommando mit der Option
-s (also über Sockets) benutzt wird (im Rahmen der Tests bei der Produktion ->
ptestd) und ansonsten (seit einiger Zeit) nur noch die Steuerung des
pumaglued auf dem ARM-Core über das
aicmd-Kommando von der ATOM-Seite erfolgt? Insofern habe ich mich also von Deinem "Beispiel" mit der Verwendung von
rpc "hinreißen" lassen und bin auf Dein "ging schon mal" hereingefallen, denn das dürfte bei deutlich älteren FRITZ!OS-Versionen gewesen sein. Oder siehst Du das anders? Die angesprochenen Variablen werden dann dennoch genutzt - halt von anderen (AVM-)Programmen (iirc erfolgt die Kommunikation durch jeweils eine Instanz von
avmicpd auf jedem System - aber "ohne Gewähr", daß ich mich richtig erinnere).
Versuch's doch mal mit einem
aicmd pumaglued (und lies Dir die verfügbaren Funktionen durch - das
aicmd dürfte für
AVM ICP command o.ä. stehen), wahlweise auch mit einem
rpc -s -- aicmd pumaglued, falls mit einem
aicmd auf dem ATOM-Core keine "Beschreibung" vom ARM-Core geliefert wird. Ich habe gerade meine Test-Box nicht in Reichweite und müßte sie erst wieder aufbauen ... das mußt Du also alleine herausfinden (zumindest ohne Test von meiner Seite aus).
Aber aus der Erinnerung heraus funktioniert es (nur inzwischen halt deutlich anders, ich weiß ja nicht, wann es bei Dir "mal ging") und für den Aufruf von
aicmd pumaglued shell start gibt es sogar einen Shell-Einzeiler (als
armconsole in
/bin - das war wohl jemandem bei AVM auch zu lang zum Eingeben). Nur wirst Du damit vermutlich auch keine Kommandos als "batch" auf dem ARM ausführen können, weil das eben immer eine interaktive Shell startet, deren Standard-Handles halt über RPC laufen (denn AVM IPC ist ja auch nichts anderes) - für einzelne Kommandos, die Du direkt beim Aufruf übergeben kannst, mußt Du dann halt über den Socket gehen (also wie oben gezeigt aufrufen, wobei ich nicht sicher weiß, ob die entfernten STDOUT und STDERR automatisch auf denselben Handle gelegt werden - kannst Du alles selbst probieren).
Auch die "Beispiele" von AVM in einer entpackten Firmware (die findest Du auch in Deiner Build-Struktur) kannst Du ja problemlos selbst suchen ... alles immer noch, ohne irgendwelche alten Images zu installieren.
