Bob Cantor bea9380149 mac80211: fix no_reload logic (FS#3902) ... If drv_mac80211_setup is called twice with the same wifi configuration, then the second call returns early with error HOSTAPD_START_FAILED. (wifi works nevertheless, despite the fact that setup is incomplete. But "ubus call network.wireless status" erroneously reports that radio0 is down.) The relevant part of drv_mac80211_setup is, if [ "$no_reload" != "0" ]; then add_ap=1 ubus wait_for hostapd local hostapd_res="$(ubus call hostapd config_add "{\"iface\":\"$primary_ap\", \"config\":\"${hostapd_conf_file}\"}")" ret="$?" [ "$ret" != 0 -o -z "$hostapd_res" ] && { wireless_setup_failed HOSTAPD_START_FAILED return } wireless_add_process "$(jsonfilter -s "$hostapd_res" -l 1 -e @.pid)" "/usr/sbin/hostapd" 1 1 fi This commit sets no_reload = 0 during the second call of drv_mac80211_setup. It is perhaps worth providing a way to reproduce the situation where drv_mac80211_setup is called twice. When /sbin/wifi is used to turn on wifi, uci set wireless.@wifi-iface[0].disabled=0 uci set wireless.@wifi-device[0].disabled=0 uci commit wifi /sbin/wifi makes the following ubus calls, ubus call network reload ubus call network.wireless down ubus call network.wireless up The first and third ubus calls both call drv_mac80211_setup, while the second ubus call triggers wireless_device_setup_cancel. So the call sequence becomes, drv_mac80211_setup wireless_device_setup_cancel drv_mac80211_setup In contrast, when LuCI is used to turn on wifi only a single call is made to drv_mac80211_setup. branches affected: trunk, 21.02 Signed-off-by: Bob Cantor <coxede6557@w3boats.com> (cherry-picked from commit a29ab3b79a)		2021-06-30 19:24:55 +02:00
..
netifd	mac80211: fix no_reload logic (FS#3902)	2021-06-30 19:24:55 +02:00
wifi	mac80211: add 802.11ad-support	2021-01-05 02:16:24 +00:00