DAWN on Archer C7, minor problems

I've been following the wifi roaming discussion on

and decided to try it at home.

I've got three TP-Link Archer C7. One is v2 used as router, two are v5 used as APs.
The experience has been less than great at first, so I filed the following bug against ath10k:
More details on my configuration are in the bug report.

However, since I switched to the non-ct version of ath10k+firmware stability is much better.
The problems I observed with the CT version on SNAPSHOT r13710-7cb721c03f were

  • devices have to reconnect when unlocking the screen, i.e. loosing wifi connectivity
  • a lot of daemon.info hostapd: wlan0: STA ea:46:3d:86:c5:e8 IEEE 802.11: disassociated due to inactivity messages in the log
  • single digit MByte/s when close to AP a while after reboot/wifi down/up
  • DAWN fails with channel utilizations out of range (negative or way bigger than 255)

@chunkeey, @greearb please let me know if there's anything I can do to help with ath10k-ct debug.
The devices are currently on the 2020-07-20 openwrt snapshot.

First of all: thank you very much, roaming really is an improvement.
There are some observations I'd like to share:
Besides occasional re-authentications (which I would not expect, because a minute earlier there was no re-authentication required when the same AP to AP transition was done) I see some errors in the log:
Tue Jul 21 09:25:50 2020 daemon.err dawn[2688]: Received NULL MAC! Client is strange!
Tue Jul 21 10:12:32 2020 daemon.err hostapd: nl80211: kernel reports: key addition failed
Tue Jul 21 12:26:29 2020 daemon.err dawn[1727]: not enough memory (3952970380 @ 104)

I didn't see the not enough memory messages with the CT version of ath10k, possibly because I used kmod-ath10k-ct-smallbuffers. So it might be related to

@adrianschmutzler thanks for making me aware of that.

Is there a way I can assist debug?


Regarding ath10k-ct instability, what chipset does this AP use?

Please open a bug on the ath10k-ct github project. If this is wave-1
9880, 9882, etc, then not sure I have time to really fix it, but good
to note the problem either way.


1 Like

Those look like they might be like the airtime fairness crashes I get when I use DAWN and QCA9884 or QCA9888.

I could be wrong but usually you get underflow warnings and bam. Wireless will be crippled until reboot.

I've switched back to ath10k-ct, but with different firmware:

ath10k-firmware-qca988x-ct-full-htt - 2020-04-24-2 - Alternative ath10k firmware for QCA988X from Candela Technologies.
 Uses normal HTT TX data path for management frames, which improves
 stability in busy networks and fixes .11r authentication.

Note the .11r statement, the openwert default ath10k-ct firmware does not seem to have that fix.
Currently I'm using firmware-2-ct-full-nrcc-community.bin. More details are in the defect I opened on greenarb/ath10k-ct, see above.

@PolynomialDivision I still see the DAWN errors, in particular the not enough memory messages are very frequent when roaming while transferring big files, I'm mentioning it because that is with the smallbuffer version of the driver: kmod-ath10k-ct-smallbuffer, so I think the driver can be ruled out as the cause of the memory messages.
I'm still willing to help debug :wink:

Or to try a more recent version, the 2020-08-02 openwrt snapshot I'm using has

dawn - 2020-07-12-32640de3-1 - This package implements a decentralized wireless daemon.

Please don't get me wrong, I'm not trying imply any expectancy on updates/fixes. Just in case you already have something...

@atiensivu thanks for making me aware.