IPQ806x NSS Drivers

grep isolate /etc/config/wireless /tmp/run/hostapd-phy*
/etc/config/wireless:	option isolate '1'
/etc/config/wireless:	option isolate '1'
/etc/config/wireless:	option isolate '1'
/etc/config/wireless:	option isolate '1'
/etc/config/wireless:	option isolate '1'
/etc/config/wireless:	option isolate '0'
/etc/config/wireless:	option isolate '0'
/tmp/run/hostapd-phy0.conf:ap_isolate=1
/tmp/run/hostapd-phy0.conf:ap_isolate=1
/tmp/run/hostapd-phy0.conf:ap_isolate=1
/tmp/run/hostapd-phy0.conf:ap_isolate=1
/tmp/run/hostapd-phy1.conf:ap_isolate=1
/tmp/run/hostapd-phy1.conf:ap_isolate=1
/tmp/run/hostapd-phy1.conf:ap_isolate=1
/tmp/run/hostapd-phy1.conf:ap_isolate=1

@quarky you are correct: it is not working. All AP's came up with ap_isolate=1...

I increased min cpu frequency to 800 MHz and locked nss frequency to 600 MHz. That is what I understood was requred to avoid the reboots at this point. Is my approach correct?

Yeah, I've read that somewhere in the forum. But what changed with the nss committs that is now impacting this? Before upgrading to the nss version, I was not having this issue.

I still did not test ap_isolate=0 to see if that solves the problem as family is now heavily using the internet...

Will try and will report back. Thanks!

And now I am confused: even though ap_isolate=1 for all IP's in hosted files, pings are still working according to the isolate settings in /etc/config/wireless ...

This may clarify things a bit:

1 Like

I think we probably may have found a cause. It could be that really when we enabled the NSS drivers, it caused the WiFi problem. My suspicion is that with NSS enabled, it took over the bridge routing tasks as well, and this somehow reset the hairpin mode for WiFi interfaces bridge ports, but perfectly fine for LAN bridge ports. That is why I asked @rog to reset the hairpin mode to inform the NSS drivers again. This is also the reason why I think I can ping WiFi clients across WiFi interfaces but not on the same interface, unless I reset the hairpin_mode.

I'll dig into the NSS code and see if that can be fixed. Meanwhile, the hairpin_mode setting seems to work for me.

1 Like

I think I found the explanation why it is working for me. Yes, ap_isoalate=1 for all AP's and the clients are isolated, unless there is net.bridge.bridge-nf-call-iptables=1 setting (to isolate 2GHz clients from 5GHz clients). The AP's that are not isolated are in a firewall zone with forward=accept while AP's that should be isolates are in a firewall zone with firewall=drop.
The wifi clients in the first zone can see each other while the clients in the second zone cannot see each other. If I change the forward rules, the the behaviour reverses: now the clients in the first zone cannot see each other while the clients in the second zone can ping each other just fine.
So it looks like all packets are forwarded up to the bridge, which now decides if the clients can or cannot talk to each other (including the clients connected to the same the same AP)...

The '/sys/class/net//brport/hairpin_mode' settings further controls whether nodes on the same bridge port can communicate with each other. If you imagine the traffic flow from node A to node B where both nodes are on the same bridge port, it'll look like a hairpin, hence the name. If you set it to '0', nodes within the same bridge port will not be able communicate with each other. I suspect this is the issue that @rog and myself have encountered when the NSS drivers are activated.

I remember some other forum members also reported the same issue some time back in this forum.

1 Like

@quarky I got erro on "qca-nss-firmware" ,didn't find the file "qca-nss0-retail.bin" in package/qca/qca-nss-firmware/files/nss-firmware

