Adding OpenWrt support for Xiaomi AX3600

Thanks @OneB1t for your explanation!
The Chinese rom was based in Chaos Calmer, so for this reason I thought that your screen captures that show a more up to date version were from a heavy modified Chinese custom firmware that had the problem. But then, if I have understood:

  • The latest official firmware is based on 18.06 and if we ssh it, we have the problem of /tmp (as expected).
  • The Chinese custom rom has a "new" version based on this latest official version and is fully working, with the changes in the config specified by you.

Is that ok? If true, it will be great a step by step tutorial about how to install this Chinese custom rom, and modify it. I think is the best we have at this moment, the stock UI of the router is very, very limited.

This is an incredible step forward that you made ! :slight_smile:

So if I truly understand, you pick up the official Chinese firmware and do some modifications to have a "clone" of OpenWrt ?

Anyway, thank you so much for your help in the community, I also hope one day we will have a pure OpenWrt build from source.

1 Like

So AX3600 woriks with plain QSDK11.2/11.3, but devs are having trouble merging QSDK into openwrt.

1 Like

The builds he's using are based off Qualcomm source which in turn Xiaomi base their builds off.

The latest build he's using is just based off a more recent Qualcomm source I believe.

And all this is done by some unknown person that doesn't share their modified code if there is any.

1 Like

Yes, I understand the risks and the problems. But some of us may prefer this before the original firmware if it is stable. I have two routers, I can install it in one for some time to check it.


Don't get me wrong, I would also prefer a Qualcomm source based vanilla build that permits a wider configuration.


@efsg seeing your comment, it seems you are part of this custom firmware? If yes, other projects that work with similar licenses, release the patches of the code, not the total code itself. It seems in this way they have no problem with the license, but people can check the changes and, if they have access to the Qualcomm source, build and compile it.

1 Like

look here

Could you please build and share kmod-* packages? kmod-fs-cifs would be, for instance, particularly useful.

1 Like

@efsg Now that with your image and some changes in the opkg configuration seems to work everything, could you post a "final" image with all this changes ready to be used? With some step by step installation instructions, please.

If this is not possible @OneB1t can you post all the steps to get to this "final" version? I've tried to follow you in the thread but there are things that I don't understand so I don't want to start until I'm sure that I will be able to do all of them.

Thanks to both in advance!


@efs, @OneB1t
Yeah. I step-by-step installation instruction would be nice.

For example: I need more dyndns provider as defined in the original firmware (namecheap) and i'm ready to test an alpha/beta version of your image.

Thank you!

If you are building from the QSDK source (which is publicly available), which part of the code is under NDA? Firmwares and microcodes are binary blobs, so not sure what can it be. Now that I am thinking about it, where is the GPL source which should be published by Xiaomi?


Guys, you cant freely distribute the SDK source as QSDK is just a part of it.
There are proprietary packages as well as firmware blobs that don't have a license allowing their distribution.

So, using "QSDK" is not an option and this thread is again full of QSDK hackery instead of upstream OpenWrt


This is true. We must let this thread clean for pure OpenWRT development.

Maybe we can create another thread with the QSDK variant and continue there?


qca-wifi, hyfi and etc

Xiaomi AX3600 on OpenWRT should without all that proprietary junk would be best >.>

1 Like

That is for sure, but without help, there is no way that I can do it.

1 Like

What kind of help are you talking about?

@efsg I have seen the instructions in the original post of @OneB1t, so I have tried to test the firmware in one of my routers. All went fine, but the latest command, the sysupgrade, gives this error:

# sysupgrade openwrt_ipq807x_generic_xiaomi_ax3600_squashfs_nand_sysupgra.bin
Device xiaomi,ax3600 not supported by this image
Suppported devices: ap-ac04
Image check failed

Do you know what can be the problem?

I've been incredibly busy with work lately, and I'm also in the middle of interviews for a new job, so I had to take a break from this for a while. Also ran out of ideas, but I've been back at it since a few days ago.
No, I didn't find a Bus Pirate yet, I'll be buying the Glasgow tool, but it's gonna take a while until they ship it..

Thanks a lot to @efsg and @OneB1t - I've replicated your results, great work guys!

