| Message ID | 1393327628-1078-1-git-send-email-michal.kazior@tieto.com (mailing list archive) |
|---|---|
| State | Not Applicable, archived |
| Headers | show |
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 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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? -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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? -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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;
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(-)