Qualcommax NSS Build

[tonytuya]

Thanks for quick reply! But it looks like it doesn't work. As you can see, the device has connected to my 2.4G wifi (no encrypted wifi), but still, openwrt cannot give it a address

Fri Feb 21 22:48:59 2025 daemon.info hostapd: phy1-ap0: STA 02:77:da:4c:2d:7e IEEE 802.11: authenticated
Fri Feb 21 22:48:59 2025 daemon.info hostapd: phy1-ap0: STA 02:77:da:4c:2d:7e IEEE 802.11: associated (aid 1)
Fri Feb 21 22:48:59 2025 daemon.notice hostapd: phy1-ap0: AP-STA-CONNECTED 02:77:da:4c:2d:7e auth_alg=open
Fri Feb 21 22:48:59 2025 daemon.info hostapd: phy1-ap0: STA 02:77:da:4c:2d:7e RADIUS: starting accounting session 02BB631115B56A81
Fri Feb 21 22:49:15 2025 daemon.notice hostapd: phy1-ap0: AP-STA-DISCONNECTED 02:77:da:4c:2d:7e

Here is system log, but I can't see any helpful content

[frog]

Cross post here to see if anyone knows a workaround or if it is a known issue: OpenWrt support for Linksys MX4200 - #2539 by rkboni

I am using the non-mesh NSS build from AgustinLorenzo and followed OneMarcFifty's video to set up a main router and a dump AP, both of them have a wifi network and an IoT network, while using Vlan to separate the traffic, I got the similar DHCP issue as the post above.

[junky]

@vochong , @qosmio Thank you for the information!

I have four WXR-5950AX12 APs, so I tested which image works with STA mode, and I found that AgustinLorenzo's 2024-12-09-0128 prebuilt image is the latest build that works properly with STA mode. (I'm so addicted to trying NSS builds, btw.)

Unfortunately, the build images before 2025-01 was shipped with OPKG, not APK, so I had to change the repo from downloads.openwrt.org/snapshots/ to archive.openwrt.org/releases/24.10.0 to install the relayd package, but otherwise, it works very well.

It easily achieves over 2Gbps transfer speed, sometimes over 3Gbps, thanks to the power of the 8T8R antenna, even with an 80MHz width. The 160MHz 4T4R mode doesn’t speed up much in STA mode.

root@debian:~# iperf3 -c 172.20.1.66 -i 10 -t 60
Connecting to host 172.20.1.66, port 5201
[  5] local 172.20.1.212 port 56154 connected to 172.20.1.66 port 5201
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-10.00  sec  2.76 GBytes  2.37 Gbits/sec    4   3.13 MBytes
[  5]  10.00-20.00  sec  2.93 GBytes  2.52 Gbits/sec  358   3.13 MBytes
[  5]  20.00-30.00  sec  2.96 GBytes  2.54 Gbits/sec    0   3.13 MBytes
[  5]  30.00-40.00  sec  2.89 GBytes  2.49 Gbits/sec  855   2.99 MBytes
[  5]  40.00-50.00  sec  2.91 GBytes  2.50 Gbits/sec    1   3.00 MBytes
[  5]  50.00-60.00  sec  2.95 GBytes  2.53 Gbits/sec  2119   2.86 MBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-60.00  sec  17.4 GBytes  2.49 Gbits/sec  3337             sender
[  5]   0.00-60.00  sec  17.4 GBytes  2.49 Gbits/sec                  receiver

NSS is really doing a good job. I'll stick with the 12-09 build image for STA-purpose APs until the problem is resolved.

My setup is like this;

