I'm not certain what I did wrong, but in attempting to follow the instructions given on the TOH page for this router (although mine is a Belkin RT3200), I ended up with not being able to boot (without resorting to pushing FIP and BL2 over serial with mtk_uartboot). I get the dreaded, "ERROR: BL2: Failed to load image id 3 (-2)".
I think this means that my FIP is bad. But I can't seem to figure out how to write to the FIP after using mtk_uartboot using the FIP, BL2 recommended on the TOH page.
I don't have a release version of OpenWRT, as I built it from the head of git. Since I can't find a matching kmod-mtd-rw package, and there isn't one in the recovery, I think I'm SOL, but hoping I'm not. I don't currently have equipment for JTAG, and seeing as how this is my dad's router (in another state) I dont' want to wait two weeks for a shipment from aliexpress.
Do I have other options? I guess, worst case scenario, I can try to rebuild kmod-mtd-rw, but I'm not that skilled with git, and can't remember exactly how to do that.
Some additional information: This router was imaged with the FIP on MTD, not UBI.
I seem to have also corrupted my U-boot env, which I think I can overcome, but I'm not sure about how to calculate the checksum, and I'm also not sure that is what is preventing boot, but I suppose it could be. I believe I did that trying to burn my FIP using the U-boot menu from the one pushed by serial. I am afraid it assumed a FIP in UBI, and overwrote my env.
Is it possible to reflash with the new recovery-install.itb image, and go straight to the latest OpenWRT from the recovery mode? Then I'd have FIP in the UBI.
You're not SOL, but you'll need to go through a few extra steps to get the router working again. Whether caused by OKD or due to a broken flash, your router indeed cannot load the FIP.
For full recovery, go to the main topic for the e8450/RT3200 and look for the post marked 'hard recovery instructions'. That contains all of the steps necessary for restoring all of the flash data to the layout used by the 23.x version (BL2, FIP, and Factory in MTD). Depending on what has been corrupted, you may need to restore a previously taken backup image of the factory partition. You'll know this because U-Boot will immediately complain about not having a MAC (ethernet) address, and your 5GHz radio will not work (it won't even show as a device).
Re-writing the FIP is easily done through the U-Boot console. The big trick is getting there. After using mtk_uartboot, you get 3 seconds from the time the FIP is received by the router to the time the router stops waiting for user input and starts trying to boot. If your terminal program is too slow to load (PuTTY, for instance), you won't get a chance to do anything. If you can't speed up the load time for the terminal program, you can try the following FIP with mtk_uartboot: https://github.com/grauerfuchs/owrt_device_support/raw/refs/heads/main/linksys-e8450-foxed-for-openwrt-23.05-noinit.fip This particular FIP was compiled with longer access windows and a few additional features intended to make recovery easier, such as dropping right into the U-Boot console rather than automatically trying to boot. It is also built to be 23.x compatible, so it will not work with the all-in-UBI (24.x or snapshot) firmware.
For recovery purposes, you do want to use an official release for the process. The instructions listed in the post are very specific about versions. Don't make substitutions. You can later go back to your own custom image for the main running firmware if you wish, but the boot chain and recovery volume should always be the official ones unless you're willing to deal with issues and a complete lack of support from anyone. Custom images present too many variables and too many potential differences, so the general policy is to support only official images.
As for corrupted U-Boot environment, it won't prevent boot. It will only force the router to use the built-in default values. Since most people never change the U-Boot environment, this isn't an issue.
If you're in a working recovery image without any issues on flash, you can use the UBI installer image. If you have problems on flash (and it sounds like you do), do not try to run the installer. It will most likely stop and fail out because it can't find the data it needs.
Thank you, @grauerfuchs! This looks like exactly what I needed!
I actually have three of these, and two of them have corrupted Factory. I didn't back up factory for each router, not knowing they were individualized. Ironically, the one backup of factory I have is the one that isn't corrupted. Always, this.
And, this begs the question:
I can see the MAC addresses in the backed up factory. Is it possible (or smart) to edit the actual MACs from the labels into copies of this one backup, and use those, rather than the one you created by looking at the driver? Or am I better off using (and editing with MACs) the one you made?
Not only is it smart, it is preferred. Although the factory data in each device appears to be unique in ways other than the MAC addresses, I couldn't identify the reason for it. However, there is a lot of data present in the EEPROM regions that the driver doesn't appear to use. Therefore, it's very possible that my surrogate could be missing data that is used within the factory firmware BLOB but not within the driver itself. Because of this and because the RT3200 doesn't contain tuning data in the factory partition, the real thing is definitely preferred.
I was able to edit a donor factory image to update the MAC addresses. I used a hex-editor on my PC (imhex worked well for me on Linux).
Translated the offsets (offset from 0 below) from the "if you don't have factory" part of the "hard recovery instructions" (actually, I verified these by looking to see that they looked like MAC addresses consistent with WAN at 0x7FFFA, according to the sticker for the good (donor) router).
--TO EDIT DONOR FACTORY IMAGE--
Notes: In Factory (donor)...
WAN MAC starts at offset 0x7FFFA
LAN MAC starts at offset 0x7FFF4
wl0 MAC starts at offset 0x00004
wl1 MAC starts at offset 0x05004
I changed each one to have the same first 5 bytes (two hex digits) as on the sticker for the recipient device (under repair). Then the last byte starts with the WAN MAC address (the one from the sticker), and add 0x01 to LAN, 0x02 to wl0, 0x03 to wl1.
It's just like in Grauerfuchs' "if you don't have factory" section, but with actual values for the 4th and 5th bytes taken from the sticker of the router under repair.
One more quick question: I'm loading a self-built firmware (from the same commit as 14.10.0) after I'm already running 14.10.0, and it's telling me, "Image check failed:
Sat Mar 29 11:42:12 UTC 2025 upgrade: The device is supported, but this image is incompatible for sysupgrade based on the image version (1.0->2.0). Sat Mar 29 11:42:12 UTC 2025 upgrade: SPI-NAND flash layout changes require bootloader update. Please run the UBI installer version 1.1.0+ (unsigned) first. Image check failed. "
What's up? It's safe to force it, I assume?
BTW, I built from source because it appears that the bridge kernel option was built without BRIDGE_VLAN_FILTERING=y. I haven't quite confirmed that yet. This is a conversation for a different topic...
Hmm. Did you restore a config that was from prior to the 24.10.0 upgrade process? If so, then that's the reason for the warning.
Interesting. I'd be very surprised if it was actually set that way, given how common it is for people to need it. Not only that, but I am using an RT3200 on 24.10.0 between this computer and my core network. The upstream port is a trunk line that has everything tagged, and the router has to properly split out multiple VLANs just to provide the proper service. I've seen no issues at all in operation, and all of the connected devices have the correct addresses.
Yes, I edited out the firmware environment file (and maybe another file? I can't remember) and then restored the config from previous v23.x.y. That must be it.
Well, it's really hard to tell whether my bridge vlan filtering issue is caused by the lack of driver support, but I'll find out very soon.
ip link del br-lan 2>/dev/null
ip link add name br-lan type bridge vlan_filtering 1
I realized I misunderstood. You're talking about the build config, right? Well yes and yes. I have now done a make distclean, 17 attempts to update feeds . Still waiting to reconfigure and rebuild. ./scripts/feeds update starts over after failure. and is both slow (almost dial up slow) and unreliable.
I'll let you know what i find out about bridge vlan filtering, though, after I successfully build a compatible image...
Is there a particular reason why you're not allowing this to happen via uci? The functionality is all right there, and it "just works" on the official firmware builds, both the default binary and the custom ones out of the firmware selector + custom packages.
Sadly, I'm not going to be able to help you on a home-compiled image. There are too many variables that could be encountered, and there's no way for me to rule them out.
I did try it with UCI and it didn't work. Those commands were debugging investigation.
This was on the official 14.10.0 rekease build. My personal build is my next step to debug/ confirm or refute the hypothesis that the kernel was compiled without 'BRIDGE_VLAN_FILTERING=y'
But the fact that you have it working treks me I likely have a configuration error. I don't have the custom build installed (yet) and alas, my custom build doesn't boot which is a separate puzzle, and I'm aware that devs have a very sensible policy to not support custom builds. I reloaded the release and or boots fine.
Since you say "it works" I'm investigating whether it's because of 802.1q being created by DSA because I configured VLANs implicitly, while what I really need is 802.1d.
I don't understand what you need that is part of 802.1d but doesn't seem to be working. It may require rethinking your processes and adapting, or maybe there is an unexpected and uncommon use case that OpenWRT doesn't currently handle. I don't know, so all I can do is wish you luck.