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>

0 files changed, 0 insertions, 0 deletions