Adding OpenWrt support for Xiaomi "Redmi Router AX6S"/"Xiaomi Router AX3200"

Wrong post again. Thanks for your work, but please dont mix router models :confused:

Does anybody know what connector the AX6s wall wart uses? They original ones look a bit dubious so I would like to replace them with mean well or similar...

4.0x1.7mm the wiki page claims.

3 Likes

There are also cheap adapters from more standard 5x2.1 or 5x2.5 barrel plug to 4x1.7.
I'm using one with extension cable and another power brick.

1 Like

That's precisely what I was going for

1 - Take a config backup
2 - Follow the instructions from danpawlik:

mount -o remount,ro /
mount -o remount,ro /overlay
cd /tmp
dd if=factory.bin bs=1M count=4 | mtd write - kernel
dd if=factory.bin bs=1M skip=4 | mtd -r write - ubi

with the last version of the factory image.
3 - If you restore a backup, you won't be able to apply sysupgrades anymore. To fix this, you need to run:
uci set system.@system[0].compat_version="2.0"
DO NOT run this command if you have not done step 2 as it would brick your device on the next sysupgrade.

1 Like

Hello there!

When a lightning stikes near your house and your trusty old router - Netgear WNDR3800 in my case - goes hairwire, you know a hardware upgrade is pending.

Xiaomi AX3200 on openwrt may be a router to fill the hole there the heart of a computer network used to be.

Though that is not clearly known are the misty rough edges around the AX3200 RB01 experience.

Can somebody please clarify,

  1. if it's possible to gain telnet or SSH access to the AX3200 via XMiR patcher alone (no netmode: 4, nor UART required)?

  2. is it possible to get away with mtd-style updates in case the router have troubles with sysupdates?

  3. if "Xiaomi AX3200 Production Date after 12/2023 with telnet disabled" is going to fail with sysupdates regardless of telnet being disabled or enabled during the update?

  4. in case the newer AX3200 fails with factory update, will UART be the only solution to the problem?

If you receive Internet via ethernet cable and you no longer want to change expensive routers and everything connected to them with cables after lightning, then buy a cheap pair of media converters and place them between your provider cable and the router, connecting 0.5 meters of optical cable. Lightning will not pass through it and at most one media converter module will burn out, costing about 5-8 dollars. By purchasing exactly the same pair in this case and swapping the modules, you will get a working system + another spare module and all this will cost less than the price of the router and especially the peripherals connected to it.

1 Like
  1. yes XMiR work on my AX3200 12/2023
  2. not clear about this question, sysupdate fail, it seem like we need to modify u-boot , wait for someone test & confirm
  3. yes sysupgrade make my device soft-brick

Grounding an internet connection cable had not been on a list of concerns up until suddenly it became one... :cloud_with_lightning:

Thanks for the heads up! :ok_hand:

About the 2nd point.
It's about Memory Technology Device utility.

There's an entry in the wiki
under the Upgrading OpenWrt
which says

mtd

If sysupgrade does not support this router, use mtd.

  • Login as root via SSH on 192.168.1.1, then enter the following commands:

cd /tmp wget http://downloads.openwrt.org/snapshots/trunk/XXX/xxx.abc mtd write /tmp/xxx.abc linux && reboot

And I was wondering if the router can be updated like so on a regular basis in the absence of a u-boot fix. (without much bricking that is :brick: )

hope this help to get U-Boot version from console

# grep 2022 /dev/mtd3
U-Boot 2014.04-rc1 (May 20 2022 - 10:19:21)

I have two of these, bought them on Amazon (Europe). One router, one accesspoint. They work fine and sysupgrade also works (upgraded to 23.05.04 today), BUT ... both of them sometimes brick after a reboot. Happened with 23.05.03, and today with 23.05.04. The right light flashes once, then the small light on the left flashes very briefly. This goes on forever and I cannot get the soft-reset to work.

Debricking works with tftp, but with every reboot I keep my fingers crossed. It's not a lot of work to restore them, but it is cumbersome. Especially when the router bricks.

If I can provide any info to prevent this for other people, I'd be happy to collect some data.

1 Like

How does your flag_xxxx and boot_xxxx u-boot environment variables look before and after reboot?

Mines are:

root@AX3200-B24 ~ # fw_printenv | grep -e ^flag -e ^boot
boot_auto=bootxq
boot_fw0=run boot_rd_img;bootm
boot_fw1=run boot_rd_img2;bootm
boot_rd_img=nand read ${loadaddr} 0x2C0000 2000;image_blks 2048;nand read ${loadaddr} 0x2C0000 ${img_align_size}
boot_rd_img2=nand read ${loadaddr} 0x20C0000 2000;image_blks 2048;nand read ${loadaddr} 0x20C0000 ${img_align_size}
boot_wait=on
bootargs=console=ttyS0,115200n1 loglevel=8 swiotlb=512 rootfstype=squashfs firmware=0 uart_en=1
bootcmd=bootxq
bootdelay=5
bootmenu_0=1. Load firmware 0 and bootup.=run boot_fw0
bootmenu_1=2. Load firmware 1 and bootup.=run boot_fw1
bootmenu_2=3. Load firmware selected by Xiaoqiang and bootup.=run boot_auto
bootmenu_delay=30
flag_boot_rootfs=0
flag_boot_success=1
flag_boot_type=2
flag_flash_permission=1
flag_last_success=1
flag_ota_reboot=0
flag_show_upgrade_info=1
flag_try_sys1_failed=34
flag_try_sys2_failed=6
flag_upgrade_push=0

