Prima wäre dann noch die Rückmeldung was denn davon noch funktioniert.
In aktueller Firmware (Boxen s. Signatur) sind die ganzen *cfgchanged-Kommandos nur noch Shell-Skripte.
Bei ar7cfgchanged werden diverse Netzwerk-Dienste neu gestartet (rc.net reload) - man könnte fast sagen: alle -, darunter auch die DSL-Verbindung und damit natürliche auch alle VPN-Verbindungen.
voipcfgchanged dürfte
ohne Parameter (reload oder voipdrestart) eigentlich nicht mehr funktionieren, beeinflußt aber wirklich nur den voipd (und ggf. 'telefon'/'csvd', da gibt es wohl auch noch Abhängigkeiten).
Das dritte Script im Bunde (wlancfgchanged) startet auch nicht nur das WLAN neu, sondern ebenso den Media-Server (und bei einigen Modellen noch andere abhängige Dienste, vermutlich all diejenigen, die explizit an bestimmte Interfaces gebunden sind und wo das WLAN zu diesen Interfaces gehört).
Wegen des kompletten Neustarts so ziemlich aller Dienste, die auf das Netzwerk zugreifen, bei ar7cfgchanged versuche
ich diesen Aufruf zu vermeiden (ich könnte dann ja auch gleich selbst rc.net aufrufen). Solange man
sicher weiß (oder es sich zumindest einbildet, es zu wissen - wie in meinem Falle), wo sich die Änderung auswirkt, reicht es auch aus, wenn man für gescriptete - nicht manuelle (!) - Änderungen den ctlmgr "abschießt" (ctlmgr -s), die Änderungen vornimmt und anschließend den ctlmgr neu startet.
Das gilt aber ausdrücklich nicht für Remote-Zugriffe, beim Stoppen des ctlmgr ist man - eben je nach Konfiguration der Box - auch mal schneller aus dem WAN geworfen, als einem lieb ist. Wenn dann das Shell-Script auch abgebrochen wird, kommt der ctlmgr ggf. gar nicht neu in die Gänge.
Beim Stoppen/Starten des ctlmgr werden zwar einige Dienste auch neu gestartet (meist mindestens WLAN und CAPIoverTCP, es hängt aber wirklich sehr viel von der WAN-Konfiguration und dem Box-Modell ab), es geht aber normalerweise wesentlich schneller als 'rc.net reload' und
in den meisten Fällen wird nicht einmal die PPPoE-Verbindung ab- und neu aufgebaut (was dann ja wieder weitere Aktionen wie DynDNS-Updates usw. nach sich ziehen würde). Generell gilt aber, daß das oben angeführte nur für
kurze Unterbrechungen der Ausführung des ctlmgr geeignet ist. Wenn andere Komponenten über die IPC-Mechanismen auf den ctlmgr zugreifen wollen und er nicht aktiv ist, sind die Folgen schwer voraussagbar und hängen von der Fehlerbehandlung in dieser Komponente ab.
@PsychoMantis:
Zum Verhalten des ctlmgr gäbe es sicherlich noch einiges zu sagen. In Anbetracht von rollos Ermahnung mach bitte einen eigenen Thread dafür auf (z.B. in Modifikationen), dann stelle ich da auch gerne mal ein Script rein, mit dem man das "Cachen" des ctlmgr für bestimmte Konfig-Files (mich interessiert nur das Verhalten bei bestimmten) automatisiert prüfen kann. Ich benutze das u.a. bei jedem Erscheinen einer neuen Firmware - einfach um zu prüfen, ob dort Änderungen im Verhalten erfolgt sind.
