Scanning regression since "cfg80211: use DS or HT operation IEs to determine BSS channel"

Scanning regression since "cfg80211: use DS or HT operation IEs to determine BSS channel"

[Rafał Miłecki]

Hi,

I've just finished bisecting wireless scanning regression I'm
experiencing with my 14e4:432b (BCM4322) and b43 driver.

The problem is getting my network visible in scanning results (iw dev
wlan0 scan). I've to repeat scanning dozens of time to notice my AP.
It's also well visible when using wpa_supplicant. It takes from 20s to
100s before I get the "Trying to authenticate with".
The performance however is not affected. Once I connect to my network,
I can transmit (tested with iperf) with stable 21.5Mb/s which is just
great for 802.11g.

After going back to the kernel before that commit it takes
wpa_supplicant less than 2 seconds to connect to my WiFi network.

My network is at channel 13, I still have to verify if it matters.

Any thought about that?


The first bad commit (I've verified manually after bisecting) appears to be:

0172bb75073e11a5aa9d8a953bdaefb8709f00c8 is the first bad commit
commit 0172bb75073e11a5aa9d8a953bdaefb8709f00c8
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Fri Nov 23 14:23:30 2012 +0100

    cfg80211: use DS or HT operation IEs to determine BSS channel

    Currently, mac80211 checks the DS params IE if present and
    uses it for the (primary) BSS channel, instead of the one
    that the frame was received on. This is particularly useful
    in the 2.4 GHz band since a frame is often received on one
    of the adjacent channels due to overlap.

    Move this code to cfg80211 so other drivers also do this.

    Additionally, on 5 GHz, in particular with some (possibly)
    upcoming changes in 802.11ai and duplicate transmissions
    when wider channels are used, something similar happens.
    So if present, also use the (primary) channel information
    contained in the HT operation IE.

    Signed-off-by: Johannes Berg <johannes.berg@intel.com>

-- 
Rafa?
-------------- next part --------------
BSS 00:11:22:33:44:55 (on wlan0)
	TSF: 165376384 usec (0d, 00:02:45)
	freq: 2472
	beacon interval: 100
	capability: ESS Privacy ShortSlotTime (0x0411)
	signal: -50.00 dBm
	last seen: 153 ms ago
	Information elements from Probe Response frame:
	SSID: zajec_poznan_160
	Supported rates: 1.0* 2.0* 5.5* 11.0* 6.0 9.0 12.0 18.0 
	DS Parameter set: channel 13
	Country: PL     Environment: Indoor/Outdoor
		Channels [1 - 13] @ 20 dBm
	ERP: Barker_Preamble_Mode
	Extended supported rates: 24.0 36.0 48.0 54.0 
	RSN:     * Version: 1
		 * Group cipher: CCMP
		 * Pairwise ciphers: CCMP
		 * Authentication suites: PSK
		 * Capabilities: 16-PTKSA-RC (0x000c)
	HT capabilities:
		Capabilities: 0x104e
			HT20/HT40
			SM Power Save disabled
			RX HT40 SGI
			No RX STBC
			Max AMSDU length: 3839 bytes
			DSSS/CCK HT40
		Maximum RX AMPDU length 65535 bytes (exponent: 0x003)
		Minimum RX AMPDU time spacing: 8 usec (0x06)
		HT TX/RX MCS rate indexes supported: 0-15
	HT operation:
		 * primary channel: 13
		 * secondary channel offset: below
		 * STA channel width: any
		 * RIFS: 0
		 * HT protection: 20 MHz
		 * non-GF present: 0
		 * OBSS non-GF present: 0
		 * dual beacon: 0
		 * dual CTS protection: 0
		 * STBC beacon: 0
		 * L-SIG TXOP Prot: 0
		 * PCO active: 0
		 * PCO phase: 0
	WMM:     * Parameter version 1
		 * BE: CW 15-1023, AIFSN 3
		 * BK: CW 15-1023, AIFSN 7
		 * VI: CW 7-15, AIFSN 2, TXOP 3008 usec
		 * VO: acm CW 3-7, AIFSN 2, TXOP 1504 usec

Scanning regression since "cfg80211: use DS or HT operation IEs to determine BSS channel"

[Johannes Berg]

On Tue, 2013-03-26 at 18:10 +0100, Rafa? Mi?ecki wrote:

> I've just finished bisecting wireless scanning regression I'm
> experiencing with my 14e4:432b (BCM4322) and b43 driver.

Hmmm.

> The problem is getting my network visible in scanning results (iw dev
> wlan0 scan). I've to repeat scanning dozens of time to notice my AP.
> It's also well visible when using wpa_supplicant. It takes from 20s to
> 100s before I get the "Trying to authenticate with".

That's strange.

> After going back to the kernel before that commit it takes
> wpa_supplicant less than 2 seconds to connect to my WiFi network.

> My network is at channel 13, I still have to verify if it matters.
> 
> Any thought about that?
> 
> 
> The first bad commit (I've verified manually after bisecting) appears to be:

"verified manually" how? By reverting the commit? But anyway the commit
is clearly scanning related, so ...

Can you check your channel list? (iw list or iw phy0 info)

Also can you show the full data including beacon data from the AP (iw
wlan0 scan dump -b) please?

Does reverting just the mac80211 change fix it?

johannes

Scanning regression since "cfg80211: use DS or HT operation IEs to determine BSS channel"

[Rafał Miłecki]

2013/3/26 Johannes Berg <johannes@sipsolutions.net>:
> On Tue, 2013-03-26 at 18:10 +0100, Rafa? Mi?ecki wrote:
>
>> I've just finished bisecting wireless scanning regression I'm
>> experiencing with my 14e4:432b (BCM4322) and b43 driver.
>
> Hmmm.
>
>> The problem is getting my network visible in scanning results (iw dev
>> wlan0 scan). I've to repeat scanning dozens of time to notice my AP.
>> It's also well visible when using wpa_supplicant. It takes from 20s to
>> 100s before I get the "Trying to authenticate with".
>
> That's strange.
>
>> After going back to the kernel before that commit it takes
>> wpa_supplicant less than 2 seconds to connect to my WiFi network.
>
>> My network is at channel 13, I still have to verify if it matters.
>>
>> Any thought about that?
>>
>>
>> The first bad commit (I've verified manually after bisecting) appears to be:
>
> "verified manually" how? By reverting the commit? But anyway the commit
> is clearly scanning related, so ...

Oh, that was just about
1) git checkout 0172bb75073e11a5aa9d8a953bdaefb8709f00c8
2) test
3) git revert 0172bb75073e11a5aa9d8a953bdaefb8709f00c8
4) test


