IPQ807X NSS Build

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?

Thanks

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

4 Likes

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.

Changelog:

Sources:

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

5 Likes

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

Hi boys,

Compiling again, since the fix for NAT Loopback was not working correctly, since it was applied before the network service was started

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

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

PATCH UPDATED: https://github.com/AgustinLorenzo/openwrt/commit/9c20f0ebb55972d75376c8594a096c49c868b46c

Regards, Agustin

2 Likes

Is the NAT Loopback the issue we saw with the reboot loop when the WAN cable was plugged in, as it’s still doing the same with yesterdays build (01/05/23)

Hi @carpcat

Device? Dynalink DL-WRX36?

I have this issue: https://github.com/bitthief/openwrt/issues/15

Still, I have not removed those patches from the version

Regards, Agustin

Yes sorry, WRX36. Ok That makes sense… Thanks :slightly_smiling_face: