| Both sides previous revision Previous revision Next revision | Previous revision Next revisionBoth sides next revision |
| toh:linksys:e8450 [2024/11/01 12:24] – [Troubleshooting] 1andrevich | toh:linksys:e8450 [2024/12/05 16:12] – Formatting carlitossuper1 |
|---|
| |
| Read the advice there and download the initial installation image **...ubi-initramfs-recovery-installer.itb** | Read the advice there and download the initial installation image **...ubi-initramfs-recovery-installer.itb** |
| | |
| | __**Upgrading an UBI installation to new releases after 2024-02 (Includes ALL SNAPSHOTS, 24.10-SNAPSHOTs, 24.10.0-rcX releases and all releases in the foreseable future)**__ |
| | |
| | Since some SNAPSHOTs releases after February 2024, the flash layout of the router moved the FIP and Factory partitions into UBI, and thus, those releases need a new installer. That installer, as of December 2024 is v1.1.3 is available [[https://github.com/dangowrt/owrt-ubi-installer/releases/tag/v1.1.3|here]]. The procedure to upgrdade to Main SNAPSHOTS and newer releases (24.10-SNAPSHOT, 24.10.0-rcX and the future stable 24.10.0) //without keeping the configuration// is the following: |
| | |
| | 1. Download the //unsigned// installed from the link above, and the desired sysupgrade image you want to upgrade to (On Firmware Selector or [[https://downloads.openwrt.org/|OpenWRT's downloads]] page). |
| | 2. Flash the unsigned installer on Luci > System > Backup/Flash Firmware. Make sure to force the upgrade and uncheck to Keep the configuration! |
| | 3. The router will reboot into a recovery environment and will be accessible at 192.168.1.1. Go again to Luci > System > Backup/Flash Firmware and flash the desired sysupgrade image. Again, don't keep the configuration. |
| | 4. The router will reboot on the desired image and is ready to be set up. All future releases can be safely flashed using Luci, Attended Sysupgrade or OWUT unless a new installer is required and is instructed to be flashed. |
| | |
| | **In case the configuration wants to be preserved:** |
| | |
| | The configuration between stable 23.05 and MAIN Snapshots and current 24.10-rcX releases is almost identical, but needs some changes, so the procedure to upgrade while keeping the configuration is the following. |
| | 1. On the stable release, SSH into the router and execute ''uci set system.@system[0].compat_version=2.0'' and ''uci commit''. |
| | 2. Make a backup of said configuration on Luci > System > Backup/Flash Firmware. |
| | 3. Delete the following files from the backup file: |
| | * /etc/config/ubootenv |
| | * /etc/fw_env.config |
| | 4. Flash the //unsigned// 1.1.3 installer like the previous instructions. |
| | 5. The router will reboot in a recovery environment and then, flash the desired sysupgrade image. |
| | 6. The router will reboot on the desired image and the backup file can be uploaded in Luci > System > Backup/Flash Firmware. |
| | |
| | In the event that those files aren't deleted from the backup, those files need to be modified to match the new flash layout and avoid problems on future sysupgrades: |
| | - /etc/fw_env.config |
| | |
| | <webcode name="Default" frameborder=0 width=100% scrolling=yes externalResources="," renderingMode=story > |
| | /dev/ubi0_2 0x0 0x1f000 0x1f000 1 |
| | /dev/ubi0_3 0x0 0x1f000 0x1f000 1 |
| | </webcode> |
| | |
| | - /etc/config/ubootenv |
| | |
| | <webcode name="Default" frameborder=0 width=100% scrolling=yes externalResources="," renderingMode=story > |
| | |
| | config ubootenv |
| | option dev '/dev/ubi0_2' |
| | option offset '0x0''' |
| | option envsize '0x1f000' |
| | option secsize '0x1f000' |
| | option numsec '1' |
| | |
| | config ubootenv |
| | option dev '/dev/ubi0_3' |
| | option offset '0x0' |
| | option envsize '0x1f000' |
| | option secsize '0x1f000' |
| | option numsec '1' |
| | |
| | </webcode> |
| | |
| | More info about those changes in the files [[https://forum.openwrt.org/t/belkin-rt3200-linksys-e8450-wifi-ax-discussion/94302/5950|here]]. |
| |
| __**non-UBI**__ | __**non-UBI**__ |
| |
| A few caveats to using WED: | A few caveats to using WED: |
| * Users may experience stability issues as this is a [[https://patchwork.kernel.org/project/linux-wireless/patch/20220505113729.50380-4-nbd@nbd.name/|relatively new]] feature | * Requires 22.03 or later |
| | * May be less stable as this is a [[https://patchwork.kernel.org/project/linux-wireless/patch/20220505113729.50380-4-nbd@nbd.name/|relatively new]] feature |
| * It can be used alone or in addition to other hardware offloading | * It can be used alone or in addition to other hardware offloading |
| * Requires 22.03.0 or later | * It is incompatible with AQL |
| * Only accelerates wireless traffic, not wired traffic | * Only accelerates wireless traffic, not wired traffic |
| * Only supported on the 5 GHz radio | * Only supported on the 5 GHz radio |
| * If used on a [[:docs:guide-user:network:wifi:dumbap|dumb access point]], an additional package is needed | * If used on a [[:docs:guide-user:network:wifi:wifiextenders:bridgedap|dumb AP]], an additional package is needed |
| |
| === Enable WED === | === Enable WED === |
| == OpenWrt 22.03.2 == | == 22.03 or 23.05 == |
| * Edit ''/etc/modules.d/mt7915e'' and append this line ''mt7915e wed_enable=Y'' | * Edit ''/etc/modules.d/mt7915e'' and append this line ''mt7915e wed_enable=Y'' |
| * This change requires a reboot | * This change requires a reboot |
| * :!: This change will not persist upon updating as the file edited is not the target of a backup tarball. | * :!: This change will not persist upon updating as the file edited is not the target of a backup tarball. |
| == Development snapshot == | == 24.10 or Main snapshots onward == |
| * Edit ''/etc/modules.conf'' and append this line: ''options mt7915e wed_enable=Y'' | * Edit ''/etc/modules.conf'' and append this line: ''options mt7915e wed_enable=Y'' |
| * This change requires a reboot | * This change requires a reboot |
| == Dumb access point configuration == | == Dumb Access Point configuration == |
| Flow offloading happens in situations where flows are actually being tracked, ie. when using NAT/routing. To use WED on a dumb access point requires the [[https://github.com/openwrt/openwrt/tree/master/package/network/services/bridger|bridger]] package which does a bit of BPF magic to get bridged streams tracked (and hence offloaded). | Flow offloading happens in situations where flows are actually being tracked, ie. when using NAT/routing. To use WED on a dumb AP requires the [[https://github.com/openwrt/openwrt/tree/master/package/network/services/bridger|bridger]] package which does a bit of BPF magic to get bridged streams tracked (and hence offloaded). |
| * [[faq/how_to_install_packages|Install]] the bridger package. Optionally edit ''/etc/config/bridger'' and define a device or bridge to exclude from bridge forwarding acceleration. | * [[faq/how_to_install_packages|Install]] the bridger package. Optionally edit ''/etc/config/bridger'' and define a device or bridge to exclude from bridge forwarding acceleration. |
| |
| v2.10.0 (release):OpenWrt v2024.01.17~bacca82a-2 (mt7622-snand-ubi-1ddr) | v2.10.0 (release):OpenWrt v2024.01.17~bacca82a-2 (mt7622-snand-ubi-1ddr) |
| </code> | </code> |
| If you are on the v2.9 or 2.10 branch and the suffix of the build is ...a**-1** or ...a**-2** => Device is affected and at risk of OKD on boot, reboot, power up. | If you are on the v2.9 branch or (2.10 branch and the suffix of the build is ...a**-1** or ...a**-2**) => Device is affected and at risk of OKD on boot, reboot, power up. |
| |
| <code> | <code> |
| 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) |
| </code> | </code> |
| You are safe as you have the fixed ...a**-3** or later build. | You are safe as you have the fixed v2.10.0...a**-3** or later build. |
| |
| ===Recovery from live OpenWrt main/master snapshot with FIP in UBI layout=== | ===Recovery from live OpenWrt main/master snapshot with FIP in UBI layout=== |
| * Linux, when `mtk_uartboot` automatically recognizes the connected serial device: <code>./mtk_uartboot -s /dev/ttyUSB0 -a -p mt7622-ram-1ddr-bl2.bin -f *uboot.fip && screen /dev/ttyUSB0 115200</code> | * Linux, when `mtk_uartboot` automatically recognizes the connected serial device: <code>./mtk_uartboot -s /dev/ttyUSB0 -a -p mt7622-ram-1ddr-bl2.bin -f *uboot.fip && screen /dev/ttyUSB0 115200</code> |
| * macOS, when `mtk_uartboot` would otherwise use the wrong serial device: <code>./mtk_uartboot -a -p mt7622-ram-1ddr-bl2.bin -f openwrt-mediatek-mt7622-linksys_e8450-ubi-bl31-uboot.fip -s /dev/cu.usbserial-B002EI6Z && screen /dev/cu.usbserial-B002EI6Z 115200</code> | * macOS, when `mtk_uartboot` would otherwise use the wrong serial device: <code>./mtk_uartboot -a -p mt7622-ram-1ddr-bl2.bin -f openwrt-mediatek-mt7622-linksys_e8450-ubi-bl31-uboot.fip -s /dev/cu.usbserial-B002EI6Z && screen /dev/cu.usbserial-B002EI6Z 115200</code> |
| | * (The serial device on your system may be different than the one shown above, such as `tty.usbserial-0001` or similar. If the handshake does not succeed, compare your `/dev` directory before and after plugging in the serial device to discover the newly created adapter. Running `ls -t1r` after plugging in the adapter may help see the newest devices. Replace `cu.usbserial-B002EI6Z` with the correct serial device every time it appears in the above command.) |
| * Windows: <code>mtk_uartboot -a -s COM(X) -p mt7622-ram-1ddr-bl2.bin -f openwrt-23.05.3-mediatek-mt7622-linksys_e8450-ubi-bl31-uboot.fip && putty.exe -serial COM(X) -sercfg 115200,8,n,1,N</code> note: **replace (X)** with the actual COM port number of the serial adapter | * Windows: <code>mtk_uartboot -a -s COM(X) -p mt7622-ram-1ddr-bl2.bin -f openwrt-23.05.3-mediatek-mt7622-linksys_e8450-ubi-bl31-uboot.fip && putty.exe -serial COM(X) -sercfg 115200,8,n,1,N</code> note: **replace (X)** with the actual COM port number of the serial adapter |
| * Power on the RT3200 / E8450 | * Power on the RT3200 / E8450 |
| * mtk_uart should trigger a boot (if you never get past 'Handshake...' from mtk_uartboot, you have the wrong serial device selected, don't have a good serial connection, or - and this is the case for many people - your serial adapter may not be compatible and you should try another if your attempts fail repeatedly) and your screen / putty session should present you with a U-Boot menu. If you take no action for a number of seconds, your router will boot. To recover, **you want to immediately press any key (like a down arrow) to interrupt the boot and stay on the boot menu**. | * mtk_uart should trigger a boot (if you never get past 'Handshake...' from mtk_uartboot, you have the wrong serial device selected, don't have a good serial connection, or - and this is the case for many people - your serial adapter may not be compatible and you should try another if your attempts fail repeatedly) and your screen / putty session should present you with a U-Boot menu. If you take no action for a number of seconds, your router will boot. To recover, **you want to immediately press any key (except for 0-a as these are options in the menu. a down arrow works) to interrupt the boot and stay on the boot menu**. |
| * From the boot menu, select the option ''Load BL2 preloader via TFTP then write to flash.'' | * From the boot menu, select the option ''Load BL2 preloader via TFTP then write to flash.'' |
| * Note that the current version automatically does the reflashing without further interaction, provided you have TFTP working. So, after the 4th "Writing 131072 byte(s) (64 page(s)) at offset 0x000600000" line everything should be ready. After reboot, the grep "(release)" /dev/mtd0ro command should give you v2.4 again. | * Note that the current version automatically does the reflashing without further interaction, provided you have TFTP working. So, after the 4th "Writing 131072 byte(s) (64 page(s)) at offset 0x000600000" line everything should be ready. After reboot, the grep "(release)" /dev/mtd0ro command should give you v2.4 again. |