Ja und nein.
Bei einigen Modellen kann man das über die Abfrage des Status der GPIO-Pins bewerkstelligen, sofern AVM die notwendigen Interfaces in den Kernel eingebaut hat (
pinctrl oder auch die GPIOLib über /sys/class/gpio).
Dann kann man darüber die LEDs sowohl steuern als auch auslesen ... aber es gibt kein einzelnes CLI-Tool und bei anderen Modellen, die ihrerseits die Pins per Multiplexer ansteuern (iirc gehören die GRX-Boxen alle dazu), gibt es m.W. bisher gar keine Möglichkeit ... oder besser formuliert: Dort habe ich bisher noch keine (sinnvolle) Möglichkeit gefunden. Es gibt noch ein paar LED-relevante Module vom jeweiligen Chipset-Hersteller (z.B. "ifx_gpio" bei den VR9-Boxen), aber die werden von AVM nur partiell implementiert und ein Setzen/Auslesen von LEDs ist mir darüber eher selten gelungen.
Eine andere Alternative, sofern die entsprechende Box MMIO (memory mapped I/O) für die GPIO-Pins verwendet (wo Schreiben in bestimmte Speicheradressen dann zu Änderungen des Zustands von GPIO-Pins führt), ist der Versuch mit dem "devmem"-Applet der BusyBox. Dazu muß man aber erst mal ermitteln, an welchem Pin welche LED hängt, wie sie angeschlossen ist (ob "high" (direct) oder "low" (inverted) zum Leuchten der LED führt) und welche Adresse (bis hin zum genauen Bit im Control-Wert) im Speicher für diesen Pin zuständig ist (diese Adressen sind i.d.R. nicht mal zusammenhängend, es gibt "Bänke" von Bits, die für die GPIO-Pins zuständig sind).
Das mit der MMIO funktioniert (iirc) bei der 7390 einwandfrei, inkl. Schreiben, weil das drei verschiedene "Register" im Speicher sind. Bei den VR9-Boxen ist das mit dem Schreiben nicht mehr ohne weiteres möglich (bzw. "riskant", weil es nicht atomar ist, da man den alten Wert lesen, das Bit ändern und den neuen zurückschreiben müßte), aber das Auslesen funktioniert:
https://www.ip-phone-forum.de/threads/fritzbox-speziell-7270-die-leds-können-ja-auch-rot-leuchten.271934/post-2025914 ... mit einem eigenen Programm (also ohne "devmem"-Applet, weil das eigene Programm das Lesen, Ändern und Schreiben in einem Rutsch erledigen kann) ist das Schreiben aber auch da wieder machbar; am besten macht man das sogar mit einem eigenen LKM, weil man dann den Zugriff auch "locked" ausführen kann.
Ansonsten steuert AVM vom Rest des Codes aus die LEDs i.d.R. über "events" an ... welche LED dann für welches Event ein- oder ausgeschaltet wird bzw. ob und wie schnell blinkt, organisiert ein Kernel-Module (led_module.ko) und die anderen AVM-Programme kommunizieren mit dem wohl über eine Library im Userspace namens "libled.so(.2)".
Einerseits arbeitet das bei AVM halt als "Stack" (d.h. neuere Ereignisse überlagern die älteren und damit kann - nach dem "Abräumen" eines neueren Ereignisses - auch der vorherige Stand der Anzeige wiederhergestellt werden), was manches erleichtert und andererseits dürfte die Tatsache, daß AVM damals gegen Cybits in dem Punkt "falsche (LED-)Anzeigen" gewonnen hatte (und nur in diesem) sicherlich auch eine Rolle spielen bei der "Geheimniskrämerei", die AVM seit einigen Jahren um die Ansteuerung der LEDs betreibt.
In älteren Versionen gab es noch passende Gerätetreiber (u.a. "/dev/led" oder "/dev/new_led"), die auch ein passendes Interface boten (durch Schreiben bestimmter Werte), um vom Userspace aus mal eine LED ein- oder auszuschalten. Das geht heute nur noch über "led-ctrl", wozu man sich erst mal passende Events suchen muß für die LED, die man gerne ändern möchte und ein Auslesen der aktuellen Anzeige ist darüber auch nicht möglich.
Bei einigen Modellen gibt es auch noch einen AVM-Treiber für die GPIO-Pins, der ein "procfs" dafür bereitstellt (unter "/proc/avm/gpio") ... darüber kann man (wenn der Kernel das überhaupt enthält) auch den Zustand von Pins ändern, aber nichts auslesen (die "read"-Funktion ist schlicht nicht implementiert).
Um mal ein Beispiel zu machen ... nehmen wir mal die 6490. Da hat AVM das zuletzt erwähnte Interface (im "procfs") implementiert und man muß nur ermitteln, welcher Pin welche LED steuert. Das steht u.a. in der Hardware-Beschreibung:
Code:
vidar:/home/FritzBox/FB6490/ATOM/GPL/linux-2.6.39 $ grep -A 2 led arch/arm/mach-avalanche/puma6/avm_hw_config_hw199a.h
.name = "gpio_avm_led_power",
.value = 92,
.param = avm_hw_param_gpio_out_active_low,
--
.name = "gpio_avm_led_info_red",
.value = 93,
.param = avm_hw_param_gpio_out_active_low,
--
.name = "gpio_avm_led_internet",
.value = 101,
.param = avm_hw_param_gpio_out_active_low,
--
.name = "gpio_avm_led_dect",
.value = 91,
.param = avm_hw_param_gpio_out_active_low,
--
.name = "gpio_avm_led_wlan",
.value = 102,
.param = avm_hw_param_gpio_out_active_low,
--
.name = "gpio_avm_led_info",
.value = 104,
.param = avm_hw_param_gpio_out_active_low,
vidar:/home/FritzBox/FB6490/ATOM/GPL/linux-2.6.39 $
Wie man sieht (active_low), sind die LEDs über einen Inverter angeschlossen, man muß also zum Einschalten den Pin auf "0" setzen. Das geht hier (mit dem AVM-Treiber) auch wieder ganz simpel, indem man einfach ein "set <pin> <val>" an "/proc/avm/gpio" ausgibt. Das gibt keine weitere Quittung, nur die LED ändert ihren Zustand. Will man die nun blinken lassen, muß man das über die entsprechende Abfolge von Kommandos selbst organisieren.
Da die 6490 parallel auch noch das generelle Kernel-Interface für GPIO-Pins bietet (gpiolib), kann man den Zustand darüber allerdings auch abfragen (und auch setzen, wenn man will). Dazu braucht man auch nur die Pin-Nummer und muß diesen dann erst einmal "exportieren", damit die passenden Nodes im "sysfs" angelegt werden:
Code:
~ # ls -l /sys/class/gpio/
--w------- 1 root root 4096 Jul 17 10:45 export
lrwxrwxrwx 1 root root 0 Nov 7 2000 gpiochip0 -> ../../devices/virtual/gpio/gpiochip0
lrwxrwxrwx 1 root root 0 Nov 7 2000 gpiochip32 -> ../../devices/virtual/gpio/gpiochip32
lrwxrwxrwx 1 root root 0 Nov 7 2000 gpiochip64 -> ../../devices/virtual/gpio/gpiochip64
lrwxrwxrwx 1 root root 0 Nov 7 2000 gpiochip96 -> ../../devices/virtual/gpio/gpiochip96
--w------- 1 root root 4096 Jul 17 10:49 unexport
~ # echo 93 >/sys/class/gpio/export
~ # ls -l /sys/class/gpio/
--w------- 1 root root 4096 Jul 17 10:49 export
lrwxrwxrwx 1 root root 0 Jul 17 10:49 gpio93 -> ../../devices/virtual/gpio/gpio93
lrwxrwxrwx 1 root root 0 Nov 7 2000 gpiochip0 -> ../../devices/virtual/gpio/gpiochip0
lrwxrwxrwx 1 root root 0 Nov 7 2000 gpiochip32 -> ../../devices/virtual/gpio/gpiochip32
lrwxrwxrwx 1 root root 0 Nov 7 2000 gpiochip64 -> ../../devices/virtual/gpio/gpiochip64
lrwxrwxrwx 1 root root 0 Nov 7 2000 gpiochip96 -> ../../devices/virtual/gpio/gpiochip96
--w------- 1 root root 4096 Jul 17 10:49 unexport
~ # ls -l /sys/class/gpio/gpio93/
-rw-r--r-- 1 root root 4096 Jul 17 10:50 active_low
-rw-r--r-- 1 root root 4096 Jul 17 10:50 direction
-rw-r--r-- 1 root root 4096 Jul 17 10:50 edge
-rw-r--r-- 1 root root 4096 Jul 17 10:50 multi
drwxr-xr-x 2 root root 0 Jul 17 10:50 power
lrwxrwxrwx 1 root root 0 Jul 17 10:49 subsystem -> ../../../../class/gpio
-rw-r--r-- 1 root root 4096 Jul 17 10:49 uevent
-rw-r--r-- 1 root root 4096 Jul 17 10:50 value
~ #
Mit dem "export" kommt also "gpio93" dazu und da kann man jetzt die Eigenschaften des GPIO-Pins auslesen/ändern. Ändern sollte man aber im Falle der FRITZ!Box nur "value" (der Rest stimmt auch nur, wenn man ihn zuvor selbst dort initialisiert hat) - beim Rest sollte man schon sehr, sehr genau wissen, was man da eigentlich macht. Wenn man auch über das "sysfs"-Interface schreiben will, muß man zuvor noch die korrekte Richtung über das "direction"-File einstellen (das wäre dann "out"), ansonsten kann man "value" nicht beschreiben. Diese "Verrenkung" kann man sich sparen, wenn man die Interfaces kombiniert und - sofern vorhanden - über das "procfs"-Interface des AVM-Treibers für die GPIO-Pins die Änderungen vornimmt.
Ich habe mal das Shell-Skript, mit dem ich schon länger die LEDs der 6490 auch ohne das AVM-Module kontrolliere (bei der 6490 sind die Interfaces dafür eben vorhanden) in mein Repo eingecheckt (im Unterverzeichnis "led") und es zuvor noch etwas "aufgehübscht" für potentielle Interessenten ... vielleicht kann es ja jemand nachnutzen. Dabei habe ich es gleich noch auf alle Puma6-Geräte von AVM erweitert, denn nach der Hardware-Beschreibung in den Kernel-Quellen nutzen die alle dieselben GPIO-Pins für die LEDs. Damit vereinfacht sich das wieder einigermaßen ... will man z.B. dreimal alle LEDs für jeweils 2 Sekunden blinken lassen, ginge das so:
Code:
#! /bin/sh
led=/var/media/ftp/pentest/led
org="$($led states)"
set -- $org
on=""
off=""
while [ -n "$1" ]; do
on="${on}${on:+ }on"
off="${off}${off:+ }off"
shift
done
$led wyatt_earp
for i in 1 2 3; do
$led restore $on
sleep 2
$led restore $off
sleep 2
done
$led restore $org
Allerdings ist das nicht allzu schnell und daher sieht man bei diesem "Blinken" dann schon recht deutlich, daß die LEDs alle einzeln gesteuert werden ... daher ist ein "Laufband" fast besser zu organisieren (ich habe mal noch eine Angabe, welche LED sich wo befindet in der Reihe, dazugepackt).
Der Rest der Ansteuerlogik für die LEDs ist bei AVM halt "closed source" und darf deshalb nicht einfach weitergegeben werden (jedenfalls nicht einzeln) ... daher muß man von Box zu Box (bzw. Prozessor zu Prozessor) schauen, wie man die LEDs am besten ansteuert.
Meine Ansätze, das wieder in einem gemeinsamen Skript zusammenzufassen für mehrere Architekturen und Modelle, sind leider noch nicht "spruchreif".