Hi all,
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?
Thanks
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[2]: *** [Makefile:168: package_install] Error 255
make[1]: *** [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?
Cheers.
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.
@Lynx @daniel
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.
Thanks ka2107, that is very helpful, will read it through.
For the mesh users, I imagine for practical purposes this will only fix the initial crash reported for mesh in trace, but not this new node inaccessible issue with mesh. Or perhaps it fixes both.
Interesting. Could weak signal arise because of lack of use and a sort of winding power down associated therewith?
I ask because mine were in a fixed location with a strong connection when I checked. But maybe if power wound down or something during non use that would fit with the problem and solution described in this fix.
I managed to brick my router when trying to revert to factory firmware.
I have lost my own mtd blocks, and used those posted by ka2107, and confirmed by dangowrt to be good, but I edited mtd3 before writing it, to include device data of my router, taken from the stickers at the back (serial no, mac, wifi pass, etc.). Now I have a blinking power, no ping. I wonder if anybody would like to take a look? I'm happy to send the router via post, or any suggestions on how to fix it?
