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.
1 Like
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?
1 Like
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.
1 Like
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?
The documentation has been updated by @loyukfai and me:
@Octi Did you complete these steps including the final step, uploading the vendor firmware via TFTP?
1 Like
That's a bit scary then indeed. You may need to wire up serial console to see what has happened.
Which LED is blinking and at which frequency (approximately)?
The power LED is blinking, in white colour, approx twice a second.
You should've also edited the mtd2 (factory partition) if you restored it from another device backup because MAC-s are also there in hex form. But I think that mtd2 (i.e. original mtd4 partition) should NOT be restored anyway because it is not touched by upgrades or conversion to UBI. Also this factory partition keeps very important data specific to the router, it should definitely not be loaded from another router as it is.
When you say you cannot ping the router, which address have you tried? I think both original and UBI loaders expect a tftp server at 192.168.1.254 (which should be the fixed IP assigned to your computer). Try then to serve by tftp an original factory firmware renamed to "lede-mediatek-mt7622-MTK-AX3200-MT7531-squashfs-sysupgrade.bin". Even if the router will be revived the wireless part could be affected by the different factory partition.
1 Like
twice per second sounds like reboot loop, that's not good...
There must be a way to fix this situation, no?
Perhaps we should all chip in to an OpenWrt brick insurance. We all chip in $5 and next person to brick device can claim.
Yes. Attaching serial console is the first step to know what's going on.
If you don't get anywhere from there (because bootchain fails very early) you got two more options:
- directly connect to the SPI-NAND flash chip, e.g. using CH341 USB-SPI adapter (more complicated than one might think as you will have to imitate the in-hardware ECC OOB layout)
- connect JTAG pads e.g. to FTDI FT2232H breakout and use OpenOCD, see