Qualcommax NSS Build

Those can be ignored. None of those DTS are required for a proper image. We don't actually compile the required device tree binaries until the target/install phase.

I removed it from my local builds as I didn't like the output either... Didn't add the main build in case it messed things up for others.

--- a/target/linux/qualcommax/Makefile
+++ b/target/linux/qualcommax/Makefile
@@ -4,7 +4,7 @@ ARCH:=aarch64
 BOARD:=qualcommax
 BOARDNAME:=Qualcomm Atheros 802.11ax WiSoC-s
 FEATURES:=squashfs ramdisk fpu nand rtc emmc
-KERNELNAME:=Image dtbs
+KERNELNAME:=Image
 CPU_TYPE:=cortex-a53
 SUBTARGETS:=ipq807x ipq60xx

@qosmio

i have recently switched to your build. i am running the last commit before you bumped it up to 6.6.

any idea whats causing the below? i have set my inactive_time to 604800 (1 week). these devices have NOT been inactive for that long.

also, i noticed when i enter the hostapd_cli terminal and do a forced poll sta, sometimes it will output the encap vif wrong warning in dmesg. when i left my inactive_time at default (300), my dmesg would be packed with these warnings. so the poll sta sometimes, frequently, but not always causes the warning to pop up in dmesg. 100% sure on this last point.

also, initially i thought this was caused by naughty esp8266 devices but no, its happening on my 5ghz interfaces as well with my samsung s23+ and ax211 laptop.

all in all, its pretty benign, doesn't appear to cause any issues. except i use(d) the inactive time in my iot setup which i can't anymore.

last but not least, notice the 2nd paste below... these are on my 5ghz interface where i have not changed the inactive time, so its at default 300. this is not correct, these sta poll events shouldnt really be taking place unless you have long sleeping devices or are on the edge of signal reception.... prior to these new nss+wifi builds i use to very very rarely see these...

@sppmaster can you run logread | grep POLL | wc and paste the output? maybe this is something unique to my setup... although i doubt it as i am seeing it across all 3 of my deivces.

fyi, i am running a very very vanilla /etc/config/wireless. since i just switched over to the nss+wifi builds, i have everything pretyt much disabled (k/v/r/w) and plain jane wpa2.

so to summarize: for some reason regular station activity is not being used to reset the inactive time on associated stations. when hostapds inactive_time is reached, hostapd will send out a sta poll request to make sure the station is alive. this will in turn reset the inactive time, but sometimes / frequently / not always will dmesg out the encap vif warning.

root@OPENWRT-SALON:~# iw dev phy1-ap0 station dump | grep inactive
        inactive time:  30421720 ms
        inactive time:  28629533 ms
        inactive time:  30419920 ms
        inactive time:  30419020 ms
        inactive time:  28619334 ms
        inactive time:  26475453 ms
        inactive time:  15706 ms
        inactive time:  675699 ms
        inactive time:  1251393 ms
        inactive time:  30491289 ms
        inactive time:  30490829 ms
        inactive time:  30491004 ms
        inactive time:  30490906 ms
        inactive time:  30490699 ms
        inactive time:  27234047 ms
        inactive time:  26475654 ms
        inactive time:  4207 ms
        inactive time:  649200 ms
        inactive time:  1222194 ms
        inactive time:  30468802 ms
        inactive time:  30468375 ms
        inactive time:  26085957 ms
        inactive time:  18745 ms
root@OPENWRT-SALON:~# logread | grep POLL | wc
       59       590      5369
1 Like

@sppmaster unrealted to the above. i have been able to fix my ssl issues.

turns out my /etc content is a bit broken as i have gone through MANY sysupgrade over the last year. the sysctl.d file for ecm was missing:

net.netfilter.nf_conntrack_tcp_no_window_check=1

as soon as i add that to my sysctl, all ssl issues are gone.

1 Like
root@QNAP:~# logread | grep POLL | wc
      299      2990     27209

