As you didn't run the installer but only manually updated the bootloader you suspicion that the device lacks factory data is 100% correct. The v1.1.x installer also moves the factory data into a UBI volume.
Did you delete the content of the boot_backup volume? If not, you will find a copy of the former factory MTD partition there (check mount ubi0:boot_backup /mnt; ls -l /mnt). If you have really deleted it your only chance is to use the factory data of another very similar device (ie. preferably same production batch and hence almost identical radio properties) and patch the MAC addresses to the ones printed on the sticker on your device. Contact me via PM if you need help with that.
Youâre right in that the factory data was lost. However, the lack of network devices within OpenWRT suggests something else is going on here as well. More likely than not, you have a bad configuration file that has scrambled the network devices. There were device naming changes between 23.x and 24.x, so that might have caused problems. Donât try to restore a configuration file in this situation, but try to rebuild the configuration from scratch. (Edit: Per the following posts, it looks like the loss of all network devices is now expected and diagnostic behavior when the factory volume is missing as of OpenWRT 24.10.) As for recovering the device now, just follow the below instructions to restore your factory data. Those instructions require removal of the user data (settings) in order to reclaim space for the factory data.
As for restoring the MTD2 partition to a running install of 24.10, you should still have access to the network from within U-Boot. The recovery can take place there. Youâll simply need to set the MAC address to get it to appear on the network, and then configure the device and your TFTP server as you did when you recovered it in the first place. The troubleshooting section of the wiki document for this device has a link to the âhard recoveryâ instructions that were previously posted in this forum. That post includes the commands for setting the MAC address in U-Boot and the process for restoring everything, including replacement of the factory partition. Since you have your valid MTD2 from backup, you will want to use that backup file. If you are sure you were able to properly recover to 24.10 otherwise, you should only need the recovery steps for restoring the factory partition under 24.10. However, since it did boot into OpenWRT, the user data volume has probably now taken up all unoccupied space. Therefore, it must be removed in order to restore the factory data. The easiest way to do this is by running the command ubi part ubi && ubi remove rootfs_data from within U-Boot. Once the user data volume has been removed, you can run the commands to restore the factory data.
Let me be more clear: If the Ethernet driver won't be able to load the MAC address due to an error of the NVMEM subsystem (in this case clearly caused by the missing factory UBI volume) it won't probe. That means no network, and the same applies for the WiFi driver.
Hmm. Just for my own clarification, is this a behavior change between 23.05 and 24.10? In my earlier testing on a unit cold-booted with no factory data present in flash (23.05), OpenWRT would detect the hardware and automatically assign a random MAC to the Ethernet and to the 2.4GHz radio. Only the 5GHz radio would fail to appear, and that was because the driver required the EEPROM data to initialize.
Is it safe to assume that the difference is due to the 23.05-era driver detecting data with an invalid MAC address (mtd2 was filled with 0x00 or 0xFF), vs. 24.10 detecting no data (null) because the UBI volume doesnât exist?
Yes, exactly. With 23.05-era driver the factory mtd partition would always be present, just the data stored there might be invalid. In 24.10 and later, the situation @dogpile is facing is that the factory UBI volume doesn't even exist at all, which means the driver won't even ever probe because Linux is waiting for all dependencies (in this case: the NVMEM provider) to come up before.
@grauerfuchs Thanks so much your steps in the hard recovery thread https://forum.openwrt.org/t/belkin-rt3200-linksys-e8450-wifi-ax-discussion/94302/5108 worked perfectly. I just followed the steps in section Recovery instructions - Reload OpenWRT 24.10 from scratch and itâs back up and running with all my devices back after loading my backup mtd2 factory bin.
Thanks everyone for the support.
I donât understand this, as I believe Iâm already on UBI. I ran the UBI installer 1.1.4 a while ago. can the owut upgrade be used?
BusyBox v1.36.1 (2025-11-11 23:08:15 UTC) built-in shell (ash)
| |.-----.-----.-----.| | | |.----.| |_
| - || _ | -| || | | || || |
|_____|| |||||___||| |____|
|| W I R E L E S S F R E E D O M
OpenWrt 24.10.4, r28959-29397011cc
root@E8450:~# grep "(release)" /dev/mtd0ro
v2.10.0 (release):OpenWrt v2024.01.17~bacca82a-3 (mt7622-snand-ubi-1ddr)
v2.10.0 (release):OpenWrt v2024.01.17~bacca82a-3 (mt7622-snand-ubi-1ddr)
v2.10.0 (release):OpenWrt v2024.01.17~bacca82a-3 (mt7622-snand-ubi-1ddr)
v2.10.0 (release):OpenWrt v2024.01.17~bacca82a-3 (mt7622-snand-ubi-1ddr)
root@E8450:~# owut upgrade
ASU-Server https://sysupgrade.openwrt.org
Upstream https://downloads.openwrt.org
Target mediatek/mt7622
Profile linksys_e8450-ubi
Package-arch aarch64_cortex-a53
Version-from 24.10.4 r28959-29397011cc (kernel 6.6.110)
Version-to 24.10.5 r29087-d9c5716d1d (kernel 6.6.119)
82 packages are out-of-date
Request hash:
f7e47a10de1fde1dc972e22d15bd543ac391870e679fff0eaf9b66cff218f2a8
Status: queued - 0 ahead of you
Progress: 0s total = 0s in queue + 0s in build
Status: init
Progress: 0s total = 0s in queue + 0s in build
Status: container_setup
Progress: 5s total = 0s in queue + 5s in build
Status: validate_manifest
Progress: 16s total = 0s in queue + 16s in build
Status: building_image
Progress: 31s total = 0s in queue + 31s in build
Status: done
Progress: 33s total = 0s in queue + 33s in build
Build succeeded in 33s total = 0s in queue + 33s to build:
Image saved : /tmp/firmware.bin
ERROR: sysupgrade validation failed:
stderr =
Sun Dec 21 20:25:50 CET 2025 upgrade: The device is supported, but this image is incompatible for sysupgrade based on the image version (1.0->2.0).
Sun Dec 21 20:25:50 CET 2025 upgrade: SPI-NAND flash layout changes require bootloader update. Please run the UBI installer version 1.1.0+ (unsigned) first.
Image check failed.
If youâre currently on 24.10.4 and your device works normally, it means you ran the 1.1.3 or 1.1.4 installer at some point. The error you get is that you didnât change the system compat flag in your configuration. That was clearly mentioned in the wiki.
You need to run uci set system.@system[0].compat_version=2.0 and then uci commit. After that, you can run owut upgrade as usual.
Also, make sure you have the fitblk package installed.
Repeating for emphasis...
Now that the maker of owut is here, Iâd like to thank you for it and how easy was to go from 24.10.5 to 25.12.0-rc1.
I upgraded my two RT3200âs to 25.12 without any issues. I just had to tweak my script to install the Argon theme with APK at first boot, but other than that. Itâs working great!
Anyone else with the E8450/RT3200 is on 25.12.0? Almost no one is talking about it.
To be slightly more precise: the correct new value came originally ok from currently running firmware image, but was likely overrun by an old value from a restored backup. So, thatswhy you need to set it manually. (or at least check it)
Originally noted in
Ps. The advice to fix it only applies, when you know that you have already been in the new "fip in ubi" structure and that you have restored settings after the previous sysupgrade (or Daniel's installer run).
fitblk was installed, but somehow I managed to reach 24.10.4 without system.[0].compat_version='2.0' being setâor so it seemed. As it turns out, I may have set it earlier, but it got lost along the way during recovery-installer install and sysupgrade earlier
Once I set it properly on the devices (I have two), the upgrade on one of them went smoothly using owut. The other device was more challenging: I only had a single VLAN port available to connect, couldnât resolve the configuration issues, could not find an issue and ended up doing a hard reset. I then ran the 24.10.0 installer again and sysupgraded to 24.10.5 (ubi). After restoring the configuration, everything is now working correctly.
I still have no clear idea what happened or what caused the issue. I noticed that system.[0].compat_version='2.0', which had previously been set, was unset, so Iâve set it again. Hopefully this will make the next owut upgrade go more smoothly.
Thanks for the suggestions.
Guess import old config without âsystem.@system[0].compat_version=2.0â was probably the cause indeed. Now set and backing up daily, all set for future updates.
Has anyone encountered sudden drop (i.e. <5Mbps) of BW on 5GHz dumb AP mode with WED enabled and bridger* installed (default config)? I need to restart the AP to âresetâ the speed. For now I've just disabled it.
Please advise how to enable it. Not doing so limits my BW to 600Mbps DL. Otherwise I can reach 780Mbps.
Thanks in advance.
I have never achieved more than 700-780Mbps in WiFi download speeds (running a speed test) with my RT3200, with both WED enabled and disabled. In fact, I get the same speeds with either, so I left WED disabled because it was troublesome.
With iPerf3, I do get 900 Mbps and up.
My whole setup is a RT3200 acting as a main router (connected to the Fiber ONT) and another RT3200 as dumb AP (actually plugged to the WAN port, converted as a LAN port). On both I get speed tests of around 700-ish Mbps in download and 800 to 900Mbps in upload. WED disabled in both devices.
So, my advise is remove the bridger package and donât use WED, itâs not woth it.
PS: The WiFi tests were made with a Thinkpad X280 with an Intel AX210 WiFi 6E card and another Thinkpad P14s Gen 5 AMD with Qualcomm 6900 WiFi 6E. Both cards siupport 160MHz channels that I have set up on my routers.
Thanks for the inputs! Will revert enabling the WED then.
Advance happy new year to you and your family!
Happy New Year to you, too!
I forgot. On both routers I do have IRQbalance and have the IRQs of the ethernet and wifi pinned to each core of the CPU.
I have this on my startup file:
echo 2 > /proc/irq/127/smp_affinity
echo 2 > /proc/irq/128/smp_affinity
echo 1 > /proc/irq/139/smp_affinity
echo 1 > /proc/irq/140/smp_affinity
And of course those IRQs ignored in irqbalance.
And this is what my IRQs look after:
CPU0 CPU1
10: 392151161 10476686 GICv2 30 Level arch_timer
14: 0 0 mt-eint 0 Edge gpio-keys
67: 12 0 mt-eint 53 Level mt7530
116: 0 0 mt-eint 102 Edge gpio-keys
117: 1 0 MT_SYSIRQ 163 Level mt-pmic-pwrap
118: 12 0 MT_SYSIRQ 91 Level ttyS0
120: 38395 252356 MT_SYSIRQ 95 Level mtk-ecc
121: 0 0 MT_SYSIRQ 118 Level 1100a000.spi
122: 0 0 MT_SYSIRQ 122 Level 11016000.spi
123: 10662 63112 MT_SYSIRQ 96 Level mtk-snand
127: 22 5180823 MT_SYSIRQ 224 Level 1b100000.ethernet
128: 7 7623786 MT_SYSIRQ 225 Level 1b100000.ethernet
130: 0 0 dummy 0 Edge PCIe PME
132: 0 0 MT_SYSIRQ 219 Level 1b007000.dma-controller
133: 9 0 mt7530 0 Edge mt7530-0:00
134: 0 0 mt7530 1 Edge mt7530-0:01
135: 0 0 mt7530 2 Edge mt7530-0:02
136: 0 0 mt7530 3 Edge mt7530-0:03
137: 3 0 mt7530 4 Edge mt7530-0:04
138: 0 0 MT_SYSIRQ 232 Level xhci-hcd:usb1
139: 7578358 0 MT_SYSIRQ 211 Level mt7615e
140: 9940636 0 MTK PCIe MSI 524288 Edge mt7915e
IPI0: 1523927 1828889 Rescheduling interrupts
IPI1: 16432261 22059939 Function call interrupts
IPI2: 0 0 CPU stop interrupts
IPI3: 0 0 CPU stop NMIs
IPI4: 0 0 Timer broadcast interrupts
IPI5: 1318717 4991853 IRQ work interrupts
IPI6: 0 0 CPU backtrace interrupts
IPI7: 0 0 KGDB roundup interrupts
Err: 0
I cannot pin IRQ 140 to any core. It sticks to all cores.
root@AccessPoint:~/OpenWrtTools# cat /proc/irq/140/smp_affinity
3
root@AccessPoint:~/OpenWrtTools# cat /proc/interrupts
CPU0 CPU1
10: 49408 33624 GICv2 30 Level arch_timer
14: 0 0 mt-eint 0 Edge gpio-keys
67: 3 0 mt-eint 53 Level mt7530
116: 0 0 mt-eint 102 Edge gpio-keys
117: 1 0 MT_SYSIRQ 163 Level mt-pmic-pwrap
118: 13 0 MT_SYSIRQ 91 Level ttyS0
120: 35611 0 MT_SYSIRQ 95 Level mtk-ecc
121: 0 0 MT_SYSIRQ 118 Level 1100a000.spi
122: 0 0 MT_SYSIRQ 122 Level 11016000.spi
123: 10058 0 MT_SYSIRQ 96 Level mtk-snand
127: 12 474 MT_SYSIRQ 224 Level 1b100000.ethernet
128: 0 990 MT_SYSIRQ 225 Level 1b100000.ethernet
130: 0 0 dummy 0 Edge PCIe PME
132: 0 0 MT_SYSIRQ 219 Level 1b007000.dma-controller
133: 0 0 mt7530 0 Edge mt7530-0:00
134: 0 0 mt7530 1 Edge mt7530-0:01
135: 0 0 mt7530 2 Edge mt7530-0:02
136: 0 0 mt7530 3 Edge mt7530-0:03
137: 0 3 mt7530 4 Edge mt7530-0:04
138: 32 0 MT_SYSIRQ 232 Level xhci-hcd:usb1
139: 971 0 MT_SYSIRQ 211 Level mt7615e
140: 3061 0 MTK PCIe MSI 524288 Edge mt7915e
IPI0: 1178 1655 Rescheduling interrupts
IPI1: 4714 8239 Function call interrupts
IPI2: 0 0 CPU stop interrupts
IPI3: 0 0 CPU stop (for crash dump) interrupts
IPI4: 0 0 Timer broadcast interrupts
IPI5: 3398 2065 IRQ work interrupts
IPI6: 0 0 CPU wake-up interrupts
Err: 0
After 9 hours, all seems good despite not being able to set IRQ 140.
root@AccessPoint:~/OpenWrtTools# cat /proc/interrupts
CPU0 CPU1
10: 8462729 15425584 GICv2 30 Level arch_timer
14: 0 0 mt-eint 0 Edge gpio-keys
67: 9 0 mt-eint 53 Level mt7530
116: 0 0 mt-eint 102 Edge gpio-keys
117: 1 0 MT_SYSIRQ 163 Level mt-pmic-pwrap
118: 13 0 MT_SYSIRQ 91 Level ttyS0
120: 109759 0 MT_SYSIRQ 95 Level mtk-ecc
121: 0 0 MT_SYSIRQ 118 Level 1100a000.spi
122: 0 0 MT_SYSIRQ 122 Level 11016000.spi
123: 28602 0 MT_SYSIRQ 96 Level mtk-snand
127: 12 1055513 MT_SYSIRQ 224 Level 1b100000.ethernet
128: 0 3783641 MT_SYSIRQ 225 Level 1b100000.ethernet
130: 0 0 dummy 0 Edge PCIe PME
132: 0 0 MT_SYSIRQ 219 Level 1b007000.dma-controller
133: 0 0 mt7530 0 Edge mt7530-0:00
134: 0 0 mt7530 1 Edge mt7530-0:01
135: 0 0 mt7530 2 Edge mt7530-0:02
136: 0 0 mt7530 3 Edge mt7530-0:03
137: 0 9 mt7530 4 Edge mt7530-0:04
138: 32 0 MT_SYSIRQ 232 Level xhci-hcd:usb1
139: 173814 0 MT_SYSIRQ 211 Level mt7615e
140: 3572763 0 MTK PCIe MSI 524288 Edge mt7915e
IPI0: 88979 73933 Rescheduling interrupts
IPI1: 6277610 5922735 Function call interrupts
IPI2: 0 0 CPU stop interrupts
IPI3: 0 0 CPU stop (for crash dump) interrupts
IPI4: 0 0 Timer broadcast interrupts
IPI5: 432917 800089 IRQ work interrupts
IPI6: 0 0 CPU wake-up interrupts
Err: 0
My bad. I didnât mention that the MT7915E (The WiFi 5GHz radio) doesnât move when WED is disabled. Thatâs why I pinned the 7615E (2.4GHz radio) to CPU0 and ethernet to CPU1. When WED is enabled, the IRQs change a bit and you can pin Ethernet to CPU0 and both radios to CPU1.
Anyway, did you see a little bit of improvement on the WiFi speeds with this? At best it can give you a little bit better, or donât make a difference at all.
Also, do you have packet steering enabled or disabled? That should also make a difference.