Ath10k-ct spits a kernel oops, but it’s an unrelated issue (warning now treated as error).
I thought there was an issue as my iPhone wouldn’t connect. Seems instead that iOS devices don’t seem to like 80+80 mode. I tested android and windows devices and all connected fine.
If you apply the patch and then run wifi config it will rewrite /etc/board.json with the new capabilities (if they are supported).
Otherwise you can check iw manually.
I could not find enough info on the standards for EHT to understand how to set 80P80 (if it is even supported) so for now I have excluded it.
Support for extra modes is trivial though! Just need hardware and a bit of reading of the standards and hostapd.conf
My router is an ASUS TUF-AX6000 running OpenWrt 24.10.0.
Executing iw phy1 info gives the following results, so I assume my router has the right capabilities.
VHT Capabilities (0x339b79f6):
(...)
short GI (160/80+80 MHz)
(...)
HE PHY Capabilities: (0x4c70ce926d1bf3164e3f00):
(...)
20MHz in 160/80+80MHz HE PPDU
80MHz in 160/80+80MHz HE PPDU
My understanding of the patch ist that you only change 2 existing scripts, so I applied the patch manually:
Then I updated the config with HE80P80 (and VHT80P80) and channels 36 + 149. But when I run /etc/init.d/network restart wifi doesn't come up (neither 2,4Ghz nor 5Ghz). I couldn't find anything relevant in the system log.
I guess it is not accurate to use that line for reference, because that line applies in both scenarios:
Hardware supports 160 MHz but not 80+80 MHz, short GI in 160 MHz
Hardware supports both 160 MHz and 80+80 MHz, short GI in 160 / 80+80 MHz
Checking Supported Channel Width: should be more accurate.
From the VHT Capabilities string provided (0x339b79f6), it seems that the hardware supports 160 MHz but not 80+80 MHz for 802.11ac.
(For 802.11ax, not sure whether I have decoded the HE PHY Capabilities string correctly but maybe it supports HE80+80, you can check whether it says HE160/HE80+80/5GHz instead of HE160/5GHz.)
P.S. If iw doesn't print the full information, maybe you can try iw-full.
I currently only have one device (QCA9888 acting as AP) which supports VHT80P80, so I can't do a real test at the moment, but I think it works for the 802.11ac part - the network starts, devices can connect to it (although at only 80 MHz channel width since my client devices don't support 80+80 MHz), and iw scan results shows correct center freq segment entries (e.g. 106 and 155 for channel 100 and channel2 149).
For 802.11ax, I don't have any ax AP so I can't test. But I am wondering one thing: What happens if a device supports HE80P80 but not VHT80P80?
From this comment, apparently @olek210's Xiaomi AX3200 is such case: Supported Channel Width: 160 MHz HE160/HE80+80/5GHz
From this gist, @mcbridematt's Compex PN02.1 module (QCN9074) may also be such case: Supported Channel Width: neither 160 nor 80+80 HE160/HE80+80/5GHz
Maybe we need a VHT80+HE80P80 case with vht_oper_chwidth=1 but he_oper_chwidth=3?
Can you please run iw again to check the supported channel width? Perhaps your device happens to be such case (supports HE80P80 but not VHT80P80) and the network fails to start because the patch doesn't handle such case?
Hi, I have a TP-Link RE500 running mt76 driver (MT7615E), which seems to support 802.11ac 80+80Mhz configuration, and would like to test this pr. But i don't know how i can do it.
This is from the output of iw list command.
VHT Capabilities (0x338001f8):
Max MPDU length: 3895
Supported Channel Width: 160 MHz, 80+80 MHz
RX LDPC
short GI (80 MHz)
short GI (160/80+80 MHz)
TX STBC
RX antenna pattern consistency
TX antenna pattern consistency
I know a lot of folks have been putting in efforts...
with 11ac and 11ax - when we go to 80+80, we fall back to SISO operations across the two radios, which is a pretty serious hit, both in the analog domain, as each radio loses diversity gain, which is a 3dB hit there on uplink and downlink, and we lose MIMO across the radios - which can be up to another 3dB...
Looking back at what has actually been broadly deployed - 160/320MHz channels (11ac/ax respectively on supported bands) is a pragmatic approach to wider channels outside of 80MHz for 5 and 6 GHz bands...
Looking at the logic here - effort is better placed on 11BE/EHT modes, where MLO comes in, and coordination across the different modes is more standard - albeit perhaps more complicated, lol..
There are many countries where a 160MHz contiguous channel is not available without DFS. This lets you get around that.
Yes there are radio penalties to some degree and some clients won’t benefit, however there are certainly clients that can.
I am more than happy to extend this patch to 6GHz if the first is accepted.
I need to know that the proposed “channel2” is acceptable, otherwise why bother making more changes I’ll need to revise.
First and foremost, I’m responding to the pleading in this thread to submit a patch upstream.
Secondly, the radio is capable of it. Why not expose the functionality? It’s trivial code (in my opinion), and we’ve been carrying it as a patch in Gargoyle for years.
First of all, the device is currently running ImmortalWrt 24.10, so what i've done might be completely irrelevant. I will try it with OpenWRT later when i get the chance. For now, I followed these steps:
I changed the htmode value of the 5g radio from VHT40 to VHT80P80, then issued network restart command after i set the channel2 value to 149 (channel was set to 140), and none of the radios came up. Waited for a while, then decided to try changing the channel to 100, and after that, reverting the htmode value back to VHT40, both with a network restart, but unfortunately the radios didn't seem to come up in either of the cases.
The system and kernel logs didn't have any particular entries regarding wifi radios.
Then i reverted the files back to original without changing htmode to VHT80P80, and the radios were back online.
While the radios were down, i was still able to do wireless scans on luci with the patch applied.
My device might not be a test candidate as well, in which case I wouldn't be surprised a bit given that even 160Mhz configuration doesn't work either on OpenWRT or ImmortalWrt while it says it should work. All clients still report 80Mhz connection (866Mbps max for 2x2) while the wireless network shows up as a 160Mhz one (a whopping 3467Mbps total for 4x4), which is weird. I would say it might be related to mt76, but to be fair the oem firmware doesn't support 160Mhz configuration too, so it's probably hardware related.
In /var/run/, check the respective configuration file e.g. hostapd-phy0.conf, to see whether the patch has applied correctly and the configuration is correct, by looking for values of vht_oper_chwidth, vht_oper_centr_freq_seg0_idx, and vht_oper_centr_freq_seg1_idx.
If the logs don't output useful error messages, I'd add this under the wifi-device (e.g. config wifi-device 'radio0') section in /etc/config/wireless to make hostapd more verbose, and then look for any messages that indicate errors like invalid channels:
list hostapd_options 'logger_syslog=-1'
list hostapd_options 'logger_syslog_level=0'