@anom3
I don't know if this can negatively impact the wifi.
One new follow up about the stability. Last night I saw first reboot of the router. I don't know the reason and seems we don't have pstore enabled to see the kernel dumps.
I can't remember if only choosing it from menuconfig is enough to work or anything else is needed.

looks like its doing it on yours as well.

as mentioned, the STA POLLs should be fairly rare...

any sort of traffic should reset the counter, and the ap should only poll the client if it has been idle for a long time. the default which you probably have is 5 minutes (300 secs). within 300 secs pretty much every device will do something, thus resetting the counter.

generally speaking, the sta polls are used for situations where you walk away from your house and your device has not had a chance to gracefully disconnect from the ap. so the ap sends out a 'hey are you still there?'.

yeah, they are used in other situations but thats the most common use as far as we are concerned.

2 Likes

After 1 day on 1-4-24 Julius build, getting these errors, but also seen in earlier (these few weeks) of NSS builds from others. Running out of builds to try.

This is a AX3600 as STA-WDS and AP, aka a wifi repeater.

Thu Apr  4 11:49:59 2024 kern.warn kernel: [109948.301695] br-lan: received packet on wi-wds with own address as source address (addr:b8:b8:b8:b8:b8:b8, vlan:0)
Thu Apr  4 12:49:33 2024 kern.warn kernel: [113522.621193] br-lan: received packet on wi-wds with own address as source address (addr:b8:b8:b8:b8:b8:b8, vlan:0)
Thu Apr  4 15:27:40 2024 kern.warn kernel: [123009.697676] br-lan: received packet on wi-wds with own address as source address (addr:b8:b8:b8:b8:b8:b8, vlan:0)
Thu Apr  4 15:32:50 2024 kern.warn kernel: [123319.871309] br-lan: received packet on wi-wds with own address as source address (addr:b8:b8:b8:b8:b8:b8, vlan:0)
Thu Apr  4 16:19:05 2024 kern.warn kernel: [126094.128348] br-lan: received packet on wi-wds with own address as source address (addr:b8:b8:b8:b8:b8:b8, vlan:0)
Thu Apr  4 16:20:36 2024 kern.warn kernel: [126185.470621] br-lan: received packet on wi-wds with own address as source address (addr:b8:b8:b8:b8:b8:b8, vlan:0)

also this:

Thu Apr  4 12:06:59 2024 daemon.notice hostapd: nl80211: nl80211_recv_beacons->nl_recvmsgs failed: -5
Thu Apr  4 12:06:59 2024 daemon.notice hostapd: nl80211: nl80211_recv_beacons->nl_recvmsgs failed: -5
Thu Apr  4 12:16:25 2024 daemon.notice hostapd: nl80211: nl80211_recv_beacons->nl_recvmsgs failed: -5
Thu Apr  4 12:20:34 2024 daemon.notice hostapd: nl80211: nl80211_recv_beacons->nl_recvmsgs failed: -5
Thu Apr  4 12:47:51 2024 daemon.notice hostapd: nl80211: nl80211_recv_beacons->nl_recvmsgs failed: -5
Thu Apr  4 12:47:51 2024 daemon.notice hostapd: nl80211: nl80211_recv_beacons->nl_recvmsgs failed: -5
Thu Apr  4 12:49:24 2024 daemon.notice hostapd: nl80211: nl80211_recv_beacons->nl_recvmsgs failed: -5
Thu Apr  4 12:49:24 2024 daemon.notice hostapd: nl80211: nl80211_recv_beacons->nl_recvmsgs failed: -5

and something that looks serious:

