Compiling your own NSS image for OnHub routers with ACwifidude

I've been bugging people to do this for me, but shortcuts are not the best method. I figured it out myself and it was pretty much in plain sight on the forum already from @ACwifidude posts. I have an old laptop running 32-bit Debian Linux as my workstation for compiling. ATOM processor with 2 cores.

Step one: ACwifidude source imported:

git clone -b openwrt-23.05-nss-qsdk11

There might be a newer source for these files, but I don't know what it is or how to find it.

When this process finishes, look in the openwrt directory. There are several diffconfig files. Two of these files are for chromium, one has ath10k-ct driver/firmware and the other has ath10k driver/firmware. The OnHub threads have long suggested that the -ct builds not be used on the OnHub, but, @ACwifidudes speed test demonstrate they are faster.

I just renamed the diffconfig-chromium-ath10k to diffconfig (after deleting the others)

Then according to @ACwifidude do this:

./scripts/feeds update -a && ./scripts/feeds install -a && cp diffconfig .config && make defconfig && ./scripts/

make -j2

The -j2 refers to how many cpu cores your computer has, and my old laptop just has two, so -j2. If you have 8 cores, you could use -j8 and so on. Run lscpu from the command line to discover how many CPU cores your system has.

The first time I tried this, I didn't have all the needed packages installed -- but during the process it tells you which dependencies are missing so you have to find those. Often the names of the packages you need to install are not exactly the same as the error messages report, so you'll have to sort that before you'll be successful.

I got one error I haven't sorted:

WARNING: Makefile 'package/kernel/mac80211/Makefile' has a dependency on 'kmod-qca-nss-drv', which does not exist

Then... wait a few hours and see what happens.


Run a make menuconfig and search (use the “/“) for kmod-qca-nss-drv. It’s probably missing. Exit out.

Now try a make -j $(($(nproc)+1)) download.

Instead of wasting cycles running the make after this, run another instance of make menuconfig and see if the required kmod is found this time. If it’s there now, go ahead and run your make -j2

1 Like

When I did the / search, there were dozens of hits that said DEFAULT_kmod-qca-nss-drv with a variety of extensions. I went through every submenu one by one looking for that kmod. So much stuff and it's just not clear to me what the error is. I did what you suggested and the make -j2 is working now. Maybe by tomorrow it will be done. The old laptop is a bit underpowered and slow.

It seems like you used this diffconfig which should give you a working build:

Those series of commands with that diffconfig should spit out a build with a manifest that looks like this in the build folder:

It did and that one worked. The one I tried to customize flashed okay, but all three wifi radios didn't work. @Kong version is still compiling and it seems to be doing things differently because it's spitting out a lot of verbose output and it looks like lots of errors I can't track them all.

I'm attempting to make something as speedy and stable as possible with a minimum of extras. I have an Asus On-Hub in Canada and a TP-Link OnHub in the USA as the main routers. I want to be able to stream my US stuff in Canada and my Canada stuff in the USA. All I need is either OpenVPN or WireGuard added on.

I realize the NSS tweaks do nothing when I'm on the VPN, but others here have taught me how to toggle the VPN off and on so I only enable it when I'm using it and otherwise I'd really like to get that 900 Mbps speed on wireless the way you did.

Back to the Stanley Cup Finals. Thanks for all the source code and programming efforts with NSS.

Yeah VPN needs CPU power for encryption, here NSS does not really help, especially since openvpn runs in userspace thus it needs additional CPU power to transfer the data from user space to kernel space. Wireguard consumes less CPU power. IPSec should be the fastest as NSS has accelerators for it, but I have never tested IPSec on the NSS builds, so not sure if it IPSec acceleration is working in our builds.
As for OpenVPN if the provider allows it you can use 128Bit encryption to sped things up, if you just use it for streaming then you don't need the extra security 256Bit offers.

BTW. On real compile errors, the build will fail, thus what you see are compiler warnings and info messages.

It’s been proven many times the non-nss build give the same speeds as nss builds. Wifi and wired. The extra cpu usage is negligable. Only thing is obviously you can’t use sqm on gigabit speeds, but if you have gigabit speeds, do you really need sqm? You’re gonna get an A to A+ score almost no matter what, which is also the same as when using nss cores.

Just use the excellent snapshots OpenWrt which are on DSA and let nss die in peace.

Can to expand on this a bit?

Did that first build work with the wifi radios?

