802.11s: ath9k slow speeds on HT40; ath10k doesn't support mesh above VHT20, and no encryption support?

Installing and Using OpenWrt
1

I'm using a Netgear R6100 with LEDE 17.0.1, and in experimenting with 802.11s, I've come across some issues that I wanted to bring to the community (before considering if they should be raised as bug reports?):

802.11s mesh on ath9k

  • 802.11s on ath9k (Atheros AR9344): When using ath9k for mesh without encryption (Channel 4, HT40), my two R6100s are reporting speeds like (117.0 Mbit/s, 20 MHz, MCS 14 / 216 Mbit/s, 40 MHz, MCS 13). This seems above the theoretical limit (which I thought should be 144 Mbit/s.) Is this a bug?

  • When I turn on encryption (psk2 with authsae), this same network's performance will drop to (54 Mbit/s, 20 MHz / 54 Mbit/s, 20 MHz.) However, (see next point)

  • If I switch HT40 to HT20 (but continue using psk2), performance will bump to (65 Mbit/s, 20 MHz, MCS 7 / 144.4 Mbit/s, 20 MHz, MCS 15, Short GI)

User greybeard has suggested that there are problems in mac80211.sh and authsae.sh that are causing problems with the HT channel selection and authsae. (See mac80211.sh and authsae. Seems like a pretty odd thing to be a bug, though -- HT40 is the recommended value setting for 2.4 GHz (afaik), I would expect this has been used and tested heavily.

Is there an explanation for this--maybe I'm missing something? Are these scripts really not supporting HT40 properly?

ath10k

The R6100 uses Qualcomm Atheros QCA9882-2R4E, and I've discovered that 802.11s with it will only mesh with the LEDE-provided kmod-ath10k at VHT20. VHT40 and VHT80 will not mesh at all. (All done without encryption.)

If I switch to using the Candela Tech firmware and Driver, I cannot get a mesh network to form whatsoever, on any channel or mode.

Is this a problem with the scripts not supporting VHTx? They appear to not support HT40, and I don't see reference to VHT--so perhaps that's the issue, but I feel like enough people are using these scripts that if HT40 (and VHTx) are not supported properly, it would've been a fixed issue long ago.

Can anyone shed some light on what's happening here? If this is not a script issue, and instead a driver/firmware issue on ath10k, should one hold their breath that 802.11s will be supported at VHT40/80 and with encryption, or will it probably not happen (for whatever reason--possibly closed binaries, or too much work, etc?)

1 Like
2

HT40 should only be used in case the spectrum is clear where you are. In most cases, this is not true (easy to see with a spectrum analyzer).

Is the ath10k testing done with recent firmware? AFAIK mesh support in ath10k is very recent.

3

Have you tried the firmware linked in this thread?

4

I have not -- thanks for the reference! However, this is firmware without a driver -- so would I simply use this firmware in conjunction with the latest kmod-ath10k driver?

5

I think so, but I'm far from being any kind of expert, so no warranties.

6

Haha, same here. I'll give this is a shot and report back.

7

I found a repository by kvalo that seems to host even newer firmware still:

I'm not sure what the differences are between code aurora and kvalo's repos, etc. Just an interesting discovery.