OpenWrt support for Xiaomi AX3000T

For Developers
2601

oh, thank you for share.

2602

I just acquired three new units of the AX3000T in a local sale.

I asked the seller to send the RB23 variant if its in his sale's stock (he said he had a mixed batch of RB03 and RB23).

Fingers crossed for MediaTek switches I guess. I'll let you which switch RB23 is shipping.

2603

Is there a pr to fix this issue?

2604

As far as I know, No.

We had only intention (but I have never seen a PR in the official OpenWrt repository):

2 Likes
2605

I also didn't find opened issue for AX3000t. I've opened a PR:

3 Likes
2606

Yeah defently issues with the rc5 here.dnsmasq gets a sigtem and restarts for some reason. I did not see this happen on rc4.

2607

Could you please check if RC5 is properly using the right package feeds?

I've seen reports of it using RC2 feeds.

2608

How I check for that? Looking at the manifest after compiling, the packages on rc5 seems higher or same as rc4

2609

24.10 still uses opkg, so the command should be cat /etc/opkg/distfeeds.conf, check the output.

1 Like
2610

Checked it, it's using rc5 packages.

Which doesn't make a diff cause I haven't installed any packages yes from ook.

Only what I needed I compiled in the image, which is luci, ddns and wireguard.

2611

Hello.
I tried the instructions to get ssh access, but I get
{"code":1541}{"code":1541}{"code":1541}{"code":1541}{"code”:1541}
When I try to ssh to it, I get
Unable to negotiate with 192.168.31.1 port 22: no matching host key type found. Their offer: ssh-rsa
Any ideas?

2613

Congrats, all 5 curls from Wiki were executed correctly on your AX3000T.

The reason is explained here: XiaoMI AX3600 not able to connect to SSH :
you need to disable the deprecated ssh-rsa algorithm offered by your router's SSH server. The ssh-rsa algorithm has been deprecated due to security concerns, and your modern ssh client won't accept it.

Solution: try

  • ssh -o StrictHostKeyChecking=no -o HostKeyAlgorithms=+ssh-rsa -o PubkeyAcceptedAlgorithms=+ssh-rsa -v root@192.168.31.1
    or just use PuTTY if you are using a Windows PC.
1 Like
2614

I received 3 units of RB23 with FW 1.0.31.

My steps to install OpenWrt:
  • Updated to FW 1.0.49
  • Used xmir-patcher to get SSH access.
  • Run dmesg to make note of NAND and Switch versions

dmesg | grep "NAND" dmesg | grep "MT7531" dmesg | grep "AN8855"

All 3 units have ESMT nand and MT7531 switch as expected.

  • Tried to backup partitions using xmir-patcher, I got a SSH timeout error (in all devices).
  • Used putty ssh connection to backup partitions.

nanddump -f /tmp/BL2.bin /dev/mtd1 nanddump -f /tmp/Nvram.bin /dev/mtd2 nanddump -f /tmp/Bdata.bin /dev/mtd3 nanddump -f /tmp/Factory.bin /dev/mtd4 nanddump -f /tmp/FIP.bin /dev/mtd5 nanddump -f /tmp/ubi.bin /dev/mtd8 nanddump -f /tmp/KF.bin /dev/mtd12

  • Used WinSCP to download the backup files from /tmp folder to my Windows PC.

  • Flashed openwrt-23.05.5-mediatek-filogic-xiaomi_mi-router-ax3000t-initramfs-factory.ubi using xmir-patcher (file was placed in "xmir-patcher-main\firmware" folder).

  • Device restarted, OpenWrt was running, then I performed a sysupgrade.

sysupgrade -n /tmp/openwrt-mediatek-filogic-xiaomi_mi-router-ax3000t-squashfs-sysupgrade.bin
  • Device restarted, OpenWrt was running.

Now this is where things went unexpected. After the first reboot after flashing openwrt-mediatek-filogic-xiaomi_mi-router-ax3000t-squashfs-sysupgrade.bin the device did not boot anymore.

  • MiWiFi Router Repair Tool did not work at first (see investigation below why)
  • Connected the device to UART
  • Device was stuck in bootloop due kernel panic "Unable to mount root fs on unknown-block(0,0)"
  • Note: I was able to replicate the bootloop issue in two devices, also did tests using xmir-patcher, sysupgrade from OpenWrt ssh and LuCi to make sure it was not a bad flash.
  • Used "Load Image" and used MiWiFi repair tool to load openwrt-mediatek-filogic-xiaomi_mi-router-ax3000t-initramfs-kernel.bin and unbrick the device.
Investigation of MiWiFi Router Repair Tool not working

During my investigation I found out why MiWiFi Router Repair Tool may fail to work in certain RB23 units.

The default IP and server IP for stock bootloader was this:

ipaddr=192.168.10.1 serverip=192.168.10.100

The IP address / server IP that MiWiFi Router Repair Tool will use is:

ipaddr=192.168.31.101 serverip=192.168.31.100

The solution was pretty simple, the stock bootloader allows to change this when loading an image. I just changed the client IP and server IP to 192.168.31.x subnet and I was able to load openwrt-mediatek-filogic-xiaomi_mi-router-ax3000t-initramfs-kernel.bin using the MiWiFi Router Repair Tool and unbrick the device.

I'm currently testing a workaround in the 3rd device to avoid UART usage in case of soft-brick, if successful I'll share the steps needed to make sure MiWiFi Router Repair Tool will work in your device.

2 Likes
2615

where are the full logs?

2616

I think this is exactly what's happening to mine. Although I used a 24.10 RC5's .ubi and sysupgrade file. I was able to configure OpenWrt at first but when I first reboot it it started acting up. It seems like it won't fully boot. Orange light slowly turning off and on. Won't give my computer an IP.

Pressing the reset button with a sim injector fixed the boot loop but still won't give me an IP. Can't open LuCi and SSH

Was able to revert back to stock firmware 1.0.49 via TinyPXE

Can you elaborate on this "I just changed the client IP and server IP to 192.168.31.x subnet"? Is it simply giving my computer a static ip? Also noticed you used a different .bin file

I will try remittor's images when I get home

Thanks in advance

2617

These are the default bootloader values (confirmed in all three RB23 devices with factory 1.0.31 FW).

loadaddr=0x46000000 serverip=192.168.10.100 ipaddr=192.168.10.1 netmask=does not exist bootfile=does not exist

Before flashing OpenWrt you need to run these commands in SSH (nvram values for MiWiFi Router Repair Tool to work):

nvram set loadaddr=loadaddr=0x46000000 nvram set serverip=192.168.31.100 nvram set ipaddr=192.168.31.101 nvram set netmask=255.255.255.0 nvram set bootfile=miwifi_rd23_firmware_153e1_1.0.49_INT.bin

This allowed me to recover my device with the stock firmware using MiWiFi Router Repair Tool without using UART.

serverip is your computer network interface IP.
ipaddr is the IP the router will request to the TFTP server.
bootfile is the file the device will look in the TFTP server.

If you're already stuck in the bootloop and did not touch the default settings you can try another TFTP software with same values as the stock bootloader

serverip=192.168.10.100
ipaddr=192.168.10.1

There is no guarantee these will work as there is no default bootfile name.

1 Like
2618

After some digging, I found out why the router was throttling.

I live in Costa Rica, so I was setting the Country Code to CR - Costa Rica in the Wireless settings of my 5 GHz radio. That setting for some reason makes the router to only use 20 MHz bandwidth instead of the usual 80 MHz, which absolutely throttles the speed.

I set the Country Code now to US - United States and it now uses the 80 MHz.

I wonder why that specific setting creates such behavior. It completely overrides the Operating frequency settings, which I had in 80 MHz, and it still only offered 20 MHz. My guess is that this may be a bug and is not intended. Thankfully I had WiFi Analyzer on my phone and I was able to spot it.

1 Like
2619

Unfortunately I did not save the full logs, but I saw some users with the same error in this topic.

I'm trying to replicate but after recovering the device with miwifi repair tool it is not repeating the issue.

At least (apparently) I found out why some devices fail to recover using miwifi repair tool.

@alexq I think we should add this to the wiki just as safeguard/good measure.

Commands to run before flashing

nvram set loadaddr=loadaddr=0x46000000 nvram set serverip=192.168.31.100 nvram set ipaddr=192.168.31.101 nvram set netmask=255.255.255.0 nvram set bootfile=miwifi_rd23_firmware_153e1_1.0.49_INT.bin or the filename of your stock firmware

Can anyone with RB03 running OpenWrt run these and post the output?

fw_printenv loadaddr fw_printenv serverip fw_printenv ipaddr fw_printenv netmask fw_printenv bootfile

1 Like
2620

Mine has a similar issue during installation. Here's my experience installing OpenWrt 24.10.0-rc5 to my router (RD23 / Winbond NAND / No AN8855):

After installing both initramfs-factory.ubi and sysupgrade.bin, the device won't boot after a hard reset (remove power and the plug it back in) if I don't use the script detailed in the Basic Configuration section of the wiki, so I had to restore to the stock firmware that time.

After that, I reinstalled OpenWrt and used the script to avoid the issue. But I noticed that, if you hard reset the device once, it wipes any configuration you may have done to the router. If you only soft-reset (through LuCI or ssh), this does not happen. It has to be a full power off.

After the full reset, the router takes way longer to boot (the LED light flashes orange every 4~5 seconds), but it eventually boots. But that's it. After that, configurations are saved normally, even after hard reboots, and it boots at a "normal" speed. Though, I haven't tried hard rebooting it more than 6 times, to see if it truly keeps the configuration.

1 Like
2621

If your device is taking a long time to boot, it most likely is trying to boot from sys2, I saw this sometimes in UART log.

When flag_try_sys2_failed is lower than 6, it tries to boot from the wrong partition until it reaches 6, after that it will boot from sys1 (correct partition).

2 Likes