If I'm not wrong, all stable releases of OpenWrt for RT3200/E8450 suffer from this crash. The fix was done on the master tree sometime in Dec 2023 (IIRC) but it was not back-ported to 23.05 branch.
My E8450 running my own master build from early Feb 2024, and it's been up and running normally for more than 90 days now. Before this, my E8450's WiFi will randomly stop working and all network access disabled. Only way to see what's wrong is via serial console. Power-cycling my E8450 is the only way to get back service.
Will be staying on this build until the root cause of the OKD has been identified tho.
Edit: I forgot to add that I only see WiFi driver crashes when WED is enabled. Without WED, it is stable.
Whelp, one of my APs just died after an update. It was the oldest boy of the three, so I guess it was just a matter of time - June 2021 purchase and it's been on 24/7 since.
There's absolutely no lights, serial port does not give any outputs (though I have a suspicion my UART dongle is faulty, so waiting for a new one from Amazon at this moment just to verify), and the only thing it does is emit a little bit of coil whine. I suspect it's fully dead, unrecoverably so.
Do you guys have any recommendations for a replacement? WiFi 7 would be nice but not a must, and the goal would be to have 2-3 downstream ethernet port for some wired needs (Xbox, Apple TV). 2.5G uplink to my router would be great too. I'm eyeing another Netgear WAX220 (grabbed one for Black Friday last year, a proper beast, and has OWRT support too), but it lacks the downstream ports...
Xiami Redmi AX6000 (same CPU and wifi chipsets as MT6000 but available at a better price but 1GB WLAN), GL.iNet GL-MT6000 (Flint 2), or Banana RPi3 / RPi4 for some DIY fun.
Apologies, forgot to mention, this will be limited to AP mode - both the Xiaomi and the GL.inet are in the "traditional router" form factor, which won't fit into the space I have. Which is why I've been thinking of the WAX220.
GL-iNet's MT6000 is a solid replacement and slight upgrade, affordable, flashable to community OpenWrt out of the box. I have their MT3000 currently and it also is a (very) slight upgrade to the RT3200.
This saved me a ton of time. My RT3200 was on its way to its second OKD and I really didn't want to tear it open again. After these steps, I don't need to stick it in the freezer to boot, and didn't need to open it up and redo the serial connection. Thanks!
You can also just use TFTP, it'a about 1000x faster. But I admit that it's a bit more involved when it comes to setup a TFTP server and get the IP configuration on both ends right...
I wholeheartedly agree. It's a bit more work at first, but it also seems to be the defacto go-to method for transferring files to many devices in need of recovery. I do all of my recovery/test work via tftp unless I have an explicit reason to use an alternate method. In this case, the user specifically requested the use of loadx, and so xmodem it is. It was a new one for me; I'm so used to using 'screen' for my serial terminal sessions that I'd completely forgotten how to get minicom running without having to initialize the device as a dial-up modem, all so I could test the loadx commands that appeared to be correct.
For what it's worth, with how fully functional U-Boot has become, my secondary preference would be transferring the files via USB flash drive. fatload is pretty fast and seems to be reliable, as long as the drive is properly formatted and you can identify the USB device.
I'm been trying to figure out possible root causes for the OKD by going thru the source of the bootloader. Tho I'm not getting any leads, I'm reminded of a thread (link) I read quite some time back, that I also encountered with my Linksys EA-7500v2.
It could be that the change of moving FIP into UBI may have hit the same issue as discussed in the thread I linked above. I would think that the UBI IO driver implemented in BL2 is probably not as robust as those in the Linux kernel, and is not able to catch bit-flips? when loading from the MTD device?
The freezer trick saved one out of three. The other two I still had to crack open and get serial console. So funny the cold works at all.
I notice that:
ubi remove rootfs_data ; ubi read $loadaddr fip && ubi write $loadaddr fip $filesize
gets it booting but the number of data bytes reported when running
ubinfo -d 0 -n 0
looks the same as before updating the FIP partition like hnyman suggested. I went ahead and followed hnyman's instructions after getting it to boot from console to be safe.
That sounds like the power supply could be the issue. Did you try swapping it or at least measure that the output of the supply unit is still around 12V DC?
Is it just me or is this device not beefy enough to run Wireguard at above ~700 Mbps? I enabled hardware offloading. htop shows that both CPU cores are maxed out when running iperf3 against a Wireguard peer
