net80211: fix VHT160 and VHT80P80 selection and enable in LinuxKPI 802.11

[bz]

Summary

net80211: fix VHT160 and VHT80P80 selection and enable in LinuxKPI 802.11

Between 802.11ac-2013 and 802.11-2020 some fields were deprecated and the
wau VHT160 and VHT80P80 are selected has changed.
In order to get onto VHT160 with modern APs adopt and support both the
deprecated as well as the new logic.

For simplicity of blocks we pull out the non-HT40 handling early on,
followed by the "use HT", followed by the deprectaed options and then
the 80Mhz channel width.

In all cases keep checking (a) what is locally supported, (b) what the
user has locally allowed (FVHT flags, [-]vht160 [-]vht80p80 [-]vht80
[-]vht40), as well as (c) what is announced. Provide possible fallbacks
to lower channel widths in all cases (but VHT20, which means VHT is
disabled).

With this enable VHT160 and VHT80P80 in the LinuxKPI 802.11 driver
compat code as well.

Sponsored by: The FreeBSD Foundation
MFC after: 3 days

[bz]

There's a logic bug in there from last night when AP and STA disagree on the max possible connection. We used to allow that in the past and I do not anymore. I'll revise it. I realized last night once I was AFK and just tested by doing -vht160 and got bumped down to HT/40.

[bz]

Update to provie fallbacks (and logging if enabled).

[adrian]

ah I'm glad you got to this! I've been eyeballing fixing the 80/80 and 160 wide code for a while, but there's just been a lot of stuff in front of it.

I'm gonna tentatively say this looks OK, but I haven't tested it yet - I don't have a 160MHz wide AP at home (but I do have 160MHz wide ath10k stuff, I just need to fire it up in STA mode.)

[bz]

I've had a few people try this at least with no ill effects (though I am not sure they could test VHT160). @thj can you test the net80211 part?
I don't know otherwise what to do with it as it's been sitting here for a month now.

[thj]

In D49773#1153069, @bz wrote:

I've had a few people try this at least with no ill effects (though I am not sure they could test VHT160). @thj can you test the net80211 part?
I don't know otherwise what to do with it as it's been sitting here for a month now.

I'm pretty sure I can, I'll put it this on the list for tomorrow

[thj]

No regressions I can see, iwlwifi has vht160 enabled without any configuration.

I don't seem to end up with a 160MHz association on either of my openwrt based APs:

GL-INET MT3000

root@GL-MT3000:~# iwinfo rax0 htmodelist                              
HT20 HT40 VHT20 VHT40 VHT80 VHT160 HE20 HE40 HE80 HE160               
   
root@GL-MT3000:~# iwinfo rax0 assoclist                                                      
4C:49:6C:80:38:5B  -20 dBm / unknown (SNR -20)  0 ms ago                                     
        RX: 195.0 MBit/s, VHT-MCS 4, 80MHz, VHT-NSS 1         0 Pkts.                        
        TX: 866.0 MBit/s, VHT-MCS 9, 80MHz, VHT-NSS 2         0 Pkts.                        
        expected throughput: unknown

or the openwrt one

root@OpenWrt:~# iwinfo phy1-ap0 htmodelist
HT20 HT40 VHT20 VHT40 VHT80 VHT160 HE20 HE40 HE80 HE160 

root@OpenWrt:~# iwinfo phy1-ap0 assoclist                                                                                          
4C:49:6C:80:38:5B  -69 dBm / -91 dBm (SNR 22)  24390 ms ago                                                                        
        RX: 260.0 MBit/s, VHT-MCS 3, 80MHz, VHT-NSS 2    252041 Pkts.         
        TX: 585.0 MBit/s, VHT-MCS 7, 80MHz, VHT-NSS 2    317148 Pkts.         
        expected throughput: unknown

Rates to both (when physically near) at about 550Mit/s.

I added logging to ieee80211_vht_get_vhtflags and we never set can_vht160.

Let me know what output you would like to debug with and I can share it via email

[mark_freebsdfoundation.org]

