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]

[-- Attachment #1: Type: text/plain, Size: 1881 bytes --]

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ł

[-- Attachment #2: scanning.txt --]
[-- Type: text/plain, Size: 1458 bytes --]

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

Re: 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

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

[Rafał Miłecki]

[-- Attachment #1: Type: text/plain, Size: 2034 bytes --]

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ł

[-- Attachment #2: iw.list.log --]
[-- Type: application/octet-stream, Size: 2893 bytes --]

Wiphy phy3
	Band 1:
		Frequencies:
			* 2412 MHz [1] (20.0 dBm)
			* 2417 MHz [2] (20.0 dBm)
			* 2422 MHz [3] (20.0 dBm)
			* 2427 MHz [4] (20.0 dBm)
			* 2432 MHz [5] (20.0 dBm)
			* 2437 MHz [6] (20.0 dBm)
			* 2442 MHz [7] (20.0 dBm)
			* 2447 MHz [8] (20.0 dBm)
			* 2452 MHz [9] (20.0 dBm)
			* 2457 MHz [10] (20.0 dBm)
			* 2462 MHz [11] (20.0 dBm)
			* 2467 MHz [12] (20.0 dBm) (passive scanning, no IBSS)
			* 2472 MHz [13] (20.0 dBm)
			* 2484 MHz [14] (20.0 dBm) (passive scanning, no IBSS)
		Bitrates (non-HT):
			* 1.0 Mbps
			* 2.0 Mbps (short preamble supported)
			* 5.5 Mbps (short preamble supported)
			* 11.0 Mbps (short preamble supported)
			* 6.0 Mbps
			* 9.0 Mbps
			* 12.0 Mbps
			* 18.0 Mbps
			* 24.0 Mbps
			* 36.0 Mbps
			* 48.0 Mbps
			* 54.0 Mbps
	max # scan SSIDs: 4
	max scan IEs length: 2285 bytes
	Coverage class: 0 (up to 0m)
	Available Antennas: TX 0 RX 0
	Supported interface modes:
		 * IBSS
		 * managed
		 * AP
		 * AP/VLAN
		 * WDS
		 * monitor
	Supported commands:
		 * new_interface
		 * set_interface
		 * new_key
		 * new_beacon
		 * new_station
		 * set_bss
		 * authenticate
		 * associate
		 * deauthenticate
		 * disassociate
		 * join_ibss
		 * set_tx_bitrate_mask
		 * action
		 * frame_wait_cancel
		 * set_wiphy_netns
		 * set_channel
		 * set_wds_peer
		 * Unknown command (84)
		 * Unknown command (87)
		 * Unknown command (85)
		 * Unknown command (89)
		 * Unknown command (92)
		 * connect
		 * disconnect
	Supported TX frame types:
		 * IBSS: 0x0000 0x0010 0x0020 0x0030 0x0040 0x0050 0x0060 0x0070 0x0080 0x0090 0x00a0 0x00b0 0x00c0 0x00d0 0x00e0 0x00f0
		 * managed: 0x0000 0x0010 0x0020 0x0030 0x0040 0x0050 0x0060 0x0070 0x0080 0x0090 0x00a0 0x00b0 0x00c0 0x00d0 0x00e0 0x00f0
		 * AP: 0x0000 0x0010 0x0020 0x0030 0x0040 0x0050 0x0060 0x0070 0x0080 0x0090 0x00a0 0x00b0 0x00c0 0x00d0 0x00e0 0x00f0
		 * AP/VLAN: 0x0000 0x0010 0x0020 0x0030 0x0040 0x0050 0x0060 0x0070 0x0080 0x0090 0x00a0 0x00b0 0x00c0 0x00d0 0x00e0 0x00f0
		 * mesh point: 0x0000 0x0010 0x0020 0x0030 0x0040 0x0050 0x0060 0x0070 0x0080 0x0090 0x00a0 0x00b0 0x00c0 0x00d0 0x00e0 0x00f0
		 * P2P-client: 0x0000 0x0010 0x0020 0x0030 0x0040 0x0050 0x0060 0x0070 0x0080 0x0090 0x00a0 0x00b0 0x00c0 0x00d0 0x00e0 0x00f0
		 * P2P-GO: 0x0000 0x0010 0x0020 0x0030 0x0040 0x0050 0x0060 0x0070 0x0080 0x0090 0x00a0 0x00b0 0x00c0 0x00d0 0x00e0 0x00f0
		 * Unknown mode (10): 0x0000 0x0010 0x0020 0x0030 0x0040 0x0050 0x0060 0x0070 0x0080 0x0090 0x00a0 0x00b0 0x00c0 0x00d0 0x00e0 0x00f0
	Supported RX frame types:
		 * IBSS: 0x0040 0x00b0 0x00c0 0x00d0
		 * managed: 0x0040 0x00d0
		 * AP: 0x0000 0x0020 0x0040 0x00a0 0x00b0 0x00c0 0x00d0
		 * AP/VLAN: 0x0000 0x0020 0x0040 0x00a0 0x00b0 0x00c0 0x00d0
		 * mesh point: 0x00b0 0x00c0 0x00d0
		 * P2P-client: 0x0040 0x00d0
		 * P2P-GO: 0x0000 0x0020 0x0040 0x00a0 0x00b0 0x00c0 0x00d0
		 * Unknown mode (10): 0x0040 0x00d0

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

[Rafał Miłecki]

[-- Attachment #1: Type: text/plain, Size: 804 bytes --]

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ł

[-- Attachment #2: 0001-mac80211-fix.patch --]
[-- Type: application/octet-stream, Size: 1229 bytes --]

From 10803e81b50b7bc257f9cee44a775a9a79a9abe7 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Rafa=C5=82=20Mi=C5=82ecki?= <rmilecki@antmicro.com>
Date: Tue, 26 Mar 2013 22:30:13 +0100
Subject: [PATCH] mac80211 fix

---
 net/mac80211/scan.c |    9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/net/mac80211/scan.c b/net/mac80211/scan.c
index cb34cbb..d23e46c 100644
--- a/net/mac80211/scan.c
+++ b/net/mac80211/scan.c
@@ -153,6 +153,7 @@ void ieee80211_scan_rx(struct ieee80211_local *local, struct sk_buff *skb)
 	u8 *elements;
 	struct ieee80211_channel *channel;
 	size_t baselen;
+	int freq;
 	struct ieee802_11_elems elems;
 
 	if (skb->len < 24 ||
@@ -184,7 +185,13 @@ void ieee80211_scan_rx(struct ieee80211_local *local, struct sk_buff *skb)
 
 	ieee802_11_parse_elems(elements, skb->len - baselen, &elems);
 
-	channel = ieee80211_get_channel(local->hw.wiphy, rx_status->freq);
+	if (elems.ds_params && elems.ds_params_len == 1)
+		freq = ieee80211_channel_to_frequency(elems.ds_params[0],
+						      rx_status->band);
+	else
+		freq = rx_status->freq;
+
+	channel = ieee80211_get_channel(local->hw.wiphy, freq);
 
 	if (!channel || channel->flags & IEEE80211_CHAN_DISABLED)
 		return;
-- 
1.7.10.4

Re: 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

Re: 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

Re: 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