Ist gluon-core.@wireless[0].preserve_channels gesetzt?
In diesem Fall wird der eingestellte Wireless Kanal beim aktivieren des Outdoor modes nicht geändert.
das „preserve_channels“ kannte ich bislang nur als Feature für Sysupgrades, dass die lokalen Settings nicht überschrieben werden beim jeweils folgenden Update.
Wenn sich das ausschließen sollte mit Outdoor-Betrieb („weil DFS so ähnlich ist wie Autoupdater?“), dann wäre das natürlich schade.
preserve_channels sorgt dafür, dass Gluon die gesetzten WiFi channels nicht ändert.
Aktiviere ich nun den Outdoor mode nachdem preserve_channels aktiviert wurde, so ändert Gluon auch nicht den verwendeten 5GHz Kanal. Anders herum ändert Gluon den Outdoor Kanal auch nicht zurück auf einen indoor Kanal wenn preserve_channels nach aktivieren des Outdoor modes aktiviert wurde.
das ist mir leider jetzt auch klar.
das „preserve-wifichannels“ haben wir aktiviert, weil viele für ihre (lanmesh-vernetzten) Indoor-Setups „für mehr airtime“ die Kanäle gewechselt haben und bei einem Autoupdate die nicht verlieren möchten.
Das ist default in der Firmware…
Wenn ich das nicht trennen lässt, dann müssen die wenigen Outdoor-user das „Preserve-Wifichannel“ halt nach dem Autoupdate entfernen (wenn ich die Mechanik richtig verstehe).
1 „Gefällt mir“
Das ist korrekt.
Ich verstehe zwar die Logik dahinter nicht, warum diese Kreuzabhängigkeit zwischen „Autoupdater-preserve-Wifichannel“ und „dfs-ignore/no-outdoormode“ gibt. Vielleicht lässt sich das ja entkoppeln indem man da zwei unterschiedliche „preserve_channels“-settings draus macht.
p.s. auf einem unifi-ac-mesh unter Gluon 2020.1.3
uci set gluon-core.@wireless[0].preserve_channels=0
uci set gluon.wireless.outdoor=1
uci commit
gluon-reconfigure
wifi
reboot
(ja, das war vermutlich etwas übertrieben, aber sicher ist sicher)
uci show |grep channels
wireless.radio0.channels='100-140'
aber iwinfo meint immernoch, er wäre auf Kanal 44:
iwinfo
client0 ESSID: "Freifunk"
Access Point: 22:67:85:45:20:70
Mode: Master Channel: 44 (5.220 GHz)Magst du einmal die komplette wireless config sowie den syslog teilen?
Danke. Du musst den preserve_channels key komplett löschen, damit der neue Kanal eingestellt wird.
(Das hängt übrigens nicht mit dem Outdoor mode zusammen, das ist schon immer so).
Ansonsten hast du eine chanlist, hostapd zieht diese allerdings nur hinzu, wenn ACS durchgeführt werden muss (bspw. bei einem DFS event oder beim initialen aktivieren des interfaces). Dein channel ist allerdings weiterhin auf 44 gestellt (Muss auto sein).
Ich bin mir an dieser Stelle aber auch nicht sicher, wie das bei dir in Taiwan mit den verfügbaren Channels aussieht. GGF. sind die DFS Kanäle dort nicht verfügbar.
1 „Gefällt mir“
Schade, dass sich der nicht unabhängig von 2.4 und 5GHz setzen lässt und nicht „sowohl für autoupdater wie für outdoormode“ bezieht.
Da die Mehrzahl der Leute ihre Router hier drinnen hängen haben aber das „keep-radiochannels“ brauchen, lassen wir das besser drin in der Firmware.
Wie wäre es denn mit einem PR für benötigte Features?
Ich verstehe es nicht, wenn sich überall beschwert wird, aber ein Upstream PR von den Leuten, die Firmware bauen und das damit vermutlich technisch hinbekommen, nicht drin ist. The same procedure as every time…
Viele Grüße
margau
Ach Du meinst so wie mit der Offline-SSID?
Du sagst es. Gluon-PRs sorgen nicht dafür, dass einem das Hobby mehr Spass macht.
1 „Gefällt mir“
Du kannst das ganze kombinieren, indem du beim update das preserve_channels flag entfernst, wenn der eingestellte Channel dem in der Site bestimmten Channel übereinstimmt.
Das Flag ist dazu gedacht, den User-Intent zu speichern. Ich sehe das Problem, vor dem du stehst, allerdings ist das Automatische Einstellen des Flags an der stelle Kontraproduktiv.
Was ich allerdings aus dem ganzen mitnehme, ist dass die aktivierung des outdoor-modes im Config mode am besten nicht möglich sein sollte, sofern preserve_channels aktiviert ist.
ich werde die Zeile, die auf „preserve-channels“ triggert in ./gluon-core/luasrc/lib/gluon/upgrade/200-wireless einfach auf irgendwas a la „preserve-channels-outdoor“ patchen. Dann können diejenigen, die es „immernoch“ wollen das entsprechend setzen. ansonsten kommt eben Kanal „auto“
P.S: untested: firmware/ignore-preservechannels-for-outdoormode.patch at v2020.1.x · eulenfunk/firmware · GitHub
@adorfer
Als wir das „preserve-channels“ defaultmässig noch in der Firmware hatten, da haben wir es ähnlich gemacht wie Du.
Ganz einfach umgedreht und „Outdoor“ gewinnt immer anstelle von „preserve-channels“ gewinnt immer.
Edit:
Und den Outdoor-Modus hatten wir testweise als „Opt-in“ und nicht als „Opt-out“ im Konfigmodus.
Das hat ganz gut zusammengespielt.
1 „Gefällt mir“
Die Mechanik bei meinem patch ist jetzt:
- ein gesetztes „gluon-core.@wireless[0].preserve_channel“ wird von einem gluon.wireless.outdoor=1 „überstimmt“
- wer wirklich trotz outdoormode den Wifi5-Kanal festnageln wollen sollte muss einen key „gluon-core.@wireless[0].force_channel_outdoor“ setzen.
1 „Gefällt mir“
So richtig glücklich werde ich damit nicht mit UnifiACmesh outdoor.
Entweder „plötzlich“ gibt es keine Clients mehr auf 5GHz, die Airtime ist 100% frei und der Noise-Level bei konstant -127/128dBm.
Tue Jul 7 13:50:12 2020 daemon.notice hostapd: ACS: Survey is missing noise floor
Tue Jul 7 13:50:12 2020 daemon.notice hostapd: ACS: Survey is missing channel time
Tue Jul 7 13:50:12 2020 daemon.notice hostapd: ACS: Survey is missing RX and busy time (at least o
Tue Jul 7 13:50:12 2020 daemon.notice hostapd: client0: ACS-COMPLETED freq=5700 channel=140
Tue Jul 7 13:50:12 2020 daemon.notice hostapd: client0: interface state ACS->DFS
Tue Jul 7 13:50:12 2020 daemon.notice hostapd: client0: DFS-CAC-START freq=5700 chan=140
Tue Jul 7 13:50:53 2020 daemon.err gluon-radv-filterd[2190]: Unable to find TQ for originator 02:c
Tue Jul 7 13:51:16 2020 daemon.notice hostapd: client0: DFS-CAC-COMPLETED success=1 freq=5700 ht_e
Tue Jul 7 13:51:18 2020 daemon.notice hostapd: client0: DFS-PRE-CAC-EXPIRED freq=5700 ht_enabled=0
[..]
root@HLG-7483c2c92322:~# iwinfo
client0 ESSID: "Freifunk"
Access Point: 06:13:C5:20:93:40
Mode: Master Channel: unknown (5.000 GHz)
Tx-Power: 26 dBm Link Quality: unknown/70
Signal: unknown Noise: -99 dBm
Bit Rate: unknown
Encryption: none
Type: nl80211 HW Mode(s): 802.11nac
Hardware: 168C:003C 0000:0000 [Qualcomm Atheros QCA9880]
TX power offset: none
Frequency offset: none
Supports VAPs: yes PHY name: phy0
Oder aber der Wifi-Kanal ist gleich komplett weg.
was dann nicht hilft:
wifi up
wifi down; wifi up
wifi down; wifi config; wifi up
was (meist) hilft als workaround
wifi down; killall hostapd; wifi config; wifi up
aber halt nicht immer… further investigation needed.
zu dem Thema „DFS-PRE-CAC-EXPIRED“
führt mich Google zu diesem dieser Openwrt/hostapd/ath10k-Bug von 2018
FS#1385 : Unable to set up repeater on DFS-channel
ein paar Tage später… mit Trial and Error und ein paar Workaround-script-Iterationen weiter, etwas mehr Klarheit:
- der Hostapd im 2020.1.x-Gluon mag es nicht, ein SigHUP zu bekommen während er gerade DFS-Scanning macht (evtl. mag er es auch zu anderen Zeiten nicht). Ergebnis ist dann ein irgendwie undefinierter Zustand, der sich entweder äußert in
- PID im pidfile passt nicht zur PID in der Tasklist
- es gibt eine Meldung „DFS-PRE-CAC-EXPIRED“ und nie wieder eine weitere Meldung vom Hostapd
- das Radio-Interface ist gemäß „wifi status“ „down“ und status „pending“, trotz vorherigem „wifi up“
Workaround?
Fork vom Offline-SSID-Script, aufruf eines check-Workaround-scripts nach dem „killall -HUP hostapd“, Zeile 174ff
und dann das Checkscript, was
a) mismatching PIDs (main issue) mit einem Wifi-Restart rettet
und
b) longer pending interfaces (script läuft auch in der Cron alle paar Minunten) erkennt und auch dann das wifi restartet.
Falls jemand bessere Vorschläge hat (außer „Muss upstream gefixed werden, also upstream, vom upstream vom upstream“, also entweder in openwert, im Hostapd oder im Linuxkernel)
Was ich mir vorstellen könnte:
- nur das betroffene Phy neu starten
- den Lock-Zustand anders/besser erkennen
- das gerade laufende DFS-Scanning erkennen oder dem Hostapd dafür ein Locking zu verpassen (was in beide Richtungen „wirkt“). Und nein, nicht per „swatch“ (tried, not 100% success) auf dem syslog lauschen. direkt auf dem ubus?
- den hostapd irgendwie sinnvoll patchen, dass er den Fehlerzustand selbst erkennt und restartet.
4 „Gefällt mir“
Ich denke, das wäre eine bessere Lösung. Wie kann man das Erkennen?
Das Problem ist, dass es -für mich erkennbar- kein Locking gibt. Also nichts was einen sichergehen lässt, dass wenn „gerade im syslog nix von dfs-scan steht“, dass man dann für x Sekunden „freie Bahn“ hat für ein sigHUP an den hostapd.
Meiner Meinung nach wäre es sinnvoller, wenn der Hostapd selbst den Fehlerzustand „nicht passende PID“ nicht nur erkennen (und ins Log schreiben), sondern sich neu starten oder notfall sterminieren würde (dann könnten systemd&co sich um einen Restart kümmern)