Belkin RT3200/Linksys E8450 WiFi AX discussion

For Developers
82

iw info shows me that mesh sadly stays at 40mhz no matter what i do. 160mhz works only on AP mode :frowning:

I will test WDS (station?) and report back.

EDIT: WDS is not stable.

83

See the script the installer is running inside initramfs to understand what it is doing:

1 Like
84

It definitely works - but I also suspected it was broken in the past.

Things to note:

  • Does your client device support 160mhz bands?
  • It takes a lot longer for the radio to spin up on higher bands (wait up to 5 minutes)

Here's my /etc/config/wireless

config wifi-device 'radio1'
        option type 'mac80211'
        option hwmode '11a'
        option path '1a143000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0'
        option cell_density '0'
        option txpower '26'
        option channel '100'
        option htmode 'HE160'
        option country 'GB'

If you don't want to/can't use DFS, try this

option txpower '20'
option channel '36'
85

Hey @daniel, as a sort of "side question", I basically just took the following steps:

#1 Updated this file to remove the "read-only" part for the "bl2" and "fip" partitions, and compiled the E8450 UBI images using the normal OpenWRT build process:

#2 Flashed the resulting 'sysupgrade' image on my device (which has already been converted to UBI)

#3 Copied the preloader and uboot files over to my device to /tmp/, and manually ran the following two sets of commands:

And that all seemed to succeed, and after rebooting the device it seemed like I had successfully updated the preloader / u-boot. I guess my primary question for you would be - how "safe" is the process I just followed? Like is that something I could (in theory) continue to do again in the future for later iterations of u-boot? Or is this a situation that's more like "You're lucky you didn't brick your device and I wouldn't suggest doing that again"?

86

Generally this is how it works.
To be more safe you should check the hash (eg. sha256sum) of the bl2 and bl3 images before and after writing them to flash. Make sure checksums match before you reboot and you are safe.

2 Likes
87

Hi. I just got my Linksys E8450 router today. Is there some information on the openwrt forums or github where I can come to know what is working and what is not for this router in the latest snapshot. Sorry to message in this thread since I couldn't see a relevant thread. Thanks.

1 Like
88

AFAIK there's no hardware lab for automated regression testing that would go through a predefined list of usage scenarios with the router, but it seems like most of the stuff is working now - what kind of stuff are you interested in?

89

Hi risk. Thanks for responding. I am an intermediate operwrt user. Earlier I was using Archer C7 v5 router for PPPOE, Wifi AP, SQM and firewall (for opening ports) through LuCI. I was hoping that similar features are stable in Linksys E8450 snapshot as well. Since I am an intermediate operwrt user, I would also prefer going back to stock firmware when something breaks. I read the forums and correct me if I am wrong, once you partition the ROM to UBI, the process to go back to stock is complicated. In Archer C7 you could just flash the stock firmware using TFTP. Thanks for the help. I have basic linux knowledge since I am using Raspberry Pi4 for NAS, FTP, torrenting, cloud storage, adblocker and vpn. Thanks in advance.

90

You might update topicstart hostpad link as hostapd is partly accepted https://patchwork.ozlabs.org/project/openwrt/list/?series=229531&archive=both&state=*

not able to find actual merge though...?

91
  • PPPOE- works
  • Wifi AP- works (minor issues on more exotic bands)
  • SQM - works with fq_codel, not so much with cake for some reason
  • firewall (for opening ports) through LuCI - works

You should also be able to set up adblocking and VPN on the router without issues.

92

Thanks for the update @andyrichardson . This gives me some confidence in installing openwrt. In case I want to revert back to stock, can we flash the stock firmware directly from LuCI?

93

@andyrichardson @alleyu2 - most switch chips can do PPPoE encap/decap in hardware. I think PPPoE on OpenWRT would work through CPU.

It's been a while since I had to use PPPoE, not sure how much CPU it needs, if not much perhaps that pair of Cortex A53 cores on MT7622 is enough?

94
  • SQM - works with fq_codel, not so much with cake for some reason

are you sure ? for rt3200 is better use fq codel ?

95

Don't mess with antennas if you don't understand them. There are lots of things to do wrong and the gain you get from external ones are not equal to better power/signal unless you use a very high quality one with proper design, placement and proper connections in relation to the correct amplifier and driver.

To get started more or less its the amplifier hitting its limits (hardware or more often artifically software wise) - newer chips come with newer standards and limitations in regards to transmission power e.g. in most countries using 5GHz on the upper channels allows for 1000mW while the lower channels only allow for 200mW and generally 2.4GHz is limited to 100mW. The only country/case I know still being an exception is the US and some of these older ones from china from Xiaomi - only before they migrated to a newer kernel (there may be others, documented in the Linux Kernel).

96

hi!

I'm trying to understand what is missing for this device to be included in 21.02, seeing both the availability of snapsnots and the inclusion of a list of other mt7622 targets (ie. ubnt unifi 6 lr) in the release.

(or /was missing/, I understand branching happens at some point)

I just happily used https://github.com/dangowrt/linksys-e8450-openwrt-installer/ and then went on to SNAPSHOT r16838-54cc1756e2. Thanks for making this work!

1 Like
97