I've also tested it today, and things are much the same as they were. I'm finding conflicting information as to whether the base station I'm connected to supports 160 wide channels or not. Some resources I find say yes, some say no (it's a TP-Link Deco M9Plus - which is 'AC2200' it says). Either way, I'm not getting a 160 connection, and ifconfig still shows -vht160:

ifconfig wlan0
wlan0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
	options=0
	ether 08:b4:d2:fe:d1:a7
	inet 192.168.98.115 netmask 0xffffff00 broadcast 192.168.98.255
	inet6 fe80::ab4:d2ff:fefe:d1a7%wlan0 prefixlen 64 scopeid 0x2
	groups: wlan
	ssid kkkkkkk channel 36 (5180 MHz 11a vht/80+) bssid ce:c9:e3:99:b5:f9
	regdomain ETSI country GB authmode WPA2/802.11i privacy ON
	deftxkey UNDEF AES-CCM 2:128-bit txpower 23 bmiss 7 mcastrate 6
	mgmtrate 6 scanvalid 60 -ampdutx ampdurx ampdulimit 64k
	-amsdutx amsdurx shortgi -ldpctx ldpcrx -uapsd vht vht40 vht80 -vht160
	vht80p80 wme roaming MANUAL
	parent interface: iwlwifi0
	media: IEEE 802.11 Wireless Ethernet autoselect mode 11ac
	status: associated
	nd6 options=1<PERFORMNUD>

[bz]

In D49773#1153842, @mark_freebsdfoundation.org wrote:

I've also tested it today, and things are much the same as they were. I'm finding conflicting information as to whether the base station I'm connected to supports 160 wide channels or not. Some resources I find say yes, some say no (it's a TP-Link Deco M9Plus - which is 'AC2200' it says). Either way, I'm not getting a 160 connection, and ifconfig still shows -vht160:

Yes, you have vht80p80 supported apparently. That is 160Mhz on two non-consecutive channels. I have an open TODO here to get back to you to see as-to why that is not selected but given you are the only one so far I have noticed seeing this.

Do I have a ifconfig -v wlan0 list sta output from you from when you are associated at 5Ghz?

[bz]

Rates to both (when physically near) at about 550Mit/s.

I added logging to ieee80211_vht_get_vhtflags and we never set can_vht160.

Let me know what output you would like to debug with and I can share it via email

@thj Can you share the output of the ifconfig -v wlan0 list sta and possibly if you can a beacon or assoc response pcap per email?

[mark_freebsdfoundation.org]

In D49773#1153892, @bz wrote:

Yes, you have vht80p80 supported apparently. That is 160Mhz on two non-consecutive channels. I have an open TODO here to get back to you to see as-to why that is not selected but given you are the only one so far I have noticed seeing this.

Intriguing! No problem.

Do I have a ifconfig -v wlan0 list sta output from you from when you are associated at 5Ghz?

You do. Or should have — via email. Let me know if you can't find it, and I'll happily sent it over again Bjoern.

[thj]

I'm not able to convince an ap to actually do 160MHz channels - despite support in the radios.

I think if we hit the limit of what we can test we should land this and work on bugs once we can actually test.

[thj]

I've sent test output via email. With 160MHz configured on my ap and it beaconing iwlwifi doesn't pick a vht rate for the band, just 80211a

[bz]

In D49773#1155062, @thj wrote:

I've sent test output via email. With 160MHz configured on my ap and it beaconing iwlwifi doesn't pick a vht rate for the band, just 80211a

I replied to you. It's net80211 doing the channel selection and I cannot see why it wouldn't do 11ac or 11n; You need to check your setup.

[thj]

Setting the regdomain on iwlwifi cleared this out - sorry for the testing delay.

I'm starting to think regdomain is one of our bigger issues.

[bz]

In D49773#1155343, @thj wrote:

Setting the regdomain on iwlwifi cleared this out - sorry for the testing delay.

I'm starting to think regdomain is one of our bigger issues.

Yes and it will be worse when we get to 11ax and 11be... That's why I did the experimental regdomain.xml generated from the Linux regdb; but ifconfig at least and possibly other places have FCC hard coded as default in them etc so there is more work to do before I could seriously say we can attempt to switch.