What customizations did you apply on the build that the wifi radios didn’t work?

It's still running on my underpowered workstation. There were some yes/no prompts that stopped the process in the middle of the night, but it's still going.

I'll keep updating the progress because I think a lot of user will benefit from learning to do this stuff and learning about what happens and/or goes wrong.

I'd actually like to figure out how to set my PiVPN server to use CHACHA20-POLY1305 cipher to get it even faster.

It may come to that obviously. I can't help myself wanting to use the capabilities of the hardware as designed. The TP-Link OnHub even has an directional antenna and the now unsupported Google firmware was able to use it to optimize signals to clients with it. I have no idea if an OpenWrt package could be written to tap into that.

Does my January build work ok on your routers? You can test normal 23.05 vs NSS directly (you can flash back and forth).

I have never used the make menuconfig interface before and did not know where to look for the driver the compiler said didn't exist - so I went through everything and did the / search but at least to me, the search results seemed ambiguous. I likewise didn't know if something should be a M module or not. I went through every menu and submenu just to see what was there. I unchecked DDNS and added luci-app-wireguard. I must have toggled or changed something else in the process of looking at every single item one by one in the menuconfig. The second build, flashed, but no wireless. @ACwifidude defaults STABLE builds flashed and worked and I may just have to accept success and just go with those.

Yes. But the logs spit out several messages where it said the NSS virtual interfaces were "destroyed" and I didn't get any speed increase.

The one I compiled overnight yesterday with your defaults and STABLE is installed now and the logs are clean and there's maybe a 10% speed increase.

I'm going to try and learn this skill of compiling from source. All new to me. The OnHubs are both going to be clients. Each location has a Raspberry Pi4 running PiVPN as the server. One is setup as WireGuard in Canada and one is setup as OpenVPN in the USA. I can't help myself. I just keep screwing around with the setup trying to get it perfect and so that I can remotely control it all.

Post some speedtest and/or iperf results. Wireless should be ~500-600mbps range with a good 2x2 client on 80Mhz and wired should be full line speed (~940mbps). If you use iperf don’t use the router as the server or the client (routers don’t create traffic, they pass traffic).

1 Like

They just give the same speeds when you do a simple throughput test with one client. In real world, with multiple clients doing their work things look different.

Many of us have higher requirements. E.g. I have 20 wifi clients in my home some of them stream constantly I have kids playing games at the same time and I still want to download and have video calls without stuttering. In this case you can't live without sqm gigabit doesn't help here.

1 Like

And the CPU load is next to nothing with multiple clients too. The NSS definitely is an improvement.

Not saying I don’t believe you (and I know you from the DD-Wrt days so I have no reason too) , but I think everybody would like to see numbers backing that up and how that affects real world usage.

Thougj I can see gigabit sqm could make a difference in extreme cases..but I mean, the wifi is never going to saturate a gigabit line anyways, and todays crowded 5ghz frequencies will f up your pings now and then anyways:-) (unless..:face_with_open_eyes_and_hand_over_mouth:)

Here’s a cheat sheet:

Using the menuconfig search feature using the 'kmod-qca-nss-drv' as an example

make menuconfig
enter the '/' character and paste in 'kmod-qca-nss-drv' and Enter

Any SYMBOL containing the entered expression will be displayed ie.

 Symbol: DEFAULT_kmod-qca-nss-drv [=DEFAULT_kmod-qca-nss-drv]
 Type  : unknown

Symbol: DEFAULT_kmod-qca-nss-drv-vlan-mgr [=DEFAULT_kmod-qca-nss-drv-vlan-mgr]
Type  : unknown