What's missing for backport:
21.02 is based on Linux v5.4 while in snapshot at the point the device was added, mediatek/mt7622 was already on Linux v5.10. Hence all patches necessary for the SPI-NAND to work in one way or the other would have to be ported from v5.10 to v5.4 (ie. either BMT/BBT for non-UBI firmware and uImage.FIT parser for UBI firmware). To also have TF-A and U-Boot available for the UBI variant, those will have to be cherry-picked as well.
I'm not saying this is impossible, it's a day of work cherry-picking things in the right order from master branch into 21.02. The problem is that one got to either do a lot of fixing for patches which do not apply cleanly (and then need all that needs testing and maintenance in future) or cherry-picking very broadly which will result in more or less bumping 21.02 to the level of master...

In short: UniFi 6 LR is an easy target because it got SPI-NOR flash and there is not much to get wrong there. Linksys E8450/Belkin RT3200 use SPI-NAND flash, and that's much more tricky.

7 Likes
98

Hi all,

First of all, wow! The fact that I can install OpenWrt on a device that's barely been in market for a year (ish?)... props to everybody in this community who's made this possible.

I have a few questions which I hope isn't already addressed somewhere super obvious:

  1. non-UBI vs. UBI: apart from having LuCI pre-installed, what other practical advantages are there in installing OpenWrt in the UBI scheme (as documented in diogenes' Github page?)
  2. uninistalling in non-UBI: to "uninstall" OpenWrt and return to the OEM factory default installation (assuming a non-UBI installation,) I simply have to upload the vendor-supplied firmware file (currently "FW_E8450_1.0.01.101415_prod.img" for my linksys device) using the normal software update mechanism, for example in LuCI, correct?
  3. UBI installation risk: I see that installing OpenWrt in diogenes' "UBI method" involves taking a backup of the boot sector(s) early on in the setup process. They also recommend taking a backup of the entire flash (presumably via JTAG?) Assuming those steps are actually taken, is it fair to say that the riskiness of installing in the UBI scheme is roughly equivalent to the non-UBI method? Both methods involve inherent risks that can hopefully be mitigated by the recovery modes of each respective scheme, and worst case we have JTAG I suppose...
  4. Time to "non-beta" status: Am I correct in understanding that eventually this router software will be available in a non-snapshot release with LuCI pre-installed, etc? Any rough estimate on when this next release will be?

Thanks!

99

Hi Remi,

let me try to answer to some of your questions:

  1. non-UBI vs. UBI
    I should probably include this in the wiki, for now please take a look here:
    https://github.com/dangowrt/linksys-e8450-openwrt-installer/issues/9

  2. uninstalling in non-UBI
    Yes, you can just flash the vendor firmware binary using LuCI or sysupgrade.

  3. UBI installation risk
    Replacing the bootloader is always a bigger risk than just flashing a firmware, especially on a device with dual-boot. If it really goes completely wrong, you end up having to use JTAG for recovery.
    As the process is automated and well-proven by now, I believe it's safe. You just shouldn't trip over the power cord within the 80ms of actually critical write operation :wink:
    The main risk here is that you may have gotten a device where one or more erase-blocks in the very beginning of the SPI-NAND flash are broken. I did my best to make the installer also handle these cases properly (ie. relocate factory data, which has to be kept at known offset, in order to reverse/mitigate the effects of MediaTek's BMT which is used bu non-UBI OpenWrt as well as the stock firmware). I couldn't yet get hold of device having on of the first blocks broken, hence I had not chance to test this myself.
    The worst-case here is a device which comes up without a valid MAC address and missing WiFi calibration. In that case you can either try to resolve things manually using the backup of the flash or use that to revert to the stock firmware.
    If you really won the NAND-flash lottery and got a device with insanely broken NAND flash which yet somehow worked ok with stock firmware and ends up a brick after running the UBI installer: I'll instantly replace it for you sending the brick to me by mail.
    Backup of the entire flash: You can dump the flash by when already running non-UBI OpenWrt or by booting an OpenWrt initramfs image of the non-UBI variant, read everything into /tmp and then copy it from there with scp (or use LuCI backup function on all MTD partitions). The best way to boot into initramfs image is by using the serial console (if you want to grab the flash content before ever writing anything, which is a good idea).
    The installer also makes a backup of critical regions of the flash and stores it in a UBI volume boot_backup. This backup is primarily meant to allow you to revert back to stock firmware or post-mortem analysis in case the installer messed things up. It will not help much in terms of recovery case the device won't boot at all (which is unlikely).

  4. Time to "non-beta" status
    Yes, you got it right. The device will be supported officially by the next release. It will not be part of the already branched 21.02.
    We always wanted to release more often, and maybe this year we will make it to have another 21.10 or so release based on Linux v5.10. However, that'd be for the first time to have two releases within on year, so you shouldn't count on that. It can easily be many months later for random or no reasons at all.
    Up to then, I guess you will have to use another device or use snapshots -- which can easily come with LuCI as well and can be updated including the packages of your choice using auc or luci-app-attendedsysupgrade. Both variants come with (different) dual-boot schemes which allow you to recover easily in case something goes wrong later on.

9 Likes
100

the second release candidate is out now if never

101

Thanks so much for your help. I was able to get back to this today and stepping through your code was the ideal way to make sure everything was backed up before flashing the UBI build.

1 Like