My comment regarding openvpn was in response to the speculation that it might be the cause of the issue as stated in the post to which I was responding.
I guess I should also state that I have a current @cotequeiroz cryptodev patch from patchworks in my image.
Please try to run (to increase devcrypto verbosity):
sysctl ioctl.cryptodev_verbosity=1
And see if there are any cryptodev messages close to the other error. Messages about failure to load or bad ciphers/hash/transforms, especially ciphers 4 & 12/blowfish/rmd160, are part of algorithm detection, and are normal.
Okay, did that, and there's nothing in the logs similar to what you suggested. Although I have found that the errors are easily reproducible by accessing LuCi via https.
Good observation... I didn't notice, but haven't had any of those errors until I logged into LuCi just now.
I'm still running my own builds based off of the 18.06 branch so I won't be able to apply these patches given that I'm still on 1.0.2r. Firstly, I just wanted to help direct the users of @davidc502's build facing SSL errors to you, the principal author of the recent OpenSSL patches. Secondly, to get more users to test and get your fixes/enhancements in before Hauke's planned branch of OpenWRT 19.03 between the 7th & 17th March.
I do agree that hardware digests are slower. It is corroborated by this.
Dear Dave,
I first say - Hello. On this last Build r9506 - OpenVpn would not start for me. Most significantly, I could not get the OpenVpn interface to properly function. The interface - I tried both uci and Luci - and it said there was an " error " or something to that effect. I fell back to r9287 and everything worked as it should. I use OpenVpn as a NORDVPN client.
I really have not seen anyone raise this issue in this thread, so I just figured that I would relate to you my finding regarding this issue.
Anyway, thanks for all the great work you do. If I am doing anything wrong - I hope that someone will let me know.
I setup my VPN connection as described in these posts:
and here 
For NORDVPN I use this guide with Interface and Firewall Creation from Guides listed above - a sort of hybrid setup
http://stitchroads.blogspot.com/2018/08/how-to-setup-nordvpn-openvpn-on.html
Peace and well Wishes,
directnupe
I am also getting these crypto erros with r9506 on my wrt1900acs v2. Additionally, my VPN connection is so slow that I can barely use it...
Is there a proposed fix yet?
I use Torguard, but I mainly just use the client when I need it. However, I do have my router setup for OpenVPN to be used with Tourguard for testing. I haven't used it in a while, but I just checked and it fired up without issue. Currently I have a 600/400mbps connection, and with OpenVPN, I'm getting about 80/80mbps which seems pretty typical for me with tourguard.
Let me know if you would like to see my configuration, and maybe that will help you with yours.
config openvpn 'TorGuard_AES128CBC_SHA256'
option client '1'
option resolv_retry 'infinite'
option nobind '1'
option persist_key '1'
option persist_tun '1'
option ca '/etc/openvpn/torguard/ca.crt'
option ns_cert_type 'server'
option tls_auth '/etc/openvpn/torguard/ta.key 1'
option cipher 'AES-128-CBC'
option verb '3'
option fast_io '1'
option auth_user_pass '/etc/openvpn/auth-user-pass'
option auth 'SHA256'
option reneg_sec '0'
list remote 'chi.central.usa.torguardvpnaccess.com 1912'
option sndbuf '393216'
option rcvbuf '393216'
option log '/tmp/openvpn.log'
option proto 'udp'
option compress 'lzo'
option dev 'tun'
option engine 'dynamic'I'm finished investigating a bug involving openssh, that resulted in this: engines and forks are not getting along openssl/openssl#8430. TLDR so far: engine support (& hw crypto) is not plug & play; it won't work with all applications.
Expanding the supported algorithms increases the chances of catching an incompatibility. So, we need to disable the ones causing trouble & slowdown. My recommendation is to leave only the CBC ciphers enabled, and disable everything else.
I'm going to tackle the kernel errors now. As soon as I have news, I'll post them here.
@davidc502, @WiteWulf
I need some info here. I'm using plain openwrt here, and I'm unable to reproduce the kernel error by using luci. I've tried it with either uhttpd, and nginx. I'm not familiar with Dave's build, so bear with my noobness. Are there any significant changes from plain openwrt that I should be aware of, patches to apply? Or perhaps ciphersuite/browser to use?
Out of curiosity, has anyone recently compared mbed TLS and OpenSSL as far as performance when using OpenVPN? I did it a while back on MIPS and found mbed TLS to be faster but MIPS doesn't have hardware acceleration.
LuCi Rosy is custom, so that may play into the problem? I can check tonight where I will remove Rosy and try Material or base LuCi.
Or maybe you can use the Rosy sources to check Rosy out on your build? There are 2 github sources...Will check to see which one I am pointed to for the build.
Currently no other patches except with a wifi hack I do for AMSDU, but shouldn't be associated.
Yes, this is happening no matter the theme chosen. As for Rosy, I used to have a custom feed, but was no longer needed and I commented it out.
So, I'm thinking this must have something to do with the packages chosen.
EDIT
So, I may have to go back with a clean slate (new .conf), and see how a new build acts.
Okay, a little more testing here:
Safari 12.0.2 on macOS 10.14.2 - no errors
Chrome 72.0.3626.121 on macOS 10.14.2 - errors
Safari on iOS 12.1.4 (iPhone 7) - no errors
Chrome 72.0.3626.101 on iOS 12.14 (iPhone 7) - errors
Firefox 65.0.1 on macOS 10.14.2 - errors (also complains about SEC_ERROR_UNKNOWN_ISSUER for my letsencrypt cert)
Brave 0.60.48 on macOS 10.14.2 - errors
Chrome (unknown version) on FireOS 6.3.0.1 (Fire HD8) - errors
I'm running luci on uhttpd with the standard settings in David's build and a letsencrypt SSL certificate. The router is also dual-stacked with a Hurricane Electric 6in4 tunnel and uhttpd is bound to both IPv4 and IPv6.
Hope that helps, please don't hesitate to ask if there's anything else I can do.
edit just realised I had a Windows box to hand, too:
This is probably not related to the ciphersuites in TLS. ustream-ssl uses chacha20-poly1305 as the first choice, then AES-GCM, and neither is supported by the devcrypto engine (or the cesa). Most of the browsers support AES-GCM, so unless something else is changing the ciphersuite order, AES-CBC is not being used, and I'm guessing this is either related to ECB or SHA256. At least Chrome & Firefox support chacha20-poly1305, and SHA256 is not used for them, so that leaves ECB as the fist suspect. The weird part of this is IE not triggering the error. Can you build openssl with the patch I mentioned earlier and disable ECB ciphers to see if the message goes away? I can supply the library binaries if not. I also have a binary (edit: or a patch for the source, of course) with debugging messages to syslog that can hopefully point to the function that may be causing the error, if anyone is willing to test it. As a bonus, it will log the cipher/mac of every session, and show you the length of each update call, which coupled with openssl speed output, will give you an idea if hw-crypto is speeding you up (inl > 1000 for aes-cbc; len > 10k for sha256) or slowing you down.
This is the library with debugging output to syslog: libopenssl_1.1.1b-1_arm_cortex-a9_vfpv3.ipk
This is the source patch (apply to openwrt source): openssl-debug.patch
Please note that this has not been tidied up.
Edit:
This patch applies on top of patchwork#1049156
For the next build, all of the compiled image names will start with OpenWrt. I'm thinking over 12 months ago, I switched the name from OpenWrt to LEDE. Well, it is probably time to switch it back to start with OpenWrt, so that's what I have done.
The cyrpto dma pool kernel errors should be fixed in the next build. I've just finished a test build from trunk sources, and I'm not seeing the error anymore.
Thanks for your help @cotequeiroz
Hi All,
Long user of open source firmwares but first mesage on the forum.
First of all thanks David and everyone involved. Works very well for me.
One question for the sysupgrade please. Apparently it upgrades the "other" partition. When I select keep settings does it use the settings of the current partition or uses the other one's as well?
Thansk,
K
Is anyone here running Wireguard on their router?
