Ich weiß tatsächlich nicht, ob man den "wland" zum Generieren einer Konfiguration für ein "offenes WLAN" bei der Rolle 7 "überreden" kann ... zumindest die Funktion für "cfg-set-role-config" (vom "wland_ctl" aus) gibt es dem Anschein nach im "wland" (vielleicht auch nur in dem für die Produktion) (noch?) nicht.
Damit wird eine dynamische Konfiguration für mich immer unwahrscheinlicher ... man müßte vermutlich(!) - ich betone gerne noch einmal, daß ich es ebenfalls nicht weiß - versuchen, die Konfiguration 14, 15 oder 16 irgendwie so anzupassen, daß in der resultierenden "wlan_dynamic.cfg" eben "security = none" erscheint für die STA-Rolle mit Interface "sta2".
==================================================================
Zum Steuern des "wland" gibt es "wland_ctl" ... das kann z.B. mit "wland_ctl --event reconfig" den "wland" darüber informieren, daß es Änderungen an der Konfiguration gegeben hat (das meint jetzt tatsächlich die "wlan.cfg", aber iirc werden auch die anderen Dateien dann neu gelesen - kann man aber auch wieder leicht selbst probieren, indem man einfach eine davon übermountet, ändert und dann schaut, ob die eigene Änderung Auswirkungen auf die "wlan_dynamic.cfg" hat) und diese nunmehr zu behandeln wären.
Man kann auch dem "wland" anstelle der "/var/flash/wlan.cfg" für eigene Versuche eine andere Datei "mitgeben" (dann muß man das nicht immer über Import machen), indem man ihn mit "wland -B -Dwlancfgfile=<filename>" aufruft ... das macht AVM beim Test in der Produktion auch so, wenn da mehrere Konstellationen durchgetestet werden - das ist dann auch eine gute Quelle für eigene Ideen, was man da zur Laufzeit am WLAN "schrauben" kann.
Auch die Ausgabe des "wland" (der generiert bei Problemen oder auch auf Anforderung entsprechende Support-Daten und zeigt die auch auf "/dev/console" an) kann hilfreich sein, wenn man auf der Suche nach Zusammenhängen ist ... eine Ausgabe des "wland" beim Umkonfigurieren des Gastnetzes(!) auf "unverschlüsselt" (bei gleichzeitiger Aktivierung) und zurück auf WPA2-CCMP sähe z.B. so aus:
Code:
WLAND:[03064]:01:44.08/[622503.89]:WLAND: configuring...
WLAND:[03064]:01:44.08/[622504.15]:derived config 'AP+Guest AP Dual', ID: 4 (0x00000000)
WLAND:[03064]:01:44.08/[622504.26]:role_4 changelist:
slave {
security = none;
enabled = yes;
}
WLAND:[03064]:01:44.08/[622504.26]:role_3 changelist:
slave {
security = none;
enabled = yes;
}
WLAND:[03064]:01:46.06/[622622.34]:WLAND: configuring...
WLAND:[03064]:01:46.07/[622622.61]:derived config 'AP+Guest AP Dual', ID: 4 (0x00000000)
WLAND:[03064]:01:46.07/[622622.74]:role_4 changelist:
slave {
security = wpa2-psk;
}
WLAND:[03064]:01:46.07/[622622.74]:role_3 changelist:
slave {
security = wpa2-psk;
}
Hier kann man schon einen Zusammenhang zwischen "configuration" und "role(s)" aus der "wlan_product.cfg" sehen, denn die Rollen 3 und 4, bei denen der "security"-Parameter geändert wird, sind ja die für die Interfaces "guest4" und "guest5", welche die beiden Gastnetze (jeweils auf ihrem Band) bereitstellen.
Der "wland" baut also aus verschiedenen Quellen am Ende eine Konfiguration zusammen, mit der die anderen Komponenten arbeiten ... ich bin nicht einmal sicher, daß die tatsächlich die Text-Datei aus "/var/tmp/wlan_dynamic.cfg" selbst auslesen und die nicht einfach nur der Protokollierung dient, während die verwendete Konfiguration über "shared memory" als Struktur durch die Gegend geschoben wird.
Aber das kriegt man eben auch nur heraus, wenn man die AVM-Komponenten selbst in entsprechende Wrapper verpackt (häufig hilft da schon eine Shell-Datei mit dem ursprünglichen Namen, die dann das umbenannte Binary aufruft, nachdem Parameter und Umgebung protokolliert wurden - sonst muß man halt selbst zum Compiler greifen und einen binären Wrapper bauen) und sich die Zusammenhänge schrittweise erarbeitet.
Gerade aufgrund der jüngsten Aktivitäten bei AVM mit Bezug auf das WLAN (vom Band-Steering bis hin zum "Mesh"), ändert sich da aber (zumindest meine Erfahrung) ohnehin alle Nase lang etwas (ist ja auch logisch, der "wland" auf einem "Mesh-Slave" muß ja seine Konfiguration auch irgendwie vom Master erhalten und das braucht entsprechende Mechanismen) - das macht einmal gewonnene Erkenntnisse auch sehr kurzlebig, wenn man Pech hat.
Die Frage wäre halt, was passiert, wenn der "wland" in der "wlan_product.cfg" für die Rolle 7 einen Eintrag "security" vorfindet ... ignoriert er den einfach und generiert dann trotzdem für diese Rolle ein "security = wpa2-psk" oder übernimmt er erst einmal alles aus dieser Datei und füllt nur die "Lücken" auf, die dann noch verbleiben. Das wäre jedenfalls die Stelle, wo ich als erstes ansetzen würde, wenn ich vor dem Problem stünde ... aber ob das am Ende hilft oder nicht, weiß ich auch nicht - aber das steht auch bereits seit #14 in meinen Beiträgen, daß man da halt (systematisch) testen muß. Zumindest sollte sich der "wland" auch beschweren, wenn er mit irgendeiner Eingabe aus einer Datei nicht klarkommt ... dann weiß man, daß er die Änderung nicht versteht oder man eben selbst beim Ändern Mist gebaut hat.
.
