my first step was to install openwrt-mediatek-mt7622-linksys_e8450-ubi-initramfs-recovery-installer.itb from the stock firmware. it appears that this has installed an openwrt initramfs flat image.
i saved the mtd0,mtd1 mtd2, mtd3 images from this flash.
reading through the guide, it is later suggested to do a full backup by flashing openwrt-mediatek-mt7622-linksys_e8450-ubi-initramfs-recovery.itb from stock. however, it appears that the 4 mtd files that i saved from after my first openwrt flash are not really the original mtd - it appears that i should have first flashed the second file (recovery.itb, not recovery-installer.itb)
is there any hope for restoring original firmware now?
if not - i'll just proceed
suggest - to @daniel (dangowrt) - to reword the instructions jsut a little?? thanks - im looking forward to proceeding
The instructions could be slightly more polished, as they remind a spaghetti code, but if you read carefully, then all the steps are properly in order.
Revert back to old firmware.
Install recovery image (not installer). This image is required only for backup/restore the original rom.
using ssh create a dump of the 4 mtd partitions. DO NOT USE LUCI!!!!! most probably those files will be corrupted. Do not take the risk and use the ssh method. Actually that feature should be removed from the luCI interface as it is not working good.
scp from your computer to extract the files, type reboot from ssh to return to the original firmware.
Back in the original firmware, flash the recovery-installer image and reboot.
In the installer image, now you can flash the sysupgrade image and you are all done.
I advice to update to the latest snapshot after flashing the image.
I had no trouble with the instructions, but I agree they could be more user friendly, it can be a little scary for people not used to deal with hardware, firmware, bricks, etc...
Actually, steps 2, 3 and 4 are required to create a backup of the original from in case you want to revert to the original ROM structure. If you are no interested in that, then you can jump from step 1 to step 5, however you should keep a copy of the original ROM, at least while the hardware is under warranty.
Once you run the installer, it will have automatically created backup files which you can copy off the device. This backup (called minimal backup in the README.md of the installer project on github) is enough to go back to the vendor bootchain, you will just need to also flash the firmware itself as well.
A full backup (which you don't have now) can help you in the extremely unlikely event (which hasn't happened yet for anyone afaik) of something going wrong during installation (but then you will still need to open the device, connect to serial port or even JTAG, ...). Having the full backup also makes restoring to stock a bit easier, as you don't need to download and flash the main firmware itself as well.
well - if i hadnt done it wrong to start, i might not have learned all this. thank you.
got it all reverted, fully backup up, and now ugrading using the UBI pathway you created.
thank you!
If you like the default package selection from the install image and want an updated set of images, you can always fork the repo and build an updated version. It takes 3 minutes and you don't even need a linux machine.
1: Create a github.com account if you still don't have one
2. go to https://github.com/dangowrt/linksys-e8450-openwrt-installer
and fork the repo (top right corner of the page)
3. in your repo, (something like https://github.com/YOUR_USERNAME/linksys-e8450-openwrt-installer) click on actions on the top left, 3rd row.
4. select the CI workflow
5. On the right side click on Run workflow
6. In 3 minutes Retrieve your up-to-date images as a release of your repo using the latest code.
i think you both know that luci-app-attendedsysupgrade doesnt work. any idea why?
i'm using chef imagebuilder to add to the rt4300 (ubi) snapsohot builds. i've use the imagebuilder for years and it's great (faster than my linux build system certainly, and less painful usually)
given the two-stage bootload sequence (i think) - is there any benefit of building new images for u-boot.fip and ubi-preloader.bin vs using the sysupgrade image alone?
@hnyman I got one last question about SQM and nftables since i found you thread on github regarding this. What is the current state on this? With the update to the latest snapshot i got firewall4 with nftables. But is seems like that the installation of the SQM packages triggered the installation of iptables. Is that a problem? How is my system now filtering? With nftables or iptables or both?
Or does SQM just use some lines of code from iptables and my system still uses nftables as a firewall?
No. nftables. Iptables get translated to nftables so it should not be a problem anymore.
Hey, that is the risk of running on the bleeding edge. Once in a while, something breaks and you have to clean up the mess. There be dragons.
I am curious as well if someone can test this. I am still using fw3 because of miniupnpd, and the situation remains unchanged: checking the hardware offload increase the CPU usage compared to software offload only.
Here is something that made me scratch my head - plugged Belkin RT3200 WAN port into a 2.5gb capable switch and... it definitely detects the capability but I wasn't aware of 2.5GB support on this particular switch/driver..
ethtool eth0
Settings for eth0:
Supported ports: [ MII ]
Supported link modes: **2500baseX/Full**
Supported pause frame use: Symmetric Receive-only
Supports auto-negotiation: Yes
Supported FEC modes: Not reported
Advertised link modes: **2500baseX/Full**
Advertised pause frame use: Symmetric Receive-only
Advertised auto-negotiation: Yes
Advertised FEC modes: Not reported
Link partner advertised link modes: **2500baseX/Full**
Link partner advertised pause frame use: Symmetric
Link partner advertised auto-negotiation: No
Link partner advertised FEC modes: Not reported
Speed: **2500Mb/s**
Duplex: Full
Port: MII
PHYAD: 0
Transceiver: internal
Auto-negotiation: on
Current message level: 0x000000ff (255)
drv probe link timer ifdown ifup rx_err tx_err
Link detected: yes
I think that's the internal ethernet device. If you run ethtool on the wan device you might get a different answer. I ran ethtool against eth0 and got the same answer you did, but I know I'm only plugged into a gigbit device. When I ran it against wan I got a speed of 1000Mb/s as expected.
(Oh, and hi everyone. Been up and running on a new rt3200 for about two and a half days. So far so good, and thanks to everyone who put in the work to get us this far.)
Looks like this is the most requested device on sysupgrade.openwrt.org, thanks for using this service so much. (The stats are up for less than a week).
That's probably impossible to answer, as this kind of device is only viable in mass production, targeting the ordinary public at large (what difference do a few hundred OpenWrt users make against tens of thousands regular buyers). However, at least in Europe, Belkin (under its own brand) is rather non-existent on the router market, so a few determined enthusiasts might be more visible than normal and the original concentration to the UK market seems to have fallen as well (at least in .de, Bezos' hot air store seems to have added it to their regular portfolio).
I would venture that the Linksys WRT-54GL, the TL-WR1043NDv1 and the Archer c7 might have seem a longer shelf life due to the demand of third party firmware users, than usually expected given the internals.
@apacar - your work to make image building accessible is amazing. i have used your tools for the last 2 years.
i'm not sure who all has made this project viable for the RT3200/E8450 - but this work has also been amazing. @daniel - @Dopam-IT_1987@slh@slh - and others -
is this 2-3 step bootloader and UBI overlay the new starting point for u-boot and openwrt? where can i learn more?
regarding market - i became interested in this device only because of the openwrt threads.