uninstalling in non-UBI
Yes, you can just flash the vendor firmware binary using LuCI or sysupgrade.
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
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).
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.
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.
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.
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.
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 .
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.
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.
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: 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, 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:
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).
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):
Fair warning, people might need a reset, especially if upgrading from the version hosted on GitHub - I've set my router up this morning from scratch (still trying to figure out the best config, so daily resets it is), and did an attended sysupgrade after the setup. Reboot, and bam, I had 5 separate wireless radios, with none of the interfaces working. Yes, I am aware of the dangers of using SNAPSHOT builds, so it wasn't unexpected, this comment is just a heads-up for people in case their WiFi is suddenly unavailable.
I'm getting pretty solid speeds with AX, 1.1Gbps uplink, and on my HyperOptic 500Mbit connection, a stable 650/400Mbps is achievable on my Galaxy S21 Ultra. Quite happy with it. And yes, I know my achieved top speed is higher than the advertised bandwidth, HyperOptic is like that - max speed tends to be 20-30% higher than what the package officially includes. I was getting 300-320Mbps on the previous 250Mbps package.
Yes i had 4 radios and none working, working fine after a reset.
Luci also has the option to set up an ipv6 relay now under the ipv6 client interface menu, which makes things easier for people on native ipv6
My internet is ipv6 ipoe (ip over ethernet), there is no login required just plug and play, but the router needs to act as a relay rather than a server. untill the recent update luci didnt have the options i needed without some workarounds. ipv4 internet for me is tunneled through ipv6
.
Flashing a recent OpenWrt snapshot while keeping the vendor flash layout (a.k.a. non-UBI) is no longer possible since