Hello folks,
I have an issue regarding 802.11s on my Archer C7 v2.
It's a small setup with the Archer C7 and 2 TL-WR841 (MT76) with a quite minimal build. I basically only have the WiFi stuff and dropbear running on them.
The issue is, that the mesh network just randomly stops working (after only a few minutes to sometimes several hours).
The WR841s are still showing as connected in LuCI. But I can't reach them (can't ping them, clients can connect though, but no traffic goes through at all).
The C7 is the router connected to LAN and WAN and is doing all the "heavy" work (DHCP, DNS...). The TL-WR841 are just dumb APs for range extension.
To get everything working again I have to restart the wireless interface (wifi down && wifi up) on the C7. Restarting the WR841 has no effect.
There are no related entries in system or kernel log and I am running out of ideas.
I am in no way a professional in networking stuff and maybe I just misconfigured something.
Unless something is crashing (you say there is no indication of this), then in my experience the mesh links are breaking down probably due to interference or dropping signal strength for what ever reason.
You need to set:
mesh_fwding='1'
mesh_gate_announcements='1' on at least one device but all 3 would be fine.
mesh_rssi_threshold='-80'
The first two allow the mesh to reconfigure itself and self heal its layer 2 "routing". On startup these are effectively automatically set temporarily, but if something goes wrong, a wireless restart is required without permanent setting.
The last sets the minimum signal strength required to stay in the mesh. In a noisy environment you might have to tune this one, -75, -70 until it is stable - this also effects range of course.
These HAVE to be set using the iw utility though, at startup and after a wifi command or network restart. They do not take effect in the uci config as they have to be set AFTER the interface is up. They are conveniently put in the config so you can run a script to pick them up and set using iw. I just run a background process that checks every 30 seconds or so and sets if necessary.
Of course you might have some other problem here, but..... works for me with what looks like the same symptoms.
I know the ct drivers can cause some issues, but that wasn't the case here.
Setting gate announcements via iw solved the problem for me.
I didn't know, that those settings aren't applied post-up automatically, so as suggested, I run a script every minute via cron. I think a post-up action or a hotplug.d script should also work, but the cron was the simplest solution.
Thank you so much for your help and suggestions, both of you.
I had it running using the ct drivers. Same config as above.
I already switched to non-ct drivers some weeks ago, because of the mesh breaking down (didn't help, obviously), but SAE was never a problem.
Driver default did not help. I still get interface IF_UP_ERROR for the mesh interface when using ct ath10k drivers. Switched to non ct ath 10k drivers and the mesh went working again immediately.
I'm using ct ath10k drivers and wpad-mesh-wolfssl (instead of wpad-basic-wolfssl default pkg) on 21.02rc.1 when the problem occurs . Hw tplink archer c7v5. What should I do now?
I can't reproduce on my C7 v2. If you want to get it running using the ct drivers you should consider opening a new topic. I had it running using ct drivers and wpad-mesh-wolfssl. Maybe it has something to do with the soc/chipset of the v5? I don't know, sry
Batman adv does not work in mesh mode using ath10k ct drivers! This user also got the sicsioffflags invalid and busy error in the log like me until he switched to ath10k non ct to get it work.
Wave 1 devices, those with the QCA988x abbreviation, can't do (encrypted) 802.11s mesh with the ath10k-ct driver. (I think to remember that unencrypted was possible but wouldn't try it.)
It does work with SAE in 19.07. (I only tried pure 802.11s, no batman-adv) Maybe it didn't in older releases, but now it does for sure.
I used the firmware which came with the official sysupgrade package.
I meshed with MT76 using the same SAE enabled config, so there should be no hidden encryption "downgrade" by the firmware.
I won't disagree, I was misleading with saying the "ct-driver". I did mean the ct-firmware, the 10.1 ct-firmware exactly, which usually comes together with the ct-driver and won't work with encrypted mesh. (In my experience there is no reason to mix it anyway, its getting worse than ct-only ...and the hassle with rawmode=1 for unencrypted mesh is not really a gift)
What mt76 wifi adapter do you have? Have you disabled Amsdu in the mt 76 driver? I can't mesh an ath10k adapter with a mt7612 adapter without getting <56k modem speeds.
