[PATCH] mac80211: don't downgrade VHT20 to HT20

[PATCH] mac80211: don't downgrade VHT20 to HT20

[Michal Kazior]

The check led to VHT-capable devices being unable
to pair in VHT20 and were instead paired in HT20.

This improves throughput for VHT20 pairing.

Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
---
The check was originally introduced in:

e1a0c6b3a4b27ed5f21291d0bbee2167ec201ef5
(mac80211: stop toggling IEEE80211_HT_CAP_SUP_WIDTH_20_40)

Was it really necessary to introduce this check?


 net/mac80211/vht.c | 4 ----
 1 file changed, 4 deletions(-)

diff --git a/net/mac80211/vht.c b/net/mac80211/vht.c
index e9e36a2..21c7e5b 100644
--- a/net/mac80211/vht.c
+++ b/net/mac80211/vht.c
@@ -129,10 +129,6 @@ ieee80211_vht_cap_ie_to_sta_vht_cap(struct ieee80211_sub_if_data *sdata,
 	if (!vht_cap_ie || !sband->vht_cap.vht_supported)
 		return;
 
-	/* A VHT STA must support 40 MHz */
-	if (!(sta->sta.ht_cap.cap & IEEE80211_HT_CAP_SUP_WIDTH_20_40))
-		return;
-
 	vht_cap->vht_supported = true;
 
 	own_cap = sband->vht_cap;
-- 
1.8.5.3

Re: [PATCH] mac80211: don't downgrade VHT20 to HT20

[Johannes Berg]

On Tue, 2014-02-25 at 12:27 +0100, Michal Kazior wrote:
> The check led to VHT-capable devices being unable
> to pair in VHT20 and were instead paired in HT20.

??

802.11ac says:
---
A VHT STA shall support the following features:
[...]
— 20 MHz, 40 MHz, and 80 MHz channel widths
[...]
---

so how can you have a device that's "VHT-capable" but doesn't support 40
MHz?

johannes

Re: [PATCH] mac80211: don't downgrade VHT20 to HT20

[Johannes Berg]

On Tue, 2014-02-25 at 13:07 +0100, Johannes Berg wrote:
> On Tue, 2014-02-25 at 12:27 +0100, Michal Kazior wrote:
> > The check led to VHT-capable devices being unable
> > to pair in VHT20 and were instead paired in HT20.
> 
> ??
> 
> 802.11ac says:
> ---
> A VHT STA shall support the following features:
> [...]
> — 20 MHz, 40 MHz, and 80 MHz channel widths
> [...]
> ---
> 
> so how can you have a device that's "VHT-capable" but doesn't support 40
> MHz?

And also:

A VHT STA shall set the Supported Channel Width Set subfield in its HT
Capabilities element HT Capabilities Info field to 1, indicating that
both 20 MHz operation and 40 MHz operation are supported.

(10.39.1)

johannes

Re: [PATCH] mac80211: don't downgrade VHT20 to HT20

[Michal Kazior]

On 25 February 2014 13:10, Johannes Berg <johannes@sipsolutions.net> wrote:
> On Tue, 2014-02-25 at 13:07 +0100, Johannes Berg wrote:
>> On Tue, 2014-02-25 at 12:27 +0100, Michal Kazior wrote:
>> > The check led to VHT-capable devices being unable
>> > to pair in VHT20 and were instead paired in HT20.
>>
>> ??
>>
>> 802.11ac says:
>> ---
>> A VHT STA shall support the following features:
>> [...]
>> — 20 MHz, 40 MHz, and 80 MHz channel widths
>> [...]
>> ---
>>
>> so how can you have a device that's "VHT-capable" but doesn't support 40
>> MHz?
>
> And also:
>
> A VHT STA shall set the Supported Channel Width Set subfield in its HT
> Capabilities element HT Capabilities Info field to 1, indicating that
> both 20 MHz operation and 40 MHz operation are supported.
>
> (10.39.1)

The spec also defines VHT BSS operating channel width is derived from
HT Operation Element: STA Channel Width field (Table 10-19) and 20 MHz
is not forbidden for AP/mesh. hostapd seems to go in line with this
and allows VHT20 and VHT40.

Without my patch (i.e. with the 20/40 check left intact):

* If a station connects to VHT20 BSS, hostapd tries to add a VHT20
station, but mac80211 downgrades it to HT20,
* If mac80211 station connects to a VHT20 BSS it gets downgraded to HT20 too.

This means mac80211 is unable to setup VHT20 pairing properly even
though VHT20 BSS is defined in the spec.

My take is 10.39.1 means VHT STA AssocReq must contain
IEEE80211_HT_CAP_SUP_WIDTH_20_
40. I suppose AP (hostapd) should deny STA association in that case.

I'm not really sure how IBSS fits here though.


Michał

Re: [PATCH] mac80211: don't downgrade VHT20 to HT20

[Johannes Berg]

Sorry for the delay. Somehow I thought this was addressed, but I'm
confused.

I think we all agree that the spec says:

> > A VHT STA shall set the Supported Channel Width Set subfield in its HT
> > Capabilities element HT Capabilities Info field to 1, indicating that
> > both 20 MHz operation and 40 MHz operation are supported.

and that the station should therefore set the 20_40 capability bit in
the association response?

> The spec also defines VHT BSS operating channel width is derived from
> HT Operation Element: STA Channel Width field (Table 10-19) and 20 MHz
> is not forbidden for AP/mesh. hostapd seems to go in line with this
> and allows VHT20 and VHT40.

Yes but how is that related to the *capability* bit? You're talking
about the HT/VHT operation information.

> Without my patch (i.e. with the 20/40 check left intact):
> 
> * If a station connects to VHT20 BSS, hostapd tries to add a VHT20
> station, but mac80211 downgrades it to HT20,
> * If mac80211 station connects to a VHT20 BSS it gets downgraded to HT20 too.
> 
> This means mac80211 is unable to setup VHT20 pairing properly even
> though VHT20 BSS is defined in the spec.
> 
> My take is 10.39.1 means VHT STA AssocReq must contain
> IEEE80211_HT_CAP_SUP_WIDTH_20_40.
> I suppose AP (hostapd) should deny STA association in that case.

So are you saying the station isn't setting 20_40 capability? Or is
something else unsetting the bit in case it's a 20MHz network?

johannes

Re: [PATCH] mac80211: don't downgrade VHT20 to HT20

[Michal Kazior]

On 19 March 2014 15:22, Johannes Berg <johannes@sipsolutions.net> wrote:
> Sorry for the delay. Somehow I thought this was addressed, but I'm
> confused.
>
> I think we all agree that the spec says:
>
>> > A VHT STA shall set the Supported Channel Width Set subfield in its HT
>> > Capabilities element HT Capabilities Info field to 1, indicating that
>> > both 20 MHz operation and 40 MHz operation are supported.
>
> and that the station should therefore set the 20_40 capability bit in
> the association response?

Correct.


>> The spec also defines VHT BSS operating channel width is derived from
>> HT Operation Element: STA Channel Width field (Table 10-19) and 20 MHz
>> is not forbidden for AP/mesh. hostapd seems to go in line with this
>> and allows VHT20 and VHT40.
>
> Yes but how is that related to the *capability* bit? You're talking
> about the HT/VHT operation information.

Good point.

Hostapd sets *both* HT Capability and HT Information IEs to "only
20Mhz" for VHT20. I can see Cisco EA6500 do the same thing too.


>> Without my patch (i.e. with the 20/40 check left intact):
>>
>> * If a station connects to VHT20 BSS, hostapd tries to add a VHT20
>> station, but mac80211 downgrades it to HT20,
>> * If mac80211 station connects to a VHT20 BSS it gets downgraded to HT20 too.
>>
>> This means mac80211 is unable to setup VHT20 pairing properly even
>> though VHT20 BSS is defined in the spec.
>>
>> My take is 10.39.1 means VHT STA AssocReq must contain
>> IEEE80211_HT_CAP_SUP_WIDTH_20_40.
>> I suppose AP (hostapd) should deny STA association in that case.
>
> So are you saying the station isn't setting 20_40 capability? Or is
> something else unsetting the bit in case it's a 20MHz network?

In case of AP mode you get ht_capa/vht_capa from userspace (i.e.
hostapd). This would again imply hostapd does it wrong or is it
perhaps the interface describing HT/VHT state is insufficient? Should
mac80211 treat HT Capab and HT Info separately? Should they be passed
and processed separately?


Michał

Re: [PATCH] mac80211: don't downgrade VHT20 to HT20

[Johannes Berg]

On Thu, 2014-03-20 at 10:39 +0100, Michal Kazior wrote:

> >> The spec also defines VHT BSS operating channel width is derived from
> >> HT Operation Element: STA Channel Width field (Table 10-19) and 20 MHz
> >> is not forbidden for AP/mesh. hostapd seems to go in line with this
> >> and allows VHT20 and VHT40.
> >
> > Yes but how is that related to the *capability* bit? You're talking
> > about the HT/VHT operation information.
> 
> Good point.
> 
> Hostapd sets *both* HT Capability and HT Information IEs to "only
> 20Mhz" for VHT20. I can see Cisco EA6500 do the same thing too.

That used to be fine for HT only, but I guess it's wrong for VHT. It
also means that it cannot switch to 40 MHz on the fly later.

> > So are you saying the station isn't setting 20_40 capability? Or is
> > something else unsetting the bit in case it's a 20MHz network?
> 
> In case of AP mode you get ht_capa/vht_capa from userspace (i.e.
> hostapd). This would again imply hostapd does it wrong or is it
> perhaps the interface describing HT/VHT state is insufficient? Should
> mac80211 treat HT Capab and HT Info separately? Should they be passed
> and processed separately?

It's possible that the interface is insufficient (*), but I'd argue that
if that is the case then it'd be a question of setting the operation
mode rather than any per-station information, since the per-station
information should really be capabilities, while the current operation
mode should be for the interface? If the kernel knows what it's
operating as (*) and knows the station capabilities, everything else
should be clear immediately, no?

(*) right now I suspect that the channel bandwidth is used, which might
be incorrect if we ever want to implement dynamic bandwidth switching in
the AP

johannes

Re: [PATCH] mac80211: don't downgrade VHT20 to HT20

[Johannes Berg]

On Tue, 2014-02-25 at 12:27 +0100, Michal Kazior wrote:
> The check led to VHT-capable devices being unable
> to pair in VHT20 and were instead paired in HT20.
> 
> This improves throughput for VHT20 pairing.

We also found this same issue in client mode - some APs have the same
issue and don't set the flag correctly.

I'm writing the same patch with some comments now, as a combination of
this and another patch we had internally.

johannes