Outdoor Mode in gluon2020.1.x "DFS-PRE-CAC-EXPIRED"

plaste · July 3, 2020, 8:39pm

Hallo zusammen,

ich würde gerne ein Setup von bestehenden Outdoor FF Routern (UniFi AC-Mesh @gluon 2018.2.x) auf gluon 2020.1.x updaten und sicherstellen, dass diese nach dem Update den Outdoor Mode nutzen.
Soweit ich es verstanden habe, muss nach einem Update der Outdoor Mode noch aktiviert werden, was ich wie folgt getan habe:

uci set gluon.wireless.outdoor='1'
uci commit
gluon-reconfigure
reboot

Nachdem reboot wird von den Freifunk-Knoten das Wifi allerdings weiterhin auf Kanal 44 ausgesendet, trotz aktiviertem outdoor mode. Ist das korrekt? Meine Erwartung wäre gewesen, dass nach dem Neustart ein Wifi Channel zwischen 100 und 140 genutzt wird. Wie aktiviert man den Outdoor Mode und wann werden die outdoor Channels genutzt? Muss der Wechsel erst durch ein DFS Event getriggert werden?

wifi5 in der site.conf:

 wifi5 = {
    channel = 44,
    outdoor_chanlist = '100-140',
    htmode = 'HT40',
    ap = {
      ssid = 'Freifunk',
    },
    mesh = {
      id = 'hlg-mesh',
      mcast_rate = 12000,
      disabled = false,

Danke vorab für eure Hilfe.
LG

E-Mail-Adresse dieser Kategorie zur „Mailingslisten-Nutzung“: gluon@forum.freifunk.net

blocktrron · July 4, 2020, 10:34am

Ist gluon-core.@wireless[0].preserve_channels gesetzt?

In diesem Fall wird der eingestellte Wireless Kanal beim aktivieren des Outdoor modes nicht geändert.

adorfer · July 4, 2020, 2:52pm

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.

blocktrron · July 4, 2020, 4:38pm

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.

adorfer · July 4, 2020, 5:50pm

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).

blocktrron · July 4, 2020, 6:35pm

Das ist korrekt.

adorfer · July 4, 2020, 6:40pm

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)

blocktrron · July 4, 2020, 8:37pm

Magst du einmal die komplette wireless config sowie den syslog teilen?

adorfer · July 4, 2020, 8:53pm

Voila:

https://paste.debian.net/1155145/

blocktrron · July 4, 2020, 9:13pm

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.

adorfer · July 4, 2020, 9:32pm

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.

margau · July 4, 2020, 9:38pm

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

adorfer · July 4, 2020, 9:40pm

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.

blocktrron · July 4, 2020, 9:40pm

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.

adorfer · July 4, 2020, 11:27pm

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/patches/ignore-preservechannels-for-outdoormode.patch at v2020.1.x · eulenfunk/firmware · GitHub

Jason · July 5, 2020, 11:07am

@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.

github.com

freifunk-ffm/site-ffffm/blob/test/patches/003-Fix-outdoor-mode-in-combination-with-preserve_channels.patch.after_make_update

diff --git a/package/gluon-core/luasrc/lib/gluon/upgrade/200-wireless b/package/gluon-core/luasrc/lib/gluon/upgrade/200-wireless
index eb120404..a4ea378d 100755
--- a/package/gluon-core/luasrc/lib/gluon/upgrade/200-wireless
+++ b/package/gluon-core/luasrc/lib/gluon/upgrade/200-wireless
@@ -53,12 +53,12 @@ end
 
 local function get_channel(radio, config)
	local channel
-	if uci:get_first('gluon-core', 'wireless', 'preserve_channels') then
-		-- preserved channel always wins
-		channel = radio.channel
-	elseif  (radio.hwmode == '11a' or radio.hwmode == '11na') and is_outdoor() then
-		-- actual channel will be picked and probed from chanlist
+	if  (radio.hwmode == '11a' or radio.hwmode == '11na') and is_outdoor() then
+		-- outdoor always wins
		channel = 'auto'
+	elseif uci:get_first('gluon-core', 'wireless', 'preserve_channels') then
+		-- actual channel will be restored
+		channel = radio.channel
	end

Diese Datei wurde abgeschnitten. Original zeigen

Edit:
Und den Outdoor-Modus hatten wir testweise als „Opt-in“ und nicht als „Opt-out“ im Konfigmodus.
Das hat ganz gut zusammengespielt.

adorfer · July 5, 2020, 2:04pm

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.

adorfer · July 7, 2020, 12:04pm

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.

grafik

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 · Issue #6313 · openwrt/openwrt · GitHub

adorfer · July 16, 2020, 10:52pm

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

github.com

eulenfunk/packages/blob/63de2320506b7b806b478e295c24eb39c4ab3273/gluon-ssid-changer/shsrc/ssid-changer.sh

#!/bin/sh

#################
# safety checks #
#################
safety_exit() {
	echo $1, exiting with error code 2
	exit 2
}
pgrep -f autoupdater >/dev/null && safety_exit 'autoupdater running'
UT=$(sed 's/\..*//g' /proc/uptime)
[ $UT -gt 60 ] || safety_exit 'less than one minute'
[ $(find /var/run -name hostapd-phy* | wc -l) -gt 0 ] || safety_exit 'no hostapd-phy*'

# only once every timeframe minutes the SSID will change to the Offline-SSID
# (set to 1 minute to change immediately every time the router gets offline)
MINUTES="$(uci -q get ssid-changer.settings.switch_timeframe)"
: ${MINUTES:=30}

# the first few minutes directly after reboot within which an Offline-SSID always may be activated

Diese Datei wurde abgeschnitten. Original zeigen

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.

github.com

eulenfunk/packages/blob/v2020.1.x/eulenfunk-hotfix/files/lib/gluon/eulenfunk-hotfix/check_hostapd.sh

#!/bin/sh
# check_hostapd for matching pids
restart_wifi() {
  logger -s -t "eulenfunk-checkhostapd" "wifi hard restart"
  wifi down
  killall hostapd 2>/dev/null
  rm -f /tmp/hostapd.*.core 2>/dev/null
  rm -f /var/run/wifi-*.pid 2>/dev/null
  wifi config
  wifi up
  sleep 60
}

pspid="$1"
phy=$(echo $@|sed 's/.*-B\ //g'|cut -d" " -f1|sed 's/.*hostapd-//g'|cut -d"." -f1)
if [ ${phy:0:3} = "phy" ] ; then
  pidfile=$(echo $@|sed 's/.*-P\ //g'|cut -d" " -f1)
  pid=$(cat $pidfile 2>/dev/null)
  sema="/tmp/hostapdpid"
  if [ "$pid" = "${pspid%% *}" ] ; then

Diese Datei wurde abgeschnitten. Original zeigen

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.

rubo77 · July 21, 2020, 10:43pm

Ich denke, das wäre eine bessere Lösung. Wie kann man das Erkennen?