IPQ806x NSS Drivers

@quarky I'm currently testing your latest ipq806x nss branch and for the most part things are working great. However, I'm having issues with WLAN where clients on the same AP (5G or 2G) are not able to communicate/ping between each other. I AM however able to ping between 5G and 2G and any clients that are hardwired.

I've used your custom image from Aug 15 to see if I messed something up, but it exhibits the same problem.

I've confirmed that the "isolate" option in NOT set, and even set it manually to "0" using uci.

@qosmio do you see the same result with the plain OpenWRT or LEDE firmware, i.e. without the NSS cores enabled. I'm able to ping my iMac from my iPad, both on the wireless network of my R7800, running my own firmware with NSS drivers running. I'm also able to remote desktop using VNC from my iPad to my iMac. Pinging my iPad from my iMac works too, although the iPad need to be awake.

My guess would be your wireless clients are dropping ICMP packets.

You can disable NSS processing for wireless traffic in my firmware by executing the following from a SSH shell:

echo 0 > /sys/module/mac80211/parameters/is_nss_enable

Try pinging after disabling and see if the issue is due to the NSS stack. I would think it's unlikely to be NSS related tho.

Disabling NSS for mac80211 will result in a drop in wireless thruput tho.

@quarky thanks for the reply! So, I tried disabling NSS with the setting you mentioned (using your factory image) and I'm getting some pretty inconsistent results. I was still not able to communicate between my clients (Rpi 4, MacBook, iPhone and iPad) when on the same WLAN.

I then tried reconnecting my clients after using your setting, and after about 2-3 mins it looked like I was able to communicate between my MacBook and Pi. I tried enabling the NSS cores and it seemed to work. But in subsequent reconnects I could no longer ping or communicate in any form (SSH/TELNET). Only 2G<->5G or LAN<->5G/2G work. This is for both your image and my own I customized from your latest branch.

I then tried both @hnyman and Kong's builds and both worked in allowing my WLAN clients to communicate.

It's a shame really, I pretty much had everything working great with your branch with my customization.

@qosmio Now I see what you mean. I see the same issue if both wireless clients are in the same band. It's as if the clients are all isolated from each other. Previously I tried with two clients on different wireless bands, i.e. one of 2G and the other on 5G.

Will look into it when I have some spare time.

Thanks.

1 Like

could be a limitation of the nss core?

Thanks! Honestly, a bit relieved you're having the same issue. I thought I may have done something wonky. I've switched back to my R7000 XWRT build in the mean time. I tried troubleshooting with this post (Clients in same WLAN can't reach each other).

No luck, not sure if it's even related. Figured it was worth a shot.

From what I can see it looks like issue lies with the old ath10k or mac80211 driver. Likely newer drivers resolved this issue. Unlikely to be caus3d by the NSS cores, or all communications will have issues. I am able to ping clients between 2G and 5G WiFi network. Problem seems to exist when clients are on the same WiFi freq band. I suspect the mac80211 driver is enforcing client isolation even when it’s not enabled.

1 Like

Both mac80211 and ath10k drivers would be kernel specific correct? I tried upgrading the kernel all the way up to 4.4.206 in the hopes there were some fixes to mac80211 and ath10k that mitigated this. I had to tweak the patches a little bit but it compiled. However, upon activating the wireless I had a kernel panic and it rebooted :neutral_face:

The highest version I was able to get was 4.4.196 that didn't kernel panic, but that didn't seem to fix my same WLAN client isolation issue.

Lastly, I tried compiling the 17.04 branch without any of the NSS patches and it didn't exhibit the issue. So, something seems to be related to the NSS patches.

OpenWrt uses an out-of-tree version of mac80211, so upgrading the kernel has little effect

1 Like

So, I got it working. It's not an ideal solution but it works for what I need, and doesn't compromise on all the work @quarky's done getting NSS acceleration working.

For me, the solution was to ensure ap_isolate=0 in the WiFi configs hostapd generates. I had to edit /lib/functions/hostapd.sh and hardcode the value since setting "option isolate 0" has no effect in the generated config. I believe the reason for this was to have everything forwarded to the bridge, and have the isolation controlled there... but, since that doesn't work to begin with...

Hope this helps someone. Again, not ideal as it will mean you're removing the isolation feature for every WLAN. I suppose I could update the hostapd.sh script to only apply it to non-guest WLANs, but not really something I wanna much around with more.

1 Like

@quarky Do you remember if the nss-drv needed the qsdk package?

@Ansuel qsdk is not used by the NSS drivers. As far as I know it’s standalone. It’s basically a utility tool used to configure the qca8337 switch.

But nss drivers is the one that load the firmware right? To use nss crypto feature i don't need qsdk

Correct. The nss-drv module loads the firmware. The nss-crypto driver provides the APIs to use the crypto engine. The nss-clients then uses those APIs to accelerate IPSec crypto functions, among other things. QSDK is mainly used to configure the switch. It’s not used by the NSS drivers.

To achieve network acceleration you only need the following:

qca-gmac
qca-drv
qca-ecm
nss-firmware

1 Like

In your opinion is possible to accelerate raw crypto operation (and make openssl use the nss core?)

From later versions of the NSS firmware and drivers it seems Qualcomm has already done the work to accelerate OpenVPN, but we do not have access to the latest NSS firmware.

IPSec support supposedly already added in the version of the firmware and drivers in my Github repo, although it does not seem to work right. Someone tried to use IPSec and failed. Only works when NSS is bypassed. I haven’t spent too much time on IPSec tho.

As for OpenSSL acceleration, I tried. Performance was terrible, but it’s likely due to how I wrote the driver. Too much interrupts. Technically it is possible. Practically, not sure, as we don’t have much documentation to go with. I sort of understand how the firmware and drivers talks to achieve crypto functionalities using the NSS cores, but without knowing the full suite of APIs that the firmware provides for crypto functions I think it’ll be hard to make it work well. Will be lots of trial and errors.

1 Like

Could be also a problem with the frequency scaling.
For now I will try to make the drv works on 5.4 (overkill)

7 Likes

It’ll be great when you get it to work. Good luck.

2 Likes

Just curious. Ansuel did you had any luck getting it working on 5.4?
being able to run this against master would significantly improve adoption I think.

1 Like

Would love to know the same, @Ansuel. Thanks!