Ok, ich kenne die aktuelle Version des ruKernelTools nicht ... ein Problem bei den geschilderten Änderungen kann irgendwann dann entstehen, wenn man diese Aktionen (bei laufender Box und damit laufendem ctlmgr - das ist die zentrale Komponente zur Verwaltung dieser Einstellungen) vornimmt und einige Randbedingungen nicht beachtet. Ich habe keine Ahnung, welche Vorkehrungen ein aktuelles ruKernelTool da treffen mag.
1. Deine Feststellung "aber nein, es bleibt so gespeichert" sollte maximal bis zur nächsten "regulären" Schreiboperation für die betreffende Konfigurationsdatei gelten, denn beim (eigenen) Schreiben verschlüsselt die Firmware derartige Einträge automatisch.
2. Es gibt eine Art "Cache" im "ctlmgr", in dem der (aus Sicht dieses Daemons) aktuelle Stand enthalten ist. Ändert man jetzt die betreffende Datei im Filesystem und setzt hinterher manuell (ctlmgr_ctl, set.lua) oder über das GUI einen Wert neu (es gibt auch ein paar Stellen, wo regelmäßig automatisch neu geschrieben wird), dann wird nicht nur der vorher geänderte Wert wieder verschlüsselt zu sehen sein ... es wird in aller Regel auch der Wert sein, der intern vom "ctlmgr" als gültig angesehen wird und das ist nicht der neue Wert in der Datei im Filesystem. Also muß man bei solchen Änderungen weitere Maßnahmen treffen ... z.B. den ctlmgr (ohne weitere Schreiboperationen, die eine Änderung ja sofort wieder rückgängig machen würden) beenden und neu starten, weil er dann tatsächlich den Inhalt der Datei neu einliest. Die Verwendung eines eher ältlichen Mechanismus (den Aufruf von speziellen Skripten, die auf "...cfgchanged" enden) ist nicht mehr zu empfehlen ... AVM paßt die schon sehr lange nicht mehr an Änderungen an und es kann gutgehen, muß es aber nicht. Einige machen auch umgehend einen Neustart nach solchen Änderungen, wobei der "ctlmgr" ja auch neu gestartet wird. Das ist aber eher die Holzhammer-Methode und bleibt mit einer kleinen Unsicherheit behaftet, weil der ctlmgr vor seiner Beendigung ja noch Schreiboperationen ausführen könnte. Der verwendet wohl auch eine Art "lazy write", damit mehrere aufeinanderfolgende Konfigurationsänderungen nicht jedesmal eine Schreiboperation für den Flash-Speicher auslösen - daher ist nicht einmal ein definierter Abstand zur letzten Änderung zu beziffern. Am besten ist es bei diesen Aktionen tatsächlich, den "ctlmgr" zu beenden, die Änderung vorzunehmen oder zu speichern (z.B. durch das Kopieren des vorbereiteten neuen Standes) und dann den "ctlmgr" wieder zu starten.
Wobei Punkt 2 auch nur einen alten Stand wiedergeben könnte ... das testet man kaum bei jeder Version aufs Neue - das kannst Du aber anhand des geschilderten Ablaufs und unter Verwendung des Programms "ctlmgr_ctl" in einer Telnet-Session (oder über das GUI) jederzeit selbst probieren. Sollte sich dort in letzter Zeit etwas getan haben (wobei ich nicht glaube, daß AVM vom "lazy write" abgehen würde, denn das hat ja auch den Zweck, die Schreiboperationen in den Flash signifikant zu verringern ... da dieses TFFS "transaktionssicher" ist, wird da auch keine Schreiboperation vom Dateisystemtreiber abgefedert), kannst Du uns ja dann die neuen Erkenntnisse zukommen lassen. Bei 06.23 sollte auch "decode_passwords" noch funktionieren, damit man beim Testen sehen kann, was da eigentlich in dem verschlüsselten Eintrag steht.
Zum vordefinierten WLAN-Schlüssel dachte ich bereits alles Notwendige geschrieben zu haben ... Du wolltest ja nur Stichworte und damit sollte man etwas finden. Abgesehen davon kann ich einfach nicht glauben, daß das ruKernelTool (wenn man froh ist, "mal ein wenig Maus zu schubsen") es verlernt haben soll, Environment-Variablen im Bootloader zu verändern.
Den Key aus der Finalisierung kriegt man nun mal nur mit einem Bootloader-Image und einem Hex-Editor geändert ... das hat aber mit "recovery-fest" nichts zu tun, dafür reicht bereits die Änderung im Environment über die passenden Kommandos (oder über die traktierte Maus, die sich sicherlich auch etwas Schöneres vorstellen könnte, als permanent durch die Gegend geschubst zu werden - und so ein Tierchen fällt deutlich unter das Tierschutzgesetz).
Wenn Du etwas weitersuchst, wirst Du auch feststellen, daß nach so einer Änderung des "wlan_key"-Wertes (wie auch bei "maca") zwingend ein Zurücksetzen auf die Werkseinstellungen erfolgen muß (das ist gar nicht so einfach über das GUI, weil man sich nämlich nicht mehr anmelden kann nach so einer Änderung im Bootloader) ... der Wert von "maca" und "wlan_key" wird für die erwähnte Verschlüsselung der - im FRITZ!OS immer mit reversibler Verschlüsselung gespeicherten - Credentials herangezogen und zu diesen Werten gehören auch die Namen und Kennwörter aller FRITZ!Box-Benutzer.
Eine Alternative ist nach so einer Änderung die Verwendung des AVM-Recovery-Programms (und nicht des ruKernelTools), weil das eben (siehe #2) anders als das ruKernelTool das TFFS-Image "richtig" schreibt und nicht einfach nur den Flash an dieser Stelle löscht (worauf dann wieder der Wert aus der Finalisierung geladen wird). Damit wird dann auch der geänderte "wlan_key" in dieses TFFS-Image vom Recovery-Programm eingebaut und die Box startet mit dem neuen "wlan_key" und der eingetragenen "maca"-Adresse ... nun kann sie selbst leere Werte (so sehen die Standardeinstellungen in der Regel aus) unter Zuhilfenahme der neuen Angaben im Environment ver- und später wieder entschlüsseln.
Solange Du ansonsten nicht endlich konkreter wirst, was Du eigentlich vorhast und was "noch ein paar andere Dinge" sein mögen, wirst Du kaum sinnvolle Antworten erhalten können und jedes "Schubsen" kann - egal in welche Richtung - nur als Rempelei enden.
Es gibt eine Möglichkeit, einige Werte "reset-fest" zu setzen ... das klappt aber auch nur dauerhaft, wenn man genau auf "recovery-fest" gar keinen Wert legt, weil bei Recovery eben diese Einstellungen wieder dahin wären ... u.a. deshalb gibt es bei derartig konfigurierten Boxen keine Möglichkeit, das AVM-Recovery-Programm zu verwenden, wenn ein entsprechender "Schutzschalter" (die Variable "provider" im Environment ist dafür zuständig) gesetzt wurde.