As you can see, my try_sys2 is sticked at 6 and the try_sys1 is counting.

While at it, prepare the /etc/rc.local file with resetting those try_sys values:

root@AX3200-B24 ~ # grep fw_setenv /etc/rc.local 
#fw_setenv flag_try_sys1_failed 0
#fw_setenv flag_try_sys2_failed 0

(Yeah, they are commented out for now ...)

1 Like

My accespoint:

from:
boot_auto=bootxq
boot_fw0=run boot_rd_img;bootm
boot_fw1=run boot_rd_img2;bootm
boot_rd_img=nand read ${loadaddr} 0x2C0000 2000;image_blks 2048;nand read ${loadaddr} 0x2C0000 ${img_align_size}
boot_rd_img2=nand read ${loadaddr} 0x20C0000 2000;image_blks 2048;nand read ${loadaddr} 0x20C0000 ${img_align_size}
boot_wait=on
bootargs=console=ttyS0,115200n1 loglevel=8 swiotlb=512 rootfstype=squashfs firmware=0 uart_en=1
bootcmd=bootxq
bootdelay=3
bootmenu_0=1. Load firmware 0 and bootup.=run boot_fw0
bootmenu_1=2. Load firmware 1 and bootup.=run boot_fw1
bootmenu_2=3. Load firmware selected by Xiaoqiang and bootup.=run boot_auto
bootmenu_delay=5
flag_boot_rootfs=0
flag_boot_success=1
flag_boot_type=2
flag_last_success=0
flag_ota_reboot=0
flag_try_sys1_failed=2
flag_try_sys2_failed=0
to:
flag_try_sys1_failed=3
flag_try_sys2_failed=0

My router:

from:
boot_auto=bootxq
boot_fw0=run boot_rd_img;bootm
boot_fw1=run boot_rd_img;bootm
boot_rd_img=nand read ${loadaddr} 0x2C0000 2000;image_blks 2048;nand read ${loadaddr} 0x2C0000 ${img_align_size}
boot_rd_img2=nand read ${loadaddr} 0x20C0000 2000;image_blks 2048;nand read ${loadaddr} 0x20C0000 ${img_align_size}
boot_wait=on
bootargs=console=ttyS0,115200n1 loglevel=8 swiotlb=512 rootfstype=squashfs firmware=1 uart_en=1
bootcmd=bootxq
bootdelay=3
bootmenu_0=1. Load firmware 0 and bootup.=run boot_fw0
bootmenu_1=2. Load firmware 1 and bootup.=run boot_fw1
bootmenu_2=3. Load firmware selected by Xiaoqiang and bootup.=run boot_auto
bootmenu_delay=5
flag_boot_rootfs=1
flag_boot_success=1
flag_boot_type=2
flag_last_success=0
flag_try_sys1_failed=6
flag_try_sys2_failed=8
to:

I can't reboot the router now, I need it for work, but I'll update the post tonight,

I've had my router bricked at random, both of them pretty early after installing OpenWrt, the've been working fine for months actually and yesterday my accesspoint died on me.

@xabolcs , sorry I misunderstood you, I thought you only needed the counters.

1 Like

You didn't included all the flags I asked, but at least, the key ones! :+1:

Just add (and uncomment) those fw_setenv commands to /etc/rc.local!

1 Like

No problem! The difference of the try_sys counters were the most valuable! :slightly_smiling_face:

On your access point you need to update the boot_fw1 to the same as boot_fw0 - to boot from the very same address, the address of the first slot!

And as I wrote earlier, just add those fw_setenv commands to that startup file to reset those counters to 0 at every boot!

2 Likes

I ran into exactly the same problem, and debricked it once, then ran into it again. Thanks for your post, if it hadn't been so recent I wouldn't have found it out. I think this should be more clearly stated in the installation process in the Wiki as it is just mentioned with a hyperlink...

Is this what was causing the brick? It trying to reboot into a faulty bootloader or something?

I ran fw_setenv boot_fw1 'run boot_rd_img;bootm', and now both entries read

boot_fw0=run boot_rd_img;bootm
boot_fw1=run boot_rd_img;bootm

So I should be okay now

1 Like

The softbrick is caused by the counting try_sys flag. After it reaches 6 then the bootloader switches slots.
Therefore the next boot tries from booting from the overwritten second slot.

So one solution is to reset those try_sys counters to 0.
And an other solution is to use the very same boot command for both slot, like you did now!

I think it should solve your soft bricking misery. But you will know it anyway. :wink:

2 Likes