make[3]: Leaving directory '/media/jack/128G/sam2/masternss/package/network/utils/iw'
time: package/network/utils/iw/tiny/compile#5.91#1.31#8.55
make[3]: Entering directory '/media/jack/128G/sam2/masternss/package/qca/qca-nss-firmware'
rm -rf /media/jack/128G/sam2/masternss/build_dir/target-arm_cortex-a15+neon-vfpv4_musl_eabi/qca-nss-firmware/.pkgdir/qca-nss-firmware.installed /media/jack/128G/sam2/masternss/build_dir/target-arm_cortex-a15+neon-vfpv4_musl_eabi/qca-nss-firmware/.pkgdir/qca-nss-firmware
mkdir -p /media/jack/128G/sam2/masternss/build_dir/target-arm_cortex-a15+neon-vfpv4_musl_eabi/qca-nss-firmware/.pkgdir/qca-nss-firmware
install -d -m0755 /media/jack/128G/sam2/masternss/build_dir/target-arm_cortex-a15+neon-vfpv4_musl_eabi/qca-nss-firmware/.pkgdir/qca-nss-firmware/lib/firmware
cp -fpR ./files/nss-firmware/qca-nss0-retail.bin /media/jack/128G/sam2/masternss/build_dir/target-arm_cortex-a15+neon-vfpv4_musl_eabi/qca-nss-firmware/.pkgdir/qca-nss-firmware/lib/firmware/qca-nss0.bin
cp: cannot stat './files/nss-firmware/qca-nss0-retail.bin': No such file or directory
Makefile:24: recipe for target '/media/jack/128G/sam2/masternss/build_dir/target-arm_cortex-a15+neon-vfpv4_musl_eabi/qca-nss-firmware/.pkgdir/qca-nss-firmware.installed' failed
make[3]: *** [/media/jack/128G/sam2/masternss/build_dir/target-arm_cortex-a15+neon-vfpv4_musl_eabi/qca-nss-firmware/.pkgdir/qca-nss-firmware.installed] Error 1
make[3]: Leaving directory '/media/jack/128G/sam2/masternss/package/qca/qca-nss-firmware'
time: package/qca/qca-nss-firmware/compile#0.21#0.10#0.29
package/Makefile:111: recipe for target 'package/qca/qca-nss-firmware/compile' failed
make[2]: *** [package/qca/qca-nss-firmware/compile] Error 2
make[2]: Leaving directory '/media/jack/128G/sam2/masternss'
package/Makefile:107: recipe for target '/media/jack/128G/sam2/masternss/staging_dir/target-arm_cortex-a15+neon-vfpv4_musl_eabi/stamp/.package_compile' failed
make[1]: *** [/media/jack/128G/sam2/masternss/staging_dir/target-arm_cortex-a15+neon-vfpv4_musl_eabi/stamp/.package_compile] Error 2
make[1]: Leaving directory '/media/jack/128G/sam2/masternss'
/media/jack/128G/sam2/masternss/include/toplevel.mk:222: recipe for target 'world' failed
make: *** [world] Error 2

Unfortunately you have to source for the qsdk11 NSS firmware binaries. I do not have any rights to distribute it. You probably missed the discussion earlier in this thread.

OK, understood
Thank you

for now you are stuck with qsdk10 or 6

I didn't try qsdk10 or 6 yet
Do you have any idea? I really want to try openwrt master with nss driver

thanks

My repo... we are testing stability and you need to do some workaround to make it stable... just read some post up... also i need to sync qith quarky changes so the package to select are different

ok,I got it
I guess it's hard for me to test nss driver at the monent
maybe I need wait for the final stable version later
thanks for your great job :handshake:

Hi all. I had to revert back to non-nss firmware due to the wifi ping problem but router did not have any reboots since yesterday.

@quarky: echo 1 > /sys/class/net/wlan[x]/brport/hairpin_mode did not work for me. In addition, I did not have time to figure out how to change the ap_isolate option to "0" to see if that would solve the problem.

Could you give me more details on how to do that? I did not find any easy fix for that.

Hi guys,

Managed to merge Ansuel "kernel5.4-nss-qsdk10.0" branch and building image is ok.
But what is the way to force NSS cores to 800MHz (for expected stability) for testing?

I cannot find a direct answer for that in above messages.

echo 800000000 > /proc/sys/dev/nss/clock/current_freq