Dev AP : 5950AX12 (AgustinLorenzo's 2025-02-15 purebuilt image)
Dev STA: 5950AX12 (AgustinLorenzo's 2024-12-09-0128 purebuilt image)

Iperf3 server (VM) - AP - 3-4 meter distance - STA(relayd) - iperf3 client (Linux PC with Intel X550-T2 NIC)

wlan_2g is for the default route, used to install packages, etc. lan is for control purposes.

I like OpenWRT so much, but I'm quite new to the Linux kernel and C language, so all I can do is only pray for professionals to resolve this issue someday.

[jav]

@qosmio

I hadn't been testing with AP+STA mode, but looks like even in WDS mode it's broken (which I had tested few months ago, but mesh provided much greater performance). I'm not exactly sure of the cause tbh. It will take a significant amount to traceback.

I have a AW1000 as AP with WDS enabled, and another OpenWRT device connected to it through WDS and acting also as AP. The configuration is stable, but the AW1000 sometimes crashes. My suspiction is it crashes when end devices roam from one AP to the other. The secondary AP is rock-solid.

I haven't used mesh config, as this is a very simple setup and I was expecting WDS would be good enough, but I'd need to reconsider it if it cannot be fixed.

[nn5]

@junky Thank you! Now I know which NSS build I can use for my MX 4200v1 in STA mode.
When I flashed and used the version that you mentioned I see that APK, not OPKG, is used as the package manager. I need the travelmate package to test my MX4200v1 in STA mode, but from luci I cannot find it. What do I need to do to get packages for that build?
Any help will be appreciated. TIA.

[SlotTech]

@qosmio I've noticed recently that packet steering gets enabled after doing a sysupgrade to the current 24.10-nss (r28580-e3694223b7) even though it was disabled before upgrading the firmware version. This is on a Dynalink DL-WRX36. I build from your source and just configure the make file to my liking. The last build I made that worked as expected was r28435-1cae719a6a that I made on Jan 7. Are you able to provide any insight on this is?

[qosmio]

Yes, I'm aware of the issue. Upstream recently switched to in enabling it on by default. Working on a fix to have it set to false on NSS platforms.

[nn5]

[quote="junky, post:4425, topic:148529"]
Unfortunately, the build images before 2025-01 was shipped with OPKG, not APK, so I had to change the repo from [downloads.openwrt.org/snapshots/](http://downloads.openwrt.org/snapshots/) to [archive.openwrt.org/releases/24.10.0](http://archive.openwrt.org/releases/24.10.0) to install the relayd package, but otherwise, it works very well.
[/quote]

@junky I flashed the 2024-12-09 prebuilt image to my MX4200v1 without any configuration, and I do not see opkg installed. In luci it shows apk, and apprently opkg is not installed (I tried in ssh shell).
I'm curious as how did you install the relayd package on this old image? I am trying to install the travelmate package. Any info/help would be appreciated.
TIA.

[junky]

I checked the AP and found that the actual running firmware was not the 12-09 build but the 07-21 build.

Release Updated prebuilt images (NSS-WiFi) 2024-07-21-1508 ·...

While testing, I tried a bunch of firmware and accidentally overwrote it. This build has been running in STA/relayd mode for a very long time, so I believe it’s a stable one (at least with my 5950AX12).

Sorry for the confusion!

[qosmio]

All,

Pushed few updates and fixes, most notably:

1. NSS offloaded dynamic VLAN should be functional (should resolve Unable to get IP via dynamic VLAN on non-default networks please test @tardeaux)
2. Resolve SME: Authentication request to the driver failed when running as wifi in client mode. (should resolve Qualcommax NSS Build - #4410 by junky please test @junky)
3. Ensure packet steering is always disabled. This one has always been a pain point with new users switching to NSS. So now, even if you enable it from the front end or manually, it will auto-disable. (should resolve Qualcommax NSS Build - #4428 by SlotTech)

date	commit	desc
2025-02-28	bb301cf44a	hostapd: fix SME Authentication request to the driver failed
2025-02-28	2525d6ee66	ath11k_nss: fix null chanctx warning for NSS dynamic VLAN

NSS Packages:

date	commit	desc
2025-02-28	e4489bb	nss-ecm: ensure packet steering is always disabled

I've pushed to both main-nss and 24.10-nss.

Cheers

[sppmaster]

After latest updates I have lots of those Disabling feature: rx-gro-list lines after every DHCPREQUEST DHCPACK and other events.

daemon.info dnsmasq-dhcp[1]: DHCPREQUEST(br-lan) 192.168.1.51 00:00:01:70:44:10
daemon.info dnsmasq-dhcp[1]: DHCPACK(br-lan) 192.168.1.51 00:00:01:70:44:10 PC
user.notice root: [ethtool] Disabling feature: rx-gro-list: disabled on (10g-1)
user.notice root: [ethtool] Disabling feature: rx-gro-list: disabled on (10g-2)
user.notice root: [ethtool] Disabling feature: rx-gro-list: disabled on (lan1)
user.notice root: [ethtool] Disabling feature: rx-gro-list: disabled on (lan2)
user.notice root: [ethtool] Disabling feature: rx-gro-list: disabled on (lan3)
user.notice root: [ethtool] Disabling feature: rx-gro-list: disabled on (lan4)
user.notice root: [ethtool] Disabling feature: rx-gro-list: disabled on (phy0-ap0)
user.notice root: [ethtool] Disabling feature: rx-gro-list: disabled on (phy1-ap0)

MACs redacted.

Summary

root@QNAP:~# nss_diag
     MODEL: QNAP 301w
   OPENWRT: r29059-282feb2adc
IPQ BRANCH: main-nss
IPQ COMMIT: 282feb2adc
  IPQ DATE: 2025-02-28
    NSS FW: NSS.FW.12.2-161-HK.R
  MAC80211: v6.12.6-0-ge9d65b48ce1a
 ATH11K FW: WLAN.HK.2.9.0.1-02146-QCAHKSWPL_SILICONZ-1
 INTERFACE: br-lan     tx-checksumming: on  rx-gro-list: on
            10g-1      tx-checksumming: on  rx-gro-list: off
            10g-2      tx-checksumming: on  rx-gro-list: off
            lan1       tx-checksumming: on  rx-gro-list: off
            lan2       tx-checksumming: on  rx-gro-list: off
            lan3       tx-checksumming: on  rx-gro-list: off
            lan4       tx-checksumming: on  rx-gro-list: off
            phy0-ap0   tx-checksumming: on  rx-gro-list: off
            phy1-ap0   tx-checksumming: on  rx-gro-list: off

  NSS PKGS: kmod-qca-mcs-6.6.79.12.5.2024.02.27~26d6424-r1 aarch64_cortex-a53 {feeds/nss_packages/qca-mcs} () [installed]
            kmod-qca-nss-dp-6.6.79.2024.11.18~4c9f671a-r1 aarch64_cortex-a53 {feeds/base/kernel/qca-nss-dp} () [installed]
            kmod-qca-nss-drv-6.6.79.12.5.2024.04.06~53a0dc1-r15 aarch64_cortex-a53 {feeds/nss_packages/qca-nss-drv} () [installed]
            kmod-qca-nss-drv-bridge-mgr-6.6.79.12.5.2024.06.12~1bcef16-r7 aarch64_cortex-a53 {feeds/nss_packages/qca-nss-clients} () [installed]
            kmod-qca-nss-drv-igs-6.6.79.12.5.2024.06.12~1bcef16-r7 aarch64_cortex-a53 {feeds/nss_packages/qca-nss-clients} () [installed]
            kmod-qca-nss-drv-qdisc-6.6.79.12.5.2024.06.12~1bcef16-r7 aarch64_cortex-a53 {feeds/nss_packages/qca-nss-clients} () [installed]
            kmod-qca-nss-drv-vlan-mgr-6.6.79.12.5.2024.06.12~1bcef16-r7 aarch64_cortex-a53 {feeds/nss_packages/qca-nss-clients} () [installed]
            kmod-qca-nss-ecm-6.6.79.12.5.5.2024.09.12~c5d8727-r3 aarch64_cortex-a53 {feeds/nss_packages/qca-nss-ecm} () [installed]
            kmod-qca-ssdk-6.6.79.2024.06.13~c451136b-r3 aarch64_cortex-a53 {feeds/base/kernel/qca-ssdk} () [installed]
            nss-firmware-default-2024.08.04~794fe373-r1 aarch64_cortex-a53 {feeds/nss_packages/firmware/nss-firmware} () [installed]
            nss-firmware-ipq8074-2024.08.04~794fe373-r1 aarch64_cortex-a53 {feeds/nss_packages/firmware/nss-firmware} () [installed]

[SlotTech]

@qosimo

I get an error during compile, here's the output below. If you need anything else let me know. Any idea what's going on?

make[5]: Entering directory '/home/openwrt-ipq/build_dir/target-aarch64_cortex-a53_musl/linux-qualcommax_ipq807x/linux-6.6.79'
  CC      net/ipv4/ipmr.o
  CC      net/ipv6/ip6mr.o
  CC      net/ipv4/udp_bpf.o
  CC      net/ipv4/bpf_tcp_ca.o
  CC [M]  net/ipv4/ip_tunnel.o
  CC [M]  net/ipv4/gre_demux.o
  CC [M]  net/ipv4/ip_gre.o
net/ipv4/ipmr.c: In function 'ipmr_mfc_stats_update':
net/ipv4/ipmr.c:455:35: error: invalid operands to binary + (have 'atomic_long_t' {aka 'atomic64_t'} and 'u64' {aka 'long long unsigned int'})
  455 |         cache->_c.mfc_un.res.pkt  += pkts_out;
      |         ~~~~~~~~~~~~~~~~~~~~~~~~  ^~
      |                             |
      |                             atomic_long_t {aka atomic64_t}
net/ipv4/ipmr.c:456:36: error: invalid operands to binary + (have 'atomic_long_t' {aka 'atomic64_t'} and 'u64' {aka 'long long unsigned int'})
  456 |         cache->_c.mfc_un.res.bytes += bytes_out;
      |         ~~~~~~~~~~~~~~~~~~~~~~~~~~ ^~
      |                             |
      |                             atomic_long_t {aka atomic64_t}
make[9]: *** [scripts/Makefile.build:243: net/ipv4/ipmr.o] Error 1
  CC      net/ipv6/addrconf_core.o
make[9]: *** Waiting for unfinished jobs....
  CC      net/ipv6/exthdrs_core.o
net/ipv6/ip6mr.c: In function 'ip6mr_mfc_stats_update':
net/ipv6/ip6mr.c:925:34: error: invalid operands to binary + (have 'atomic_long_t' {aka 'atomic64_t'} and 'uint64_t' {aka 'long long unsigned int'})
  925 |         cache->_c.mfc_un.res.pkt += pkts_out;
      |         ~~~~~~~~~~~~~~~~~~~~~~~~ ^~
      |                             |
      |                             atomic_long_t {aka atomic64_t}
net/ipv6/ip6mr.c:926:36: error: invalid operands to binary + (have 'atomic_long_t' {aka 'atomic64_t'} and 'u64' {aka 'long long unsigned int'})
  926 |         cache->_c.mfc_un.res.bytes += bytes_out;
      |         ~~~~~~~~~~~~~~~~~~~~~~~~~~ ^~
      |                             |
      |                             atomic_long_t {aka atomic64_t}
make[9]: *** [scripts/Makefile.build:243: net/ipv6/ip6mr.o] Error 1
make[9]: *** Waiting for unfinished jobs....
make[8]: *** [scripts/Makefile.build:480: net/ipv4] Error 2
make[8]: *** Waiting for unfinished jobs....
make[8]: *** [scripts/Makefile.build:480: net/ipv6] Error 2
make[7]: *** [scripts/Makefile.build:480: net] Error 2

[ghoffman]

[
that is what i was going to report in my deleted post above. my nss_diag showed all those interfaces in disabled state.

[qosmio]

Should be resolved in latest 24.10-nss branch.

@sppmaster

After latest updates I have lots of those Disabling feature: rx-gro-list lines after every DHCPREQUEST DHCPACK and other events.

Pushed an update to qca-nss-ecm to reduce log spam.

EDIT: Just pushed another update to qca-nss-ecm @sppmaster @asvio @pwned

  nss-ecm: only set reload trigger to disable packet steering

  Previous change was reloading ECM on client DHCP requests causing
  temporary packet loss. Change reload trigger to instead just disable
  packet steering (the original intent of this feature).

[pwned]

For me this is not a cosmetic issue. Everytime this message appears within the logs everything is disconnected for a few seconds. I can see it while running a TV stream or getting disconnected from a server during gaming. Output of nns diag is the same as sppmasters. I just wonder about br-lan.

EDIT: I will not rule out the fault is on me. It's my first build this year 2025. But maybe I'm not alone.

[asvio]

I did a build around the changes @qosmio posted on the 28th and added the 6.6.80 kernel to see if there were any problems (along with the nbg7815 modifications) and it has been running for more than 24 hours without anything noteworthy to mention.
The message that you mentions only appeared to me during the initial process when the network devices were activated.

Sat Mar  1 12:50:11 2025 kern.info kernel: [   31.882857] ECM init
Sat Mar  1 12:50:11 2025 kern.info kernel: [   31.882942] ECM database jhash random seed: 0x54a0aa27
Sat Mar  1 12:50:12 2025 kern.info kernel: [   32.037981] ECM init complete
Sat Mar  1 12:50:12 2025 user.notice root: [ethtool] Disabling feature: rx-gro-list: disabled on (10g)
Sat Mar  1 12:50:12 2025 user.notice root: [ethtool] Disabling feature: rx-gro-list: disabled on (lan1)
Sat Mar  1 12:50:12 2025 user.notice root: [ethtool] Disabling feature: rx-gro-list: disabled on (lan2)
Sat Mar  1 12:50:12 2025 user.notice root: [ethtool] Disabling feature: rx-gro-list: disabled on (lan3)
Sat Mar  1 12:50:12 2025 user.notice root: [ethtool] Disabling feature: rx-gro-list: disabled on (lan4)
Sat Mar  1 12:50:12 2025 user.notice root: [ethtool] Disabling feature: rx-gro-list: disabled on (wan)
Sat Mar  1 12:50:12 2025 daemon.notice procd: /etc/rc.d/S26qca-nss-ecm: net.bridge.bridge-nf-call-arptables = 0
Sat Mar  1 12:50:12 2025 daemon.notice procd: /etc/rc.d/S26qca-nss-ecm: net.bridge.bridge-nf-call-iptables = 0
Sat Mar  1 12:50:12 2025 daemon.notice procd: /etc/rc.d/S26qca-nss-ecm: net.bridge.bridge-nf-call-ip6tables = 0
Sat Mar  1 12:50:12 2025 daemon.notice procd: /etc/rc.d/S26qca-nss-ecm: dev.nss.general.redirect = 1

What I do have to mention is that in the last few days I'm having problems when I disable mold in the compilation CONFIG_USE_MOLD=n

It's also curious because when I compile for the r7800 it's the opposite, in this case I have to disable it so that it doesn't give me problems with some packages.

in both compilations I'm using gcc 14.2

[...]
CONFIG_EXPERIMENTAL=y

## Global build settings
CONFIG_BUILD_PATENTED=y
CONFIG_DEBUG=n
CONFIG_USE_GC_SECTIONS=y
CONFIG_USE_LTO=y
CONFIG_USE_MOLD=y

## Advanced configuration options (for developers)
CONFIG_DEVEL=y
CONFIG_CCACHE=y
CONFIG_TOOLCHAINOPTS=y
CONFIG_GCC_USE_VERSION_14=y
CONFIG_GCC_VERSION_14=y
CONFIG_GCC_USE_GRAPHITE=y
CONFIG_BINUTILS_USE_VERSION_2_43=y
CONFIG_TARGET_OPTIONS=y
[...]

root@NBG7815:~# nss_diag
     MODEL: Zyxel NBG7815
   OPENWRT: r28921+166-ce68f61cb6
IPQ BRANCH: nbg7815-main-nss-test
IPQ COMMIT: dc88ad8a06
  IPQ DATE: 2025-03-01
    NSS FW: NSS.HK.11.4.0.5-6-R
  MAC80211: v6.12.6-0-ge9d65b48ce1a
 ATH11K FW: WLAN.HK.2.12-01460-QCAHKSWPL_SILICONZ-1
 INTERFACE: br-lan     tx-checksumming: on  rx-gro-list: on
            10g        tx-checksumming: on  rx-gro-list: off
            lan1       tx-checksumming: on  rx-gro-list: off
            lan2       tx-checksumming: on  rx-gro-list: off
            lan3       tx-checksumming: on  rx-gro-list: off
            lan4       tx-checksumming: on  rx-gro-list: off
            phy0-ap0   tx-checksumming: on  rx-gro-list: off
            phy0-ap1   tx-checksumming: on  rx-gro-list: off
            phy1-ap0   tx-checksumming: on  rx-gro-list: off
            wan        tx-checksumming: on  rx-gro-list: off

  NSS PKGS: kmod-qca-mcs-6.6.80.12.5.2024.02.27~26d6424-r1 aarch64_cortex-a53 {feeds/nss_packages/qca-mcs} () [installed]
            kmod-qca-nss-dp-6.6.80.2024.11.18~4c9f671a-r1 aarch64_cortex-a53 {feeds/base/kernel/qca-nss-dp} () [installed]
            kmod-qca-nss-drv-6.6.80.11.4.0.5.2021.09.13~53e5863-r15 aarch64_cortex-a53 {feeds/nss_packages/qca-nss-drv} () [installed]
            kmod-qca-nss-drv-bridge-mgr-6.6.80.11.4.0.5.2021.08.17~c4049d1-r7 aarch64_cortex-a53 {feeds/nss_packages/qca-nss-clients} () [installed]
            kmod-qca-nss-drv-igs-6.6.80.11.4.0.5.2021.08.17~c4049d1-r7 aarch64_cortex-a53 {feeds/nss_packages/qca-nss-clients} () [installed]
            kmod-qca-nss-drv-pppoe-6.6.80.11.4.0.5.2021.08.17~c4049d1-r7 aarch64_cortex-a53 {feeds/nss_packages/qca-nss-clients} () [installed]
            kmod-qca-nss-drv-qdisc-6.6.80.11.4.0.5.2021.08.17~c4049d1-r7 aarch64_cortex-a53 {feeds/nss_packages/qca-nss-clients} () [installed]
            kmod-qca-nss-drv-vlan-mgr-6.6.80.11.4.0.5.2021.08.17~c4049d1-r7 aarch64_cortex-a53 {feeds/nss_packages/qca-nss-clients} () [installed]
            kmod-qca-nss-ecm-6.6.80.12.5.5.2024.09.12~c5d8727-r2 aarch64_cortex-a53 {feeds/nss_packages/qca-nss-ecm} () [installed]
            kmod-qca-ssdk-6.6.80.2024.06.13~c451136b-r3 aarch64_cortex-a53 {feeds/base/kernel/qca-ssdk} () [installed]
            nss-firmware-default-2024.08.04~794fe373-r1 aarch64_cortex-a53 {feeds/nss_packages/firmware/nss-firmware} () [installed]
            nss-firmware-ipq8074-2024.08.04~794fe373-r1 aarch64_cortex-a53 {feeds/nss_packages/firmware/nss-firmware} () [installed]
root@NBG7815:~#

[pwned]

@asvio

The message that you mentions only appeared to me during the initial process when the network devices were activated.

For me it comes up randomly (it seems) if there is load on the device.

Just grepped "wan":

logread | grep -i ethtool | grep -i  wan
Sat Mar  1 08:25:56 2025 user.notice root: [ethtool] Disabling feature: rx-gro-list: disabled on (wan)
Sat Mar  1 08:25:58 2025 user.notice root: [ethtool] Disabling feature: rx-gro-list: disabled on (wan)
Sat Mar  1 08:26:05 2025 user.notice root: [ethtool] Disabling feature: rx-gro-list: disabled on (wan)
Sat Mar  1 08:26:05 2025 user.notice root: [ethtool] Disabling feature: rx-gro-list: disabled on (wan)
Sun Mar  2 12:22:16 2025 user.notice root: [ethtool] Disabling feature: rx-gro-list: disabled on (wan)
Sun Mar  2 12:52:18 2025 user.notice root: [ethtool] Disabling feature: rx-gro-list: disabled on (wan)
Sun Mar  2 13:22:20 2025 user.notice root: [ethtool] Disabling feature: rx-gro-list: disabled on (wan)
Sun Mar  2 13:26:51 2025 user.notice root: [ethtool] Disabling feature: rx-gro-list: disabled on (wan)
Sun Mar  2 13:52:20 2025 user.notice root: [ethtool] Disabling feature: rx-gro-list: disabled on (wan)
Sun Mar  2 14:22:25 2025 user.notice root: [ethtool] Disabling feature: rx-gro-list: disabled on (wan)
Sun Mar  2 14:52:25 2025 user.notice root: [ethtool] Disabling feature: rx-gro-list: disabled on (wan)
Sun Mar  2 15:22:29 2025 user.notice root: [ethtool] Disabling feature: rx-gro-list: disabled on (wan)
Sun Mar  2 15:52:31 2025 user.notice root: [ethtool] Disabling feature: rx-gro-list: disabled on (wan)
Sun Mar  2 16:22:34 2025 user.notice root: [ethtool] Disabling feature: rx-gro-list: disabled on (wan)
Sun Mar  2 16:52:36 2025 user.notice root: [ethtool] Disabling feature: rx-gro-list: disabled on (wan)
Sun Mar  2 17:22:38 2025 user.notice root: [ethtool] Disabling feature: rx-gro-list: disabled on (wan)
Sun Mar  2 17:52:40 2025 user.notice root: [ethtool] Disabling feature: rx-gro-list: disabled on (wan)
Sun Mar  2 18:22:43 2025 user.notice root: [ethtool] Disabling feature: rx-gro-list: disabled on (wan)
Sun Mar  2 18:52:45 2025 user.notice root: [ethtool] Disabling feature: rx-gro-list: no changes performed on (wan)

@asvio

What I do have to mention is that in the last few days I'm having problems when I disable mold in the compilation CONFIG_USE_MOLD=n

Well, I think I have to check my .config first and see if there were changes within the last 2 month I didn't reflect here.

[sppmaster]

@qosmio

Pushed an update to qca-nss-ecm to reduce log spam.

I no longer have those lines after the initial ones after device reboot. Updated to today's commit.

@asvio

What I do have to mention is that in the last few days I'm having problems when I disable mold in the compilation CONFIG_USE_MOLD=n

It's also curious because when I compile for the r7800 it's the opposite, in this case I have to disable it so that it doesn't give me problems with some packages.

I noted the same. Maybe it's because of the different CPU architecture.
I ran numerous compiles changing the settings till I found a working setup for my R7800-NSS build based on 23.05. For example I had zerotier segmentation fault on start if I used GCC14 for ipq806x but it works with ipq807x.
But when I install the zerotier package from the software tab on ipq806x, it works.

[tardeaux]

Unfortunately, no joy. I updated the bug thread on github with my results.

The DHCP issue from the other thread you linked isn't NSS related, that turned out to be UniFi (gateway router) doing a bad job tagging traffic, so a client would send a tagged request out on VLAN1, then UniFi would fail to tag the response properly. I got around that by just remapping the APs to use VLAN1 as an untagged network end to end since nothing I tried on the Ubiquity end seems to improve anything.

[SlotTech]

Able to compile and it's working great @qosmio Thank you!