Thu Apr  4 05:00:40 2024 kern.warn kernel: [85389.351897] WARNING: CPU: 0 PID: 0 at backports-6.6.15/net/wireless/nl80211.c:18857 cfg80211_rx_unexpected_4addr_frame+0x44/0x1ac [cfg80211]
Thu Apr  4 05:00:40 2024 kern.warn kernel: [85389.355560] Modules linked in: ecm(O) jitterentropy_rng nft_fib_inet nf_flow_table_inet ath11k_ahb(O) ath11k(O) ath10k_pci(O) ath10k_core(O) ath(O) nft_reject_ipv6 nft_reject_ipv4 nft_reject_inet nft_reject nft_redir nft_quota nft_numgen nft_nat nft_masq nft_log nft_limit nft_hash nft_flow_offload nft_fib_ipv6 nft_fib_ipv4 nft_fib nft_ct nft_chain_nat nf_tables nf_nat nf_flow_table nf_conntrack mac80211(O) cfg80211(O) qrtr_smd qrtr qmi_helpers(O) ppp_async nfnetlink nf_reject_ipv6 nf_reject_ipv4 nf_log_syslog nf_defrag_ipv4 libcrc32c l2tp_ppp compat(O) sch_tbf sch_ingress sch_htb sch_hfsc em_u32 cls_u32 cls_route cls_matchall cls_fw cls_flow cls_basic act_skbedit act_mirred act_gact qca_nss_cfi_cryptoapi(O) qca_nss_crypto(O) qca_nss_qdisc(O) qca_nss_vxlanmgr(O) qca_nss_pptp(O) pptp qca_nss_pppoe(O) pppoe pppox qca_nss_map_t(O) qca_nss_l2tpv2(O) ppp_generic slhc qca_nss_gre(O) qca_nss_bridge_mgr(O) qca_nss_vlan(O) ip6_gre ip_gre gre ifb nat46(O) nf_defrag_ipv6 qca_nss_drv(O) ip6_tunnel tunnel6 vxlan sha512_generic
Thu Apr  4 05:00:40 2024 kern.warn kernel: [85389.355777]  sha512_arm64 seqiv sha3_generic drbg michael_mic hmac geniv cmac leds_gpio xhci_plat_hcd xhci_pci xhci_hcd dwc3 dwc3_qcom qca_nss_dp(O) qca_ssdk(O) gpio_button_hotplug(O) ext4 mbcache jbd2 aquantia hwmon crc_ccitt crc32c_generic
Thu Apr  4 05:00:40 2024 kern.warn kernel: [85389.457837] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G           O       6.6.23 #0
Thu Apr  4 05:00:40 2024 kern.warn kernel: [85389.479074] Hardware name: Xiaomi AX3600 (DT)
Thu Apr  4 05:00:40 2024 kern.warn kernel: [85389.486534] pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
Thu Apr  4 05:00:40 2024 kern.warn kernel: [85389.490791] pc : cfg80211_rx_unexpected_4addr_frame+0x44/0x1ac [cfg80211]
Thu Apr  4 05:00:40 2024 kern.warn kernel: [85389.497562] lr : ieee80211_rx_nss_notify_4addr+0x14/0x2b8 [mac80211]
Thu Apr  4 05:00:40 2024 kern.warn kernel: [85389.504505] sp : ffffffc080003d30
Thu Apr  4 05:00:40 2024 kern.warn kernel: [85389.510922] x29: ffffffc080003d30 x28: ffffffc07900e5f0 x27: ffffff801346c000
Thu Apr  4 05:00:40 2024 kern.warn kernel: [85389.514142] x26: 0000000000000001 x25: 0000000000000001 x24: ffffff8008f66000
Thu Apr  4 05:00:40 2024 kern.warn kernel: [85389.521261] x23: ffffffc078fc597c x22: ffffff8009532020 x21: ffffff80074c0000
Thu Apr  4 05:00:40 2024 kern.warn kernel: [85389.528378] x20: ffffff80074cbf80 x19: ffffff8012708300 x18: 0000000000000000
Thu Apr  4 05:00:40 2024 kern.warn kernel: [85389.535497] x17: ffffffbf9f3b4000 x16: ffffffc080000000 x15: 0000000000000000
Thu Apr  4 05:00:40 2024 kern.warn kernel: [85389.542614] x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000
Thu Apr  4 05:00:40 2024 kern.warn kernel: [85389.549732] x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000
Thu Apr  4 05:00:40 2024 kern.warn kernel: [85389.556850] x8 : ffffffc080bf9000 x7 : 0000000000000001 x6 : ffffffc080bf9088
Thu Apr  4 05:00:40 2024 kern.warn kernel: [85389.563969] x5 : 0000000000000004 x4 : 00000000ffffffff x3 : 0000000000000820
Thu Apr  4 05:00:40 2024 kern.warn kernel: [85389.571087] x2 : 0000000000000002 x1 : ffffff8008f66024 x0 : ffffff801346c000
Thu Apr  4 05:00:40 2024 kern.warn kernel: [85389.578206] Call trace:
Thu Apr  4 05:00:40 2024 kern.warn kernel: [85389.585313]  cfg80211_rx_unexpected_4addr_frame+0x44/0x1ac [cfg80211]
Thu Apr  4 05:00:40 2024 kern.warn kernel: [85389.587579]  ath11k_nss_update_wds_peer+0x58c/0x5bc [ath11k]
Thu Apr  4 05:00:40 2024 kern.warn kernel: [85389.594174]  nss_core_send_buffer+0x18cc/0x20ec [qca_nss_drv]
Thu Apr  4 05:00:40 2024 kern.warn kernel: [85389.599903]  nss_core_handle_napi_queue+0x30/0x80 [qca_nss_drv]
Thu Apr  4 05:00:40 2024 kern.warn kernel: [85389.605546]  __napi_poll+0x38/0x178
Thu Apr  4 05:00:40 2024 kern.warn kernel: [85389.611269]  net_rx_action+0x144/0x298
Thu Apr  4 05:00:40 2024 kern.warn kernel: [85389.614744]  __do_softirq+0xf8/0x254
Thu Apr  4 05:00:40 2024 kern.warn kernel: [85389.618562]  ____do_softirq+0x10/0x1c
Thu Apr  4 05:00:40 2024 kern.warn kernel: [85389.622295]  call_on_irq_stack+0x24/0x4c
Thu Apr  4 05:00:40 2024 kern.warn kernel: [85389.625855]  do_softirq_own_stack+0x1c/0x2c
Thu Apr  4 05:00:40 2024 kern.warn kernel: [85389.629848]  irq_exit_rcu+0x90/0xc8
Thu Apr  4 05:00:40 2024 kern.warn kernel: [85389.633752]  el1_interrupt+0x38/0x54
Thu Apr  4 05:00:40 2024 kern.warn kernel: [85389.637226]  el1h_64_irq_handler+0x18/0x24
Thu Apr  4 05:00:40 2024 kern.warn kernel: [85389.641045]  el1h_64_irq+0x68/0x6c
Thu Apr  4 05:00:40 2024 kern.warn kernel: [85389.644950]  default_idle_call+0x28/0x3c
Thu Apr  4 05:00:40 2024 kern.warn kernel: [85389.648337]  do_idle+0x1fc/0x228
Thu Apr  4 05:00:40 2024 kern.warn kernel: [85389.652416]  cpu_startup_entry+0x34/0x3c
Thu Apr  4 05:00:40 2024 kern.warn kernel: [85389.655628]  kernel_init+0x0/0x1e0
Thu Apr  4 05:00:40 2024 kern.warn kernel: [85389.659534]  arch_post_acpi_subsys_init+0x0/0x8
Thu Apr  4 05:00:40 2024 kern.warn kernel: [85389.662748]  start_kernel+0x508/0x618
Thu Apr  4 05:00:40 2024 kern.warn kernel: [85389.667174]  __primary_switched+0xb4/0xbc
Thu Apr  4 05:00:40 2024 kern.warn kernel: [85389.670994] ---[ end trace 0000000000000000 ]---

