Search Linux Wireless

Re: [RFC PATCH] mac80211/cfg80211: update bss channel on channel switch

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> > 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.

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




[Index of Archives]     [Linux Host AP]     [ATH6KL]     [Linux Wireless Personal Area Network]     [Linux Bluetooth]     [Wireless Regulations]     [Linux Netdev]     [Kernel Newbies]     [Linux Kernel]     [IDE]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite Hiking]     [MIPS Linux]     [ARM Linux]     [Linux RAID]

  Powered by Linux