Belkin RT3200/Linksys E8450 WiFi AX discussion

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

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

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).

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

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

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!

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

the second release candidate is out now if never

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

you will save what ? the original firmware ?

on belkin i just flashed recovery installer and openwrt is appair , is right ?

then i flash the snapshot via susypgrade.itb

thanks for the reponse

Hey Daniel- thanks for your earlier response.

Does anybody have any pointers on how to disassemble this thing!? I see there's space to slide in a knife etc between the rear panel containing all of the wired inputs and the outer shell of the router body (I can also see there are at least two tabs that I can gently pry in,) but I can't seem to get anything moving beyond that.

There are 4 screws behind the bottom label. Then the lower part of the stand comes off after 2 more screws one may easily slide that whole back part with them connectors out like it is on sort of a plastic tray.

Please find my high-res teardown pictures here.

5 Likes

I wasn't aware of your PR. I've opened one waiting for a reviewer at https://github.com/openwrt/luci/pull/5070 which in addition to yours also enables rate information parsing. Feedback is very appreciated.

1 Like

Thanks @sumo for the pointers. Shoulda figured there were hidden screws under the label.

Ha, now get a load of this- with access to the serial port I naively tried wire-wrapping the tx/rx/GND leads to the DB9 pins of a RS-232/USB converter that was in turn connected to my PC. When nothing came out of the terminal after turning on the router, I dug into the openwrt wiki a bit more and realized that 1) there was a difference between RS-232 serial ports and the TTL serial ports used in this router (+3.3V volt if we assume they're using the same scheme as outlined in the WRT devices posted here) and 2) I may have fried the TTL serial port with the 12V or whatever the RS-232 was pumping in!?!

If this is any consolation (mostly to me and my poor router,) I don't think I typed anything into the serial terminal on my PC. Is there any chance of this thing working if I were to properly procure a TTL-to-USB cable, for example? Or is the serial port definitely fried (which won't be the end of the world either, this just means that I won't be able to take a backup of the flash prior to modifying it with a OpenWrt image. Plus the router is still properly booting up and the http:// admin interface is still responsive.)

Figured someone here with prior experience with Linksys devices and their serial interfaces might be able to chime in. As always thanks in advance for any input.

Likely but hard to say. Maybe at least the routers TX is still fine. I have no prior experience with any MediaTek chips but I fried various other electronics in my career. Please note that most routers or embedded boards in general only have TTL serial aka UART ports. While 3.3 volt is still the most common voltage level, later ones (e.g. Qualcomm IPQ807x) even have 1.8 volt only (and are likely even more sensitive and such adapters even somewhat hard to get).

Anyway, if you PM me your address I might send you a spare tested USB-to-serial adapter even with the proper JST PH 6 pin connector. So you may test whether or not it really fried it :stuck_out_tongue_winking_eye:.

Based on previous feedback of others trying the same with this router, the device has likely ceased its existence completely. The voltage is fed directly into the SOC, without additional safeguards or filtering, anything above the expected voltage will fry it basically instantly.

3 Likes

Hello. I'm again having problems with 2.4Ghz WiFi: my phone (galaxy s10e, and I've now noticed that the same happens with my tablet, and also all of the IoT devices seem to be avoiding it, so it must be completely broken) would not connect to the 2.4Ghz WiFi (I just see it connecting/disconnecting with no errors in settings debug menu) and if it roams to it from 5Ghz/other routers, it manages to connect but I seem to have no network. What can I do to diagnose it and help fix it before it goes away and I have to wait another month for it to may be randmoly reappear? I'm running OpenWrt SNAPSHOT r16844-296aa0781b / LuCI Master git-21.147.31971-74be304 (I think I've updated about 1-2 weeks ago) and my uptime is 2 days. Routing and 5Ghz seem to work perfectly and at least my phone connects and works fine with it.

It worked with 3.3V for me, 115200 N81.

1 Like

hello everybody good news for this router

AX in luci available

4 Likes

Hi. I am planning to install the openwrt snapshot for this device. I am a novice operwrt user and hence would like to know the steps to go back to stock firmware in case something goes wrong. Can someone guide me to the steps required to go back to stock firmware? Thanks.

Edit: :warning: Flashing a recent OpenWrt snapshot while keeping the vendor flash layout (a.k.a. non-UBI) is no longer possible since 050621aa017273086d46ccf22dfb6942a367e049 / 2021-08-27 :warning:, see: this post
i.e. the below instructions are no longer valid since 2021-08-27

Original instructions (outdated)

The default storage provides the "safety" of dual partitions:

  1. You can start by flashing the regular "non-UBI" version https://downloads.openwrt.org/snapshots/targets/mediatek/mt7622/openwrt-mediatek-mt7622-linksys_e8450-squashfs-sysupgrade.bin. Just use the regular Firmware upgrade feature as provided by the vendor but instead of providing a vendor firmware, provide the OpenWrt one.
  2. Configure and experiment with OpenWrt (note that if you are novice with OpenWrt, snapshots do not have any web UI so you need to use SSH to install LuCI).
  3. If you are done with OpenWrt, or if you encounter an issue, you can use the 3x power off cycle to trigger booting back into the vendor firmware from the alternate partition, where you can flash the vendor firmware again to overwrite the OpenWrt partition (i.e. make sure that both partitions have the vendor firmware) if you really want to go back to stock

Note that if you are "happy" with OpenWrt, the "UBI" layout may offer more convenience (except stock restoration is more tricky):

4 Likes