@qosmio

i've found, and fixed a bug with sqm-scripts-nss

/lib/sqm/nss-zk.qos

BURST100 should never be lower than MTU, otherwise, in dmesg:

[ 1203.316684] nss_tbl_change[187]:Burst size: 1214 is less than the specified MTU: 1514

this pops up for people who have a slightly slower upstream, like me, at 100000kbit the calculation is:


SQM: calc_limit: Queue limit should be 823 packets for speed 100000, MTU 1518 and maximum delay 100 ms

so, 100000/823 = 1214, and it plugs that into:

SQM: ERROR: cmd_wrapper: tc: FAILURE (2): /sbin/tc qdisc add dev lan4 parent 10:1 handle 100: nsstbl rate 10000kbit burst 1214 accel_mode 0
SQM: ERROR: cmd_wrapper: tc: LAST ERROR: RTNETLINK answers: Invalid argument

anyways, im no tc wizard but i just popped this into /lib/sqm/nss-zk.qos:

  if [ $BURST100 -lt $MTU ]; then
        BURST100=$MTU
  fi

line 141


btw, fully working sqm now. 500/100 limits, while fully loaded ping increases by 0-5ms max both up / down.

4 Likes

Is there anyone that can compile a nss build including sqm nss for the dl-wrx36 as I don’t currently have the means to do this myself at the moment? Thanks in advanced.

