Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
SvenRoederer opened this issue Jun 12, 2019 · 13 comments · Fixed by #863
Closed

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

SvenRoederer opened this issue Jun 12, 2019 · 13 comments · Fixed by #863
Labels

Comments

@SvenRoederer
Copy link
Contributor

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
Copy link
Contributor Author

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 }
  1. similar issues are reported by Gluon

@SvenRoederer
Copy link
Contributor Author

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
Copy link
Contributor

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

@pmelange
Copy link
Contributor

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?

@pmelange pmelange changed the title ath10k-ct wifi-driver failing to setup 802.11s and ap in parallel Openwrt 19x: ath10k-ct wifi-driver failing to setup 802.11s and ap in parallel Jun 16, 2019
@neocturne
Copy link
Contributor

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 pmelange changed the title Openwrt 19x: ath10k-ct wifi-driver failing to setup 802.11s and ap in parallel Openwrt 19x: ath10k-ct wifi-driver does not support 802.11s in wave1 devices Jun 16, 2019
@pmelange
Copy link
Contributor

@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
Copy link
Contributor

neocturne commented Jun 19, 2019

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
Copy link

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...

@SvenRoederer
Copy link
Contributor Author

I made PR #765 to make use of the target-definitions @NeoRaider mentioned for gluon in #696 (comment).
With 5d9abcd support for the recent board-list for ath79-generic was added, which generates "ath10" (non-ct) images.

adschm added a commit to FreifunkFranken/firmware that referenced this issue Apr 2, 2020
OpenWrt offers two variants of ath10k driver and firmware, the
"normal" mainline/QCA variant and the "CT" variant [1]
developed as fork by Candela Technologies.
Both deviate from each other with respect to their feature set,
level of support and system impact (i.e. memory consumption).

Since the 19.07 release, OpenWrt has made the "CT" variant its
default for supporting (almost) all ath10k chips. [2]
However, for this firmware the CT driver/firmware introduces a number
of (potential) drawbacks:

- CT memory consumption seems to be higher. (This still needs to be
  verified for the new kmod-ath10k-ct-smallbuffers variant.) This
  is particularly a problem on several ath10k devices with 64 MB RAM,
  where the devices run into OOM regularly (i.e. C60 v1/v2). [3]
- Though CT has active support, it is still just a fork effectively
  maintained by one person.
- With CT driver/firmware there are frequent reports that the
  combination of AP and 802.11s is not working. [4] While this issue
  couldn't be reproduced in recent tests, it still is explicitly
  not supported, and there is no interest to change that at the
  moment. [5]

Due to these reasons, it seems more appropriate for us to use the
mainline/QCA variant of ath10k driver and firmwares. This patch
applies that to all affected devices.

Note that currently the mainline driver also benefits from a local
patch in OpenWrt that reduces the memory footprint. This patch has
been removed in master, so we will need to keep it locally when using
a 20.xx OpenWrt release. [6]

[1] https://github.com/greearb/ath10k-ct.git
[2] openwrt/openwrt@61b5b49
[3] openwrt/openwrt@1ac6270
[4] freifunk-berlin/firmware#696
    https://forum.openwrt.org/t/ath10k-ct-and-802-11s-mesh-not-working-on-archer-c7/13877
[5] openwrt/openwrt#2341 (comment)
[6] openwrt/openwrt@1e27bef

Signed-off-by: Adrian Schmutzler <[email protected]>
Reviewed-by: Fabian Bläse <[email protected]>
Tested-by: Fabian Bläse <[email protected]>
@SvenRoederer
Copy link
Contributor Author

freifunk-weimar tracks the same issue as weimarnetz/firmware#7

@SvenRoederer
Copy link
Contributor Author

WeimarNetz implemented a solution, that might easy to integrate for us too.

@SvenRoederer SvenRoederer linked a pull request Jul 9, 2021 that will close this issue
SvenRoederer added a commit that referenced this issue Jul 18, 2021
Allows to define packages to be added / remove from the packagelist on a
per router basis. This gives a way to do something similar to OpenWrt
devicepackages, to adapt to router specific requirements.

The initial usecase is handling of ath10k-wave1 chips (#696), but also
turned out be handy for xDSL (#838) and others.
@SvenRoederer
Copy link
Contributor Author

By implementing #863 we are using non-ct drivers for all wave1-chips. As all other Freifunk-teams are using too.

@Steve-Newcomb
Copy link

Steve-Newcomb commented Jul 20, 2021 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants