Re: [Openvpn-devel] [PATCH] Support for wolfSSL with OpenVPN v2.4.8

2019-11-25 Thread Juliusz Sosinowicz
Hi David, I apologize for the delayed response. I will rebase our OpenVPN work off of the master branch this week in anticipation for a possible inclusion in version 2.5. Regarding your question "What kind of commitment will we see from the WolfSSL organization?": We have a large customer dr

Re: [Openvpn-devel] [PATCH v2 3/7] wintun: implement opening wintun device

2019-11-25 Thread Gert Doering
Hi, On Mon, Nov 25, 2019 at 09:44:19AM +, Simon Rozman wrote: > 1.if adapter "My VPN Connection" doesn't exist, create it. > 2.else enable it > 3.use it > 4.disable it > An annoyance here is, the adapters pile up over time. On multi-user > computers, OpenVPN GUI don't have a

Re: [Openvpn-devel] [PATCH v2 3/7] wintun: implement opening wintun device

2019-11-25 Thread Selva Nair
Hi On Mon, Nov 25, 2019 at 4:03 AM Lev Stipakov wrote: > Hi, > > (cc:ed to -devel) > > >> I would vote for B and not the combination. >> >> With wintun there is no backwards compatibility requirements, so we could >> use a cleaner, consistent and simpler approach (i.e B). Do not create any >> ad

Re: [Openvpn-devel] [PATCH v2 3/7] wintun: implement opening wintun device

2019-11-25 Thread Simon Rozman
I know. The tap.c code needs an upgrade, not to evaluate all drivers, but just compatible drivers when creating a new adapter. This speeds things a lot. There's a flag that needs to be changed. Somewhere deep on my TODO lists. I would suggest against temporary adapters on Windows. This is OK

Re: [Openvpn-devel] [PATCH v2 3/7] wintun: implement opening wintun device

2019-11-25 Thread Lev Stipakov
Hi, (cc:ed to -devel) > I would vote for B and not the combination. > > With wintun there is no backwards compatibility requirements, so we could > use a cleaner, consistent and simpler approach (i.e B). Do not create any > adapter during installation and dynamically create a temporary adapter a