IPQ807X NSS Build

Sorry for the late reply.

Yeah there's an easy way to test wlan.hk firmwares. Go to

and download the version you like. Please note that wlan.hk.2.7 has some issues reloading changes, so you have been warned. Other than that it's alright if you're able to boot after replacing the firmware.

  1. Download the firmware version folder you want,
    WLAN.HK. or
    WLAN.HK. or maybe
    or the whole thing, so you can test others too
  2. Create a .tar file of WLAN.HK. folder and scp to /tmp/ folder on your AP
  3. Unpack the .tar file and copy the files to folder /lib/firmware/IPQ8074/
  4. Reboot

Happy testing.

1 Like

I have not posted in quite some time as I have not had a reason to as everything is working perfectly:

I am getting some very nice uptimes with bittheifs build:

20:50:41 up 96 days, 21:57, load average: 0.00, 0.00, 0.00


20:51:01 up 96 days, 21:34, load average: 0.00, 0.01, 0.00

I will add that the wifi adapters have not been restarted once. I have some clients that have been connected for 90 (!) days without disconnecting... I have quite a few wifi based iot devices so its one of these:

root@OPENWRT-UPSTAIRS:~# iw dev phy1-ap0 station dump | grep connect
        connected time: 8372073 seconds
        connected time: 8372057 seconds
        connected time: 5533130 seconds
        connected time: 4066010 seconds
        connected time: 4065980 seconds
        connected time: 4065978 seconds
etc etc etc...

Very stable build for me.


May I ask what wlan.hk version are you using?
Thanks :slight_smile:


Sorry if it was already asked (I didn't found a clear answer), is it safe to perform an upgrade to NSS build from official 23.05.0?
I did the 23.05.0 upgrade on my AX3600 few days ago (I was on an old robimarko build) but I have some troubles with somes devices like my stove.

So, I just have to backup the config, do sysupgrade -n then restore the config?


Thanks for sharing the steps.

I tried all and, looks like my AX3600 cannot start wifi with any But I downgraded to the oldest, which didn't resolve the random disconnection, but much better. Assuming you have a different router?

I have a Netgear wax630 and wax620. But I'm having some trouble with bidir (iperf3 --bidir). So I'm trying to figure that one out...

It was done in this commit.
Subsequently updated in the bitthief NSS 6.1 repo as well.
Compiling new build now.

Already running it. I see better load time after a reboot.

root@QNAP:~# uname -a
Linux QNAP 6.1.62 #0 SMP PREEMPT Thu Nov  9 02:56:59 2023 aarch64 GNU/Linux
root@OPENWRT-PRIMARY:~# dmesg | grep HK
[   11.827967] ath11k c000000.wifi: fw_version 0x290984a5 fw_build_timestamp 2023-07-19 02:31 fw_build_id WLAN.HK.

Bear in mind that I am running the 5ghz channels @ 80Mhz as I live fairly close to an airport and the 160Mhz scan fails frequently. I did not really fight too hard to try and get 160 running as 80mhz is just fine for our use. I'm pushing 60-70MBs when doing Samba transfers on my laptop which is more than enough.

Also, the high Wi-Fi uptimes I posted are for the 2.4ghz band, so keep that in mind.


The way I have my network setup is my 2.4ghz band is set exclusively for my home automation devices (of which there are probably about 60)... So that gets its own SSID as well as having it set to hidden.

And the 5.8ghz band is for our phones and laptops. Which see quite a bit of roaming (3 floor home, 3 routers) as well as frequent bursts of high bandwidth usage. I have not had ANY issues what so ever in close to 100 days now with this setup.

So much so that I am about to pull the trigger on a 3rd and final QNAP-301W to replace my middle floor APU2D4+MT7916 mini pcie... I really don't need it as the APU2D4 does just fine, but these builds are running so smoothly I'm tempted to drop the 250EUR just to keep things consistent. I can probably sell the APU2D4 + MT7916 for close to 150EUR so theres that.

Just for clarity, what I currently have is:


So the 2 301Ws are running a compiled build of bittheifs repo. And the middle floor is most likely about to get swapped out for another 301W.

I'll be back in another 100 days or so, but again... For anyone looking for a really solid QCA based AX setup with 10gbe the QNAP-301W + BitThiefs build is the way to go.

One last little nugget... My top floor qnap is running a couple of docker containers... One of which is one of my zwave networks via zwave-js-ui... This thing has been so solid that I've got close to 0.5 million (!!!) rx'd commands. For those who know, this is an excellent. All running via usb based zwave adapter piped to the container on one of the 301Ws.


See you all in about 100 days!


Hey. I was wondering what's the status on NSS build compared to mainlined openwrt. I have an Xiaomi AX6 in which I tried about 2 years ago to flash with openwrt but I remember it was very unstable.
I followed the thread of robimarko until it closed and merged with openwrt.

Is the openwrt build is stable? Does it have no hw offload at all? Some?
And about the nss build - does it have both wifi offloading and switch offloading? Or just the wifi?

Thank you.

I think my WDS broke with NSS. Anyone else can confirm this?

Thu Nov  9 12:22:41 2023 kern.warn kernel: [ 4855.775914] hsl_phy_phydev_get[805]:ERROR:phy_addr 0 phydev is NULL
Thu Nov  9 12:22:42 2023 kern.warn kernel: [ 4856.799891] hsl_phy_phydev_get[805]:ERROR:phy_addr 0 phydev is NULL

Do you got it, I get it in every second.

Nope, syslog is clean.

Do you build it with qca-ssdk, it looks like this

suggest you start by using @bitthief repo first ...or @AgustinLorenzo ... or ...

I've got the same, I have to use a patch to disable the log spam. I think it depends on chipset in use. I have ipq8074.

Edit: I think this PR 3 hours ago, fixes this.


No, this patch is not in bitthief's repo. But I don't have these entries in the syslog on QNAP.

nssinfo should give you the number or otherwise you can type in in the console ecm_dump

regarding the mem profile

on the nss-drv Makefile remove

ifneq (, $(findstring $(CONFIG_TARGET_BOARD), "ipq807x" "ipq60xx"))

I've compiled it twice, once with the commit you mentioned, but it still have the logs, and then, I cherry-pick https://github.com/openwrt/openwrt/commit/947b44d9ae17b4d56578c10a5dd675e79e4c621b with previous source, finally it is fixed.

Ah, glad it finally worked for you. The new patch worked for me.

I am using @bitthief repo too, with two patches, my ipv6 is good.