Qualcommax NSS Build

Has anyone also noticed that https://github.com/qosmio/packages-extra has stopped compiling in builds or is it just me? @qosmio

If you completed the OpenWrt transition, there shouldn't be a 16 megabyte limit; you seem to have a different problem.

here below my own build’s size it’s bigger than 16mb and it’s working fine

df -h
Filesystem                Size      Used Available Use% Mounted on
/dev/root                17.3M     17.3M         0 100% /rom
tmpfs                   432.5M    408.0K    432.1M   0% /tmp
/dev/ubi0_5             196.9M     96.0K    192.1M   0% /overlay
overlayfs:/overlay      196.9M     96.0K    192.1M   0% /
tmpfs                   512.0K         0    512.0K   0% /dev

23480589 openwrt-qualcommax-ipq807x-asus_rt-ax89x-squashfs-sysupgrade.bin

Hi boys,

This version include NSS offload for WiFi and full support for kmods and target specific

I am redo the repos over the latest commit from OpenWRT.

Changelog (include upstream of OpenWRT):

Notes:

Sources:

BUILDED (UNIFIED): https://github.com/AgustinLorenzo/openwrt/releases/tag/ipq807x-nsswifi-unified-2026-03-03-2055
REPOSITORY: https://openwrtdata.agustinls.com

NOTICE: I am currently only compiling for the following devices: ASUS RT-AX89X, Arcadyan AW1000, Buffalo WXR-5950AX12, Dynalink DL-WRX36, Linksys HomeWRK, Linksys MX4200 (v1 and v2), Linksys MX4300, Linksys MX5300, Linksys MX8500, Netgear RAX120v2, Netgear SXR80, Netgear SXS80, Netgear WAX218, QNAP 301W, Spectrum SAX1V1K, Xiaomi AX3600, Xiaomi AX6, Xiaomi AX9000, and Zyxel NBG7815 devices., if someone has used my versions with other devices (and it is supported), let me know and I will add it.

10 Likes

Hi @JuliusBairaktaris,

I rebase my repo over the latest OpenWRT commits this afternoon and was able to compile the package and install it correctly.

Regards, Agustin

Update:

It looks like that a complete reset of router is needed. I was able to reset the router, set it up exactly as as previous setup except touching mac address, get everything working again, then do the mac address change and it’s is now successfully changed.


Thanks for your devotion to get the builds out for us, it’s been running great for the last couple of years.

I had encountered a problem that I could not set mac address for interfaces, LAN/WAN and others, I tried both Luci and SSH to modify the /etc/config/network but still end up getting same network ID in Windows, but for router’s summary page it’s showing correctly with new mac address, I’m not sure it’s a bug something else caused this one, this was not happening in previous builds and both WRX36 and MX4300 are having same problem.

1 Like

Hi all. I have been using the AgustinLorenzo(thanks for your work!) builds on my Dynalink dl-wrx36’s for a couple years now I think and other builds before that. Everything has been rock solid with uptimes of multiple months, up until I upgraded from the 202511(1115? i think) build to the 20260125 build. Since then I began noticing that my AP going offline occasionally, maybe once every couple weeks and needing to be power cycled to bring it back. When the 20260303 build came out I upgraded hoping for improvement, but unfortunately my AP has gone down consistently every night since. I’m sorry I can’t provide any better details but I don’t have a UART cable to hook up. Hoping someone else might have some ideas.

I have since downgraded to the 20251228 build, since the November build no longer has the kmods posted online, and hoping for the best. If I can confirm stability on this build I may try putting the recent build back on and using a newer ath11k firmware(not using mesh) but other than that I am out of ideas. Thanks!

To install this version of OpenWRT, can I use only the SysUpgrade package, or is it necessary to install from stock? I currently have version 25.12.0, router Linksys MX4300

From my experience it’s okay to use sysupgrade, it’s needed to reset router setting completely though.

1 Like

Update: unfortunately I am still having my AP crash on the 20251228 build.I went back to build 20260303. I thought I read there was newer ath11k firmwares to try if you didnt need mesh but I am only seeing one. I switched from 160Mhz to 80Mhz width on my 5g radio as I have read 160Mhz can be flakey on ath11k. So far its been up a full day…

Hi @derzahla,

The last major firmware changes were made in version “20251115.” In this version, I unified the NSS version to 11.4 and stopped differentiating between regular and mesh builds.

Before November, I was testing some versions internally with the new ath11k firmware “WLAN.HK.2.12-01460-QCAHKSWPL_SILICONZ-1” and discarded it because the synchronization speed was lower in many circumstances.

So right now, the best combination is NSS FW 11.4 and WLAN.HK.2.9.0.1-02146-QCAHKSWPL_SILICONZ-1.

Perhaps you can configure a syslog on your side to see the last lines it sends before dying.

This @qosmio PR indicates that Dynalink DL-WRX36 is not compatible with ramoops, so I can't enable it in the next build either and see what happens on that side.

