I saw this error, when both devices had different settings in there wifi mesh configuration. make sure, theyre configs did not differ, even minor feature setting and (probable) unrelated settings
I think I made some progress with the current mesh brokenness. In my 3x mesh setup, so long as I keep the nodes active, all three remain accessible. When one of the two extension nodes (i.e. node that connects to gateway) has a period of inactivity, it becomes inaccessible. It still shows connected with mesh station dump from other nodes, but 'tx bytes' on the affected node increases very slowly:
root@OpenWrt:~# iw dev wlan1 station dump |grep -i bytes rx bytes: 24222245 tx bytes: 147301 rx bytes: 626904121 tx bytes: 372754833 root@OpenWrt:~# iw dev wlan1 station dump |grep -i bytes rx bytes: 24224452 tx bytes: 147301 rx bytes: 626906328 tx bytes: 372754833 root@OpenWrt:~# iw dev wlan1 station dump |grep -i bytes rx bytes: 24225989 tx bytes: 147301 rx bytes: 626908137 tx bytes: 372754919 root@OpenWrt:~# iw dev wlan1 station dump |grep -i bytes rx bytes: 24372908 tx bytes: 147479 rx bytes: 627143495 tx bytes: 372823476 root@OpenWrt:~# iw dev wlan1 station dump |grep -i bytes rx bytes: 24379516 tx bytes: 147538 rx bytes: 627150666 tx bytes: 372823844
how do you adjust your 2.4ghz in N auto and 20mhz or 40mhz? thank you
Same setup I have always used for mesh that worked before for months. I have x3 nodes. Mesh on 5Ghz using 80Mhz width on channel 36. All x3 nodes also offer AP's on 2.4Ghz (40Mhz on channel 1) and 5Ghz on channel 36. All same SSID and mesh id is same as main SSID.
@daniel what is the maximum transmit power on 2.4 Ghz and 5 Ghz that the RT3200 is capable of? What happens if the transmit power of a country is set that exceeds this value?
I am wondering if country code / power handling could be a factor in the mesh brokenness.
I vaguely remember that 802.11s on MT7915 doesn't work as well as with MT7615, as all the offloading features are geared towards AP/STA mode, so 11s/mesh, ibss/adhoc and radiotap/monitor has to go through some slow path bypassing all that.
Yet it's weird that it's stops working completely, that more reminds me of FS#4098 which is also discussed here.
In any case, no matter if this is a bug in MT7915E firmware, mt76 driver or mac80211 802.11 stack, as sad as it is, you are best off just not using 11s mesh.
It is of course worth fighting for and trying our best to get bugs in drivers (and proprietary firmware...) sorted so 11s works equally well as AP/STA mode already does with foss drivers.
But to just have a bunch of repeaters basically, a "mesh network" in the true meaning of the word (ie. a mobile ad-hoc forwarding network which uses mesh routing) is maybe even overkill, unless you have many nodes, several gateways, ...
If it's SoHo: Just do like WiFi Alliance does, call it (easy)Mesh and do AP/STA in 4-addr/WDS mode to build a common layer-2 using bridges (ok, they also do that with a bit more advanced WPS button provisioning... and while easyMesh has nothing to do with mesh routing in the original sense, it is great as it will allow enabling 4-addr mode on otherwise locked AP devices in a standardized way)
Or do it like Ubiquiti and use VLAN trunking on top of AP/STA in 4-addr/WDS mode to separate management, 802.11k/v/r key-exchange/iapp and all that from payloads.
For larger mesh networks, if we want to get good performance with recent gear, we may want to develop protocols which dynamically setup AP/STA links and use the "real" mesh (as in 802.11s) only for the exchange of management and routing information... But nowadays, that could even be done with BLE
Given the difficulties cause by the ubi layout on reverting back to factory firmware, I wonder if somebody has a clear step-by-step instruction set on how to do it, possible without opening the case?
I have installed the ubi version, and not saved (or lost) the factory mtd blocks.
It was mentioned these blocks are not device specific, could somebody share them, together with the needed revert steps, on where and how to copy them, if possible at all please?
See the discussion here https://github.com/dangowrt/linksys-e8450-openwrt-installer/issues/14
I am trying to use image builder for the first time to build snapshot image, but encountered exactly the same error:
Collected errors: * pkg_hash_check_unresolved: cannot find dependency libubox20211120 for mtd * pkg_hash_fetch_best_installation_candidate: Packages for mtd found, but incompatible with the architectures configured * opkg_install_cmd: Cannot install package mtd. make: *** [Makefile:168: package_install] Error 255 make: *** [Makefile:123: _call_image] Error 2 make: *** [Makefile:241: image] Error 2
Has anyone figured out a way to work around this problem?
@daniel thanks a lot for your informative and interesting post about WDS. I tried it just now (main router set to access point WDS on channel 36 with 160Mhz width) and it indeed seems more stable, but throughput is bad in one direction for some odd reason. From main router the two client WDS connections report these rates:
Any idea why receive rate reported by the main router is so low for the client WDS connections? 17Mbit/s in one direction and 2268Mbit/s in the other is crazy!
This results in:
And in other direction:
Throughput seems a lot lower than mesh (and this is despite setting to 160Mhz whereas mesh only worked with 80Mhz). I wonder why. I can live with this as long as I can make it symmetric in both directions! Hopefully there is an easy fix for this?
Please try with HE80 mode. HE160 is known to be a bit special on this hardware and also limited to 2T2R and hence not even necessarily faster than HE80 mode.
Much better, thanks:
@smileys29 so how about just reverting to WDS? Seems to work fine.
@daniel 802.11r does not work with this is that correct? I still see those 'key adition failed' error messages as reported here:
Is it a software or hardware limitation?
The MT7915E hardware supports only 2T2R on HE160.
And this specific device is marketed as HE80, with the stock firmware you can't do HE160, and that makes me believe that maybe RF components (pa, lna, mixer, filters, ...) used are not suitable for HE160.
Answering my own question - read somewhere that if you wait for a day or two to let the snapshot repository bot sort itself out, these dependencies will get back in sync more likely than not.
I tried again with the newest snapshot, and could build my image successfully this time.
I just updated to the latest snapshot which has a new mt76 driver along with it. With this version i was still having mesh issues, but getting a verbose response in the error logs saying something was messing up with the auth of the mesh. I previously mentioned i was tempted to try no auth on the mesh, and should've followed suit.
With that error, i'm now testing no auth on the mesh and things seem to be running fine now. I'm only 20 minutes into the test, and i'll let it run like this over night.
I don't like to draw quick conclusions, but looking more like authentication issues on the 802.11s mesh.
Please can you post the error messages?
In one issue that @daniel posted the issue appeared related to authentication imposing a CPU burden that was not satisfied before a timeout giving error. I wonder if timeout needs increasing or irqbalance on all nodes might solve the problem.
If you don't have irqbalance enabled on all nodes can you try that?
The timeout is part of the 802.11 spec and cannot be adjusted.
However, this is not a problem as the cause to hit it back then was simply because WolfSSL was generating a random prime eventhough a plain random number would have been enough.
So first of all, only WolfSSL was affected by this issue, with OpenSSL things have always been working fine.
And maybe worth mentioning that this timeout issue back then occured on single core MIPS24Kc hardware running at a few hundred MHz, so that's a small fraction of the CPU resources of 2x. Cortex-A53 running at 1.35GHz max.
However, this is all years ago and recently new issues with SAE on mesh have occured, see also
So maybe the rate control algorithm is the problem?
Look at Bit Rate: 1.0 MBit/s . I've looked around and it seems that's the result of the rate control algorithm of the mac80211 driver when it detects inactive wifi links.
So, could it be possible that in this case, the MESH_SAE_AUTH_FAILURE is just a result of the minstrel_ht rate control which tunes down this WiFi interface because it's not being used?
Have there been recent changes (around October?) in the rate control that might be responsible for mesh having been broken in the RT3200's I wonder? @nbd?
Thankfully @daniel WDS on 80Mhz (and not 160Mhz) seems solid like mesh was before it broke. At least it has been working perfectly on my x3 RT3200's since I enabled it two days ago.
So at least this seems promising as a viable main router <> AP node connection means for the many who do not like drilling holes and running cables, and indeed as you indicated above maybe makes more sense anyway for many use cases.
But more testing is needed to confirm that WDS is as stable as mesh was on these devices.
One thing that is especially cool about the RT3200 is how cheap it is. For example for the price of one Asus RT-AX86u, you can buy 3x RT3200's and connect them wirelessly for large WiFi coverage throughout even a large home. One can start with 1x RT3200 and add more as required.
Clearly from this thread I am not the only one using the RT3200's in this way, so I think mesh / WDS are important and exciting features for this device.
BTW has anyone successfully got 802.11r to work on this device? Any particular settings needed?
I tried using 802.11r, but I have one iPhone that refuses to connect.