Now on to my findings, I spent the last 2 days (on and off) working with these QSDK builds and debugging them. My ultimate goal is to get WireGuard up and running, since the main reason why I even bought this shady router from China a year ago was to get blazing fast hardware for WireGuard on OpenWRT (and Wi-Fi 6!).

The builds are just QSDK with a few relatively minor changes (Chinese language, some custom packages - mainly DDNS, LuCI themes etc.). The following things don't work: the IoT radio (PCI issues?) doesn't appear at all, and WiFi doesn't have WPA3 support, but 802.11ax is enabled by default.
I was able to track down the exact QSDK release that efsg used: AU_LINUX_QSDK_FIG_TARGET_ALL. from

Just follow the official Qualcomm build instructions from, add any custom packages you might need (I added the latest WireGuard and its tools), and also change the kernel version to 5.4.89 in qsdk/include/ Your build might finish or not, mine failed at some point, but the WireGuard packages and kernel module were built successfully, and I just scp'd them to the router and installed with opkg.

The following packages are Qualcomm proprietary and included in efsg's binary:

kmod-qca-hyfi-bridge - 5.4.89+g9f77ad1-1
kmod-qca-mcs - 5.4.89+g31b5c5b-1
kmod-qca-nss-cfi-cryptoapi - 5.4.89+g4e363d5-2
kmod-qca-nss-crypto - 5.4.89+g9efc908-1
kmod-qca-nss-dp - 5.4.89+gd861db2-1
kmod-qca-nss-drv - 5.4.89+g77b0894-2
kmod-qca-nss-drv-bridge-mgr - 5.4.89+g6dd2ede-2
kmod-qca-nss-drv-gre - 5.4.89+g6dd2ede-2
kmod-qca-nss-drv-ipsecmgr - 5.4.89+g6dd2ede-2
kmod-qca-nss-drv-l2tpv2 - 5.4.89+g6dd2ede-2
kmod-qca-nss-drv-lag-mgr - 5.4.89+g6dd2ede-2
kmod-qca-nss-drv-map-t - 5.4.89+g6dd2ede-2
kmod-qca-nss-drv-match - 5.4.89+g6dd2ede-2
kmod-qca-nss-drv-mirror - 5.4.89+g6dd2ede-2
kmod-qca-nss-drv-netlink - 5.4.89+g6dd2ede-2
kmod-qca-nss-drv-ovpn-mgr - 5.4.89+g6dd2ede-2
kmod-qca-nss-drv-pppoe - 5.4.89+g6dd2ede-2
kmod-qca-nss-drv-pptp - 5.4.89+g6dd2ede-2
kmod-qca-nss-drv-qdisc - 5.4.89+g6dd2ede-2
kmod-qca-nss-drv-tun6rd - 5.4.89+g6dd2ede-2
kmod-qca-nss-drv-tunipip6 - 5.4.89+g6dd2ede-2
kmod-qca-nss-drv-vlan-mgr - 5.4.89+g6dd2ede-2
kmod-qca-nss-drv-vxlanmgr - 5.4.89+g6dd2ede-2
kmod-qca-nss-macsec - 5.4.89+g8d2b757-1
kmod-qca-ovsmgr - 5.4.89+gb503197-2
kmod-qca-ssdk-nohnat - 5.4.89+g6072436-1
kmod-qca-wifi-unified-profile - 5.4.89+gbfbcb2c716-dirty-1
kmod-qmi_sample_client - 5.4.89+1-1
kmod-qseecom - 5.4.89+1-1
kmod-usb-dwc3-qcom-internal - 5.4.89+1-1
kmod-usb-phy-ipq807x - 5.4.89+1-1
kmod-usb-net-qmi-wwan - 5.4.89-1
qca-acd - master.131
qca-acfg - gbfbcb2c716-dirty-1
qca-cfg80211 - gbfbcb2c716-dirty-1
qca-cfg80211tool - gbfbcb2c716-dirty-1
qca-cnss-daemon - gbfbcb2c716-dirty-1
qca-diag - gbfbcb2c716-dirty-1
qca-hostap - gbfbcb2c716-dirty-1
qca-hostap-macsec - gbfbcb2c716-dirty-1
qca-hostapd-cli - gbfbcb2c716-dirty-1
qca-hyctl - gbfbcb2c716-dirty-1
qca-icm - gbfbcb2c716-dirty-1
qca-ieee1905-init - 1
qca-iface-mgr-10.4 - gbfbcb2c716-dirty-1
qca-libhyfi-bridge - gbfbcb2c716-dirty-1
qca-lowi - gbfbcb2c716-dirty-1
qca-mad - gbfbcb2c716-dirty-1
qca-nss-fw-eip-hk - 2.5.7-1
qca-nss-fw-hk-retail - 11-1
qca-qmi-framework - gbfbcb2c716-dirty-1
qca-son-cli - gbfbcb2c716-dirty-1
qca-son-mem-debug - gbfbcb2c716-dirty-1
qca-spectral - gbfbcb2c716-dirty-1
qca-ssdk-shell - g5661366-1
qca-thermald-10.4 - gbfbcb2c716-dirty-1
qca-time-services - gbfbcb2c716-dirty-1
qca-whc-init - 1
qca-whc-lbd - gbfbcb2c716-dirty-1
qca-whc-repacd-init - gbfbcb2c716-dirty-1
qca-whc-repacd-map - gbfbcb2c716-dirty-1
qca-whc-repacd-son - gbfbcb2c716-dirty-1
qca-wifi-fw-hw12-10.4-asic - WLAN.BL.3.14-00025-S-1-1
qca-wifi-hk-fw-hw1-10.4-asic - IPQ8074-WLAN.HK.2.4-02098-QCAHKSWPL_SILICONZ-1-1
qca-wifi-scripts - 1
qca-wifison-ext-lib - gbfbcb2c716-dirty-1
qca-wlanfw-upgrade - 1
qca-wpa-cli - gbfbcb2c716-dirty-1
qca-wpa-supplicant - gbfbcb2c716-dirty-1
qca-wpa-supplicant-macsec - gbfbcb2c716-dirty-1
qca-wrapd - gbfbcb2c716-dirty-1
qca-wsplcd-init - gbfbcb2c716-dirty-1
qca-wsplcd-map - gbfbcb2c716-dirty-1
qca-wsplcd-son - gbfbcb2c716-dirty-1
qcmbr-10.4 - gbfbcb2c716-dirty-1
qmsct_client - gbfbcb2c716-dirty-1