Hey, I am not getting any of these issues on my end. My router has been up for 1 day 6 hours now.

The first & second issues seem to be related to your configuration and not nss. Please try using upstream openwrt and see if you get the same error with the same configuration.

I cannot say anything about the third error.

Thanks, I will try out Openwrt snapshots. I doubt it is specific to your build as I have these in other nss builds too.

I wonder if there are others with similar WDS setup without issues.

maybe you should try the latest build... kernel 6.6.15? 6.6.23 is the latest .

Some others on here are using that router. Qosmio has been doing some recent work on NSS support, you can check out his repo. Its very bleeding bleeding edge as it were. There are some links at the top of this topic. AgustinLorenzo has been creating releases based on Qosmio and others. I use his builds, and tinker with building my own based on his repo, and add some packages. He also includes a .full_config which is handy for loading into the menuconfig gui as a solid starting point.

I also have the same error, and the error is given on vlan 30, at this point I'm thinking that there is a limit with a >=30 for the vlan id.

1 Like

@qosmio - I figured out why insmod wasnt loading the kmods on my system - for some reason it was expecting the full path to the module. E.g.,

insmod ecm param=val

didnt work, but

insmod /lib/modules/$(uname -r)/ecm.ko param=val

worked just fine. Interestingly, either form (module name or module path) works with rmmod

Im gussing this is not the "standard" behavior, but if using the full module paths doesnt break the "standard" behavior then perhaps it would be worth changing all the insmod comands in the init scripts to use

insmod /lib/modules/$(uname-r)/<KMOD_NAME>.ko

(just in case my system isnt the only one with this quirk)

Thanks! Can you do a PR so I can merge and credit you?

Done,

Thanks for all the work BTW.

Can you post the output of

❯ ls -ltr $(which insmod)
❯ ls -ltr $(which modprobe)

Trying to figure out which distro you're using (kmodloader, or kmod)

Trying to figure out which distro you're using (kmodloader, or kmod)

both /sbin/insmod and /sbin/modprobe are symlinked to /sbin/kmod

root@OpenWrt_WRX36:~# ls -ltr $(which insmod)
lrwxrwxrwx 1 root root 10 Apr  3 15:37 /sbin/insmod -> /sbin/kmod
root@OpenWrt_WRX36:~# ls -ltr $(which modprobe)
lrwxrwxrwx 1 root root 10 Apr  3 15:37 /sbin/modprobe -> /sbin/kmod

edit: I also checked rmmod and it is linked to sbin/kmod as well.

It is already on kernel 6.6.23 on 2024-04-01 Julius's build.

I think the issue is WDS / 4addr perhaps upstream.

1 Like

I have a AX3600, been running 3.0.22 stock firmware with SSH since 2021 and it has been very solid, however very lacking in features.

Was very happy when I read about the official OpenWRT support, but after some reading I found out that the offical firmware has some performance issues, mainly lacking NSS?

Do you think this build is stable and as fast as stock firmware?

I can't decide if I should go to this build or back to 3.0.22 (bricked the install somehow, after tinkering with settings in SSH).