Voxel Custom firmware build for R9000/R8900 v. 1.0.4.44HF

[Voxel]

Continuation of:

https://www.snbforums.com/threads/custom-firmware-build-for-r9000.40125/
. . .
https://www.snbforums.com/threads/c...9000-r8900-v-1-0-4-42hf-v-1-0-4-42-1hf.64841/
https://www.snbforums.com/threads/custom-firmware-build-for-r9000-r8900-v-1-0-4-43hf.65379/

New version of my custom firmware build: 1.0.4.44HF.

Changes (vs 1.0.4.43HF):

1. Toolchain: Go is upgraded 1.14.6->1.14.8.
2. Toolchain: binutils is upgraded 2.34-> 2.35.
3. OpenSSL v. 1.1.1 package: Dynamic engine loading support (Cryptographic Hardware Accelerators).
4. OpenSSL v. 1.0.2 package: change default config directory.
5. Kernel: OpenBSD Cryptographic Framework (OCF) devcrypto support is added (/dev/crypto, kernel-space).
6. Kernel: afalg engine support is added (Cryptographic Hardware Acceleration, user-space).
7. renice utility is added (needed for @kamoj add-on).
8. util-linux package is upgraded 2.35.2->2.36.
9. wireguard package is upgraded 1.0.20200712->1.0.20200829.
10. wireguard-tools package is upgraded 1.0.20200513->1.0.20200827.
11. unbound package (used in stubby) is upgraded 1.10.1->1.11.0.
12. libubox package is upgraded 2020-07-11->2020-08-06.
13. nano package is upgraded 4.9.3->5.2.
14. qcawifi.sh: Fix for guest Wi-Fi allowing DNS over TCP (thanks to @R. Gerrits) .
15. curl package is upgraded 7.71.1->7.72.0 (fixing CVE-2020-8231).
16. SAMBA: Update SAMBA config generation & starting use affinity for SAMBA daemon (goal: slight boost).
17. sysstat package is upgraded 12.2.2->12.4.0.
18. sqlite package is upgraded 3320100->3330000.
19. ethtool package is upgraded 5.4->5.8.
20. ez-ipupdate package build (internal developmet issue) is fixed.
21. radvd package build (internal developmet issue) is fixed.
22. Host tools: upgrade bison to 3.7.1.
23. Host tools: upgrade mpfr to 4.1.0.
24. Host tools: upgrade mpc to 1.2.0.

The link is:

https://www.voxel-firmware.com (thanks to vladlenas for his help with hosting).

P.S.

Well. Info for advanced users and developers/researchers. Below text is related to only three packages from my version of firmware: OpenVPN, wget and stubby. The rest packages are left intact.

This build also adds the customized support of “HW” version by demand. I have a lot of requests from the owner of R9000/R8900: what is the latest “HW” version of firmware for R9000/R8900 and why it is not supported anymore? To clarify: “HW” does not add or disable NAT or Wi-Fi acceleration, usual HF version has such acceleration by default. So… Just keep your time and skip the reading this text.

This release allows to convert my R9000 firmware from ordinary “HF” version to HF-HW version. Funnily enough , yes?

So…Now… Well-well-well… Show must go on: Conversion to HW version. It is rather a subject of my theoretical research papers (I have three publications in scientific journals related to such research, re: OpenVPN, ARM routers, teleworking and COVID-19). According to my synthetic tests usual HF version used by OpenVPN (practical usage) is faster vs HF-HW version. But who knows? Maybe concretely in your case it would be good to use HW version; mainly if you are able to use relatively high MTU for OpenVPN.

I’ve added two different versions of OpenSSL hardware acceleration engines: devcrypto and afalg. Differences are on the level of usage. devcrypto is kernel-level. afalg is user-level. See this link for details:

[OpenWrt Wiki] Cryptographic Hardware Accelerators

openwrt.org

Unfortunately devcrypto engine is too unstable. So (!) it is highly not recommended to use it. Just only for theoretical tests. Maybe I’ll be able to use the results of this research (R9000/R8900) for practical usage with Orbi RBK50/53 backhaul connection later…

