]> git.ipfire.org Git - thirdparty/hostap.git/commit
nl80211: Fix AP scan with STA fallback error path
authorNicolas Escande <nico.escande@gmail.com>
Fri, 26 Apr 2024 12:35:53 +0000 (14:35 +0200)
committerJouni Malinen <j@w1.fi>
Fri, 12 Jul 2024 13:44:30 +0000 (16:44 +0300)
commit7b8517d1974fa728e07dabcbd788c6ef6a8a96dd
treeefeb1856241a86bec2c08aa73188423adff16977
parent6ad59779c2f6d82c5325f25efea9552fa6426055
nl80211: Fix AP scan with STA fallback error path

I've run into a case where I can bring a 2.4 GHz AP up without it being
in a bridge while I used the 'bridge=' config option. This happens when
the HT scan needed for 40 MHz operation failed to start from the get go
because another dev on the same phy was already in a scan. At the end
the AP is up and running but not added into any bridge.

Upon looking at the code, it seems that some hardware fails to issue a
scan while in AP and thus we have a fallback that switches the interface
from AP to STA before retrying another scan (it will change it back to
AP later on when finished). As we cannot have a (non-WDS) STA in a
bridge, during that procedure, we also remove/add the AP/STA from/to the
bridge as needed.

However, in wpa_driver_nl80211_scan() we do not set
drv->ap_scan_as_station until the end of the switch-to-sta &
retry-scan-start block. This means that when the recursive call to
wpa_driver_nl80211_scan() fails (the hardware is busy in my case) we
restore the interface to AP with wpa_driver_nl80211_set_mode() but that
will not add it back to the bridge. Problem.

To fix this lets always set drv->ap_scan_as_station before calling
wpa_driver_nl80211_set_mode(). In case wpa_driver_nl80211_set_mode() or
wpa_driver_nl80211_scan() fails lets call nl80211_restore_ap_mode() that
will set the mode back to AP but also handle the bridge thing as needed.

Signed-off-by: Nicolas Escande <nico.escande@gmail.com>
src/drivers/driver_nl80211_scan.c