> Can you check your channel list? (iw list or iw phy0 info)

Sure, attaching iw.list.log.


> Also can you show the full data including beacon data from the AP (iw
> wlan0 scan dump -b) please?

Hm, first of all, above command doesn't seem to perform real scanning.
It returns too quick to actually scan anything. It's result is empty
as long as I don't use standard "iw dev wlan0 scan".  After scanning a
normal way once ("iw dev wlan0 scan"), executing "dump -b" results in
the output at the one produced by "iw dev wlan0 scan" (only TSF and
last seen differ).

Is there anything special about "iw dev wlan0 scan dump -b" I should know of?


> Does reverting just the mac80211 change fix it?

Yes. Reverting just a change in net/mac80211/scan.c fixes the problem
for me. I've tested this with the latest wireless-testing.

-- 
Rafa?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: iw.list.log
Type: application/octet-stream
Size: 2893 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/b43-dev/attachments/20130326/6f21ae6a/attachment.obj>

Scanning regression since "cfg80211: use DS or HT operation IEs to determine BSS channel"

[Rafał Miłecki]

2013/3/26 Rafa? Mi?ecki <zajec5@gmail.com>:
> 2013/3/26 Johannes Berg <johannes@sipsolutions.net>:
>> Can you check your channel list? (iw list or iw phy0 info)
>
> Sure, attaching iw.list.log.

