IPQ806x NSS Drivers

Thanks - I'll give it a go! :slight_smile:

Is it possible to have the nss drivers compiled with the stable release 19.07.5 and not with the master/snapshot? Because I am unable to install some packages such as openvpn and samba I get the same exact error

Collected errors:
 * pkg_hash_fetch_best_installation_candidate: Packages for kmod-tun found, but incompatible with the architectures configured

Unfortunately not. You need a 5.4 kernel (master). To run it on 19.07 you need to back port it.

Anyone having compiling errors on NSS build with the wireless-regdb master commit?

I've tried to run the usual process, and it failed. I do see issues with the patches / rebase / merge.

I pulled a fresh copy from my GitHub and did a make dirclean. All issues fixed. I started a NSS community build if you want to start there :sunglasses:

1 Like

anybody notice any large IPv6 jitter? i have a bit of a sub-optimal setup now (Sky UK), i have to use their router so i put my R7800 in the DMZ (which is irrelevant for IP6 i gather).

anyway when i ping the LAN port of the Sky router (which is connected to the WAN port of my R7800) from a PC connected to the R7800 (wired or wireless) using IP6, i get enormous jitter...it should be around the 1-2ms range, but it sporadically (as in once every few seconds) shoots up to 8-900ms.

pinging over IP4 there is no such jitter, it maybe gets up to 8-9ms occasionally, but that's it. if i ping the IP6 address of the R7800 WAN port, it's also fine. if i ping the IP6 address of the Sky router LAN port from the R7800 directly (instead of a PC connected to the R7800), it's also fine. naively this makes me think the issue is on the R7800 somewhere, perhaps with NSS IP6 acceleration?

i have yet to try with a non-NSS build as i only just noticed this issue.

i'd guess this is an non-nss issue...

after 4 days it has been restarted tonight, so for now, kernel 5.4.80 is the one that is always in the equation. My question, is it possible to use kernel 4.14 with NSS driver?

It would be the test that I have left to certify that the kernel 5.4.80 is unstable with high workload.

yes you're right, without NSS i have the same problem.

1 Like

I made a NSS build for C2600 and EA8500 in community builds. I have one person reporting they tried to load the EA8500 build but it didn’t boot. Anyone else build or try a NSS build on a C2600 or EA8500 and were successful? (if so did you have to modify anything to get it to work, I don’t have either of these devices but I’m trying to make a easy to download build so that people try it out).

same problem withlinksys ea7500 v1, I would try too,but nobody can make it for the moment

can you provide a link to the build or git repo?

Just to let you know I'm working on the NSS Crypto driver at the moment. I fixed most of the problems using the extended crypto tests that are disabled by default in the kernel.

I added AES-ECB because it doesn't need an IV, which is a problem to do non-copy scatter lists. For ECB I am able to use "multi-buffer" scatter lists. The "nss-ecb-aes" can be used in combination with e.g. AES-XTS as used in DM-Crypt.

root@OpenWrt:/# cryptsetup benchmark
# Tests are approximate using memory only (no storage IO).
PBKDF2-sha1        41269 iterations per second for 256-bit key
PBKDF2-sha256      75328 iterations per second for 256-bit key
PBKDF2-sha512        N/A
PBKDF2-ripemd160     N/A
PBKDF2-whirlpool     N/A
argon2i       4 iterations, 71144 memory, 4 parallel threads (CPUs) for 256-bit key (requested 2000 ms time)
argon2id      4 iterations, 70000 memory, 4 parallel threads (CPUs) for 256-bit key (requested 2000 ms time)
#     Algorithm |       Key |      Encryption |      Decryption
        aes-cbc        128b        44.4 MiB/s        42.9 MiB/s
    serpent-cbc        128b               N/A               N/A
    twofish-cbc        128b               N/A               N/A
        aes-cbc        256b        37.0 MiB/s        33.8 MiB/s
    serpent-cbc        256b               N/A               N/A
    twofish-cbc        256b               N/A               N/A
        aes-xts        256b        41.4 MiB/s        42.9 MiB/s
    serpent-xts        256b               N/A               N/A
    twofish-xts        256b               N/A               N/A
        aes-xts        512b        37.6 MiB/s        34.8 MiB/s
    serpent-xts        512b               N/A               N/A
    twofish-xts        512b               N/A               N/A

#     Algorithm |       Key |      Encryption |      Decryption
        aes-cbc        128b        48.0 MiB/s        43.6 MiB/s
    serpent-cbc        128b               N/A               N/A
    twofish-cbc        128b               N/A               N/A
        aes-cbc        256b        37.1 MiB/s        34.5 MiB/s
    serpent-cbc        256b               N/A               N/A
    twofish-cbc        256b               N/A               N/A
        aes-xts        256b        89.4 MiB/s        90.1 MiB/s
    serpent-xts        256b               N/A               N/A
    twofish-xts        256b               N/A               N/A
        aes-xts        512b        82.8 MiB/s        78.5 MiB/s
    serpent-xts        512b               N/A               N/A
    twofish-xts        512b               N/A               N/A

root@OpenWrt:/# grep "xts" /proc/crypto 
name         : xts(aes)
driver       : xts(ecb(aes-generic))
module       : xts
name         : xts(aes)
driver       : xts(nss-ecb-aes)
module       : xts

Updates will follow...

3 Likes

@kipper - made a build for the C2600 (It is untested). Feel free to test it and give feedback.

@ACwifidude: is your build based on the dts that @Ansuel has made available in his repo? If it is, it probably won't work as I had tested it myself. It seems that some tweaks will be required in order to make it work (there's a GPL available for the C2600 but I lack the knowledge to contribute to the fix).

Hi,

I am using closed source QSDK v11.2 and currently struggling with getting ingress shaping to work on eth0 with NSS enabled(IPQ6018 reference board) since ifb is not supported.

Egress shaping works okay right now . Am using the following

tc qdisc add dev eth0 root handle 1: nsshtb r2q 20
tc class add dev eth0 parent 1: classid 1:1 nsshtb rate 1000Mbit crate 1000Mbit burst 100k cburst 100k
tc class add dev eth0 parent 1:1 classid 1:2 nsshtb rate 2Mbit crate 2Mbit burst 30k cburst 30k priority 0
tc class add dev eth0 parent 1:1 classid 1:3 nsshtb rate 40Mbit crate 100Mbit burst 30k cburst 30k priority 1
tc class add dev eth0 parent 1:1 classid 1:4 nsshtb rate 0Mbit crate 1000Mbit burst 30k cburst 30k priority 2
tc qdisc add dev eth0 parent 1:2 handle 2: nsspfifo limit 100
tc qdisc add dev eth0 parent 1:3 handle 3: nsspfifo limit 100
tc qdisc add dev eth0 parent 1:4 handle 4: nsspfifo limit 100 set_default

Any idea how to get it working ? Also, are you aware about IGS interface https://source.codeaurora.org/quic/cc-qrdk/oss/lklm/nss-drv/log/?h=NHSS.QSDK.11.3&qt=grep&q=IGS

not sure how to use this one though..

Kong made a tweak that got the EA8500 up and running. It will likely help your device too. If you want to test it I can help troubleshoot / tweak the C2600 .dts

The IGS interface is only available for the ipq60xx and ipq807x SoCs. So I could not try it as I only have an ipq8065 router.

From the QSDK 11.3 source tho, it looks like the IGS interface is used together with the Linux IFB interface for ingress shaping. Since you’re already using egress shaping that means that you have the nss-clients qdisc module loaded. If I’m not wrong you just need to create a new IFB interface and configure qdisc with the ‘tc’ utility. That should get ingress shaping up.