Ipq806x NSS build (Netgear R7800 / TP-Link C2600 / Linksys EA8500)

Interesting that luci opkg is not defaulted to “y”. Recent change in the last ~2-3 weeks. I’ll add it to the diffconfig for future iterations. Otherwise the changes over the last couple months have master running really well. I’m excited for the upcoming stable branch (23.04?).

@dadogroove - reverted that commit and updated the 22.03 build

1 Like

Can you try making a build for the Nokia Airscale AC400i?
I tried to get it working myself, wireless boots up, but ethernet is just a no no.

Unfortunately I don’t have that device so I won’t be very helpful with testing.

Here is my dts patch for devices other users have found successful .dts changes to get their device working:

Some devices require a little more, some require a little less. If you find changes in your testing that work, I’ll gladly build for your device. Here is an example for the r7500 from that patch for changes that get it working:

--- a/arch/arm/boot/dts/qcom-ipq8064-r7500.dts
+++ b/arch/arm/boot/dts/qcom-ipq8064-r7500.dts
@@ -258,6 +258,9 @@

 &gmac1 {
 	status = "okay";
+	qcom,phy-mdio-addr = <4>;
+	qcom,poll-required = <0>;
+	qcom,rgmii-delay = <1>;
 	phy-mode = "rgmii";
 	qcom,id = <1>;

@@ -275,6 +278,9 @@

 &gmac2 {
 	status = "okay";
+	qcom,phy-mdio-addr = <0>;
+	qcom,poll-required = <0>;
+	qcom,rgmii-delay = <0>;
 	phy-mode = "sgmii";
 	qcom,id = <2>;

can you add easymesh support in the builds.

thanks you so much for all the wonderful work you have been doing.

I usually recommend that people not use mesh. Hardwiring is always a better option. Mesh comes with significant performance degradation that negates any performance improvements from NSS.

I don’t see a package in the official OpenWrt repo. If it is in an OpenWrt repo you should just be able to install it. Do they just have their own stand alone repo?

1 Like

I cannot compile 22.03 branch using the above instructions. I get the following error:

Makefile 'package/feeds/luci/luci-app-apinger/Makefile' has a dependency on 'apinger-rrd', which does not exist

The compilation never completes. According to this, we have to wait someone adds apinger-rrd to 22.03!

Do you think that with this someday attended sysupgrade would be possible for NSS builds?

Technically, there are only two ways to make attended sysupgrade possible:

  • getting all NSS packages merged into OpenWrt
    not very likely, as the code itself is [CENSORED] and a major obstacle for kernel upgrades.
  • replicating the server setup of asu
    which would require building a hell of a lot of packages, and high performing servers with lots of bandwidth. Technically challenging, but possible - however quite expensive (server rent) to run. Apart from the mere cost issue, someone would also have to spent quite a lot of continuous work on the webservice maintenance/ webservice security side of things (as it's a quite high risk target for command injection for nefarious purposes), not something to be taken lightly.

so in short, no - not at all likely.

1 Like

I have also been having a time trying to get 22.03 to build as of late. To eliminate the luci-app-apinger dependency issue, I removed the dependency (+apinger-rrd) from the Makefile. (openwrt/feeds/luci/applications/luci-app-apinger). I do not use that app. Obviously this is not a fix if you need that app. The error went away.

The next issue I was having is that rrdtool1 would not download. The download phase would just halt at the rrdtool1 download. It didn't error, just never finished downloading. I copied the rrdtool1 Makefile from master (5.15) and put it into 22.03 (5.10) and the download phase finished without issue. (openwrt/feeds/packages/utils/rrdtool1) My guess is the download location in the 22.03 Makefile is wrong.

I am waiting for the build to finish, but so far so good. The build completed and I updated my RT4230W without issues. Luci-app-statistics is working fine.

1 Like

Latest wired speed test using @rickkz0r NSS settings in luci-app-sqm with 800/20 line speeds.

1 Like

I have exactly the same issues when building 22.03.
Thanks for pointing them out !

ERROR: package/feeds/packages/rrdtool1 failed to build.


Completed build with this MakeFile:

1 Like

Hey, if I'm not mistaken you could provide your custom packages in a repository and I'll add it to the allow list. Something like this as a GitHub package or uploaded to a regular web server would be sufficient.

1 Like

Got my build running, only web interface it not accessible anymore :frowning:
SSH is still working. Does anyone has a clue where to look for ?

uhttpd seems not to be running and netstat doesn't show port 80 or 442.

Hmm.. maybe it missed some packages for SSL or so

root@OpenWrtNSSAP:/etc/config# opkg update
Downloading https://downloads.openwrt.org/releases/22.03-SNAPSHOT/targets/ipq806x/generic/packages/Packages.gz
wget: SSL support not available, please install one of the libustream-.*[ssl|tls] packages as well as the ca-bundle and ca-certificates packages.

Got it running again with OP his stable image. Sysupgrade over SSH / SCP. Don't know what i did wrong, need to find out.

Think i found it, to much #:

# Luci (SSL from OpenSSL)


That won't help much, as NSS needs very invasive kernel modules, hooking deep into netfilter - getting that ABI compatible to the OpenWrt kernel of the day (as a strict add-on binary feed) is next to impossible.

1 Like

True... well I suppose you could offer a containing including the Image Builder :slight_smile:

1 Like

Created a new build:

I wonder if we can rework NSS ECM module to hook into existing HW_OFFLOAD hooks, like what was done for the mt7621/mt7622 SoCs. Most of the kernel patches required are for NSS ECM.

Would be a massive undertaking tho. but would have a fighting chance of getting it merged into OpenWRT if done.


Technically, yes - but as you said, that would be a major rewrite.

they used to have

I think that would be a convincing way to get it in to official OpenWrt. I don’t have the slightest idea how to utilize the existing HW_OFFLOAD hooks like what was done for the mt7621/mt7622 SoCs. If someone knows it would be massively beneficial for ipq806x and probably could be similar for ipq807x.