Re: [Openvpn-devel] PKCS#11 - a little bit of help?

Hi Emmanuel, On 03-01-18 18:13, Emmanuel Deloget wrote: > Hello Steffan,  > > On Mon, Jan 1, 2018 at 4:36 PM, Steffan Karger > wrote: > > Hi, > > On 01-01-18 14:57, Emmanuel Deloget wrote: > > I'm trying to get openvpn read my certificates from a TPM2 usin

Re: [Openvpn-devel] [PATCH v3] travis-ci: add brew cache, remove ccache

Hi, On 04-01-18 20:37, Ilya Shipitsin wrote: > 1-2 minutes speedup osx builds by using brew cache. > Also, ccache was removed for a while (builds fail > after travis-ci upgraded clang to version 5.0.0) > --- > v2: this is a "v2" of previously issued "enable ccache for osx and mingw > builds" > pa

Re: [Openvpn-devel] [PATCH] Check for more data in control channel

Hi David, On 05-01-18 20:48, David Sommerseth wrote: > On 04/01/18 13:07, Steffan Karger wrote: >> If control channel packets arrive quickly after each other, or out of >> order, there might be more data available than we can read in one >> tls_process() call. If that happened, and no further con

Re: [Openvpn-devel] OVPN vs IPSec performance as a transport

-SNIP- I haven't taken the time to fully understand the tests you've done etc. [And it does seem you are not some neophyte blindly hacking your way through this...] However, I will tell you that it's *very* common for people to do things that appear very similarly as you describe, and find the

Re: [Openvpn-devel] OVPN vs IPSec performance as a transport

Hi Samuli, Yes, that was the document that I read before going down this path.  I did a bunch of testing and found the optimum MTU range in my setup is 47500 to 52500, and 5 is probably as close to the peak as necessary. When I have 2 nodes, nothing between them and not routing to elsewhere,

Re: [Openvpn-devel] [PATCH] Check for more data in control channel

On 04/01/18 13:07, Steffan Karger wrote: > If control channel packets arrive quickly after each other, or out of > order, there might be more data available than we can read in one > tls_process() call. If that happened, and no further control channel > packet arrived (e.g. because the last two pa