IPQ807X NSS Build

I flashed your latest image onto DRX36. When ever the WAN cable in plugged in to the WAN port the router goes into a boot loop. Once removed it’s stable. This is with default settings. Any suggestions to look at? Thanks

I have logged a bug report about this in @bitthief repo.



Hi @Dimfish, @AgustinLorenzo

Could you please include sqm portpackages in your build ? IPQ807X NSS Build - #66 by bitthief?


What's the problem to install nss-ifb in my builds?

Thanks, there is no problem to install nss-ifb in your build @dimfish, but sqm package is missing and if you try to install it from software center it misses iptables packages (not sure if this can be ignored) and not sure if the build needs to be patched in order to use cake.qos from IPQ807X NSS Build - #66 by bitthief ?

You should use fq_codel and nss.qos on sqm for traffic shaping. Currently openwrt's sqm package does not support it, but you can use a third-party sqm makefile or compile with patches to enable traffic shaping on nss. By the way, you need to modify the interface name of nss.qos to enable sqm correctly, and it may cause a kernel panic in the firmware during self-starting!

1 Like

We are using more then a year nftables.
I won't add old (2020) not working with nftables patches. You have to create your own nss-ifb scripts or maybe someone else already created.

No no, the idea is not to include iptables, sqm works perfectly with nftables, the idea was if you guys can patch and include sqm in your builds in order to be usable with nss builds.

Team, can you please explain why in nss builds we are rejecting input in firewall global config?


have a look @ Reject WAN zone input traffic? - #10 by trendy

1 Like

Is there any chance of this getting added to openwrt official?

'Chance', in the sense of 'anything is possible, if you throw enough resources at it' - yes (kernel side code is crap, but available and GPL2 licensed)...

Realistically, no.
As mentioned above, the code is 'not very good' /EUPHEMISM (but at the same time very invasive, hooking deeply into volatile and evolving netfilter code), it would have to be rewritten from scratch into a hardware flow-offloading module (without documentation and against the existing NSS firmware blobs) and get merged into mainline kernel/ netfilter. It's 'possible', but veeeeery unlikely to happen - too big of a task.

1 Like

Realistically, it's cheaper (in every sense of the word) to throw hardware (x86_64 as router) at the problem, than to dedicate a team of developers for 6-24 months to rewrite/ submit the NSS code to pass netdev/ netfilter scrutiny.

1 Like

Exacly, this is te main problem why i had to go a few years ago, x86 ftw , blazing fast performance, no bricked devices etc.

Hi @rmandrad

I have needed to refresh almost all the patches and remove some that were already applied.

I'll give you the commits related to the NSS update in case you want to take a look:

Regards, Agustin


Hi @carpcat @larrynz

For the next version I remove these 3 patches and see how it works, I'll let you know.

Regards, Agustin

1 Like

Hi boys,

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



BUILDING: https://github.com/AgustinLorenzo/openwrt/actions/runs/4864621503/jobs/8673868020 UPDATED

BUILDED: https://github.com/AgustinLorenzo/openwrt/releases/tag/ipq807x-2023-05-02-2059 UPDATED

PD: I have deleted the version, since the fix for NAT Loopaback is not working correctly, in a few minutes I will compile again

Regards, Agustin


Reverting the WLAN vulnerability fixes is just hiding the fact that TX flush is half broken in ath11k

Hi Robi,

At the moment, without those 2 commits the WiFi remains stable without disconnecting everyone randomly.

The only pattern I could find when disconnecting everyone from WiFi was with some IOT devices and WiFi (AC) antennas.

Autocomplete is terrible.

Regards, Agustin

Well yeah, since its getting rid of the protection that is flushing the queue after a client disconnects so its hiding the issue in ath11k or its FW