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

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

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.