On Thu, 2019-03-21 at 15:19 +0000, Sergey Matyukevich wrote:
> FullMAC STAs have no way to update bss channel after CSA channel switch
> completion. As a result, user-space tools may provide inconsistent
> channel info. For instance, consider the following two commands:
> $ sudo iw dev wlan0 link
> $ sudo iw dev wlan0 info
> The latter command gets channel info from the hardware, so most probably
> its output will be correct. However the former command gets channel info
> from scan cache, so its output will contain outdated channel info.
> In fact, current bss channel info will not be updated until the
> next [re-]connect.
>
> Note that mac80211 STAs have a workaround for this, but it requires
> access to internal cfg80211 data, see ieee80211_chswitch_work:
>
> /* XXX: shouldn't really modify cfg80211-owned data! */
> ifmgd->associated->channel = sdata->csa_chandef.chan;
>
> This patch suggests to convert mac80211 workaround to cfg80211 behavior
> and to update current bss channel in cfg80211_ch_switch_notify.
>
> Signed-off-by: Sergey Matyukevich <sergey.matyukevich.os@xxxxxxxxxxxxx>
>
> ---
>
> This issue has been observed for both qtnfmac and brcmfmac. Fix tested
> for qtnfmac and iwlwifi, to make sure there is no regression for mac80211.
> However this is not going to be enough to fix brcmfmac behavior as it
> does not use cfg80211_ch_switch_notify. This issue may also affect
> ath6kl and mwifiex, but I have no hardware to check.
Yeah, I think this makes sense.
> + if (wdev->iftype == NL80211_IFTYPE_STATION) {
> + if (wdev->current_bss)
> + wdev->current_bss->pub.channel = chandef->chan;
> + }
Maybe do
if (wdev->iftype == ... &&
!WARN_ON(!wdev->current_bss))
wdev->current_bss->... = ...
I worry slightly about locking too, since there's no protection on the
wdev->current_bss pointer here.
johannes
