Openwrt 19x: ath10k-ct wifi-driver does not support 802.11s in wave1 devices #696
Comments
|
This is a follow up from: #583
|
|
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. |
|
Ath10k-ct only supports 802.11s on Wave2 chips, what hardware is this bug report related to? |
|
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 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
changed the title
|
In Gluon, we use 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
changed the title
|
@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 Thanks for the comment about the title. I have updated it. |
|
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:
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. |
|
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... |
|
I made PR #765 to make use of the target-definitions @NeoRaider mentioned for gluon in #696 (comment). |
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 <freifunk@adrianschmutzler.de> Reviewed-by: Fabian Bläse <fabian@blaese.de> Tested-by: Fabian Bläse <fabian@blaese.de>
SvenRoederer
added this to Backlog (Blockers for next Major-release)
in Freifunk Berlin Firmware Meetings
|
freifunk-weimar tracks the same issue as weimarnetz/firmware#7 |
|
WeimarNetz implemented a solution, that might easy to integrate for us too. |
* via "curl -L https://github.com/weimarnetz/packages/raw/brauhaus-19.07/assemble/profiles/ath79_generic.profiles|grep ";" >> profile-packages.txt" * weimarnetz/packages@8c399e6 * See #696, weimarnetz/firmware#7
* via "curl -L https://github.com/weimarnetz/packages/raw/brauhaus-19.07/assemble/profiles/ath79_generic.profiles|grep ";" >> profile-packages.txt" * weimarnetz/packages@8c399e6 * See #696, weimarnetz/firmware#7
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.
|
By implementing #863 we are using non-ct drivers for all wave1-chips. As all other Freifunk-teams are using too. |
|
I saw that. No choice. Well done!
…On 7/19/21 4:08 PM, Sven Roederer wrote:
By implementing #863
<#863> we are using
non-ct drivers for all wave1-chips. As all other Freifunk-teams are
using too.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#696 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AF3KLJQMMRWIUEJCBTGJA7LTYSA3RANCNFSM4HXOHF3A>.
|
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
The text was updated successfully, but these errors were encountered: