search

Freifunk-Nord / gluon-ssid-changer

Other
1 stars 10 forks source link

prevent non operational status after sigHUP, #26

Open rubo77 opened 4 years ago

rubo77 commented 4 years ago

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

https://github.com/eulenfunk/gluon-ssid-changer/commit/1893c695906d43dfe77156ff2a2eece60f417213#commitcomment-40789534

How could we detect a running DFS scan

Adorfer commented 4 years ago

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

rubo77 commented 4 years ago

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 commented 4 years ago

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.

https://github.com/freifunk-gluon/gluon/pull/1649#issuecomment-653930041

Adorfer commented 4 years ago

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 commented 4 years ago

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

Adorfer commented 4 years ago

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)