I attempted to upgrade my router without installing the v1.1.3 updater first. (I forgot that I haven't done it.) This is contrary to the advice in the announcement (quoted below).
User of the Linksys E8450 aka. Belkin RT3200 running OpenWrt 23.05 or earlier will need to run installer version v1.1.3 or later in order to reorganize the UBI layout for the 24.10 release. A detailed description is in the OpenWrt wiki. Updating without using the installer will break the device. Sysupgrade will show a warning before doing an incompatible upgrade.
The upgrade failed, but with no bad effect: Here's my experience:
I used luci-app-attendedsysupgrade Web GUI to request 24.10.0. It proceeded to build my firmware with my custom packages.
I clicked "Install firmware image"
I saw:
Downloading
Uploading
Installing
Several seconds later, i was back at the main Status page running 23.05.5.
I checked the System Log and saw these lines:
Thu Feb 6 06:59:48 2025 user.info upgrade: The device is supported, but this image is incompatible for sysupgrade based on the image version (1.0->2.0).
Thu Feb 6 06:59:48 2025 user.info upgrade: SPI-NAND flash layout changes require bootloader update. Please run the UBI installer version 1.1.0+ (unsigned) first.
The router continues to run 23.05.5 with my prior config. I plan to run the v1.1.3 updater when I have time.
I wouldn't necessarily call this good news, but I'd definitely say it went about as well as a failure could go.
At some point within the last year and before 24.10 came out, the behavior of mismatched upgrades on this device changed. Prior to this change, such a mistake likely would have bricked the router. As for attendedsysupgrade, it's long been notorious for not identifying new packages and new requirements when things drastically change. This has caused issues such as losing the ability to upgrade at all, loss of the 5GHz wifi (when the firmware packages split apart), and other problems on this device alone.
The fact that it's now able to reject the upgrade is a major improvement from previous behavior. Had it accepted and attempted to run the upgrade, you wouldn't have WiFi and your MAC addresses would have been randomized on every boot as well.
After that, the router will reboot on a recovery environment and will be accessible on 192.168.1.1 and you can enter Luci and flash the 24.10.0 sysupgrade (that you should have downloaded by now, also the file name MUST include UBI in its filename) image (Luci > Backup/Flash firmware). Again, don't keep settings.
When you're done, the router will reboot on 24.10.0 and you can set it up from scratch or retore the configuration taking note on the instructions linked above on the Wiki. It's best if you set up the router from scractch.
@daniel@grauerfuchs@el_charlie But since this is such a high-risk operation (because you might brick the router), I would ask someone to verify the following procedure...
And because so many people will be doing this in the next month (upgrading from one version of the UBI installer to another), I would also ask that it be placed prominently in the github repo and in the Device Page. (Once the wording has been verified, I am willing to update the Wiki page and create a PR.)
Thanks
Upgrades requiring a new UBI Flash Layout
Generally you can upgrade your Linksys E8450 / Belkin RT3200 to a new OpenWrt version without difficulty using sysupgrade or the Attended Sysupgrade facility. However, the upgrade from earlier versions to 24.10.0 requires that the flash layout be updated.
This procedure assumes you are successfully running OpenWrt firmware, having already used an earlier version of the UBI installer. See the notes at the bottom if this does not apply to you.
Make a backup of your current router configuration (Always. Every time you make a change.)
Download the current ubi-initramfs-recovery-installer.itb file from the Releases page.
Download the current Linksys RT3200 UBI or Linksys E8450 UBI binary from the OpenWrt Firmware SelectorNB: The "UBI" in the name is critical.
Using the standard LuCI web interface, flash the first file (...ubi-initramfs-recovery-installer.itb) to the router. You will see a formidable warning about a "format check failure". This is expected. If you are sure you have downloaded the correct file, check the Force upgrade box and click Continue.
The after flashing, the router boots into a recovery image. Reconnect to the default 192.168.1.1. Ignore the "password" warning and proceed to the System -> Flash firmware page.
Flash the second file:
Browse and find ...ubi-squashfs-sysupgrade.itb
Upload it to the router
Uncheck all three boxes, DO NOT "Keep settings..."
I'm the one that made the instructions that currently are on the Device Page. You can edit that part and expand on the instructions.
Reading on what you wrote, it seems I missed some important parts like making emphasis on the UBI in the filename and verify the SHA. Basically the rest is already there with different words. I separated in 2 parts: upgrade to configure from scratch and upgrade and restore the configuration (that involves editing the backup file).
If you feel that you need to change everything to make it more clear, be my guest. The idea is to make the instructions foolproof to prevent users from bricking their routers.
Is there a way to force this in general without corrupting out the firmware config area? Maybe even something applicable outside of just this particular hardware?
Specifically "enforce" as default behaviour, so that even at the earliest point in the boot the WAN-side interface is never revealing its hardware MAC.
At some point I need to make a separate thread, but I am very interested in finding all unique ids, especially those revealed to the ISP (like DUID, part of why I am avoiding IPv6 until I understand more) and randomising them before my first router setup; after all, you can leak random identifiers any number of times, but you only need one slipup to permanently leak a real id.
You can force a non-factory MAC onto a device with option macaddr in the config file. I believe that "random" is also now an allowed setting which will compute a random MAC at run-time.
I will keep that in mind; but I would rather surgically nuke the particular region of the factory? fip? area that stores the WAN-facing MAC so that in case of missing or unloaded config it will fail safe to random.
@grauerfuchs is there a script or known offset in a particular partition/mtd image to set this? Do you set all 00 to cause it to randomise at boot?
Take a look in the main topic for this device, specifically for the 'hard recovery' instructions. That post contains the offsets for the MAC addresses within the factory volume. If you truly want to nuke the WAN MAC so it's completely gone, then yes, set it to 00:00:00:00:00:00. You shouldn't need to do that for the others if all you want to do is randomize the public MAC address.
There will be some complications when you do this, however. U-Boot will no longer be able to access the network until you assign it a valid MAC address. This means that if you want to update the firmware or boot chain from the serial console, you'll need to set a MAC address via the U-Boot console prior to doing so.
@el_charlie - I did see that your instructions include those steps. But I wasn't sure whether they applied to me (or where the instructions were for people with a new router who hadn't used the installer...)
I'm going to take a crack at the wording, and will let you know when it's available. I would really appreciate having someone who knows this well review it. Thanks
I have created a draft Device Page for the Belkin RT3200/Linksys E8450 that (attempts to) explain the reasons and steps for using the "UBI recovery installer". I made a copy in the playground so it's not live.
I think I got the installation steps/reasons correct. Comments welcome.
I basically stopped writing/editing after the Installation section (although I moved a lot of the old installation steps to the end). I don't know enough about this device to do more work on this page.
I would encourage people to give me comments, or make edits directly. Once we agree, we can move this draft page to the live page. Many thanks.
@One-Hoopy-Frood might also be working on new sections for the wiki, so it may make sense to work together or at least avoid both rewriting the same sections simultaneously:
