Re: [Openvpn-devel] [PATCH v2] Add demo plugin that excercises "CLIENT_CONNECT" and "CLIENT_CONNECT_V2" paths

Hi, thanks for the review. On Fri, Sep 11, 2020 at 09:03:43PM +0200, David Sommerseth wrote: > On 11/08/2020 12:44, Gert Doering wrote: > > This is a new "samples" plugin which does not do many useful things, > > besides [..] > > +sample-client-connect.o: sample-client-connect.c > > + > > +# This

[Openvpn-devel] [PATCH v3] Add demo plugin that excercises "CLIENT_CONNECT" and "CLIENT_CONNECT_V2" paths

This is a new "samples" plugin which does not do many useful things, besides - show how a plugin is programmed - how the various messages get dispatched - how to pass back information from a client-connect/v2 plugin - how to do async-cc plugins [not yet implemented] the operation of the plugi

Re: [Openvpn-devel] problem with beta3 and wintun

Hi On Fri, Sep 11, 2020 at 1:45 PM RafaeHil Gava wrote: > Hi Selva, > > I was wondering if it's possible to detect UAC during the installation. > What do you think? > There are many ways of running the GUI as admin and all involve some deliberate action on the part of the user. The best we can

Re: [Openvpn-devel] [PATCH v2] Add demo plugin that excercises "CLIENT_CONNECT" and "CLIENT_CONNECT_V2" paths

On 11/08/2020 12:44, Gert Doering wrote: > This is a new "samples" plugin which does not do many useful things, > besides > - show how a plugin is programmed > - how the various messages get dispatched > - how to pass back information from a client-connect/v2 plugin > - how to do async-cc plugi

Re: [Openvpn-devel] problem with beta3 and wintun

Hi Selva, I was wondering if it's possible to detect UAC during the installation. What do you think? BR Gava On Fri, Sep 11, 2020 at 1:48 PM Selva Nair wrote: > Hi, > > On Fri, Sep 11, 2020 at 1:58 AM Gert Doering wrote: > >> Hi, >> >> On Thu, Sep 10, 2020 at 06:10:17PM -0700, Marvin wrote:

[Openvpn-devel] [PATCH applied] Re: Handle NULL returns from calloc() in sample plugins.

Patch has been applied to the master, release/2.5 and release/2.4 branch. commit a61c08a2c80d95dcc2bc30ddcb9a54a462e565ed (master) commit 5382bdbfbfb9ac26c7c75bc967af86db352b54b3 (release/2.5) commit 2b8dda69115e1e048ff685bc366705156781548c (release/2.4) Author: Gert Doering Date: Wed Sep 9 12:4

[Openvpn-devel] OpenVPN 2.5-beta4 released

The OpenVPN community project team is proud to release OpenVPN 2.5-beta4. Source code and Windows installers can be downloaded from our download page: Debian and Ubuntu packages are available in the official apt repositories:

Re: [Openvpn-devel] problem with beta3 and wintun

Hi, On Fri, Sep 11, 2020 at 1:58 AM Gert Doering wrote: > Hi, > > On Thu, Sep 10, 2020 at 06:10:17PM -0700, Marvin wrote: > > To All 3, > > Thank you with your help I found the issue. UAC was disabled in the > > registry on this image. IIRC we had trouble updating some software by > > automated

Re: [Openvpn-devel] [PATCH] Handle NULL returns from calloc() in sample plugins.

On 09/09/2020 12:48, Gert Doering wrote: > This is basic housekeeping, adding NULL checks to context initialization > of the sample plugin collection which are missing it. Realistically, > this can never happen, but since these are supposed to be "good examples", > not checking calloc() return isn

[Openvpn-devel] [PATCH applied] Re: man: Add missing --server-ipv6

Acked-by: Gert Doering Thanks :) I have removed one line + This is only accepted if ``--mode server`` or ``--server`` is set. as this is no longer correct after merging of Antonio's ipv6-only patch set (but the corresponding doc change might have gotten lost in between). Your patch has be

[Openvpn-devel] OpenSolaris / OpenIndiana help sought

Hi, as you know, OpenVPN supports OpenSolaris / OpenIndiana / Illumous / ... OTOH, none of us really understands the magic incantations that are needed to open/close the tun/tap driver there - it's very different from all other platforms. Now, things do work today, except for one detail - if we

[Openvpn-devel] [PATCH] man: Add missing --server-ipv6

During the conversion from .8 to .rst and further reorganizing of the content into separate files, the --server-ipv6 entry got lost. This resurrects it again. Signed-off-by: David Sommerseth --- doc/man-sections/server-options.rst | 14 ++ 1 file changed, 14 insertions(+) diff --gi

[Openvpn-devel] [PATCH applied] Re: Fix description of --client-disconnect calling convention in manpage.