As for my results and observations:

This is my 3rd attempt to get WireGuard working by building the module/package and injecting it into Xiaomi/QSDK builds, without success :frowning:
On all of them, the WireGuard interface comes up, but wg setconf or certain configuration changes are either blocked, or cause a kernel panic. With these QSDK builds, I can see an "Operation not permitted" message when trying to configure it, and when I take it down, the kernel panics.
Digging deeper and researching, I saw that this QSDK has a NSS module for VXLAN (loaded by the wireguard module), so this is most likely where these issues are coming from. For example, they added a NSS module for OpenVPN also in this build, so my guess is that one would need to be written for WireGuard also to ensure everything is smooth.

As an experiment, I tried to disable NSS by renaming the 2 firmware files (is there a cleaner method?), and this is where things got interesting: as soon as I rebooted the router, I lost all wired ethernet support (literally what Ansuel and robimarko were seeing). So it appears that NSS is mandatory now, or at least some parts of it.. I wouldn't be surprised if Qualcomm or Xiaomi put something in the firmware which needs to be enabled/triggered by NSS, some kind of initialization stub, maybe some CPU registers or some backdoor :slight_smile: or anti-reverse engineering attempt :stuck_out_tongue_winking_eye:?

I don't really have that much time to burn on this (sadly this kind of work doesn't pay bills :(), but I think that anyone who wants to get to the bottom of it should reverse engineer those qca-nss kernel modules, that is the missing link. Just load them up in IDA or a disassembler and see what they're up to.. I don't have the equipment or tools for this, but I'd also look at the state of the CPU registers etc., what gets exchanged with the firmware in the early kernel initialization phase, especially NSS.

Given the amount of pain this involved already, I'm seriously considering getting rid of this router and buying a PC Engines APU board with a separate Compex Wi-Fi module, and build my own router from scratch. For fun, I might order an AX9000 when they're available, maybe we'll have better luck with that one? :slight_smile:

1 Like