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 <[email protected]>
---
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.
---
net/mac80211/mlme.c | 3 ---
net/wireless/nl80211.c | 6 ++++++
2 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
index 2dbcf5d5512e..b7a9fe3d5fcb 100644
--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
@@ -1188,9 +1188,6 @@ static void ieee80211_chswitch_work(struct work_struct *work)
goto out;
}
- /* XXX: shouldn't really modify cfg80211-owned data! */
- ifmgd->associated->channel = sdata->csa_chandef.chan;
-
ifmgd->csa_waiting_bcn = true;
ieee80211_sta_reset_beacon_monitor(sdata);
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index 25a9e3b5c154..1ca6930ddac0 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -15721,6 +15721,12 @@ void cfg80211_ch_switch_notify(struct net_device *dev,
wdev->chandef = *chandef;
wdev->preset_chandef = *chandef;
+
+ if (wdev->iftype == NL80211_IFTYPE_STATION) {
+ if (wdev->current_bss)
+ wdev->current_bss->pub.channel = chandef->chan;
+ }
+
nl80211_ch_switch_notify(rdev, dev, chandef, GFP_KERNEL,
NL80211_CMD_CH_SWITCH_NOTIFY, 0);
}
--
2.11.0
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 <[email protected]>
>
> ---
>
> 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
> > 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 <[email protected]>
> >
> > ---
> >
> > 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.
Ok, I will add WARN_ON. As for locking, this function is supposed to be
called with wdev->mtx held, see ASSERT_WDEV_LOCK. Do you think this may
not be enough ?
I need to check mwifiex more carefully, but other cfg80211_ch_switch_notify
users (mac80211, ath6kl, qtnfmac) seem to do that locking properly.
Regards,
Sergey
On Mon, 2019-03-25 at 15:44 +0000, Sergey Matyukevich wrote:
> > >
> > I worry slightly about locking too, since there's no protection on the
> > wdev->current_bss pointer here.
>
> Ok, I will add WARN_ON. As for locking, this function is supposed to be
> called with wdev->mtx held, see ASSERT_WDEV_LOCK. Do you think this may
> not be enough ?
Oops, no, that's definitely sufficient. I missed it.
> I need to check mwifiex more carefully, but other cfg80211_ch_switch_notify
> users (mac80211, ath6kl, qtnfmac) seem to do that locking properly.
Well I guess they'd assert and then do something unsafe, so wouldn't
worry about it.
johannes