Now, how to enable “HW” version. Under your own risk. By default it is disabled (i.e. you have usual HF version after flashing fw).

To enable afalg engine:

Edit the file /etc/ssl/openssl.cnf and change the lines (see context below):
. . .
[engines]
# To enable an engine, install the package, and uncomment it here:
#devcrypto=devcrypto
afalg=afalg
#padlock=padlock
. . .

To enable devcrypto engine (not recommended at all for practical usage(!)):
. . .
[engines]
# To enable an engine, install the package, and uncomment it here:
devcrypto=devcrypto
#afalg=afalg
#padlock=padlock
. . .

After such changes you should immediately get HF-HW version. FYI: it accelerates the only AES-CBC cipher for R9000/R8900. No acceleration of AES-GCM or other.

Next, again just for your info, result of OpenSSL 1.1.1 tests of AES-256-CBC:

Ordinary version, no HW acceleration, by default, no any manual user changes in configs:

(dynamic) Dynamic engine loading support

The 'numbers' are in 1000s of bytes per second processed.
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes
aes-256-cbc 43934.62k 52524.65k 56441.17k 58116.78k 58531.84k 58370.73k

afalg acceleration:

(dynamic) Dynamic engine loading support
(afalg) AFALG engine support

The 'numbers' are in 1000s of bytes per second processed.
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes
aes-256-cbc 643.80k 2578.52k 9721.26k 34376.36k 188710.91k 265650.18k

devcrypto acceleration:
(dynamic) Dynamic engine loading support
(devcrypto) /dev/crypto engine

The 'numbers' are in 1000s of bytes per second processed.
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes
aes-256-cbc 1143.24k 4546.52k 18153.30k 67321.51k 266351.96k 358531.07k

So, theoretically HW is faster vs ordinary HF in more than (up to) 6 times (!). But life is life… The bottleneck is that crypto device is PCI device. It works much faster only for large blocks. If you just need VPN client for your router, my recommendations from high to low (speed): WireGuard->OpenVPN HF->OpenVPN HF-HW.

P.P.S.

Just info for R7800 owners who were able to read all this "HW" stuffs. HW version for R7800 is possible (e.g. /dev/crypto) but it has no sense to use it at all. HW acceleration (R7800) does not support AES-CBC, AES-GCM etc..

That's all for today. buona notte, buenos noches, さよなら, dobranoc, bonne nuit, boa noite, спокойной ночи, godnatt, gute nacht, dobrou noc, good night, 晚安 ...

Stay safe.

Voxel.

 

[KW.]

Wow! Thank you so much. I will install it now. Your firmware is so god damn great! Is your articles ones and zeros and some arrows here and there, or is it possible for an uneducated man to read and understand some of it? Got very curious. Must say its jackpot to have researcher work with my router every other months or so. I would not change the router for a router, double the cost. Its fantastic to have you Kamoj and others work with it.

 

[multicast]

@Voxel Thank you so much for taking the time in providing an updated version, always VERY appreciated.

 

[foo man]

Kudos @ voxel & kamoj, you two are the best!

 

[Supersaiyan_IV]

Amazing stuff! Big thanks Voxel and everybody involved!

If you're in the mood, here's a mad way for optimizing some of Netgear's precompiled binaries:
https://github.com/facebookincubator/BOLT
https://github.com/facebookincubator/BOLT/tree/master/paper/reproduce-bolt-cgo19

 

[Voxel]

If you're in the mood, here's a mad way for optimizing some of Netgear's precompiled binaries:
https://github.com/facebookincubator/BOLT
https://github.com/facebookincubator/BOLT/tree/master/paper/reproduce-bolt-cgo19

Thanks but I prefer to use normal way of optimization. Such optimizer(s) could be dangerous to use. And exactly this stuff cannot be used because of its requirements:

Input Binary Requirements​

BOLT operates on X86-64 and AArch64 ELF binaries. At the minimum, the binaries should have an unstripped symbol table, and, to get maximum performance gains, they should be linked with relocations (--emit-relocs or -q linker flag).​

Precompiled binaries from NG are ARM ELF and are stripped. And they are not so critical (speed).

Voxel.