I noticed that openvpn’s performance is well below expectations, on average 80Mbps is the maximum I can get, and this is using AES-128 to alleviate processing.
I verified that the CPU supports AES, but it appears that the Kernel does not have the module enabled. Am I correct about this?
If so, is there a plan to enable them in the kernel?
Best regards
At the risk of being off topic I’ll add my findings for my Spitz AX.
When doing the grep I’m getting
arc4
chacha_neon
crc32_generic
crc32c_generic
des_generic
kernel
md5
poly1305_neon
My OpenVPN speeds using AES-128-GCM do hit the advertised speed for the Spitz AX of 150 Mbps. Seeing 150 Mbps does seem like AES acceleration is working.
Correction: you verified you have a generic kernel module loaded to handle AES operations.
These SOCs are similar to ones found mobile phones if not near identical (ARM Cortex A53 in this case). It’s highly doubtful they’d have full AES support like Intel AES-NI. GL doesn’t used the SOCs that supports something like AES-NI on ARM from what I’ve seen. It’s currently the exception rather than norm.
Is there some reason you’re not using WG?
cat /etc/openwrt_release
Precisely, I believe that the generic module does not bring all the performance of the AES instruction built into the CPU. The intention is to use OpenVPN and not Wireguard due to personal needs for the application.
So it really is abnormal… a theoretically superior equipment is having lower performance. This just shows that there may be a lack of optimization, whether in the kernel module or in the openvpn version.
There is no AES acceleration in the ARM Cortex A53. You’d have to look @ the Cortex A76 + Cortex A55 SOC fr what I’ve read.
It’s not just a lack of AES-NI style acceleration; OVPN is single threaded. It favors GHz over cores.
Be aware OVPN is a very well known VPN protocols that can be detected… but I don’t know your threat model.
https://www.usenix.org/conference/usenixsecurity22/presentation/xue-diwen
Here is some more information about the SoC:
You don’t happen to have anything kicking around for the MT7986AV (Flint v2 SOC), by chance, do you? I’d like to read the differences should you have them on hand.
The Cortex-a53 supports AES instructions as can be seen in the first main article I posted and also in the ARM documentation below:
Please note that I am only mentioning AES, since AES-NI, if I’m not mistaken, is an Intel proprietary instruction
Possibly it is there… due to some licensing issue, the ARM is not enabled… that could be it!
BPI-R3 uses another SOC, the MT7986A, while Flint 2 uses the MT7986AV. I believe there are differences between them. They may be small, but I believe the model used in Flit would be newer!
About the Cortex-A53 processor Cryptography Extension
The Cortex-A53 processor Cryptography Extension supports the ARMv8 Cryptography Extensions. The Cryptography Extensions add new A64, A32, and T32 instructions to Advanced SIMD that accelerate Advanced Encryption Standard (AES) encryption and decryption, and the Secure Hash Algorithm (SHA) functions SHA-1, SHA-224, and SHA-256.
Note
The optional Cryptography Extension is not included in the base product. ARM supplies the Cryptography Extension only under an additional licence to the Cortex-A53 processor and Advanced SIMD and Floating-point support licences.
🢁 Emphaisis mine. This could be the root problem, I speculate. GL would have to chime in on that.
I’m saying “AES-NI style”… so we’re both on the same page (AMD licensed AES-NI too IIRC).
I only found
so far.
Exactly… that’s what I think… I don’t see any other impediment other than not being able to use the AES instruction that is already there…
Best regards
If you get clarification/resolution, pls post. I’d be interested to know, if not future readers.
& to you.
Use cat /proc/crypto instead as it’ll show you what crypto drivers are running. AES should be among them.
You can also verify if openvpn is using devcrypto or afalg for acceleration via openvpn --show-engines.
Sorry for the late. Our fellow will help you to clarify it. will do it tomorrow. 
I’d mentioned this in my original reply, but I edited it out since it could negatively impact crypto performance if your device doesn’t support it.
Install libopenssl-devcrypto, reboot and then run openvpn --show-engines again.
You could also use openssl engine -pre DUMP_INFO devcrypto to verify if hardware acceleration is being used for most ciphers.
80mpbs is low?
I would be super happy with 20mbps.
what i wonder is why do you guys not use wireguard when u can?
im also wondering what does this Crypto thing does on a router! anyone?
I thought you’re working for me only! I see you’re here too!!!
Jk lol
