2597

Hi @qosmio

Sorry if it bothers you, I was going to rebase again on my repo and I see that you are rebasing the entire branch in your repo, if you want to let me know when you finish and I can redo and retest.

Do you think we should apply this by default?

for the next version I think I will switch to non-ct driver to check the performance.

In my case the WiFi IoT is for when I test channels with the main network, it always gives the best results on channel 40-44 at 160 MHz.

Regards, Agustin

2598

I finally got a round to rebasing some ~180 commits over the weekend. So many ugly merge commits (my own doing...). But a lot cleaner now, and I dropped a lot old commits that weren't needed explicitly for proper NSS (dnsmasq, flow offload scripts, anything outside of target/linux, package/kernel).

Was going to ask everyone if they could test building from there. If it works out well, I'll rename that branch as the primary qualcommax-6.x-nss-wifi

So, after testing over 4 days with 6.6.30 with (ecm.general.disable_gro='1'), I decided to reset it to '0' to see if my socket problem returned, and within a few hours everything locked up again. I couldn't call out to any external resolvers, or even locally. This was directly on the router. I could still resolve from clients if I specified a server directly (1.1.1.1).

I don't know if it's a combination of unbound + NSS + GRO, or just GRO + NSS. I haven't seen anyone else reporting it. @rmandrad , @jkool702 I know you both use unbound in your setup, curious if you've ran into this issue.

Either way, I think it's probably best to (ecm.general.disable_gro='1') for NSS focused builds.

Side note, the issue regarding enabling the bridge filtering options net.bridge.bridge-nf-call-* I found out was not really an issue, and in fact should not be enabled for nftables based builds since it competes with iptables. Which uses br_filter which has

The net.bridge.bridge-nf-call-* option simply enabling allowing iptables to accept bridge filtering rules, which it then passes onto kernel netfilter. nftables doesn't need the option to be explicitly set. That means fewer options need to be managed for ECM to function.

4 Likes
2599

Building now: https://github.com/JuliusBairaktaris/Qualcommax_NSS_Builder/actions/runs/8973508672

Edit: Failed @qosmio

My action workflow will track rebase-qualcommax-6.x-nss-wifi so you can have a reference if it builds.

Edit 2: Everything is working! It was just some build shenanigans that caused it to fail

1 Like
2600

I have clone your rebase branch, I also add my commits for fan and leds support for NBG7815 and compile it without problem. Now running on device.

I'll inform if there is any problem.

2 Likes
2601

Hi! I made a build this morning but the wan doesn't connect. I don't know why, there are no errors in system and kernel logs. Then i flashed the previous build (without 12.5 qssdk) and all is fine.
Now i try to build from your @qosmio rebase branch to see if it will connect the wan.

@asvio is it working all fine at your nbg7815?

2602

No problem for me with 12.5 until i flash to the new rebase branch. It has been almost 48h working fine.

2603

Did you do a sysupgrade, or fresh install?

UPDATE: @asvio , could you expand on the problem you're having? Failed to boot? Or something else?

Is that something that should be upstreamed? I feel like it'd be good since you're adding support for missing hardware, especially LED/fan related PRs which is easier to get approved than NSS changes.

1 Like
2604

I do a sysupgrade

1 Like
2605

From a regular, inexperienced user perspective both thumbs up for it. I always stick to @asvio repo, because his LEDs and fans support commits make our nbg7815 feel like a normal, "complete" router experience (minus 160mhz support unfortunately). He also provides basic config, which makes compiling a breeze and offload works flawlessly. I am too inexperienced to add this support to other Devs repos and ultimately give them a try.

3 Likes
2606

I think there was a problem with what I wanted to say. (language problems).
the new branch is working correctly.

LEDs support is more a cosmetic problem. This device has a relative big multiintensity multileds that can be annoying. There is firmware for the leds controller but it is not upstreamed. I've been updating the firmware to be used for 6.x kernels.

The fan support is another history. NBG7815 can easy reach 80°C on wifi, aqr113c and cpu chip with 25°C RT. So fan it a must to have if someone want to use this device seriously. NSS support also up temp 2-3°C.

I am using an implementation for the fan that surely would not be accepted upstream, but that allows me more freedom to control the device temperature.

4 Likes
2607

Both PRs - kernel: qca-ssdk: update to 12.5 for kernel 6.6
and
kernel: qca-nss-dp: update to 12.5.r2 for kernel 6.6
were merged to main.
I have compiled both two days ago with kernel 6.6.30 (now in main too) and running with all of them was OK.

Just finished compiling from your new rebase-qualcommax-6.x-nss-wifi branch then sysupgraded keeping the settings. On top of it I've added qca-nss-dp: update to 12.5.r2 for kernel 6.6 and Mold 2.31. Runs OK.

The only negative experience is that this stupid error during compiling returned again. I had the same on ipq806x.

Now trying to compile after distclean to see if I can get rid of this build error again.
While waiting the QNAP is running with libcurl mbedtls variant that compiled with no errors.