Hm, after some recompilations, rmmod, modprobe... now I can see
> * 2472 MHz [13] (20.0 dBm) (passive scanning, no IBSS)
(I didn't have "passive" for channel 13 earlier). Not sure what could
change that. I've to do more experiments with different channels.


>> Does reverting just the mac80211 change fix it?
>
> Yes. Reverting just a change in net/mac80211/scan.c fixes the problem
> for me. I've tested this with the latest wireless-testing.

Just to make it clear: I've modified scan.c as you can see in attached
0001-mac80211-fix.patch (application/octet-stream) 2 KB

-- 
Rafa?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-mac80211-fix.patch
Type: application/octet-stream
Size: 1229 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/b43-dev/attachments/20130326/dda774b7/attachment-0001.obj>

Scanning regression since "cfg80211: use DS or HT operation IEs to determine BSS channel"

[Johannes Berg]

On Tue, 2013-03-26 at 22:58 +0100, Rafa? Mi?ecki wrote:
> > Can you check your channel list? (iw list or iw phy0 info)
> 
> Sure, attaching iw.list.log.

This is after the scan, presumably? Is channel 13 also marked as
passive/no-ibss before scanning?

> > Also can you show the full data including beacon data from the AP (iw
> > wlan0 scan dump -b) please?
> 
> Hm, first of all, above command doesn't seem to perform real scanning.

True, you can remove the "dump" part if you wanted to.

> It returns too quick to actually scan anything. It's result is empty
> as long as I don't use standard "iw dev wlan0 scan".  After scanning a
> normal way once ("iw dev wlan0 scan"), executing "dump -b" results in
> the output at the one produced by "iw dev wlan0 scan" (only TSF and
> last seen differ).

Really? It should have printed more if you'd ever received a beacon.
That's curious. It means you never received a beacon? But then how did
the channel get activated (i.e. no longer be passive)? That should have
been by receiving a beacon ...

> > Does reverting just the mac80211 change fix it?
> 
> Yes. Reverting just a change in net/mac80211/scan.c fixes the problem
> for me. I've tested this with the latest wireless-testing.

Sounds to me like you have issues receiving beacons. Channel 13 is
marked passive, thus no probe requests would get sent. Before the
change, it's possible that your probe response on channel 11 was
received by the AP on channel 13 (in particular since the AP is
configured to HT40-) and the probe response was received on channel 11.

I'm not really sure what difference this change makes though ... channel
13 is still present and not disabled, so the frame, if received,
wouldn't be dropped either way??

Or was the channel marked disabled before scanning? But then you could
never connect to the AP anyway ... hmm.

johannes

Scanning regression since "cfg80211: use DS or HT operation IEs to determine BSS channel"

[Rafał Miłecki]

2013/3/26 Rafa? Mi?ecki <zajec5@gmail.com>:
> I've just finished bisecting wireless scanning regression I'm
> experiencing with my 14e4:432b (BCM4322) and b43 driver.
>
> The problem is getting my network visible in scanning results (iw dev
> wlan0 scan). I've to repeat scanning dozens of time to notice my AP.
> It's also well visible when using wpa_supplicant. It takes from 20s to
> 100s before I get the "Trying to authenticate with".
> The performance however is not affected. Once I connect to my network,
> I can transmit (tested with iperf) with stable 21.5Mb/s which is just
> great for 802.11g.
>
> After going back to the kernel before that commit it takes
> wpa_supplicant less than 2 seconds to connect to my WiFi network.
>
> My network is at channel 13, I still have to verify if it matters.
>
> Any thought about that?
>
>
> The first bad commit (I've verified manually after bisecting) appears to be:
>
> 0172bb75073e11a5aa9d8a953bdaefb8709f00c8 is the first bad commit
> commit 0172bb75073e11a5aa9d8a953bdaefb8709f00c8
> Author: Johannes Berg <johannes.berg@intel.com>
> Date:   Fri Nov 23 14:23:30 2012 +0100
>
>     cfg80211: use DS or HT operation IEs to determine BSS channel

This has been finally fixed in 64e5acb09ca6b50c97299cff9ef51299470b29f2 [0].

[0] http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=64e5acb09ca6b50c97299cff9ef51299470b29f2

Scanning regression since "cfg80211: use DS or HT operation IEs to determine BSS channel"

[Johannes Berg]

On Sun, 2014-01-26 at 15:37 +0100, Rafa? Mi?ecki wrote:

> >     cfg80211: use DS or HT operation IEs to determine BSS channel
> 
> This has been finally fixed in 64e5acb09ca6b50c97299cff9ef51299470b29f2 [0].

It's no wonder I couldn't find it to be bad in the above commit though -
the breakage is two years older than that ... oh well. I'm surprised by
how little problematic this seems to have been.

johannes