Scroll down to the PACKAGE entries.
Here you can see the menuconfig package parameters - selected =y/n/m, the menuconfig prompt, Depends on, Location, what packages it auto selects, what packages select it, and what packages don't select it

   Symbol: PACKAGE_kmod-qca-nss-drv [=y]
   Type  : tristate
   Defined at tmp/
     Prompt: kmod-qca-nss-drv..................... Kernel driver for NSS (core driver)
     Depends on: (TARGET_ipq806x [=y] || TARGET_ipq_ipq806x) && (TARGET_ipq806x [=y] || TARGET_ipq_ipq806x || TARGET_ipq_ipq807x || TARGET_ipq_ipq807x_64 || TARGE
       -> Kernel modules
   (1)   -> Network Devices
   Selects: PACKAGE_kmod-qca-nss-gmac [=y]
Selected by [y]:  
     - PACKAGE_kmod-nss-ifb [=y] && (TARGET_ipq806x [=y] || TARGET_ipq_ipq806x || TARGET_ipq_ipq807x || TARGET_ipq_ipq807x_64 || TARGET_ipq807x [=n] || TARGET_ipq 
     - PACKAGE_kmod-qca-nss-crypto [=y] && (TARGET_ipq806x [=y] || TARGET_ipq_ipq806x) && (TARGET_ipq806x [=y] || TARGET_ipq_ipq806x || TARGET_ipq_ipq807x || TARG   
     - PACKAGE_kmod-qca-nss-ecm-standard [=y] && (TARGET_ipq806x [=y] || TARGET_ipq_ipq806x || TARGET_ipq_ipq807x || TARGET_ipq_ipq807x_64 || TARGET_ipq807x [=n]     
Selected by [n]:
     - PACKAGE_kmod-qca-nss-drv-ovpn-mgr [=n] && (TARGET_ipq806x [=y] || TARGET_ipq_ipq806x || TARGET_ipq_ipq807x || TARGET_ipq_ipq807x_64 || TARGET_ipq807x [=n]    
     - PACKAGE_kmod-qca-nss-ecm-noload [=n] && (!PACKAGE_kmod-tls [=n] || PACKAGE_kmod-tls [=n]) && (TARGET_ipq806x [=y] || TARGET_ipq_ipq806x) && (TARGET_ipq806x   
     - PACKAGE_kmod-qca-nss-ecm-premium [=n] && (!PACKAGE_kmod-tls [=n] || PACKAGE_kmod-tls [=n]) && (TARGET_ipq806x [=y] || TARGET_ipq_ipq806x || TARGET_ipq_ipq8   
     - PACKAGE_kmod-qca-nss-ecm-premium-noload [=n] && (!PACKAGE_kmod-tls [=n] || PACKAGE_kmod-tls [=n]) && (TARGET_ipq806x [=y] || TARGET_ipq_ipq806x) && (TARGET

On these builds all the core requirements exist for a default working build. You can safely leave anything selected by <m> as is unless you explicitly want/need to select it.

Use the search feature on ‘wireguard’ and you should be able to locate each package you need to select.

1 Like

Thougj I can see gigabit sqm could make a difference in extreme cases..but I mean, the wifi is never going to saturate a gigabit line anyways, and todays crowded 5ghz frequencies will f up your pings now and then anyways

With 80+80Mhz and two R7800 you can transfer 1Gbps through 5G I have measured that with iperf before using clients on each side of a R7800. Somewhere in dd-wrt forum I posted screenshots of that test. This is due to the fact, that a R7800 has 4 streams unlike most clients with 4 streams in ac and 160Mhz width the theoretical connection rate is 3.466Mbps. It would even be possible to go beyond 1Gbps if the cpu wasn't maxed out.

5G does not realy travel far, I have no other neighbor 5G in my place when I run a wifi scan via webif.

Besides that I'm pretty sure, when you talk about speeds, your setup does not use pppoe. R7800 non nss without sqm cannot handle gigabit when isp uses pppoe, nss build can.

Don't waste too much time with OnHub routers. They are not in the same league as the R7800, as their main CPU runs at a slower speed and their WiFi chips are of a lower grade than those in the R7800.

Regardless of whether you use an NSS or non-NSS build, you will get around 500 Mbps or less for 802.11ac WiFi (80 MHz channel width).

The 900+ Mbps figure in ACwifidude's post referred to WIRED throughput (LAN-port connected device to Internet). You should get about the same using a non-NSS build with software offloading enabled, albeit with higher CPU utilization.

The images I created for you 1 week ago have all the latest packages and the latest kernel 5.15.158. The images from ACwifidude's repo had the older kernel 5.15.153 (I believe) from 5 months ago.

As for the "Destroyed NSS virtual interface" messages, that's normal. All you should care about is the creation of the NSS virtual interface for phyX-apX.

6,618,33451231,-;wlan1: Destroyed NSS virtual interface
6,619,33789534,-;wlan0: Destroyed NSS virtual interface
6,621,34442748,-;phy1-ap0: Created a NSS virtual interface
6,626,36238357,-;phy0-ap0: Created a NSS virtual interface

WIFI speeds may change wildly throughout the day due to RF interference and client usage. A single 10% increase observation may mean nothing.