Regards, Agustin

Hi @qosmio,

I was looking at the latest rebase of the hostapd patches for NSS and I think it's incorrect.

Because when it refreshes automatically, the patch seems to like to play around with drastically changing the line...it even changes its function, hahahaha.

After: static void do_process_drv_event
Before: int process_bss_event

In addition, “NL80211_CMD_ASSOC_MLO_RECONF” only exists in the function “static void do_process_drv_event” and not where it is placed when refresh.

I also tried to confirm these points by cloning the previous version of hostapd and applying the patches, and I was right.

If you want to see the patch I'm using in my build, you can check it out here: https://github.com/AgustinLorenzo/openwrt/commit/61832cdd85e897474297997e61dd399aeb32e775

Regards, Agustin

2 Likes

Hey, @qosmio, i saw this draft PR on openwrt’s github, https://github.com/openwrt/openwrt/pull/22381, and i wonder if this gets merged someday, would this mean a major rework for NSS support for qualcommax targets ? What’s your opinion on that ?

2 Likes

I post here because I perceive that responders in this thread will have NSS-specific knowledge and experience, more so than in the Vanilla Openwrt forum threads… thanks for your understanding.

Ideally, I’d like to hear from individuals here that have personal experience/background with qualcommax/ipq60xx, but certainly any pointers, especially to known reference would be appreciated.

Hardware in question is a Linksys MR7350 with qualcommax/ipq60xx. Vanilla (not NSS-build) 25.12.0 is installed. The router is set up as a wireless bridge.

Included in the base installation, there are two qca components:

root@AirDisk2:~# apk list | grep qca | grep installed
kmod-qca-nss-dp-6.12.71.2025.11.24~19c51af0-r1 aarch64_cortex-a53 {feeds/base/kernel/qca-nss-dp} () [installed]
kmod-qca-ssdk-6.12.71.2025.05.30~446db12b-r1 aarch64_cortex-a53 {feeds/base/kernel/qca-ssdk} () [installed]
root@AirDisk2:~# lsmod | grep qca
qca_nss_dp             45056  0 
qca_ssdk              876544  1 qca_nss_dp

Are these points correct for the ipq/60xx ? :

  • nss-dp (NSS-Data Plane) provides native PS (packet steering) and/or hardware acceleration at some level, reducing load on the CPU’s.
  • nss-dp, without the entire set of nss drivers still provides this basic level of acceleration, without all of the capabilities in the full nss builds.
  • PS is generally not called for if the hardware w/ drivers already supports it.
  • PS on top of nss-dp can lead to extra processor load and instability, especially in high load and low memory settings.

I ask because I’ve had some kernel panics/reboots after upgrading from 24.10.5 to 25.12.0, and I believe that there could have been some sort of change in default settings.

Kernel panics and reboots have completely stopped since I turned off PS. “Working good” is great, but I want to make sure I’m understanding what is going on.

1 Like

Thank you for the feedback Sir. I do have a remote syslog configured but no related messages have gotten logged when it crashes. I will try applying the ramoops PR, I will try applying it and rebuilding(though i have had bad luck having the images i build work for some reason in the past)

Before 20251115, what NSS FW version was being used on ‘regular’ builds? BTW, can you explain what you mean by “synchronization speed” was slower with 12.2 FW? Thanks!

In vanilla OpenWrt images, nss-dp does not provide any hardware acceleration. There is currently an effort to remove it from the upstream OpenWrt tree:

Features such as packet steering and irqbalance are not universally optimal across all platforms. Their effectiveness depends on the specific hardware and workload, so they often require tuning (e.g., enabling or disabling them) to determine which configuration provides the best stability and/or throughput for a given platform.

5 Likes

Hi @derzahla,

The ath11k firmware has always been the same version, “2.9.x”; the only change was the NSS firmware, which was updated from 12.2 to 11.4 to add mesh support and fix a random bug that could cause DHCP to fail on clean installations.

Regards, Agustin

1 Like

It works like a charm, thanks you!
There all kmod packages precompiled, so I'm happy.
:heart:

1 Like

How can I generate the MBN file to write u-boot? I thought that should already be part of the output, but there is just a bunch of .elf and .img files for u-boot. I tried to write the .img last night and I had problems. Now I need to open my device to enable the EDL mode.

I don't think the EDMA rework will be of great relevance for the NSS community. The current stack works well, and nobody is likely to rework the NSS hooks for a new driver on aging IPQ807x hardware. The one feature gap that remains is proper CAKE support, but that won't change with upstream PPE offloading either — any hardware offload by definition moves packets away from the kernel path, so you'd still need a CAKE implementation on the accelerator side, which Qualcomm has no incentive to provide.

My reply was simply to clarify that the nss-dp driver does nothing for hardware acceleration in standard (vanilla) OpenWrt images. It is only functional in builds that include the Qualcomm NSS stack and the corresponding patched drivers and firmware.