VHT-Mode Support

[mweinelt]

Gluon currently only offers support for the 802.11n HT-Modes (20/40 MHz). While newer devices have gotten basic support, there is no possibility to separately specify VHT-Modes yet, which would enable 80/160 MHz channel widths for newer devices, while not breaking HT-Modes on 802.11n devices.

The newer VHT-Modes are available in OpenWRT through:

• VHT80
• VHT160

[neocturne]

I've read on the ath10k mailing list that VHT is currently broken in IBSS mode for ath10k...

[neocturne]

I guess supporting 80/160MHz channels doesn't make much sense when the regulatory rules don't even allow 40MHz when there are multiple nodes in proximity of each other...

[mweinelt]

On 5 GHz that might be entirely possible.

[RubenKelevra]

@NeoRaider never read of regulatory rules which disallowes HT40 if they are from the same network. Stations of concurrent networks are my readings of the regulations rules.

[RubenKelevra]

I think this bug is obsolete, since you dropped any support for something else than ht20 anyway.

3ddcf50b800cfdfca92400a5922ff1575ff3a8a9

[CodeFetch]

You can use "Wifi Analyzer" for Android to observe the AP's behaviour very easily now. It seems that with IBSS the AP just switches between HT40 and HT20 very fast. So the fallback works in some way, but actually the AP should just stop using HT40 for a minute or so says the IEEE if there is another station on the neighbouring channels. I found the article I once read about that: http://www.smallnetbuilder.com/wireless/wireless-features/31743-bye-bye-40-mhz-mode-in-24-ghz-part-1

It's only Wi-Fi certification junk. Can't we just ignore the IEEE as long as it is no FCC regulation and reenable support for HT40 :laughing: ?

[RubenKelevra]

We're using VHT80 HT40 HT20 and that works fine. As long as a neighbor-station uses the second channel heavily OpenWRT does not use HT40 at all. You observe this behavior in the station dump where HT40 is often deactivated on noisy environments.

[CodeFetch]

@RubenKelevra Of course it works fine, but it's not the gentleman behaviour we would expect from e.g. WiFi certified routers. Read the second part and test it yourself: http://www.smallnetbuilder.com/wireless/wireless-features/31744-bye-bye-40-mhz-mode-in-24-ghz-part-2

I live in a very 2.4 GHz-noisy area and when I watch my Freifunknode I can clearly see that the AP BSS behaves correctly and the IBSS doesn't sometimes. I don't know why. It's like IBSS "forgets" that the extension channels aren't free every few seconds.

[RubenKelevra]

@CodeFetch how do you determine the wrong behavior?

[CodeFetch]

@RubenKelevra Using "Wifi Analyzer" Android app - You can increase the refresh rate and look at the channel diagram. You will see the IBSS interface jumping from HT20 to HT40 all the time while the AP BSS constantly uses HT20 in a noisy area.

[RubenKelevra]

@CodeFetch

So you just looked at the Bescons.

Actually I don't think there's a possibility to change the Ad-Hoc config on the fly in the standard.

My point was: the syncs between peers are gracefully reduced in noisy environments and if the second channel is occupied in the time of datatransmission only the first one is used.

[CodeFetch]

@RubenKelevra

So you just looked at the Bescons.

No. I watched almost the same behaviour with iw dev info where you can see it nearly in "realtime" and even while there is a transmission ongoing, but I mentioned Wifi Analyzer because you can clearly see the difference between IBSS and AP BSS there. You should also note that beacons are always sent at HT20 as far as I know. So what you see in Wifi Analyzer seems to be the actual bandwidth. Feel free to put me right...

My point was: the syncs between peers are gracefully reduced in noisy environments and if the second channel is occupied in the time of datatransmission only the first one is used.

Yes, that's true. That's why I think it's not so bad to reactivate HT40, but you should keep in mind, that the router seems to forget that it should fallback to HT20 after every transmission. Unfortunately I don't really grasp where in the ath9k source the fallback happens, yet. Maybe we just have to define a variable that contains the value of current fallback activation status or something. I don't think it should be so hard to implement this fallback properly.

[SimJoSt]

@NeoRaider It's possible to use VHT mode with 20 Mhz so all the extra 11ac capabilities that OpenWRT supports (besides broader channels) [1] can be used. Just set htmode to VHT20 [2].

[mweinelt]

Defaulting to VHT20 on 802.11ac devices should achieve a small gain on the data rates

• 1 Stream: from 72 Mbps to 87 Mbps
• 2 Streams: from 144 Mbps to 173 Mbps
• 3 Streams: from 216 Mbps to 289 Mbps

Via http://chimera.labs.oreilly.com/books/1234000001739/ch02.html#phy-table-speedcomp

[neocturne]

Adding new "patch welcome" label for VHT20 support.

[mweinelt]

Tested on an Archer C7 v4 (3x3) vs Nexus 5X (2x2).

Setting:

• wireless.radio0.htmode='HT20' yields 144 Mbit/s
• wireless.radio0.htmode='VHT20' yields 173 Mbit/s

The patch by oleander for some reason did not set the htmode on the radio, I'm still checking if that was my mistake.