ar7cfgctl

[WileC]

Hallo liebes Forum,

vielleicht kennt jemand von Euch die Funktionsweise der ar7cfgctl und wie ich diese in einer Shell benutzen kann? Die Hilfe über "ar7cfgctl -?" ist nicht wirklich ergiebig.

MfG
WileC

 

[PeterPawn]

- nur das Auslesen von Werten ist implementiert von AVM (die Hilfe schreibt (oder schrieb) irgendwas vom Schreibzugriff)
- auf STDIN erwartet das Programm den Namen (Pfad) einer Einstellung aus der "ar7.cfg" (EDIT: oder auch mehrerer, die Ausgabe erfolgt in derselben Reihenfolge, auch wenn "-w" nicht verwendet wird)
- auf STDOUT wird deren Wert zurückgegeben
- Pfadangaben immer bis zum Wert, Arrays liefern keine Ausgabe
- bei einigen Arrays (nicht bei allen, z.B. nicht für "ar7cfg.routes", aber für "ar7cfg.brinterfaces") ist die Angabe eines Schlüssels möglich, um ein Element auszuwählen (Bsp: "ar7cfg.brinterfaces[guest].interfaces"), das scheint davon abzuhängen, ob es einen "zeichenketten-basierten Schlüssel" im entsprechenden Array von Einstellungen gibt (diese Einschätzung basiert nur auf ein paar Tests und muß nicht stimmen)

Beispiele gibt es bei AVM ausreichend, speziell in einigen Skriptdateien unterhalb von "/etc".

Das Programm ist eigentlich uralt und kann mit moderneren Einstellungen gar nicht umgehen.

Heutzutage verwendet man "ctlmgr_ctl", wo man mit "u" auch die Hierarchie der Werte angezeigt bekommt - wobei AVM das in den Supportdaten selbst aufgiebig nutzt, siehe Dateien unter "/bin/supportdata*", deshalb dürfte das einigermaßen "safe" in der Verwendung sein und so schnell nicht aus der Firmware verschwinden.

