Das scheint aber ein größerer Eingriff zu sein
Es ist ein einmaliger Start der FRITZ!Box mit einem speziellen Image (über den FTP-Server im Loader) erforderlich, um einen Shell-Zugang bis zum nächsten Update zu aktivieren. Ob das jetzt schon ein "größerer Eingriff" ist oder ob man darunter die Wurzelbehandlung beim Zahnarzt verstehen würde, ist - ganz offensichtlich - von den persönlichen Erfahrungen geprägt. Als die Installation von neuen Inhouse-Versionen der AVM-Software bei der 07.08-Labor-Reihe plötzlich genau auch dieses Vorgehen erforderlich machte (also den Start der Box über eine per FTP-Server hochgeladene Firmware), war das für so manchen vorherigen "Skeptiker" dann plötzlich auch keine größere Hürde mehr, weil das "haben wollen" als eigener Antrieb offenbar geeignet war, sich tatsächlich einen EIGENEN Eindruck von den dabei auftretenden "Schwierigkeiten" zu machen.
Ich bezweífele aber ohnehin, daß es bei aktueller Firmware noch ohne weiteres möglich ist, eigene AT-Kommandos an einen solchen Stick zu senden.
Die Aktivierung der gesamte Komponenten, die für die Benutzung eines USB-Sticks als Mobilfunk-Modem (oder als "Pseudo-Netzwerkinterface", wo dann aber üblicherweise auch keine AT-Kommandos mehr verwendet werden) erforderlich sind, erfolgt über entsprechende Messages und Aktionen des
udevd, die bei der Erkennung und Initialisierung eines solchen Gerätes nacheinander erzeugt werden. Wenn man davon ausgeht, daß ein derartiger USB-Stick tatsächlich von der AVM-Firmware bei Erkennung jeweils neu initialisiert wird, müßte man ja eine Gelegenheit finden, genau in dem Zeitraum zwischen dieser Initialisierung und der eigentlichen "Benutzung" im OS (also dem Öffnen der Device-Files durch den Daemon, der dann für die Steuerung des Mobilfunk-Sticks verantwortlich zeichnet) die eigenen Kommandos abzusetzen.
Seitdem AVM die gesamte Mobilfunk-Unterstützung in einen neuen Daemon namens
mobiled gesteckt hat (der vermutlich primär für AVM-Geräte mit eigener Mobilfunkanbindung entwickelt und dann später auf andere Modelle übernommen wurde), sind das auch keine einzelnen Skript-Dateien im FRITZ!OS mehr, die sich um die Initialisierung kümmern, sondern der (notfalls auch erst gestartete, wobei nach einem solchen Start dann 10 Sekunden zum "settlen" des Daemons (bzw. bis zu seiner ersten erfolgreichen Reaktion auf eine Abfrage "von außen") eingeschoben werden) Daemon wird nur noch über eine RPC-Schnittstelle (mittels
rpctrl-Kommando) über neue Umstände informiert und jede weitere Verarbeitung erfolgt nur noch innerhalb des
mobiled. Daher wäre auch zu vermuten, daß es gar keinen solchen Zeitraum "zwischen" den Aktionen mehr gibt, wo man selbst (exklusiv) auf das Gerät zugreifen kann - es läuft alles innerhalb des Daemons und da der schon für das eigene AT-Kommando zur Initialisierung den Control-Port geöffnet haben muß, ist kaum anzunehmen, daß er den zwischendrin noch einmal (freiwillig) schließen würde ... wie es bei zwei getrennten Prozessen der Fall wäre. Früher gab es eben eine Trennung zwischen der Initialisierung und den eigentlichen Daemons in Gestalt des
umtsd und
csvd, da konnte man vor deren Start noch eigene Kommandos hinterher schieben.
Das geht heute aber so weit in Richtung "Integration in einem einzelnen Prozess", daß ich nicht einmal sicher sagen kann (weil ich das nie geprüft habe, das kann aber jeder leicht selbst machen), ob dieser Daemon überhaupt seinerseits "normale" Unix-Devices für die Schnittstellen zur Steuerung des Sticks erstellt (irgendwo im
dev-Verzeichnis) und dann diese selbst benutzt oder ob der die nur temporär irgendwo einrichtet, wo auch nur er Zugriff hat bzw. ob überhaupt "normale Devices" verwendet werden. Was ich aber mal annehmen würde - irgendwann wird auch
mobiled auf die OS-Dienste zurückgreifen (größere Teile des Daemons, wenn nicht gar alles, scheinen auch in Lua geschrieben) und dann führt fast kein Weg an entsprechenden Device-Files vorbei.
Auch das müßte man also erst einmal feststellen, BEVOR man sicher sagen kann, ob es überhaupt eine Rolle spielt, daß man einen Shell-Zugang hat oder nicht. Wenn das alles innerhalb des
mobiled abläuft und man - selbst wenn die Device-Files eingerichtet würden und man dort zugreifen könnte - schon wegen "sharing violations" gar nicht mehr richtig "dazwischen" kommt, dann nutzt der einem ja auch nichts. Die Kommunikation zwischen
udevd und
mobiled wird jedenfalls (m.E. praktisch komplett) über die Shell-Skripte
/etc/hotplug/udev-rndis-usb (bei Sticks, die als "Netzwerkinterface" daherkommen) und
/etc/hotplug/udev-mobiled gesteuert.
Eine Alternative (je nachdem, wie drängend das nun ist und wie groß der eigene "Forscherdrang" sein mag) wäre vielleicht noch die Rückübersetzung des Lua-Bytecodes (in
/usr/share/lte/*) - dann kann man den analysieren und vielleicht findet man dabei dann auch noch irgendeine versteckte Funktion des RPC-Interfaces, mit der man gezielt AT-Kommandos an geeignete Geräte senden kann ... aber darauf wetten würde ich nicht. Da erscheint es mir fast vielversprechender, in den Lua-Dateien nach entsprechenden Initialisierungskommandos zu suchen und diese dann zu patchen - natürlich mit den üblichen "Nebenwirkungen", denn das müßte man ja nach jedem Update erneut anpassen (wobei das beim eigenen Senden von AT-Kommandos ja auch so wäre, denn das überdauert auch kein Update mit originaler Firmware) und man würde sich damit auf dieses eine Modell des USB-Sticks (oder kommandokompatible) festlegen. Wie weit solche Aktionen dann noch durch die Ausnahmetatbestände im UrhG gedeckt sind und wie weit das noch mit dem "Herstellen einer Interoperabilität" vereinbar ist, muß jeder selbst einschätzen - eine "generelle" Einschätzung halte ich hier für schwierig, weil es eben stark von den Umständen des Einzelfalls abhängig ist.