root@QNAP:~# opkg info libcurl4
Package: libcurl4
Version: 8.7.1-r2
Depends: libc, libmbedtls21, libpthread, libnghttp2-14, ca-bundle
Provides: libcurl
Status: install ok installed
Section: libs
Architecture: aarch64_cortex-a53
Size: 209585
Filename: libcurl4_8.7.1-r2_aarch64_cortex-a53.ipk
Description: A client-side URL transfer library
Installed-Time: 1715080703
2608

posting this here although it may or may not be related to the nss bits in this build but:

my structure on each of these is basically:

2.4 ssid 0 - hidden, just for my iot
2.4 ssid 1 - visible for 2.4g 'real' clients
5.8 ssid 0 - visible for 5.8g 'real' clients

for what ever reason, i have noticed some bridging issues on the 2.4 hidden ssid.

generally speaking, it works fine, but some arp requests would not answer.

when i moved it to position 2, so like this:

2.4 ssid 0 - visible for 2.4g 'real' clients
2.4 ssid 1 - hidden, just for my iot

this behavior stopped.

i was able to replicate this multiple times, multiple reboots on multiple clients.

what do i mean by bridging issues? well... the devices in question would be able to route to the outside world np. eg: they had wan access. but when i tried to ping / connect / etc to them using my lan (so lan to lan), the arp requests would not get forwarded to the requesting client. so the device attempting to connect to the device on the hidden ssid had no clue how to get to the device let alone for traffic to flow. here is a better example of when it was an issue:

client 1 -> wire -> 301w -> 2.4 hidden ssid -> client 2

when client 1 sent the who has arp requersts before actually trying to flow traffic, client 2 would answer, but the 301w would not pass the arp response back to client 1.

this also happened in the following situation:

client 1 -> 5.8 visible ssid -> 301w -> 2.4 hidden ssid -> client 2

as previously mentioned, as soon as i moved the hidden ssid the 2nd ssid on the 2.4g band this stopped. all works as expected.

last but not least disabling the hidden flag on the ssid also fixed it, but i want to keep my iot ssid hidden so i opted to use this solution.

a bit of a quirk, just posting this here in case anyone is noticing some bridging issues between the various interfaces on their br-lan bridge.

important note, these devices are in dumb-ap mode. my wan to lan happens 2 floors down where we rarely are. also my iot network is as vanilla as it gets so no 802.11k/v/r etc.

1 Like
2609

@asvio I am using your build with fan and led support since a month (kernel 6.6.23) and it is pretty stable. I can confirm that the device is getting pretty hot (80 to 90°C). Especially when you plug in a multi gig lan client or having a lot of wifi clients online. The annoying thing with the fan support is that it is only 0 or 1. So on/off with no throttling depending on the temperature. The fan is pretty noisy when running at 100%. Basically it is absolutely making sense to have the fan. With the fan running constanly at 100% than temperature drops to app. 60°C.

2 Likes
2610

Yes i know, but the fan is not a pwm fan and you can't control its speed.

1 Like
2611

Hello! Sorry for the stupid question, but where can I find documentation about what might be in the /etc/config/ecm file? I want to enable hardware offload for LAN-WAN and Wi-Fi. And configure SQM (as I understand there is a built-in FQ_Codel), but in this thread there are several instructions, which one is more correct to use? In the quote I quote above, I understand there is only setting for ingress traffic?

2612

You shouldn't have to enable any NSS specific setting if you're building from my repo. ON is the default.

The repository contains all NSS kernel patches + feeds.conf.default for required NSS package + NSS SQM scripts.

You can use the frontend to enable SQM.

image
image1934×1146 193 KB

You can use my base config as a starting point

2613

Unfortunately, I use pre-assembled builds that were posted about a week ago in this thread.

I tried to build from your repository several times, but it works only under wrx36, as soon as I change the target to RAX120v2, I get an error when building the kernel.

time: target/linux/install#62.32#5.39#34.45
    ERROR: target/linux failed to build.

The update, without the j parameter (consider j -1), was compiled on the third try. I don’t understand why this happens, but to be honest, this also happens to me when building from the main OpenWrt branch (I mean that the firmware is not assembled the first or second time, you have to try many times)

2614

You have to build with verbose option "V=s" to see the actual error.

make target/linux/install V=s
2615

Built using @JuliusBairaktaris builder pointing to your rebase repo @qosmio , added custom packages. Working so far 6.6.30 on my ax3600.

1 Like
2616

UPDATE: Renamed current branch to "merge-qualcommax-6.x-nss-wifi" and "rebase-qualcommax-6.x-nss-wifi" is now the default "qualcommax-6.x-nss-wifi" that will be the rebased and current branch going forward. Should be a lot cleaner now.

Also, added NSS support for all ipq807x/ip817x targets.

    * Arcadyan AW1000
    * CMCC RM2-6
    * Linksys MX4200 V1/V2
    * Linksys MX5300
    * Sagemcom Fast 5285 Spectrum SAXV1V1S
    * Yuncore AX880
    * ZBT Z800AX
    * ZTE MF269
4 Likes