Oder man nimmt auch gleich das Lua-Interface von AVM (Beispiele: https://github.com/PeterPawn/YourFritz/tree/master/luavar), das wird von AVM selbst aber m.W. nicht mehr in Shell-Code verwendet - das gab es mal bei der Behandlung der Besonderheiten der Telefoniekonfiguration bei den DOCSIS-Boxen, als der PACM-Daemon noch kein Binary war. Mangels eigener Verwendung könnte es also passieren, daß AVM das "luavar"-Binary aus der Firmware wirft - solange es keine neue C-Library gibt, sollte man aber (dank DSOs) die Version aus einer älteren Firmware benutzen können, wenn man das in eigene Projekte einbaut.

 

[WileC]

Danke für die Antwort.. habe mich etwas gespielt und herausgefunden:

mit

echo ar7cfg.dslifaces.no_masquerading | ar7cfgctl

wird mir zwar der Wert ausgegeben, aber wie kann ich nun einen Wert setzen? .. mit ctlmgr_ctl gibts genau diesen Zweig nicht.

 

[PeterPawn]

wie kann ich nun einen Wert setzen?

Ich schrieb doch deutlich (dachte ich zumindest), daß es mit "ar7cfgctl" keinen Schreibzugriff gibt.

Die gesuchte Einstellung sollte sich unter "connection0[: ]settings/masquerading/enabled" finden lassen ("luavar" und "ctlmgr_ctl" benutzen unterschiedliche Schreibweisen) und kann (iirc) darüber auf den beiden anderen, von mir beschriebenen Wegen auch geändert werden.

root@fb7490:~ $ echo "v=connection0:settings/masquerading/enabled" | queries.lua
v="1"
root@fb7490:~ $

 

[WileC]

@PeterPawn: vielen lieben Dank für Deine Unterstützung. Bezüglich der ar7cfgctl hatte ich wohl nicht richtig deutlich genug gelesen.

In LUA bin ich leider überhaupt gar nicht fit. Daher versuche ich eine Lösung über ctlmgr_ctl zu finden. Im Dump allerdings finde ich keine Einstellung, die sich auf das masquerading bezieht...

Außerdem hab ich auf meiner 3490 gar keine queries.lua

 

[Chatty]

Mit folgendem Kommando erstellst du einen kompletten Dump, den du dann nach Belieben nach deiner Einstellung durchsuchen kannst:

ctlmgr_ctl u|tail -n +3|xargs -n 1 ctlmgr_ctl u >complete_dump

 

[PeterPawn]

Ich schrieb ja eigentlich auch, daß sich die erwähnte Einstellung auf BEIDEN anderen Wegen ändern lassen sollte.

Ob man sich nun eine fertige "queries.lua" in sein System kopiert (die Shell ist da ja sicherlich auch nicht "wie von Zauberhand" vorhanden) oder ein "spezialisiertes" Lua-Skript (ich habe ja auf die Beispiele verlinkt und eines davon befaßt sich (iirc) auch ausführlicher mit einer solchen "Spezialversion" für VPN-Verbindungen ... und zwar sowohl mit der Abfrage als auch mit Änderungen beim De-/Aktivieren), sollte keinen echten Unterschied machen ... aber auch das MUSS man ja nicht machen, denn es sollte mit "ctlmgr_ctl" ebenso funktioneren, wie ich (dachte ich schon wieder) deutlich schrieb.

Bei der Operation "u" listet der "ctlmgr_ctl" wohl nur die Einstellungen derjenigen UI-Module auf, die sich über eine bestimmte Schnittstelle registrieren und i.d.R. aus "/usr/share/ctlmgr" nachgeladen werden.

Die erwähnte Einstellung zum Masquerading auf dem WAN-Interface ist aber deutlich älter und ich bin nicht mal sicher, daß sie heute noch in allen Firmware-Versionen (bzw. in allen FRITZ!Box-Modellen) auch tatsächlich wirksam ist. Aber sie ist (dem Augenschein nach) nach wie vor vorhanden:

root@fb7490:~ $ /etc/version
113.07.11
root@fb7490:~ $ ctlmgr_ctl r connection0 settings/masquerading/enabled
1
root@fb7490:~ $ ctlmgr_ctl w connection0 settings/masquerading/enabled 0
0
root@fb7490:~ $ rc.wlan: Start WLAN...
rc.wlan start: WLAN daemon already running

root@fb7490:~ $ ctlmgr_ctl r connection0 settings/masquerading/enabled
0
root@fb7490:~ $ ctlmgr_ctl w connection0 settings/masquerading/enabled 1
1
root@fb7490:~ $ rc.wlan: Start WLAN...
rc.wlan start: WLAN daemon already running

root@fb7490:~ $ ctlmgr_ctl r connection0 settings/masquerading/enabled
1
root@fb7490:~ $

Wenn sie noch wirksam sein sollte, braucht sie m.W. aber (das war früher auch so) ohnehin den Neustart des "dsld" ... ob die Rudimente in den Netzwerkeinstellungen (im GUI), wo man das Masquerading bei einigen internationalen Versionen ein- und ausschalten konnte, noch vorhanden sind und vor allem, ob sie noch funktionieren, habe ich lange nicht mehr getestet.

PS/BTW: Wer prüfen will, ob die Einstellung auch das "no_masquerading" in der "ar7.cfg" ändert, der sollte vorher sicherstellen, daß der "ctlmgr" die "ar7.cfg" auch schon neu geschrieben hat ... das geht am einfachsten, indem man ihn anhält und neu startet: ctlmgr -s;ctlmgr

 

[WileC]

Woher weiß ich denn, dass connection0 das DSL Interface ist?! Bzw. das Interface zur „Außenwelt“?

 

[PeterPawn]

Da gibt es wohl mehrere Möglichkeiten:

- aus Erfahrung
- aus Recherchen in anderen Quellen
- aus Vergleich zweier "ar7.cfg" mit den jeweiligen Settings über "ctlmgr_ctl"
- aus einer Support-Anfrage bei AVM
- weil ich es geschrieben habe

Such' Dir was aus ... die Reihenfolge meiner Vorschläge stellt gleichzeitig auch deren Priorität dar, basierend auf meiner Einschätzung der Erfolgsaussichten.

 

[Chatty]

Bei der Operation "u" listet der "ctlmgr_ctl" wohl nur die Einstellungen derjenigen UI-Module auf, die sich über eine bestimmte Schnittstelle registrieren und i.d.R. aus "/usr/share/ctlmgr" nachgeladen werden.

Kann es sein, dass manche Variablen auf gar keinem Modul basieren, sondern direkt erstellt werden? So enthält /usr/www/avm/net/boxnet.lua:

if (box.post.nat) then
cmtable.add_var(saveset, "connection0:settings/masquerading/enabled", "0")
cmtable.add_var(saveset, "connection0:settings/firewall/enabled", "0")
else
cmtable.add_var(saveset, "connection0:settings/masquerading/enabled", "1")
cmtable.add_var(saveset, "connection0:settings/firewall/enabled", "1")
end

 

[WileC]

Die hardcore-Variante wäre ja noch eine "bearbeitete" ar7.cfg über die alte zu kopieren/streamen, danach einen ar7changed oder einen reboot laufen zu lassen?! ...

Oder die bestehende ar7.cfg heraus streamen, mittels "sed" bearbeiten und wieder zurück schreiben...

 

[PeterPawn]

@Chatty:
Ja, das sind (meiner Ansicht nach) die alten Variablen, die schon "seit Urzeiten" im "dsld" eine Rolle spielen und da dieser sich wohl nicht über dieselbe Schnittstelle beim "ctlmgr" registriert, wie die anderen Module (das Interface gab es damals vermutlich noch gar nicht), gibt es eben noch ein paar "historische Einstellungen", die bei AVM wohl nicht unter "UI modules" fallen. Ein weiteres Beispiel für "dsld"-Werte wäre "sar" - das gibt es auch nicht als "UI module".

Wenn ich noch etwas nachdenke, fallen mir garantiert noch einige andere Beispiele ein ... "rights" (das ist die Auflistung, welche Rechte das aktuell verwendete Konto hat) wäre ein solches Beispiel, das spielt wohl nur für die Session-Verwaltung im "ctlmgr" selbst eine Rolle und doch gibt es für die Lua-Files ein passendes Interface auch zu diesen Werten - ähnliches gilt für "security" oder auch ganz simpel für "box".

Daher mein Einwand (in #7), daß zwar mit "ctlmgr_ctl u" eine Möglichkeit der Darstellung der Settings in ihrer Hierarchie hinzukam (soo lange gibt es diese Option ja noch gar nicht), diese aber "nicht das ganze Bild" bietet. Nur die "neuen Settings" bzw. diejenigen, die AVM dann in verschiedene Module "ausgegliedert" hat, lassen sich auf diesem Wege ermitteln.

---------------------------------------------------------------------------------------------

Wer keine Idee hat, welches Settings durch eine Einstellung im GUI geändert wird (wenn es eine solche gibt und er sie in den Lua-Files nicht finden kann), der kann auch den "ctlmgr" mit Protokollierung der Abfragen und Änderungen starten. Dazu bietet dieser eine Option "-m" ... dann schreibt er eine Datei "/var/tmp/ctlmgrmsg.log" (iirc im XML-Format) mit diesen Infos. Das sollte man aber nicht zu lange praktizieren, denn da wird wirklich (wirklich) viel protokolliert.

@WileC:
Das funktioniert deutlich schlechter ... angefangen bei der richtigen Reihenfolge von Kommandos, denn bei einer (externen) Änderung darf der "ctlmgr" nicht aktiv sein, ansonsten überschreibt der die Änderungen beim nächsten Speichern (das kann auch beim Reboot erfolgen) gleich wieder. Von den Problemen, so eine Zeichenkette auch dann noch an der richtigen Stelle zu ändern, wenn sie mehrfach in der Datei vorkommt, ganz zu schweigen (und ein weiteres Vorkommen kann auch bei der nächsten Version des FRITZ!OS erst hinzukommen o.ä,.) ... das ist also - bitte nicht mißverstehen - eher eine "dumme Idee".

Hast Du Dir mal die Frage gestellt, warum es in der gesamten AVM-Firmware schon seit Jahren keinen Aufruf von "ar7cfgchanged" mehr gibt, auch wenn da nur noch ein Aufruf von "rc.net reload" enthalten ist?

Wie kommt man auf so seltsame Ideen wie den Einsatz von "ar7cfgchanged"? Und da meine ich in aktueller Firmware und nicht, weil es in irgendwelchen uralten Anleitungen vielleicht so stehen mag?

 

[WileC]

@PeterPawn weil ich nicht so tief in der Materie stecke und mir deshalb bei einer Änderung an der ar7.cfg ein ar7changed am naheliegendsten erschien.

aber vielen lieben Dank für die ganze Hilfe

 

[WileC]

Ist zwar schon ein älter Thread, aber ich glaube, meine Anschlussfrage gehört irgendwie dazu:

Wo, wie und wann werden denn beim booten der Box die Interfaces "zusammengebaut" und angelegt? Irgendwann muss ja per Skript oder sowas, die ar7.cfg aus /var/flash ausgelesen werden. Hintergrund wäre das Bridging der Interfaces eth0,1,2,3,wlan etc...

Könnte man das Ganze auch im rc.custom Skript auflösen und neu bridgen?! also das LAN tatsächlich nur eth0-3 ist und das WLAN wieder ein extra Interface mit eigenem IP-Adressbereich?

Aber mir gehts auch um das Grundverständnis, was wann wie genau am Start in welcher Reihenfolge passiert...

 

[PeterPawn]

Beim Start des "ctlmgr" wird die Datei eingelesen und (für die meisten anderen Daemons) gecacht. Wer welche Abfragen von Einstellungen über den "ctlmgr" macht, kann man sich mit dessen Protokoll-Modus (einfach mal "ctlmgr -?" (ja, es ist wirklich das Fragezeichen und nicht das üblichere "-h") die "-m"-Option betrachten) genauer ansehen. Das (mehr oder weniger finale) Einrichten der Interfaces erfolgt dann durch den "dsld".

Wenn ich mich recht erinnere, gibt es irgendwo sogar ein AVM-Event (nicht im Event-Log, sondern über die "avm_event"-Implementierung), wenn der damit fertig ist. Wie man damit umgehen KÖNNTE (so man C-Programme schreibt), findet man in den Kernel-Quellen - dort ist unter "drivers/char/avm_new/test.c" ein Beispiel zu finden, wie man sich als Event-Sink registriert und entsprechende Messages empfängt. Je nachdem, wie robust das Geplante dann sein soll (so eine "Umkonfiguration" kann ja auch mal mittendrin auftreten, wenn jemand per GUI etwas umstellt - man sieht sie sehr gut in der Console), kann man entweder nach dem Start des "dsld" lange genug warten (wenn das eine einmalige Aktion wird) oder man klemmt sich an das entsprechende Event und führt dann seine eigenen Aktionen nach jedem Auftreten des Ereignisses aus.

 

[WileC]

D.h. die Interfaces, die dann per "ipconfig" abgerufen werden können, werden in der /etc/init.d/rc.dsld gebaut?

 

[PeterPawn]

Ich weiß ja nicht, von welcher Version/welchem Modell Du jetzt redest und was da ggf. von Freetz noch geändert wird ... aber in meiner AVM-Firmware (113.07.01 als Beispiel, andere Modelle initialisieren das Netzrwerk etwas anders und die 07.19 wirft das alles noch einmal über den Haufen) gibt es gar keine "rc.dsld", höchstens eine "rc.dsl.sh". Und die startet auch nicht wirklich den "dsld", sondern baut (wenn die neuere Variante "E40-dsl" nicht existiert) die passende Firmware für das DSL-Frontend zusammen (und lädt dann "old-style" auch noch den FPGA und vieles andere, was in der neuen Form in getrennten Dateien erfolgt).

Die eigentliche Initialisierung des Netzwerks (und auch der Start des "dsld" und weiterer, netzwerk-technisch wichtiger Services wie "multid") erfolgt in "E46-net" (beim erwähnten Modell mit der beschriebenen Version) bzw. in der - von diesem Skript aufgerufenen - "rc.net" und in letzterer findet sich dann auch der Start des "dsld". In der Startreihenfolge ist das halt die "Gruppe 4" - wie das in der "rc.S" aussieht (alles nur vor 07.19, wo sich das deutlich ändert) und wann welche Gruppen in welcher Reihenfolge "abgearbeitet" werden, kannst Du Dir in der eigenen Firmware genau ansehen. Diese "rc.net" ist es auch, die ggf. mehrfach aufgerufen wird und dann auch für "reload" zuständig ist ... auch für den "dsld", wo dann eigene Änderungen auch wieder flöten gehen (könnten).

Die Bridges für LAN und Gastnetz und ebenso natürlich die verschiedenen WAN-Interfaces - die erstellt erst der "dsld". Die LAN-Anschlüsse per se sind schon von Beginn an vorhanden - aber auch die werden dann (beim Start des "dsld") noch einmal durcheinander gewürfelt.

Welche Interfaces gerade existieren (also zu einem bestimmten Zeitpunkt), kannst Du leicht aus "/proc/net/dev" auslesen ... ein passendes "cat" in irgendeine Protokoll-Datei (am besten inkl. Marker, wo das aufgerufen wurde und mit "Anhängen" an die vorhandene Datei) kann man ja leicht selbst irgendwo in die Startdateien von AVM hineinbasteln (z.B. vor und nach dem Start des "dsld", wobei der - wie erwähnt - ein wenig braucht, bis sich da alles "gesettled" hat und man das dann eher mehrmals einbauen sollte in die danach ablaufenden Start-Skripte), wenn man die Abläufe analysieren will.

 

[WileC]

@PeterPawn Vielen dank erstmal für die ausführliche Erklärung. Ich werde mir das mal genauer anschauen...

Aber so überschlagen lässt sich eine Trennung des LAN und WLAN per rc.custom nicht einfach so bewerkstelligen, stimmts?

 

[PeterPawn]

Das sollte aber durch eine Änderung in der "ar7.cfg" schon funktionieren ... die Frage ist aber auch, wie strikt eine solche Trennung sein sollte oder ob das nur ein eigenes Subnetz wird.

Eine echte Aufteilung in drei wirklich voneinander getrennte Netze (LAN, Gastnetz und - als Beispiel - eine eigene DMZ), ist mit dem AVM-Stack eher schwierig (schon weil die bis zum Start des "dsld" alle zusammenhängen - nicht über eine Bridge, aber über den internen Switch) - da würde ich eher zu einem weiteren (NAT-)Router greifen, der WAN-seitig per L2TPv3 vom Zugriff auf parallel existierende Netze auf der WAN-Seite abgehalten wird.

 

[WileC]

Es gab früher, in den älteren Firmwares eigens von AVM, eine CheckBox in den Netzwerk-Einstellunge, ob man das WLAN in einem eigenen Netz haben wollte, oder alles zusammen (also gebrückt),

Ich würde gerne diese Einstellung wieder beleben, dass von mir aus die Bridge von eth0-eth3 sich im "lan" befinden und das Subnetz 192.168.178.0 hat (z.B.) und sich das WLAN im 192.168.179.0 (z.B.) befindet. Natürlich sollen LAN und WLAN untereinader "reden" können, also in jede Richtung ping-bar und erreichbar sein. Und natürlich letztendlich auf das WAN-Interface geroutet werden können, also so wie früher in den AVM-Firmwares...