From: Ben Greear <[email protected]>
ath10k supports VHT on 2.4Ghz band.
If supplicant and hostapd and radio think
VHT should be allowed, then kernel should let them
try.
Signed-off-by: Ben Greear <[email protected]>
---
net/mac80211/mlme.c | 16 ----------------
net/mac80211/util.c | 13 +------------
net/mac80211/vht.c | 15 ---------------
3 files changed, 1 insertion(+), 43 deletions(-)
diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
index 6f079ca..7719867 100644
--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
@@ -4233,8 +4233,6 @@ static int ieee80211_prep_channel(struct ieee80211_sub_if_data *sdata,
struct ieee80211_supported_band *sband;
struct cfg80211_chan_def chandef;
int ret;
- u32 i;
- bool have_80mhz;
sband = local->hw.wiphy->bands[cbss->channel->band];
@@ -4285,20 +4283,6 @@ static int ieee80211_prep_channel(struct ieee80211_sub_if_data *sdata,
}
}
- /* Allow VHT if at least one channel on the sband supports 80 MHz */
- have_80mhz = false;
- for (i = 0; i < sband->n_channels; i++) {
- if (sband->channels[i].flags & (IEEE80211_CHAN_DISABLED |
- IEEE80211_CHAN_NO_80MHZ))
- continue;
-
- have_80mhz = true;
- break;
- }
-
- if (!have_80mhz)
- ifmgd->flags |= IEEE80211_STA_DISABLE_VHT;
-
ifmgd->flags |= ieee80211_determine_chantype(sdata, sband,
cbss->channel,
ht_cap, ht_oper, vht_oper,
diff --git a/net/mac80211/util.c b/net/mac80211/util.c
index f8eb0f8..cabe16f 100644
--- a/net/mac80211/util.c
+++ b/net/mac80211/util.c
@@ -1475,7 +1475,6 @@ static int ieee80211_build_preq_ies_band(struct ieee80211_local *local,
int ext_rates_len;
int shift;
u32 rate_flags;
- bool have_80mhz = false;
*offset = 0;
@@ -1604,17 +1603,7 @@ static int ieee80211_build_preq_ies_band(struct ieee80211_local *local,
*offset = noffset;
}
- /* Check if any channel in this sband supports at least 80 MHz */
- for (i = 0; i < sband->n_channels; i++) {
- if (sband->channels[i].flags & (IEEE80211_CHAN_DISABLED |
- IEEE80211_CHAN_NO_80MHZ))
- continue;
-
- have_80mhz = true;
- break;
- }
-
- if (sband->vht_cap.vht_supported && have_80mhz && !disable_vht) {
+ if (sband->vht_cap.vht_supported && /*have_80mhz &&*/ !disable_vht) {
if (end - pos < 2 + sizeof(struct ieee80211_vht_cap))
goto out_err;
pos = ieee80211_ie_build_vht_cap(pos, &sband->vht_cap,
diff --git a/net/mac80211/vht.c b/net/mac80211/vht.c
index c38b2f0..58887b3 100644
--- a/net/mac80211/vht.c
+++ b/net/mac80211/vht.c
@@ -120,7 +120,6 @@ ieee80211_vht_cap_ie_to_sta_vht_cap(struct ieee80211_sub_if_data *sdata,
struct ieee80211_sta_vht_cap *vht_cap = &sta->sta.vht_cap;
struct ieee80211_sta_vht_cap own_cap;
u32 cap_info, i;
- bool have_80mhz;
memset(vht_cap, 0, sizeof(*vht_cap));
@@ -130,20 +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;
- /* Allow VHT if at least one channel on the sband supports 80 MHz */
- have_80mhz = false;
- for (i = 0; i < sband->n_channels; i++) {
- if (sband->channels[i].flags & (IEEE80211_CHAN_DISABLED |
- IEEE80211_CHAN_NO_80MHZ))
- continue;
-
- have_80mhz = true;
- break;
- }
-
- if (!have_80mhz)
- return;
-
/*
* A VHT STA must support 40 MHz, but if we verify that here
* then we break a few things - some APs (e.g. Netgear R6300v2
--
2.4.3
On Wed, Feb 24, 2016 at 3:37 PM, Ben Greear <[email protected]> wrote:
>
>
> On 02/24/2016 05:32 AM, Arik Nemtsov wrote:
>>
>> On Wed, Feb 24, 2016 at 3:24 PM, Ben Greear <[email protected]>
>> wrote:
>>>>
>>>> Also it's pretty easy to just leave the code there and condition the
>>>> check on the 5GHz band. There's no need to remove it.
>>>
>>>
>>>
>>> Ok, so I can enable VHT on any band as long as the 5Ghz band exists and
>>> allows 80Mhz?
>>>
>>
>> No idea about that. I'm not sure how/if rate modulation is regulated
>> on 2GHz. The ISM band itself is supposed to be open (microwave heating
>> etc.) so it seems fine to me.
>> But don't take me up on that. This is lawyer domain.
>
>
> I'm trying to understand your suggestion.
>
> Maybe you mean I change my patch to only disable VHT if band == 5Ghz AND
> 80Mhz is not available?
Yes. But I'm not saying you can enable 2.4GHz VHT in that case. I
don't know about that.
On 02/23/2016 02:47 AM, Arik Nemtsov wrote:
> On Tue, Feb 23, 2016 at 12:42 AM, <[email protected]> wrote:
>>
>> From: Ben Greear <[email protected]>
>>
>> ath10k supports VHT on 2.4Ghz band.
>> If supplicant and hostapd and radio think
>> VHT should be allowed, then kernel should let them
>> try.
>
> Removing the 80Mhz check entirely is not the right way to go IMO. The
> check is there because there are countries where VHT rates are not
> allowed, even on 20MHz channels. We use the fact these countries have
> no 80MHz-allowed ranges as a crude regulatory hint to disable VHT
> entirely. I'm not sure about the regulatory landscape in these
> countries regarding VHT in 2.4GHz, but please don't break compliance
> for the 5Ghz use-case.
Maybe someone can fix the regulatory logic then?
Add a no-vht flag or whatever?
Any idea which countries this applies to?
Thanks,
Ben
--
Ben Greear <[email protected]>
Candela Technologies Inc http://www.candelatech.com
On Tue, Feb 23, 2016 at 03:10:27PM +0100, Johannes Berg wrote:
> What you really "want" is to use VHT modulations, mostly for the
> dubious purpose of marketing benchmarks to reach 256-QAM modulations.
>
> I think the de-facto standard for this would be to use IEs similar to
> VHT ones, encapsulated in some (Broadcom?) vendor IE. We may have to
> work with that, but that's not what this patch does. Jouni had some
> better idea how this worked, I think.
hostapd has code to negotiate this using the vendor specific element. I
think we ended up getting this working with AP side (i.e., ath10k on the
AP) and if I've understood correctly, this does not need any additional
changes on top of what is available in upstream kernel and hostapd.
Station mode is something that may have been left open since this issue
of what and how to advertise as capabilities came up and there was not
strong enough push at the time to get more than AP side functional..
--
Jouni Malinen PGP id EFC895FA
On Mon, 2016-02-22 at 14:42 -0800, [email protected] wrote:
> From: Ben Greear <[email protected]>
>
> ath10k supports VHT on 2.4Ghz band.
It can't. At least not formally, as this sentence is written, since VHT
per the spec requires operating on the 5 GHz band, and it also requires
80 MHz bandwidth which isn't even available in 2.4 GHz in many
countries.
What you really "want" is to use VHT modulations, mostly for the
dubious purpose of marketing benchmarks to reach 256-QAM modulations.
I think the de-facto standard for this would be to use IEs similar to
VHT ones, encapsulated in some (Broadcom?) vendor IE. We may have to
work with that, but that's not what this patch does. Jouni had some
better idea how this worked, I think.
Also, as written, this patch has practically no effect because no
driver can or should advertise real VHT support on 2.4 GHz band, even
if the code structure were to allow that.
johannes
On 02/24/2016 05:32 AM, Arik Nemtsov wrote:
> On Wed, Feb 24, 2016 at 3:24 PM, Ben Greear <[email protected]> wrote:
>>> Also it's pretty easy to just leave the code there and condition the
>>> check on the 5GHz band. There's no need to remove it.
>>
>>
>> Ok, so I can enable VHT on any band as long as the 5Ghz band exists and
>> allows 80Mhz?
>>
>
> No idea about that. I'm not sure how/if rate modulation is regulated
> on 2GHz. The ISM band itself is supposed to be open (microwave heating
> etc.) so it seems fine to me.
> But don't take me up on that. This is lawyer domain.
I'm trying to understand your suggestion.
Maybe you mean I change my patch to only disable VHT if band == 5Ghz AND
80Mhz is not available?
Thanks,
Ben
--
Ben Greear <[email protected]>
Candela Technologies Inc http://www.candelatech.com
Hi Ben,
On Tue, Feb 23, 2016 at 9:42 AM, <[email protected]> wrote:
> From: Ben Greear <[email protected]>
>
> ath10k supports VHT on 2.4Ghz band.
> If supplicant and hostapd and radio think
> VHT should be allowed, then kernel should let them
> try.
>
> Signed-off-by: Ben Greear <[email protected]>
> ---
> net/mac80211/mlme.c | 16 ----------------
> net/mac80211/util.c | 13 +------------
> net/mac80211/vht.c | 15 ---------------
> 3 files changed, 1 insertion(+), 43 deletions(-)
>
> diff --git a/net/mac80211/util.c b/net/mac80211/util.c
> index f8eb0f8..cabe16f 100644
> --- a/net/mac80211/util.c
> +++ b/net/mac80211/util.c
> @@ -1604,17 +1603,7 @@ static int ieee80211_build_preq_ies_band(struct ieee80211_local *local,
> *offset = noffset;
> }
>
> - /* Check if any channel in this sband supports at least 80 MHz */
> - for (i = 0; i < sband->n_channels; i++) {
> - if (sband->channels[i].flags & (IEEE80211_CHAN_DISABLED |
> - IEEE80211_CHAN_NO_80MHZ))
> - continue;
> -
> - have_80mhz = true;
> - break;
> - }
> -
> - if (sband->vht_cap.vht_supported && have_80mhz && !disable_vht) {
> + if (sband->vht_cap.vht_supported && /*have_80mhz &&*/ !disable_vht) {
Do you want to actually remove have_80mhz here? We do have git history
if this needs to be put back.
Thanks,
--
Julian Calaby
Email: [email protected]
Profile: http://www.google.com/profiles/julian.calaby/
On 02/23/2016 01:08 PM, Jouni Malinen wrote:
> On Tue, Feb 23, 2016 at 03:10:27PM +0100, Johannes Berg wrote:
>> What you really "want" is to use VHT modulations, mostly for the
>> dubious purpose of marketing benchmarks to reach 256-QAM modulations.
>>
>> I think the de-facto standard for this would be to use IEs similar to
>> VHT ones, encapsulated in some (Broadcom?) vendor IE. We may have to
>> work with that, but that's not what this patch does. Jouni had some
>> better idea how this worked, I think.
>
> hostapd has code to negotiate this using the vendor specific element. I
> think we ended up getting this working with AP side (i.e., ath10k on the
> AP) and if I've understood correctly, this does not need any additional
> changes on top of what is available in upstream kernel and hostapd.
>
> Station mode is something that may have been left open since this issue
> of what and how to advertise as capabilities came up and there was not
> strong enough push at the time to get more than AP side functional..
Hostapd and supplicant did not need any changes in my testing.
But, you *have* to modify the kernel or it will disable VHT no matter
what supplicant says...
Thanks,
Ben
--
Ben Greear <[email protected]>
Candela Technologies Inc http://www.candelatech.com
On Wed, Feb 24, 2016 at 3:24 PM, Ben Greear <[email protected]> wrote:
>> Also it's pretty easy to just leave the code there and condition the
>> check on the 5GHz band. There's no need to remove it.
>
>
> Ok, so I can enable VHT on any band as long as the 5Ghz band exists and
> allows 80Mhz?
>
No idea about that. I'm not sure how/if rate modulation is regulated
on 2GHz. The ISM band itself is supposed to be open (microwave heating
etc.) so it seems fine to me.
But don't take me up on that. This is lawyer domain.
Arik
On 02/22/2016 02:48 PM, Julian Calaby wrote:
> Hi Ben,
>
> On Tue, Feb 23, 2016 at 9:42 AM, <[email protected]> wrote:
>> From: Ben Greear <[email protected]>
>>
>> ath10k supports VHT on 2.4Ghz band.
>> If supplicant and hostapd and radio think
>> VHT should be allowed, then kernel should let them
>> try.
>>
>> Signed-off-by: Ben Greear <[email protected]>
>> ---
>> net/mac80211/mlme.c | 16 ----------------
>> net/mac80211/util.c | 13 +------------
>> net/mac80211/vht.c | 15 ---------------
>> 3 files changed, 1 insertion(+), 43 deletions(-)
>>
>> diff --git a/net/mac80211/util.c b/net/mac80211/util.c
>> index f8eb0f8..cabe16f 100644
>> --- a/net/mac80211/util.c
>> +++ b/net/mac80211/util.c
>> @@ -1604,17 +1603,7 @@ static int ieee80211_build_preq_ies_band(struct ieee80211_local *local,
>> *offset = noffset;
>> }
>>
>> - /* Check if any channel in this sband supports at least 80 MHz */
>> - for (i = 0; i < sband->n_channels; i++) {
>> - if (sband->channels[i].flags & (IEEE80211_CHAN_DISABLED |
>> - IEEE80211_CHAN_NO_80MHZ))
>> - continue;
>> -
>> - have_80mhz = true;
>> - break;
>> - }
>> -
>> - if (sband->vht_cap.vht_supported && have_80mhz && !disable_vht) {
>> + if (sband->vht_cap.vht_supported && /*have_80mhz &&*/ !disable_vht) {
>
> Do you want to actually remove have_80mhz here? We do have git history
> if this needs to be put back.
Yes, I just missed that when cleaning up my patch.
I'll wait for some other feedback and then do a -v2.
Thanks,
Ben
--
Ben Greear <[email protected]>
Candela Technologies Inc http://www.candelatech.com
On 02/23/2016 06:10 AM, Johannes Berg wrote:
> On Mon, 2016-02-22 at 14:42 -0800, [email protected] wrote:
>> From: Ben Greear <[email protected]>
>>
>> ath10k supports VHT on 2.4Ghz band.
>
> It can't. At least not formally, as this sentence is written, since VHT
> per the spec requires operating on the 5 GHz band, and it also requires
> 80 MHz bandwidth which isn't even available in 2.4 GHz in many
> countries.
>
> What you really "want" is to use VHT modulations, mostly for the
> dubious purpose of marketing benchmarks to reach 256-QAM modulations.
>
> I think the de-facto standard for this would be to use IEs similar to
> VHT ones, encapsulated in some (Broadcom?) vendor IE. We may have to
> work with that, but that's not what this patch does. Jouni had some
> better idea how this worked, I think.
>
> Also, as written, this patch has practically no effect because no
> driver can or should advertise real VHT support on 2.4 GHz band, even
> if the code structure were to allow that.
I don't recall making any changes to ath10k driver or firmware that would
enable VHT on 2.4, but it is there anyway in the 4.4 kernel.
I tested my patch, and I see 600Mbps tx rates (and other VHT encodings) reported,
and vht_capa shows up as expected, so I think it must be at least
partially working.
[root@ben-ota2 lanforge]# iw phy wiphy0 info
Wiphy wiphy0
max # scan SSIDs: 16
max scan IEs length: 195 bytes
max # sched scan SSIDs: 0
max # match sets: 0
Retry short limit: 7
Retry long limit: 4
Coverage class: 0 (up to 0m)
Device supports RSN-IBSS.
Device supports AP-side u-APSD.
Supported Ciphers:
* WEP40 (00-0f-ac:1)
* WEP104 (00-0f-ac:5)
* TKIP (00-0f-ac:2)
* CCMP (00-0f-ac:4)
* CMAC (00-0f-ac:6)
Available Antennas: TX 0x7 RX 0x7
Configured Antennas: TX 0x7 RX 0x7
Supported interface modes:
* IBSS
* managed
* AP
* AP/VLAN
* monitor
* mesh point
* P2P-client
* P2P-GO
* P2P-device
Band 1:
Capabilities: 0x19ef
RX LDPC
HT20/HT40
SM Power Save disabled
RX HT20 SGI
RX HT40 SGI
TX STBC
RX STBC 1-stream
Max AMSDU length: 7935 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-23
VHT Capabilities (0x338001b2):
Max MPDU length: 11454
Supported Channel Width: neither 160 nor 80+80
RX LDPC
short GI (80 MHz)
TX STBC
RX antenna pattern consistency
TX antenna pattern consistency
VHT RX MCS set:
1 streams: MCS 0-9
2 streams: MCS 0-9
3 streams: MCS 0-9
4 streams: not supported
5 streams: not supported
6 streams: not supported
7 streams: not supported
8 streams: not supported
VHT RX highest supported: 0 Mbps
VHT TX MCS set:
1 streams: MCS 0-9
2 streams: MCS 0-9
3 streams: MCS 0-9
4 streams: not supported
5 streams: not supported
6 streams: not supported
7 streams: not supported
8 streams: not supported
VHT TX highest supported: 0 Mbps
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
Frequencies:
* 2412 MHz [1] (30.0 dBm)
* 2417 MHz [2] (30.0 dBm)
* 2422 MHz [3] (30.0 dBm)
* 2427 MHz [4] (30.0 dBm)
* 2432 MHz [5] (30.0 dBm)
* 2437 MHz [6] (30.0 dBm)
* 2442 MHz [7] (30.0 dBm)
* 2447 MHz [8] (30.0 dBm)
* 2452 MHz [9] (30.0 dBm)
* 2457 MHz [10] (30.0 dBm)
* 2462 MHz [11] (30.0 dBm)
* 2467 MHz [12] (disabled)
* 2472 MHz [13] (disabled)
* 2484 MHz [14] (disabled)
Band 2:
Capabilities: 0x19ef
RX LDPC
HT20/HT40
SM Power Save disabled
RX HT20 SGI
RX HT40 SGI
TX STBC
RX STBC 1-stream
Max AMSDU length: 7935 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-23
VHT Capabilities (0x338001b2):
Max MPDU length: 11454
Supported Channel Width: neither 160 nor 80+80
RX LDPC
short GI (80 MHz)
TX STBC
RX antenna pattern consistency
TX antenna pattern consistency
VHT RX MCS set:
1 streams: MCS 0-9
2 streams: MCS 0-9
3 streams: MCS 0-9
4 streams: not supported
5 streams: not supported
6 streams: not supported
7 streams: not supported
8 streams: not supported
VHT RX highest supported: 0 Mbps
VHT TX MCS set:
1 streams: MCS 0-9
2 streams: MCS 0-9
3 streams: MCS 0-9
4 streams: not supported
5 streams: not supported
6 streams: not supported
7 streams: not supported
8 streams: not supported
VHT TX highest supported: 0 Mbps
Bitrates (non-HT):
* 6.0 Mbps
* 9.0 Mbps
* 12.0 Mbps
* 18.0 Mbps
* 24.0 Mbps
* 36.0 Mbps
* 48.0 Mbps
* 54.0 Mbps
Frequencies:
* 5180 MHz [36] (17.0 dBm)
* 5200 MHz [40] (17.0 dBm)
* 5220 MHz [44] (17.0 dBm)
* 5240 MHz [48] (17.0 dBm)
* 5260 MHz [52] (23.0 dBm) (no IR, radar detection)
DFS state: usable (for 49710 sec)
DFS CAC time: 60000 ms
* 5280 MHz [56] (23.0 dBm) (no IR, radar detection)
DFS state: usable (for 49710 sec)
DFS CAC time: 60000 ms
* 5300 MHz [60] (23.0 dBm) (no IR, radar detection)
DFS state: usable (for 49710 sec)
DFS CAC time: 60000 ms
* 5320 MHz [64] (23.0 dBm) (no IR, radar detection)
DFS state: usable (for 49710 sec)
DFS CAC time: 60000 ms
* 5500 MHz [100] (disabled)
* 5520 MHz [104] (disabled)
* 5540 MHz [108] (disabled)
* 5560 MHz [112] (disabled)
* 5580 MHz [116] (disabled)
* 5600 MHz [120] (disabled)
* 5620 MHz [124] (disabled)
* 5640 MHz [128] (disabled)
* 5660 MHz [132] (disabled)
* 5680 MHz [136] (disabled)
* 5700 MHz [140] (disabled)
* 5720 MHz [144] (disabled)
* 5745 MHz [149] (30.0 dBm)
* 5765 MHz [153] (30.0 dBm)
* 5785 MHz [157] (30.0 dBm)
* 5805 MHz [161] (30.0 dBm)
* 5825 MHz [165] (30.0 dBm)
Supported commands:
* new_interface
* set_interface
* new_key
* start_ap
* new_station
* new_mpath
* set_mesh_config
* set_bss
* authenticate
* associate
* deauthenticate
* disassociate
* join_ibss
* join_mesh
* remain_on_channel
* set_tx_bitrate_mask
* frame
* frame_wait_cancel
* set_wiphy_netns
* set_channel
* set_wds_peer
* probe_client
* set_noack_map
* register_beacons
* start_p2p_device
* set_mcast_rate
* testmode
* channel_switch
* set_qos_map
* connect
* disconnect
Supported TX frame types:
* IBSS: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
* managed: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
* AP: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
* AP/VLAN: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
* mesh point: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
* P2P-client: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
* P2P-GO: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
* P2P-device: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
Supported RX frame types:
* IBSS: 0x40 0xb0 0xc0 0xd0
* managed: 0x40 0xd0
* AP: 0x00 0x20 0x40 0xa0 0xb0 0xc0 0xd0
* AP/VLAN: 0x00 0x20 0x40 0xa0 0xb0 0xc0 0xd0
* mesh point: 0xb0 0xc0 0xd0
* P2P-client: 0x40 0xd0
* P2P-GO: 0x00 0x20 0x40 0xa0 0xb0 0xc0 0xd0
* P2P-device: 0x40 0xd0
software interface modes (can always be added):
* AP/VLAN
* monitor
valid interface combinations:
* #{ managed, P2P-client } <= 64, #{ P2P-GO } <= 3, #{ AP } <= 7, #{ IBSS } <= 1,
total <= 64, #channels <= 1, STA/AP BI must match, radar detect widths: { 20 MHz (no HT), 20 MHz, 40 MHz, 80 MHz }
HT Capability overrides:
* MCS: ff ff ff ff ff ff ff ff ff ff
* maximum A-MSDU length
* supported channel width
* short GI for 40 MHz
* max A-MPDU length exponent
* min MPDU start spacing
Device supports TX status socket option.
Device supports HT-IBSS.
Device supports SAE with AUTHENTICATE command
Device supports scan flush.
Device supports per-vif TX power setting
Driver supports a userspace MPM
Driver/device bandwidth changes during BSS lifetime (AP/GO mode)
Device supports static SMPS
Device supports configuring vdev MAC-addr on create.
Device supports VHT-IBSS.
[root@ben-ota2 lanforge]#
Thanks,
Ben
--
Ben Greear <[email protected]>
Candela Technologies Inc http://www.candelatech.com
On 02/24/2016 12:40 AM, Arik Nemtsov wrote:
> On Tue, Feb 23, 2016 at 3:46 PM, Ben Greear <[email protected]> wrote:
>>
>>
>> On 02/23/2016 02:47 AM, Arik Nemtsov wrote:
>>>
>>> On Tue, Feb 23, 2016 at 12:42 AM, <[email protected]> wrote:
>>>>
>>>>
>>>> From: Ben Greear <[email protected]>
>>>>
>>>> ath10k supports VHT on 2.4Ghz band.
>>>> If supplicant and hostapd and radio think
>>>> VHT should be allowed, then kernel should let them
>>>> try.
>>>
>>>
>>> Removing the 80Mhz check entirely is not the right way to go IMO. The
>>> check is there because there are countries where VHT rates are not
>>> allowed, even on 20MHz channels. We use the fact these countries have
>>> no 80MHz-allowed ranges as a crude regulatory hint to disable VHT
>>> entirely. I'm not sure about the regulatory landscape in these
>>> countries regarding VHT in 2.4GHz, but please don't break compliance
>>> for the 5Ghz use-case.
>>
>>
>> Maybe someone can fix the regulatory logic then?
>>
>> Add a no-vht flag or whatever?
>
> This is more tricky that it looks at first - basically current
> regulatory "hooks" concern channel width and location, transmit power
> etc. Here regulatory compliance means never emitting the VHT IE in
> probe requests etc. So a "no vht" flag would be useless to the reg.c
> code - it currently never looks at IEs. Some cards even generate them
> at the FW level.
> All in all I think the current small bit of ugliness is justified for
> regulatory compliance.
>
> Also it's pretty easy to just leave the code there and condition the
> check on the 5GHz band. There's no need to remove it.
Ok, so I can enable VHT on any band as long as the 5Ghz band exists and
allows 80Mhz?
Thanks,
Ben
>
>>
>> Any idea which countries this applies to?
>
> I know Russia is one such country. Not sure about others.
>
> Arik
>
--
Ben Greear <[email protected]>
Candela Technologies Inc http://www.candelatech.com
On Tue, Feb 23, 2016 at 3:46 PM, Ben Greear <[email protected]> wrote:
>
>
> On 02/23/2016 02:47 AM, Arik Nemtsov wrote:
>>
>> On Tue, Feb 23, 2016 at 12:42 AM, <[email protected]> wrote:
>>>
>>>
>>> From: Ben Greear <[email protected]>
>>>
>>> ath10k supports VHT on 2.4Ghz band.
>>> If supplicant and hostapd and radio think
>>> VHT should be allowed, then kernel should let them
>>> try.
>>
>>
>> Removing the 80Mhz check entirely is not the right way to go IMO. The
>> check is there because there are countries where VHT rates are not
>> allowed, even on 20MHz channels. We use the fact these countries have
>> no 80MHz-allowed ranges as a crude regulatory hint to disable VHT
>> entirely. I'm not sure about the regulatory landscape in these
>> countries regarding VHT in 2.4GHz, but please don't break compliance
>> for the 5Ghz use-case.
>
>
> Maybe someone can fix the regulatory logic then?
>
> Add a no-vht flag or whatever?
This is more tricky that it looks at first - basically current
regulatory "hooks" concern channel width and location, transmit power
etc. Here regulatory compliance means never emitting the VHT IE in
probe requests etc. So a "no vht" flag would be useless to the reg.c
code - it currently never looks at IEs. Some cards even generate them
at the FW level.
All in all I think the current small bit of ugliness is justified for
regulatory compliance.
Also it's pretty easy to just leave the code there and condition the
check on the 5GHz band. There's no need to remove it.
>
> Any idea which countries this applies to?
I know Russia is one such country. Not sure about others.
Arik
On Tue, Feb 23, 2016 at 12:42 AM, <[email protected]> wrote:
>
> From: Ben Greear <[email protected]>
>
> ath10k supports VHT on 2.4Ghz band.
> If supplicant and hostapd and radio think
> VHT should be allowed, then kernel should let them
> try.
Removing the 80Mhz check entirely is not the right way to go IMO. The
check is there because there are countries where VHT rates are not
allowed, even on 20MHz channels. We use the fact these countries have
no 80MHz-allowed ranges as a crude regulatory hint to disable VHT
entirely. I'm not sure about the regulatory landscape in these
countries regarding VHT in 2.4GHz, but please don't break compliance
for the 5Ghz use-case.
Arik
On 02/23/2016 06:22 AM, Johannes Berg wrote:
> On Tue, 2016-02-23 at 06:18 -0800, Ben Greear wrote:
>
>> [root@ben-ota2 lanforge]# iw phy wiphy0 info
>> Wiphy wiphy0
>>
>> Band 1:
> [...]
>> VHT Capabilities (0x338001b2):
>> Max MPDU length: 11454
>> Supported Channel Width: neither 160 nor 80+80
>> RX LDPC
>> short GI (80 MHz)
>> TX STBC
>> RX antenna pattern consistency
>> TX antenna pattern consistency
>> VHT RX MCS set:
>> 1 streams: MCS 0-9
>> 2 streams: MCS 0-9
>> 3 streams: MCS 0-9
>> 4 streams: not supported
>> 5 streams: not supported
>> 6 streams: not supported
>> 7 streams: not supported
>> 8 streams: not supported
>> VHT RX highest supported: 0 Mbps
>> VHT TX MCS set:
>> 1 streams: MCS 0-9
>> 2 streams: MCS 0-9
>> 3 streams: MCS 0-9
>> 4 streams: not supported
>> 5 streams: not supported
>> 6 streams: not supported
>> 7 streams: not supported
>> 8 streams: not supported
>> VHT TX highest supported: 0 Mbps
>
>> Frequencies:
>> * 2412 MHz [1] (30.0 dBm)
>>
> [...]
>
> Oops. Well, the driver isn't supposed to do that, this is certainly
> non-spec behaviour.
Is there any harm though? There is at least one other AP manufacturer
that really wants to test this feature, so I guess there will be products
on the market soon enough that support VHT in 2.4Ghz band.
Some day soon-ish, we'll benchmark this in an isolation chamber & over-the-air to see
how it actually performs.
Thanks,
Ben
--
Ben Greear <[email protected]>
Candela Technologies Inc http://www.candelatech.com
On Tue, 2016-02-23 at 06:18 -0800, Ben Greear wrote:
> [root@ben-ota2 lanforge]# iw phy wiphy0 info
> Wiphy wiphy0
>
> Band 1:
[...]
> VHT Capabilities (0x338001b2):
> Max MPDU length: 11454
> Supported Channel Width: neither 160 nor 80+80
> RX LDPC
> short GI (80 MHz)
> TX STBC
> RX antenna pattern consistency
> TX antenna pattern consistency
> VHT RX MCS set:
> 1 streams: MCS 0-9
> 2 streams: MCS 0-9
> 3 streams: MCS 0-9
> 4 streams: not supported
> 5 streams: not supported
> 6 streams: not supported
> 7 streams: not supported
> 8 streams: not supported
> VHT RX highest supported: 0 Mbps
> VHT TX MCS set:
> 1 streams: MCS 0-9
> 2 streams: MCS 0-9
> 3 streams: MCS 0-9
> 4 streams: not supported
> 5 streams: not supported
> 6 streams: not supported
> 7 streams: not supported
> 8 streams: not supported
> VHT TX highest supported: 0 Mbps
> Frequencies:
> * 2412 MHz [1] (30.0 dBm)
>
[...]
Oops. Well, the driver isn't supposed to do that, this is certainly
non-spec behaviour.
johannes