[OpenWrt-Devel] About 802.11s mesh on IPQ4019, ath10k-ct and ct-firmware

Ben Greear greearb at candelatech.com
Sun Mar 10 13:03:51 EDT 2019

On 03/10/2019 12:22 AM, Sven Eckelmann wrote:
> On Sunday, 10 March 2019 05:52:00 CET Xuebing Wang wrote:
> [...]
>> Are there anyone building 802.11s routers based on tag 18.06.1, 18.06.2
>> or branch openwrt-18.06?
> Most(?) companies and community projects just throw the 802.11s forwarding/
> routing part away and are running their preferred Layer2/Layer3 mesh protocol
> (bmxd/6/7, olsrd(2), babeld, batman-adv, ...) over it. But yes, they are still
> require the meshpoint interface support in ath10k+firmware.
> A project I am more familiar (and is using 18.06.x) is freifunk-gluon [1].
> They just select the ath10k-firmware-* (from kvalo/linux-firmware) for
> meshpoint setups and ath10k-firmware*-ct for IBSS setups.
> As far as I know, this will still be possible with OpenWrt 19.xx). And this
> should also work the same when you want to run 802.11s+HWMP over it.
>> I noticed that in OpenWRT master branch ath10k-ct and
>> ath10k-firmware-qca4019-ct are enabled by default, but they are not
>> enabled in tag 18.06.2.
> Regarding ath10k vs. ath10k-ct - yes, this is a rather unfortunate situation
> that we have two different drivers. ath10k-ct is basically ath10k with a
> ~7000 lines patch on top. You just have to keep in mind that there are some
> hacks in it which may break standard ath10k/mac80211 features [2]. So you
> cannot always assume that this can be reported to the ath10k people. And some
> of the changes in the mac80211 ath10k could be missing in ath10k-ct [3,4]. So
> you have to figure out yourself which driver better fits your needs.
> Kind regards,
> 	Sven
> [1] https://github.com/freifunk-gluon/gluon
> [2] https://github.com/openwrt/openwrt/pull/1862/commits/c1e80f1b6e673912437422e4900facb409e41143#diff-132b371dc289dab58843cae7f9c430f5

So, both of the patches above need to be applied to ath10k-ct 4.19 driver?

> [3] https://patchwork.ozlabs.org/patch/1051204/

I can apply this one to the 4.19 ath10k-ct driver too, I just am not using 4.19 internally,
so...well, no local testing.

> [4] https://github.com/openwrt/openwrt/pull/1077

It should be pretty easy for someone to write a patch to extend 'fwcfg' feature in ath10k-ct
to support this, or just hack in a commit similar to what you did to the stock driver if needed.

I'll very likely accept a patch that enables tweaking this based on fwcfg API.


Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

openwrt-devel mailing list
openwrt-devel at lists.openwrt.org

More information about the openwrt-devel mailing list