Openwrt 19x: ath10k-ct wifi-driver does not support 802.11s in wave1 devices

[SvenRoederer]

Bug report

The ath10k-ct seems not to support 802.11s mesh and ap-station in parallel

In openwrt/openwrt@61b5b49 the default driver for ath10k was switched to the "Caldera Tech" version. This driver currently fails to setup a 2 VIF-configuration of 802.11s and AP, which is a common default for our routers.

Firmware Version: all based on recent OpenWrt master

[SvenRoederer]

This is a follow up from: #583

1. from: OpenWrt-base for next minor-release #583 (comment)
   iw list on an ath10k device still gives the following results (5Ghz):

	valid interface combinations:
		 * #{ managed, P2P-client } <= 16, #{ P2P-GO } <= 3, #{ AP } <= 16, #{ IBSS } <= 1,
		   total <= 16, #channels <= 1, STA/AP BI must match, radar detect widths: { 20 MHz (no HT), 20 MHz, 40 MHz, 80 MHz, 80+80 MHz, 160 MHz }

2. similar issues are reported by Gluon

• IBSS mesh and client mode doesn't work in parallel with ath10k-ct freifunk-gluon/gluon#1584
• IBSS mesh and client mode do not work in parallel greearb/ath10k-ct#75

[SvenRoederer]

Some time ago I did a test (on a Turris Omnia) and replaced the ath10k drivers by their non-ct counterpart. As far as I remember this gave a working Mesh-Ap setup without any other change required.

So it seems to be a thing of how to change the build to include the non-ct drivers.

[mweinelt]

Ath10k-ct only supports 802.11s on Wave2 chips, what hardware is this bug report related to?

[pmelange]

If we want to switch back to the non-ct drivers, it looks like we will have to patch at least the following files:

firmware/openwrt/target/linux/ar71xx/image/*.mk
firmware/openwrt/target/linux/ath79/image/*mk
firmware/openwrt/target/linux/ipq40xx/Makefile
firmware/openwrt/target/linux/ipq806x/Makefile
firmware/openwrt/target/linux/lantiq/image/Makefile
firmware/openwrt/target/linux/mvebu/image/cortex-a9.mk

It would be quite a patch, and a lot of maintenance as new hardware is added upstream. Is there a simpler/automated way to do this?

[neocturne]

In Gluon, we use CONFIG_TARGET_DEVICE_PACKAGES_..._DEVICE_... to modify the selection of device packages. This was our string to switch from mainline/QCA to CT ath10k with OpenWrt 18.06 on ar71xx, for 19.07 it could just be used the other way around to switch back:

-kmod-ath10k kmod-ath10k-ct -ath10k-firmware-qca988x ath10k-firmware-qca988x-ct

Of course, only moves the burden from target definitions to .config...

Another option I'm considering is to provide a global config switch in OpenWrt to select the default ath10k kmod and firmware variant (mainline/QCA, CT, CT with HTT firmware), but I'm not entirely sure yet whether we want to switch globally, or just for Wave-1 chips... If such a global switch is deemed useful, I can take care of implementing it.

Note: The title of this issue is inaccurate. The CT firmwares simply don't support 11s at all, it doesn't have anything to do with 11s and AP in parallel.

[pmelange]

@NeoRaider That looks very promising, but I have a couple questions.

When looking at the firmware/openwrt/target/linux//image/.mk files (Openwrt 19.x), I see the following drivers: ath10k-firmware-qca988x-ct, ath10k-firmware-qca9887-ct, ath10k-firmware-qca9888-ct, ath10k-firmware-qca9984-ct, and ath10k-firmware-qca99x0-ct (there might be more). In https://github.com/freifunk-gluon/gluon/blob/master/targets/ar71xx-generic I see that you handle the drivers for each device separately. Does the Gluon team add new hardware manually? Can this be automated during the make process?

Would it be possible to have a global wave1 switch and a global wave2 switch? I think this would be beneficial to OpenWrt as a whole (not just us freifunkers).

For our use, I'm considering running a script in the Makefile which scrapes the -ct suffix from any string which starts with kmod-ath10k or ath10k-firmware. But this will indiscriminately change wave1 and wave2 devices.

Thanks for the comment about the title. I have updated it.

[neocturne]

We maintain a list of hardware in Gluon ourselves, which is necessary for our autoupdater. In this list we currently also specify additional packages for devices, which I hope we can get rid of at least for ath10k stuff eventually...

Having separate switches for different ath10k chips or generations might be an option, but I'm not entirely sure which firmwares have which limitations - if the Wave-1/Wave-2 rule is correct in all cases, and if there are chips which can't do 11s or IBSS with any firmware. Another issue is that it is unclear how to deal with devices that have multiple ath10k radios of different generations when there are multiple switches (this is the case on a number of ipq40xx and ipq806x devices).

This is the complete list of ath10k firmwares in OpenWrt:

• ath10k-firmware-qca4019
• ath10k-firmware-qca6174
• ath10k-firmware-qca9887
• ath10k-firmware-qca9888
• ath10k-firmware-qca988x
• ath10k-firmware-qca9984
• ath10k-firmware-qca99x0

With the exception of QCA6174 (which doesn't seem to be installed on any device by default anyways), all these firmwares exist in the 3 variants: mainline/QCA, CT and CT-HTT.

[Steve-Newcomb]

I would like to know whether anyone has made ath10k-ct in IBSS mode work with batman-adv on Archer [AC]7 v[245] in the current trunk (or any other) version of OpenWRT. "Classic" ath10k in "mesh" (802.11s) mode works well, but only two 80MHz-wide channels (36 and 149) are supported, perhaps because the "classic" version doesn't support Dynamic Frequency Selection (DFS) required when using the channels that may also be used for radar. (Two channels helps a lot, but it is not enough to allow a single mesh to be split into separate regional buses in long-haul environments. I suppose that I need at least 3 channels to do that without causing them to interfere with each other.) I have gathered (correctly or incorrectly?) that if IBSS mode could be used for batman-adv, then ath10k-ct would make the DFS channels exploitable.

Just groping around for a solution...