What exactly is wrong? I see nothing wrong with the data you posted (other than the entries in fw_env.config).
Did you flash with a ubootmod sysupgrade after flashing OpenWrt U-Boot?
it shows the environment from sthe stock bootloader:
CountryCode=CN
Router_unconfigured=0
SN=xxxxx/F4QSxxxxx
arch=arm
baudrate=115200
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 mtd=ubi uart_en=1
bootcmd=bootxq
bootdelay=2
bootmenu_0=Startup system (Default)=bootxq
bootmenu_1=Startup firmware0=bootxq 0
bootmenu_2=Startup firmware1=bootxq 1
bootmenu_3=Upgrade firmware=mtkupgrade fw
bootmenu_4=Upgrade ATF BL2=mtkupgrade bl2
bootmenu_5=Upgrade ATF FIP=mtkupgrade fip
bootmenu_6=Upgrade single image=mtkupgrade simg
......
yes:
ubus call system board
{
"kernel": "6.6.54",
"hostname": "sz2",
"system": "ARMv8 Processor rev 4",
"model": "Xiaomi Mi Router AX3000T (OpenWrt U-Boot layout)",
"board_name": "xiaomi,mi-router-ax3000t-ubootmod",
"rootfs_type": "squashfs",
"release": {
"distribution": "OpenWrt",
"version": "SNAPSHOT",
"revision": "r27677-3a168e3595",
"target": "mediatek/filogic",
"description": "OpenWrt SNAPSHOT r27677-3a168e3595"
}
}
Weird that it didn't generate a correct fw_env.config for you. Did you use the -n option in sysupgrade?
Try setting fw_env.config to:
/dev/ubi0_0 0x0 0x1f000 0x1f000 1
/dev/ubi0_1 0x0 0x1f000 0x1f000 1
1 Like
Thank you, this looks good!
but why did this happen ( I'm sure with the "-n" )?
No idea. I compared your UBI volumes to mine, and they're exactly the same and this is the fw_env.config generated for me (I am a few commits behind, on kernel 6.6.52).
offset: 0x0, env and sector sizes: 0x1f000 (124 KiB), number of sectors: 1
EDIT: /etc/fw_env.config is in the list of preserved files on upgrade. If you used LuCI to flash, the file was preserved.
Yes you are right, just checked my old backup-files.
This was the reason!
Can you give me the content of fw_sys.config because it was also overwritten?
Thank you for your help!
I don't have it.
root@router1:~# find / -name 'fw_sys.config'
root@router1:~# find / -name 'fw_sys*'
root@router1:~#
1 Like
I created a separate topic to hopefully get traction on this: Add AN8855 switch support for Xiaomi AX3000T
3 Likes
Some more testing and measuring.
Redmi Note 11 with hardware flow offloading enabled and WED enabled: sub-100 mbps (often between 30-50 mbps).
So I edited /usr/share/ucode/fw4.uc in order for hardware flow offloading to not add the WiFi interfaces into the flowtable.
devices = { br-lan, wan }
flags offload
Tested on another phone, a Redmi Note 12, can consistently reach 300-320 mbps in front of the router.
However, wired speedtest at ~900 mbps is now using ~50% of the CPU.
devices = { lan2, lan3, lan4, wan }
flags offload
and
devices = { br-lan, lan2, lan3, lan4, wan }
flags offload
Phone is back to sub-100 mbps, but wired speedtest at ~900 mbps is now back to 1-2% CPU usage.
Hello everyone, is there any information available about the U-Boot corresponding to the Xiaomi AX3000T firmware version 1.0.84? I apologize, but I have one of these machines and would appreciate any relevant adaptation information. 
most devices don't ship (nor update) the boot loader when they update the firmware.
2 Likes
Short answer to your question is, you can’t run OpenWrt on those versions because they use an unsupported switch (an8855) which isn’t supported by upstream Linux kernel yet. Until that happens, the device is useless for OpenWrt.
1 Like
People could build OpenWRT-21 using the mtk patches.
1 Like
assuming a vanilla 5.4 kernel can be patched, and you don't have to use the full SDK.
1 Like
why not? there are patches for mt76, mac80211, hostapd etc
1 Like
Yes, but what's the target they're supposed to patch?
Vanilla Linux kernel, or some butchered up MT kernel ?
It's just vanilla kernel + openwrt patches + mtk patches
mtk sdk + mac80211/mt76 is very close to openwrt-21
1 Like
I'm having IPv6 issue after upgrading from 23.05.4 to 23.05.5. Unable to get the /48 prefix. I had similar issue previously when using snapshot back in aug, I then got IPv6 working after switching to 23.05.4 and now the issue is back. Now I only got /64 global unicast without ipv6 prefix.
Edit: I set reqprefix to 48, after I restart wan6, I can see /48 for a second before it's gone.
Edit: ran tcpdump, router not receiving reply for dhcp6 solicit.
Edit: IPv6 is now working after switching off both router and modem for 10 minutes as suggested by this post to release some sort of MAC address lock.
In my case, it's my ISP's fault: Odhcp6c issue with my ISP's configuration - #5 by Cthulhu88
I've only noticed it after switching my routers because my prefixes changed after that (different WAN port MAC address, cable ISP uses DHCP and DHCPv6). The previous prefixes were routing correctly; the constant RA flooding with different parameters had me patch odhcp6c to avoid saturating my single-CPU device.
Now I've both RA flooding and RAs with prefixes that won't route at my edge gateway, so now I just drop WAN-side RAs in the firewall and rely solely on explicit solicitations for an IPv6 address and a /64 prefix.
It's quite amazing how badly ISPs (mostly the big ones) understand and configure IPv6.