[WIP,RFT,RFC] mac80211: add support for QAM-256 in 2.4GHz 802.11n

[Ansuel]

Add support for QAM-256 in 2.4GHz 802.11n. This is non-standard and comunicate vht capabilities in 2.4GHz 802.11n permittin, for supported clients, to benefits for additional data rate.

Many driver supports this, for a start enable this for ath10k and ath11k.

Signed-off-by: Christian Marangi [email protected]

---

I would ask the community some effort to document all the info we have about this feature, benefits ANY PROBLEM with this. The intention is to propose this upstream and I need some very good reasoning for this hoping they don't NACK this directly.

Also I would ask if there is any info on a parallel feature like QAM-1024 that should be present in 802.11ac

How to enable

Set for 2.4GHz htmode to VHT20 (or VHT40) FOR SUPPORTED CARD

Supported card

• qca9984 (Netgear r7800)

Supported device from report

• Samsung Galaxy S21

Additional Info on the thing

In [1] there was an interesting discussion about this. The summarize was that it's obviously non-standard but actually not that non-standard since this just push vht on 2.4GHz, something that was used later for wifi ax.

[1] https://www.cwnp.com/forums/posts?postNum=307375

_{Continuation of #12594 and #2522}

[Ansuel]

@V10lator can you suggest some patch for mt76 with this new implementation (aka the additional bit to set) I would like to include it in this pr so people can test wider devices.

@backslashxx @Leo-PL can you by chance test this version on ipq40xx?

@rany2 also tagging you since you are interested in the feature?

[Ansuel]

@tiagogaspar8 @Vladdrako@DavideFioravanti @dengqf6 @ghost @namidairo @dhewg sorry for the spam tag but you were interested in this feature

[DavideFioravanti]

Good job @Ansuel. Let's hope that this time it will gain enough attention to be accepted upstream.

However I can test it on ath10k, atk11k and mt76 devices. Do you need any particular test?

[Ansuel]

@DavideFioravanti I need proof that it does actual works, speed improvements and specific router where this is applied and clients... I know that is lots of data but we really need to make a list.

[rany2]

@Ansuel Thanks for tagging me, I have a small question regarding this change. An issue I've had with the previous patches is getting the supported htmode always excludes VHT (so it will output something like HT20 HT40 and not include VHT20 VHT40). Does this address this?

[Ansuel]

@rany2 where this happens? anyway these kind of problem are fixable...

[rany2]

@Ansuel

root@rooter2:~# iwinfo eap2ghz htmode
HT20 HT40 HE20 HE40 

VHT20 VHT40 is not in the list

[Ansuel]

@rany2 that is totally a problem i assume this is an ax system correct? anyway i would ask to test this new version and then report back if this is still a thing.

[rany2]

@Ansuel Yes it's an AX system, but it also occurs with an AC router I have.

[Leo-PL]

@Ansuel I can (and I'd like to) do some testing on ipq40xx, but only after 25.06, I'm busy AF until end of next week.

[backslashxx]

Since others are gonna test ipq40xx, then heres my report for MT7612U and MT7612E being ran on 2.4GHz (albeit this is with PR 2522)

https://imgur.com/a/LyvERxO https://imgur.com/a/v6NSbEz

As for clients, a few phones I see on my clients supports this

POCO M3 Redmi Note 10 Redmi 10C

hell, even intel cards do support this as AP (tested 8260, 9260 and AX200), and they dont even need a driver patch, just needs mac80211 support. I can make a report if needed.

[rany2]

@backslashxx I haven't had the time to test it yet, but could you report back if iwinfo >>2ghz interface<< htmode returns VHT20 and VHT40 or not?

[Ansuel]

@backslashxx can you share what path you used for mt so i can include them here?

[backslashxx]

@backslashxx can you share what path you used for mt so i can include them here?

https://github.com/openwrt/openwrt/pull/2522 + https://github.com/openwrt/mt76/pull/333

[Ansuel]

I would ask to align to this new implementation... lets try to focus on one that can actually be proposed upstream please...

[raenye]

Hello everybody. I'd love to help with mt76 testing and implementation. Running OpenWrt on DAP-1620-B1 that has via MT7615D (DBDC bgn/an+ac).

Not sure what changes are needed in mt76 though. The original patches were limited to a few functions in mt76/mac80211.c; is something else needed now? Furthermore, AFAICT, the vendor_vht configuration change is no longer needed, right?

@Ansuel As for convincing upstream why we support out-of-spec features, my ~2~ 3 cents are:

1. We already go out-of-spec by having the "Force 40MHz mode" option. The Advanced Settings tab on LuCI states explicitly "Using this option does not comply with IEEE 802.11n-2009!";
2. While out-of-spec, using VHT on 2.4 GHz respects regulation (e.g. no Tx on new frequencies, no breach of Tx power limits);
3. Quoting the Cranberries, "Everybody Else Is Doing It, So Why Can't We?" where everybody else is both AP vendors (e.g., D-Link) and clients (e.g. Snapdragon SoCs).

[rany2]

@raenye Have a look at:

• https://github.com/rany2/mt76/commit/b72ae710b4d77082139d9238404c38f55836a214
• https://github.com/rany2/mt76/commit/8c4d538ed24e26b23c6c6d99be091c75770b38c2
• https://github.com/rany2/mt76/commit/c555acfa7a1830b9718f97a58aa6fbf68112da1e
• https://github.com/rany2/mt76/commit/1da209df5742c2d4d4fd8f98b1925f1b0d565dce
• https://github.com/rany2/mt76/commit/c48ae4cf191d49d8a9ae2dcebda2e77bc19ce033

[Ansuel]

As for convincing upstream why we support out-of-spec features, my ~2~ 3 cents are:

1. that is not upstream and the regulation was relaxed so we can support that non-standard thing with a simple option
2. true and that might be the main reason there is a chance this can be accepted
3. vendor downstream do all kind of hack for marketing reason... pushing stuff upstream require standards or it would be bloated with all kind of hacks.

This testing request is to check if the option actually cause some regression on some client. For sure it needs to be enabled per driver. If we notice some regression with some device I will also give the option to disable this from the user. If it doesn't cause any regression then we just enable it by default on devices. No reason to bloat the kmods with additional options.

From the driver side the additional bit needs to be enabled (so both the new bit vendor_qam256_supported AND vht_supported)

[rany2]

Something missing from these patches is txbf enablement for mt7915+... but these are the minimum patches to get it working. At any rate, beamforming is a bit problematic on those mt7915 anyway (causes issues with fw even on 5ghz). So better not mess with it.

[raenye]

@raenye Have a look at: ...

Compiling now, thanks. The only change to configuration needed is to set htmode to VHT20 instead of HT20, right?

And for those who don't want to git clone, cherry-pick, and format-patch, here's a patch that can be dropped at openwrt/package/kernel/mt76/patches/: 200-mt76-allow-VHT-rate-on-2.4GHz.patch

EDIT: now with the vendor_qam256_supported bit set.

[rany2]

@raenye Have a look at: ...

Compiling now, thanks. The only change to configuration needed is to set htmode to VHT20 instead of HT20, right?

And for those who don't want to git clone, cherry-pick, and format-patch, here's a patch that can be dropped at openwrt/package/kernel/mt76/patches/: 200-mt76-allow-VHT-rate-on-2.4GHz.patch

I'm actually not sure, there weren't any changes to hostapd.sh so I think this is your only recourse. Is that right @Ansuel ?

[Ansuel]

@raenye the additional bit is not present so it won't work

[raenye]

Still getting only HT on 2.4:

# iwinfo phy0 htmode
HT20 HT40
# iwinfo phy1 htmode
HT20 HT40 VHT20 VHT40 VHT80

with the patch above (after setting the bit, maybe I did it wrong).

[rany2]

@raenye With the old patches you needed additional changes to hostapd.sh to get it working, seems like this is the case here as well unless more changes are made. There's a chance it might be a mt76 issue though, so maybe better to wait for someone with QCA chip to try.

[Ansuel]

Guys... check the patch with ath10k....

band->vht_cap.vendor_qam256_supported = true;

this is needed to be added where vht_cap is defined... lets not blindly add patch and expect things to magically works

[rany2]

@Ansuel He already did that in his patch, he had an extra commit that addressed it.

[Ansuel]

@rany2 it should really be done in the single patch and not globally (that was the idea of the additional bit) but I get it's to keep things working with both implementation....

for iwinfo it's probably something to support in iwinfo but it's not really the task/what was asked with this pr so i wouldn't put efforts there.

[raenye]

and not globally

Not sure what you mean by globally. I added this to mt76_init_sband_2g, which is called by mt76_register_phy and mt76_register_device.

Anyway, I also have an ath10k device (DAP-1720) to compare this with. Will compile and test later.

[Ansuel]

Not sure what you mean by globally. I added this to mt76_init_sband_2g, which is called by mt76_register_phy and mt76_register_device.

(your patch enable it for every mt76 card. The bit should be set where vht_cap are added for each single wifi card)

[rany2]

@raenye I think what he means is, instead of

phy->sband_2g.sband.vht_cap.vendor_qam256_supported = true;

do

phy->sband_2g.sband.vht_cap.vendor_qam256_supported = vht;