netdev - Re: [PATCH 4.8 2/2] brcmfmac: support get

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CACna6rxpZ5=r99yjR4OYqi_mEY0B1yz96m34Wt=u==x2A2r33g@mail.gmail.com>
Date:	Fri, 20 May 2016 12:54:14 +0200
From:	Rafał Miłecki <zajec5@...il.com>
To:	Arend Van Spriel <arend.vanspriel@...adcom.com>
Cc:	Kalle Valo <kvalo@...eaurora.org>,
	Brett Rudley <brudley@...adcom.com>,
	Arend van Spriel <arend@...adcom.com>,
	"Franky (Zhenhui) Lin" <frankyl@...adcom.com>,
	Hante Meuleman <meuleman@...adcom.com>,
	Pieter-Paul Giesberts <pieterpg@...adcom.com>,
	"open list:BROADCOM BRCM80211 IEEE802.11n WIRELESS DRIVER" 
	<linux-wireless@...r.kernel.org>,
	"open list:BROADCOM BRCM80211 IEEE802.11n WIRELESS DRIVER" 
	<brcm80211-dev-list@...adcom.com>,
	"open list:NETWORKING DRIVERS" <netdev@...r.kernel.org>,
	open list <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 4.8 2/2] brcmfmac: support get_channel cfg80211 callback

On 20 May 2016 at 09:42, Arend Van Spriel <arend.vanspriel@...adcom.com> wrote:
> On 19-5-2016 13:02, Rafał Miłecki wrote:
>> This is important for brcmfmac as the firmware may pick different
>> channel than requested. This has been tested with BCM4366B1 (in D-Link
>> DIR-885L).
>
> Can you elaborate? Is this for AP or STA mode?

This happens when using 5 GHz PHY with one AP interface. It seems
firmware respects: band, channel width & control channel location.
However it picks center channel in a more or less random way.

E.g. I configured hostapd to setup AP using 36 control channel with
VHT80 (chanspec 0xe02a). Almost every time I was restarting AP I got
firmware picking different chanspecs, all cases listed below:
0xe03a BND_5G | BW_80 | SB_LL | 58
0xe06a BND_5G | BW_80 | SB_LL | 106
0xe07a BND_5G | BW_80 | SB_LL | 122
0xe09b BND_5G | BW_80 | SB_LL | 155

I'm a bit disappointed seeing this FullMAC firmware doing such tricks
on its own. I would prefer to simply relay on hostapd doing this kind
of channel switching. I saw many times hostapd e.g. respecting my
40/80 MHz channel but switching control one in order to avoid
collisions with another AP's control frames on the same frequency.

On the other hand I never got this problem with BCM43602 using
Broadcom's official firmware, so it's some new feature you enabled
when building brcmfmac4366b-pcie.bin.


>> Signed-off-by: Rafał Miłecki <zajec5@...il.com>
>> ---
>>  .../broadcom/brcm80211/brcmfmac/cfg80211.c         | 59 ++++++++++++++++++++++
>>  1 file changed, 59 insertions(+)
>>
>> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
>> index 597495d..4fb9e3a 100644
>> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
>> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
>> @@ -4892,6 +4892,64 @@ exit:
>>       return err;
>>  }
>>
>> +static int brcmf_cfg80211_get_channel(struct wiphy *wiphy,
>> +                                   struct wireless_dev *wdev,
>> +                                   struct cfg80211_chan_def *chandef)
>> +{
>> +     struct brcmf_cfg80211_info *cfg = wiphy_to_cfg(wiphy);
>> +     struct net_device *ndev = wdev->netdev;
>> +     struct brcmf_if *ifp = netdev_priv(ndev);
>
> Can this operation be done on a P2P_DEVICE interface, ie. wdev->netdev
> == NULL?

I don't have any experience with P2P, thanks a lot for pointing this to me!


>> +     struct brcmu_chan ch;
>> +     enum nl80211_band band = 0;
>> +     enum nl80211_chan_width width = 0;
>> +     u32 chanspec;
>> +     int freq, err;
>> +
>> +     err = brcmf_fil_iovar_int_get(ifp, "chanspec", &chanspec);
>> +     if (err) {
>> +             brcmf_err("chanspec failed (%d)\n", err);
>> +             return err;
>> +     }
>> +
>> +     ch.chspec = chanspec;
>> +     cfg->d11inf.decchspec(&ch);
>> +
>> +     switch (ch.band) {
>> +     case BRCMU_CHAN_BAND_2G:
>> +             band = NL80211_BAND_2GHZ;
>> +             break;
>> +     case BRCMU_CHAN_BAND_5G:
>> +             band = NL80211_BAND_5GHZ;
>> +             break;
>> +     }
>> +
>> +     switch (ch.bw) {
>> +     case BRCMU_CHAN_BW_80:
>> +             width = NL80211_CHAN_WIDTH_80;
>> +             break;
>> +     case BRCMU_CHAN_BW_40:
>> +             width = NL80211_CHAN_WIDTH_40;
>> +             break;
>> +     case BRCMU_CHAN_BW_20:
>> +             width = NL80211_CHAN_WIDTH_20;
>> +             break;
>> +     case BRCMU_CHAN_BW_80P80:
>> +             width = NL80211_CHAN_WIDTH_80P80;
>> +             break;
>
> Not much sense to support this given that center_freq2 is set to zero below.

OK.