Patch has been applied to the master and release/2.5 branch. For 2.4, the textual change was applied to doc/openvpn.8, with nroff formatting. commit 50c7700da09a1f83474e18f8709d59dbc4b509e2 (master) commit 79910a3d2d78ec8c1b9becbd169eb9074fb242dd (release/2.5) commit 9481cca682112b502f83afe537164

Re: [Openvpn-devel] [PATCH] Fix description of --client-disconnect calling convention in manpage.

Hi, On 09/09/2020 14:29, Gert Doering wrote: > The man page claimed that --client-disconnect "is passed the same > pathname as the corresponding --client-connect command", which is > not what the code does. Fix. > > Reported-By: hvenev in Trac > Trac: #884 > > Signed-off-by: Gert Doering Chec

Re: [Openvpn-devel] [PATCH] Support for wolfSSL in OpenVPN

On 10/09/2020 14:16, Arne Schwabe wrote: > Am 10.09.20 um 14:11 schrieb Juliusz Sosinowicz: >> Hi Arne, >> >> I understand your concern and apologize for the delay. We have been busy >> with the release of wolfSSL 4.5.0. I will make sure that the fixes >> necessary for OpenVPN support will be prior

[Openvpn-devel] [PATCH] If IPv6 pool specification sets pool start to ::0 address, increment.

The first IPv6 address in a subnet is not usable (IPv6 anycast address), but our pool code ignored this. Instead of assigning an unusable address or erroring out, just log the fact, and increment the pool start to ::1 NOTE: this is a bit simplistic. A pool that is larger than /96 and has non-0 b

[Openvpn-devel] [PATCH applied] Re: Replace 'echo -n' with 'printf' in tests/t_lpback.sh

Patch has been applied to the master and release/2.5 branch. commit 81f9bb3a2ff9a3b0f5a1bdbac1d0daf38747ae7b (master) commit d17eb65d144f157942a1675bdb25f89f15aff839 (release/2.5) Author: Gert Doering Date: Wed Sep 9 15:00:24 2020 +0200 Replace 'echo -n' with 'printf' in tests/t_lpback.sh

Re: [Openvpn-devel] [PATCH] Replace 'echo -n' with 'printf' in tests/t_lpback.sh

Hi, On 09/09/2020 15:00, Gert Doering wrote: > "echo -n" is inherently less portable than printf, so the tests look > ugly on (at least) OpenSolaris/Illumos on AIX. > > Add a blank at the end of the tls-crypt-v2 messages, so it has the > same look as the cipher messages ("... OK"). > > Reported-

[Openvpn-devel] [PATCH applied] Re: Add a remark on dropping privileges when --mlock is used

Acked-by: Gert Doering Additional documentation of possible consequences of --mlock + --user is good, and pointers to "what to do about it" are always useful :-) Your patch has been applied to the master and release/2.5 branch. I have not backported it to .8 format for 2.4 - I do not think it'

[Openvpn-devel] [PATCH applied] Re: Fix handling of 'route remote_host' for IPv6 transport case.

Patch has been applied to lots of branches... :) commit aa34684972eb01bfa5c355d1c8a8a9d384bf0175 (master) commit 78c50eba82fe9bf9a899cb8587e11dcc227c0cdd (release/2.5) commit 09e46c3ca7ead4e7b817fa527302dfb1a2f225d0 (release/2.4) Author: Gert Doering Date: Fri Sep 11 10:59:07 2020 +0200 Fi

Re: [Openvpn-devel] [PATCH] Fix handling of 'route remote_host' for IPv6 transport case.

Am 11.09.20 um 10:59 schrieb Gert Doering: > If we connect to a VPN server over IPv6, and the config has a > route like this: > > route remote_host default net_gateway > > OpenVPN would try to install a route to "255.255.255.255", which > is obviously bogus. > > The bug is twofold: init_route_

Re: [Openvpn-devel] [PATCH applied] Re: Fix best gateway selection over netlink

Hi Gert, Great, many thanks -- Best Regards, Vladislav Grishenko > -Original Message- > From: Gert Doering > Sent: Thursday, September 10, 2020 2:23 PM > To: Vladislav Grishenko > Cc: openvpn-devel@lists.sourceforge.net > Subject: [PATCH applied] Re: Fix best gateway selection over net

Re: [Openvpn-devel] [PATCH v3] Fix best gateway selection over netlink

Hi, Antonio Thank you for review -- Best Regards, Vladislav Grishenko > -Original Message- > From: Antonio Quartulli > Sent: Thursday, September 10, 2020 2:02 PM > To: Vladislav Grishenko ; openvpn- > de...@lists.sourceforge.net > Subject: Re: [Openvpn-devel] [PATCH v3] Fix best gateway

[Openvpn-devel] [PATCH] Fix handling of 'route remote_host' for IPv6 transport case.

If we connect to a VPN server over IPv6, and the config has a route like this: route remote_host default net_gateway OpenVPN would try to install a route to "255.255.255.255", which is obviously bogus. The bug is twofold: init_route_list() should not set RTSA_REMOTE_HOST for an "IPV4_INVALID_A