Hey,
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.
@PolynomialDivision,
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
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.
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
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...
@PolynomialDivision
I've upgraded to OpenWrt SNAPSHOT r14181-1e696c6ced
which includes dawn - 2020-08-07-50d54a62-1 - This package implements a decentralized wireless daemon.
The not enough memory fails are gone. Thank you!
I still see daemon.err dawn[1731]: Received NULL MAC! Client is strange!
and some hostapd fails (for which I should probably open a different issue): daemon.err hostapd: nl80211: kernel reports: key addition failed daemon.err hostapd: nl80211: NL80211_ATTR_STA_VLAN (addr=98:00:c6:8a:be:6c ifname=wlan0 vlan_id=0) failed: -2 (No such file or directory)
This is 802.11k. We currently search for a way to compare the different metrics (RSSI, RCPI, RSNI). So it is completely fine to turn it off completely. Currently, the automatic reconfiguration faces a crash.
I have to play around with the different 802.11k parameter we can use.
I had to switch wireless security FT Protocol to FT over Air (option ft_over_ds '0') to get rid of the error: daemon.err hostapd: nl80211: NL80211_ATTR_STA_VLAN (addr=##:##:##:##:## ifname=wlan0 vlan_id=0) failed: -2 (No such file or directory) that your are seeing on my R7800s that I've been playing around with 802.11 r,v k.
@PolynomialDivision Since I have a setup which works more stable wrt ath10k/firmware I don't see the invalid channel utilizations anymore.
I've changed all RSSI conf parms to 0, it is better now but I still see those messages. Thu Aug 20 13:44:41 2020 daemon.err dawn[2264]: Received NULL MAC! Client is strange!
Every now an then in particular after new installs the devices seem to have difficulties to detect the whole network. The situation would be e.g. two of the three APs/router see the whole network, the third one sees only one other device.
Rebooting the one which is not visible can fix the problem. How would I debug this?
@eems01 Thank you, I've actually turned vlan functionality off on the Archer C7 v5 devices, they are merely APs. Still I see those messages every now and then. Would you know how those messages impact function/usability? Since they are rare I decided for now to just live with them.
Sorry not an expert. I do use vlan functionality but it might not matter. Searching there were driver bugs years ago that caused this error.
What I noticed is that if I roamed access points with FT over DS there would be a hang before connection would occur. Switching to FT over Air that error went away and roaming was more seamless. I saw someone else in the forum with my device do likewise switch to air but plenty of others that use DS apparently without issue.
