prevent non operational status after sigHUP,

[rubo77]

https://forum.freifunk.net/t/outdoor-mode-in-gluon2020-1-x-dfs-pre-cac-expired/22128/20?u=rubo77

eulenfunk@1893c69#commitcomment-40789534

How could we detect a running DFS scan

[Adorfer]

please be aware that the scenario may not be limited to "when in DFS scanning mode".
Generally it's:

• hostapd does not like -HUP
• hostapd does not like to wifi (in order to restart)
  It can only be fixed upstream of upstream.

[rubo77]

Since when does -HUP make such problems?

If so, we would have to add this fix to ssid-changer:
https://github.com/eulenfunk/packages/blob/v2020.1.x/eulenfunk-hotfix/files/lib/gluon/eulenfunk-hotfix/check_hostapd.sh

[rubo77]

Maybe related:

Another point to consider here is that reloading the hostapd config leads to radios operating on DFS frequencies to re-perform CAC, which will stop clients from connecting for 60 seconds. I just came across this yesterday when preparing patches for another hostapd issues but this might be a bug in hostapd.

Also this implementation will break with recent OpenWrt due to hostapd not being spawned on a per-PHY base.

freifunk-gluon/gluon#1649 (comment)

[Adorfer]

ince when does -HUP make such problems?

unknown, just stumblend upon this due to first use of autochannel/outdoor-mode.
in other words: if PIDs do not match, kill hostapd hard and restart it.

i do not see an easy solution for the moment.

[rubo77]

so if we would disable the ssid-changer on nodes with outdoor mode, we would be on the safe side?

[Adorfer]

that's not for sure. I can only say i observiced it in the outdoor-scenario. perhaps it's happening on 2.4G radios too if e.g. channel is set to "auto" (in an "no-mesh-active on radio, ap-only" configuration)