Kann man auf der Konsole die Konfiguration eines Routers so ändern, dass dieser eine zweite SSID neben der Freifunk client SSID aussendet, die aber im selben Netz ist?
Die private SSID wireless.wan_radio0.ssid ist hierfür nicht geeignet, da man darüber nicht mit dem Freifunk-Netz verbunden wäre.
Solange das network auf client steht, kannst Du so viele SSIDs erstellen, wie der Wifi-Chipsatz erlaubt (iw phy phy0 info|grep -A2 valid).
uci set wireless.client_radio0_offline=wifi-iface
uci set wireless.client_radio0_offline.network='client'
uci set wireless.client_radio0_offline.device='radio0'
uci set wireless.client_radio0_offline.mode='ap'
uci set wireless.client_radio0_offline.ssid='Freifunk-Offline'
Um das ganze update-sicher zu machen, braucht es ggf. noch ein paar mehr Schritte.
Bin mir gerade nicht sicher, was Gluon beim Upgrade mit „fremden“ Wifi-Interfaces macht.
Das könnte man beim Booten / Upgrade (/lib/gluon/upgrade/) auf Vorhandensein prüfen und ggf. erstellen, und im SSID-Changer dann einfach enablen oder disablen.
Achja, das Upgrade-Script kann dann, damit es selbst das Upgrade überlebt in der /etc/sysupgrade.conf hinterlegt werden.
Macht natürlich nur Sinn, wenn es nicht direkt mit ins Package übernommen und beim Gluon-Build eh schon da ist.
OK, vor jede Zeile dann ein uci set setzen.
kann ich dann nicht einfach in dem gluon-site-changer script die Zeilen austauschen, die die SSID ändern? Stattdessen da dann einfach die paar uci befehle absetzen?
Das braucht ja da in dem Fall nicht update-safe zu sein, sondern nur, wenn der Router offline ist die zusätzliche SSID ergänzen.
Falls man die zusätzliche SSID immer haben will, sollte das natürlich Updatesicher sein
Könnte klappen. Ich weiss nur nicht, wie sich uci verhält, wenn es die Einträge schon gibt.
klappt!
muss noch
uci set wireless.client_radio0_offline.disabled='0'
uci commit wireless.client_radio0_offline
wifi
und zum disablen dann:
uci set wireless.client_radio0_offline.disabled='1'
uci commit wireless.client_radio0_offline
wifi
habs in dem branch hier eingebaut:
@rubo77 auf die von dir gebaute art schreibste dir ständig auf den chip, das geht bestimmt lange gut, früher hiess es man solle das nicht so oft machen.
kleine Gedankenreise von mir dazu :
uci commit überschreibt die Dateien in der Config - in diesem fall in /etc/config/wireless … der commit ist aber garnicht nötig wenn dort schon das IF was du da mit den Parametern hinzufügst steht, genau genommen reicht zu checken, gibt es dein IF dort schon, wenn nein füge es hinzu (mit uci commit) und danach nur das entsprechende ifconfig up und down von dem spezifischen IF zu nehmen
das ganze wifi führt immer wieder dazu die config datei neu einzulesen (was ja kein problem ist, halt ein kleiner hickser)
mit dem schreiben in die /etc/config/wireless beantwortet sich auch die Frage ob das update/rebootfest ist : mit uci commit, ja - das wird bestenfalls überschrieben mit neuen default IF foo.
hier hatte ich mal einen ähnlichen Spass … mit anderen fallstricken, könnte dich interessieren
Scheint, du hast da Plan. Wäre cool, wenn du in meinem repo einen pr Machen könntest, wo nicht mehr auf den Flash geschrieben werden muss
ne das musste schon selber machen, weil man das strukturell komplett umbauen muss
also entweder du schaust dir die hostapd sachen von dem ssid-twitterer ab, da brauchste kein if, bzw. schaust wie du ein IF hoch nehmen kannst ohne in den configs rumzuschreiben. (= uci commit ) - dann entfällt auch wifi
oder , du baust einen check ob das bereits in der config steht, und wenn nein, schreib es rein, commit - wifi und wenn ja - dann kannste schlicht das if up oder down nehmen.
bin mir grad nicht mal sicher ob wenn du nur in das overlay schreibst, also ohne commit, wifi trotzdem aus dem overlay liest - das liegt afaik im ram. dann dürfte einfach das entfernen der commits reichen - dein if steht ja hardcoded im script drin
(anmerkung für mitleser mit fragezeichen : wifi ist ein kleines programm das etc/config/wireless ausliest und die if neu aufbaut - liest intext nur komisch)
mein /var/run/hostapd-phy0.conf sieht nun so aus:
interface=client0
ctrl_interface=/var/run/hostapd
ap_isolate=1
disassoc_low_ack=1
preamble=1
wmm_enabled=1
ignore_broadcast_ssid=0
uapsd_advertisement_enabled=1
auth_algs=1
wpa=0
ssid=http://kiel.freifunk.net/
bridge=br-client
bssid=a2:f5:c2:d8:b7:7c
bss=wlan0-2
ctrl_interface=/var/run/hostapd
ap_isolate=1
disassoc_low_ack=1
preamble=1
wmm_enabled=1
ignore_broadcast_ssid=0
uapsd_advertisement_enabled=1
auth_algs=1
wpa=0
ssid=FF kein Netz:JacquesNorris
bridge=br-client
bssid=a0:f3:c1:d8:b7:7c
Ich habe versucht in der Datei einfach den block für die bss=wlan0-2 löschen, aber das hat nichts gebracht.
Ich habe jetzt eine neue Version erstellt, die nur falls sich die TX zum Gateway ändert, einen uci befehl macht und wifi:
Wie könnte man das ohne wifi lösen? (dabei werden ja immer alle Clients rausgeschmissen)
Ich habe es rausgefunden, dank @Brother_Lal
man muss im file /var/run/hostapd-phy0.conf die Zeile
ignore_broadcast_ssid=0
auf
ignore_broadcast_ssid=1
setzen, und dann dem hostapd einen SIGHUP senden mit
killall -SIGHUP hostapd
Hier die erste lauffähige Version des pakets: [gluon-ssid-changer][1]
[1]: GitHub - rubo77/gluon-ssid-changer at ssid-notifier
Vielleicht kann da mal jemand drüber schauen, ob das jetzt wirklich ohne Schreibzugriff auf den Flash auskommt? @MrMM @anon75826926
Ich werde das morgen mal mit einem dualbandgerät testen, ob da die interfaces auch so heissen
hm, jedes uci commit schreibt in den flash , egal wo … hier hast du zumindest erreicht das das nur noch passiert wenn offline ssid wechselt
(achtung das betrifft auch den reboot … denn batman ttq baut sich von 0 an nach oben hin auf) …
kannste nach reboot beobachten … einfach mal in kurzem abstand batctl gwl prüfen
und das bedeutet nach einem reboot, 2 mal mind uci commit … einmal weil „offline“ , einmal weil dann recht fix wieder „online“ …
an orten wo die verhältnisse schlecht sind (an der grenze zu deinen limits) eskaliert das mit dem schreiben dann quasi zu alle paar minuten … bei vielen hundert tausend schreibzyklen vielleicht noch kein problem
mal so fabuliert, an so einem Grenzfall node … alle 5 minuten 2 uci commit = 12 * 2 pro stunde = 288 * 2 pro tag = 105120 * 2 pro jahr …
vielleicht solltest du mal nachlesen The UCI System [Old OpenWrt Wiki] und dort unter commit
Eine unbeantwortete Frage: wifi nutzt uci oder die raw-config-file aus dem flash oder dem overlay? je nachdem sind commits überflüssig ! kannste einfach mal testen
wifi selbst macht kein de-auth wie du oben vermutest
Wieso sollte er noch mal uci commit machen?
ich dachte einmal initial nach dem flashen der firmware wird dies
gesetzt, und dann ist der wert doch gesetzt, auch nach einem reboot und für den seeeeeehr seltenen fall, dass der hostname wechselt.
dachte ich.
also sollten keine weiteren commits kommen, wenn der Router einmal läuft, oder?
deine jetzige Version enthält commit in unterschiedlichen kontexxten, nicht nur bei der if exist abfrage: schnell nachgesehen : in zeile 84 71 45 49
ich hab da mitlerweile genug zu geschrieben, bitte versuch für dich nochmal zu verstehen
Ja, ich bin auch sehr dankbar für deine Hilfe. Ich hatte den Code ja seit deinem letzten Kommentar stark umgebaut.
Ich hab das so verstanden: jeder uci commit schreibt die aktuellen werte in die config files in /etc/config/ (schreibzugriff!) und bei wifi werden aus diesen config files die ganzen verschiedenen netzwerkconfigs in diversen Ordnern neu geschrieben (schreibzugriff!).
Deshalb hab ich uci commits auf die besagten Zeilen 45, 49, 71 und 84 reduziert die eigentlich nur einmal beim ersten aufruf, direkt nach der installation aufgerufen werden sollten. Auch wifi wird nur an diesen 4 stellen aufgerufen.
Im Betrieb sollte mit meinen Änderungen so eigentlich kein Schreibzugriff mehr passieren. Das zusätzliche WLAN wird im hostadp direkt mit awk Befelen und ohne wifi eingepflegt und durch einen SIGHUB neu gestartet. das sollte doch ohne Schreibzugriff passieren oder? (sofern der var/run/ Ordner im RAM liegt???)
Habe ich dort einen Fehler im Workflow eingebaut? Werden die Stellen eventuell doch öfter aktiv als beabsichtigt?
Falls jemand lust hat, mit zu entwickeln, ich nehme gerne Pull Requests an