Re: [Openvpn-devel] [PATCH v2] Check --ncp-ciphers list on startup

[Selva Nair]

On Wed, Oct 12, 2016 at 3:32 AM, Steffan Karger  wrote:

> Currently, if --ncp-ciphers contains an invalid cipher, OpenVPN will only
> error out when that cipher is selected by negotiation.  That's not very
> friendly to the user, so check the list on startup, and give a clear error
> message immediately.
>
> This patches changes the cipher_kt_get() to let the caller decide what
> action to take if no valid cipher was found.  This enables us to print all
> invalid ciphers in the list, instead of just the first invalid cipher.
>
> This should fix trac #737.
>
> v2: improve tls_check_ncp_cipher_list() with Selva's review suggestions.
>
> Signed-off-by: Steffan Karger 
> ---
>  src/openvpn/crypto.c |  5 +
>  src/openvpn/crypto_backend.h |  3 ++-
>  src/openvpn/crypto_mbedtls.c | 15 ++-
>  src/openvpn/crypto_openssl.c | 17 -
>  src/openvpn/options.c|  5 +
>  src/openvpn/ssl.c| 22 ++
>  src/openvpn/ssl.h|  9 +
>  7 files changed, 65 insertions(+), 11 deletions(-)



Looks good now. ACK.

Selva
--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH v2] Change the hold command to communicate the time that OpenVPN would wait to the UI.

[Selva Nair]

Hi,

On Wed, Oct 12, 2016 at 6:47 AM, Arne Schwabe  wrote:

> Before the connect-retry change to do exponential backup this was not
> necessary
> since the time was fixed. With the exponential backoff the UI needs either
> to
> implement its own exponential backoff mechansim or needs a way of knowing
> the
> value of OpenVPN internal mechansim.
>
> Patch V2: Fixed typos noticed by Selva(
> ---
>  doc/management-notes.txt |  7 +--
>  src/openvpn/init.c   | 15 +--
>  src/openvpn/manage.c |  8 ++--
>  src/openvpn/manage.h |  2 +-
>  4 files changed, 21 insertions(+), 11 deletions(-)


Looks good and works as expected. Tested on Linux.

-  >HOLD:Waiting for hold release
> +  >HOLD:Waiting for hold release:10


OpenVPN GUI does not parse the "Waiting for hold release" string, so this
doesn't affect it.

ACK from me.

Suggest to correct mechansim->mechanism (x2) in commit message during
merge.

Selva
--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [Openvpn-users] Help testing OpenVPN 2.4-alpha1 preview installers?

[Selva Nair]

Hi,

On Wed, Oct 12, 2016 at 7:29 AM, Jose Alf.  wrote:

> I tested the 64 bit installer on Windows 7 Enterprise using default
> settings. It ran smoothly. I notice that now there are 3 services - OpenVPN
> Interactive Service (appears started automatic)
> - OpenVPN Legacy Service (manual)
> - OpenVPNService (manual)
>
> Any pointers to documentation about this?
>

> I use OpenVPN-MI-GUI. I had to start OpenVPNService to connect to my
> server. Other than that, it worked fine.


To add to what Samuli wrote:

With MI-GUI, all you have to do is just start OpenVPNService (same as
previous previous versions) -- under the hood the service has changed, but
the functionality is the same.

That said, if the reason for using MI-GUI is to avoid running the GUI as
admin, now there is a better way. Do not run OpenVPNService and start
OpenVPN GUI included in the distribution as normal user. It will start
openvpn as normal user assisted by the interactive service (which is
automatically started). The main advantage is that both the GUI and
openvpn.exe will run as normal user minimizing code run as admin.

Also there are a number of improvements in the GUI including ability to
store config files in user profile, menu to import the config file to the
right location, optionally remember passwords,  support for prompting
static challenge, configuration menu for all options (no need to edit the
registry) etc.

Selva
--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH v4] Remove tun-ipv6 Option. Instead assume that IPv6 is always supported.

[Jonathan K. Bullard]

Thanks to both Gert and Arne for their answers.

On Wed, Oct 12, 2016 at 9:12 AM, Arne Schwabe  wrote:
>> What I should have asked is: with this patch will an OpenVPN client
>> still send out IPv4 packets if there are no IPv6 options specified or
>> pulled from the server?

--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH v4] Remove tun-ipv6 Option. Instead assume that IPv6 is always supported.

[Arne Schwabe]

> What I should have asked is: with this patch will an OpenVPN client
> still send out IPv4 packets if there are no IPv6 options specified or
> pulled from the server?

In short: Behave exactly as before.

Longer explaination:

Without the patch OpenVPN refuses ifconfig-ipv6 and route-ipv6 without
tun-ipv6 option because the tun device has not been configured in a IPv6
safe way. With patch it does not refuse the commands.


The problem that tun-ipv6 solved was "Method A works with IPv6/IPv4 but
might break on old versions of Linux(?) and Method B always works but
only IPv4".

On Linux the tun device has been opend/configured in different ways for
tun-ipv6 and non tun-ipv6 which are both IPv4/IPv6 capable (prepend a
header to packet/do not prepend a header) for reasons that are probably
lost in history. The patch unifies that to never prepends headers (IPv4
behaviour and Android behaviour).

For OS X tun (and utun) has always been opened in the same way no matter
if tun-ipv6 was specifiied. So only change for OS X is no longer
refusing ifconfig-ipv6 and route-ipv6 without tun-ipv6 option.
 

Arne

--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [Openvpn-users] Help testing OpenVPN 2.4-alpha1 preview installers?

[Samuli Seppänen]

Hi Jose,

Thanks for testing! The documentation about the new services is probably 
suboptimal right now. I will need to improve it a bit, because I believe 
what is said here



is all we have right now. Quickly summarizing:

1) OpenVPNService (provided by openvpnserv2.exe)

This is a new background service based on openvpnserv2. It is intended 
for running one or more VPN connections in the background without user 
interaction.

2) OpenVPNServiceInteractive (provided by openvpnserv.exe)

This service co-operates with OpenVPN-GUI to allow unprivileged users to 
successfully launch VPN connection.

3) OpenVPNServiceLegacy (provided by openvpnserv.exe)

This is the old background service. It does not work well on anything 
post-Windows 7 and is pretty crude in general. It is intended for 
running one or more VPN connections in the background without user 
interaction.

I will add this documentation somewhere - probably INSTALL-win32.txt.

-- 
Samuli Seppänen
Community Manager
OpenVPN Technologies, Inc

irc freenode net: mattock


Il 12/10/2016 14:29, Jose Alf. ha scritto:
> Samuli,
>
> I tested the 64 bit installer on Windows 7 Enterprise using default
> settings. It ran smoothly. I notice that now there are 3 services -
> OpenVPN Interactive Service (appears started automatic)
> - OpenVPN Legacy Service (manual)
> - OpenVPNService (manual)
>
> Any pointers to documentation about this?
>
> I use OpenVPN-MI-GUI. I had to start OpenVPNService to connect to my
> server. Other than that, it worked fine.
>
> Regards,
> Jose
>
> 
> *From:* Samuli Seppänen 
> *To:* "openvpn-devel@lists.sourceforge.net"
> ;
> "openvpn-us...@lists.sourceforge.net" 
> *Sent:* Tuesday, October 11, 2016 5:36 AM
> *Subject:* [Openvpn-users] Help testing OpenVPN 2.4-alpha1 preview
> installers?
>
> Hi all,
>
> We're really close to OpenVPN 2.4-alpha1 release now. In yesterday's IRC
> meeting[1] we deemed that "late this week" might be doable.
>
> However, we'd need to help with testing these preview installers:
>
> 
> 
>
> Note that the installers contain a much improved OpenVPN-GUI that
> behaves differently under the hood from the one bundled in OpenVPN 2.3.x:
>
> 
>
> The installer also contains a new, much improved Windows system service
> called openvpnserv2:
>
> 
>
> Based on earlier tests openvpnserv2 should be able to handle
> suspend/resume gracefully. It should also automatically restart a
> connection that dies for whatever reason.
>
> So far the installers linked to above have passed some basic tests:
>
> 
>
> If you can, please test the installers in your environment and let us
> know how it went: we'd like to minimize the chance of breaking existing
> setups before we make the official 2.4-alpha1 release.
>
> --
> Samuli Seppänen
> Community Manager
> OpenVPN Technologies, Inc
>
> irc freenode net: mattock
>
>
> [1]
> 
>
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> ___
> Openvpn-users mailing list
> openvpn-us...@lists.sourceforge.net
> 
> https://lists.sourceforge.net/lists/listinfo/openvpn-users
>


--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH v4] Remove tun-ipv6 Option. Instead assume that IPv6 is always supported.

[Gert Doering]

Hi,

On Wed, Oct 12, 2016 at 08:53:02AM -0400, Jonathan K. Bullard wrote:
> What I should have asked is: with this patch will an OpenVPN client
> still send out IPv4 packets if there are no IPv6 options specified or
> pulled from the server?

Yes.   Basically, the tun interface is now always in "dual-stack mode"
on those platforms where it matters (some, like NetBSD, can have 
"IPv4 only mode" or "dual stack mode", and the latter was "newly added"
some 10 years ago...).

IPv4 is not going to be broken :-)

The only user visible change *expected* by this change is that previously,
"ifconfig-ipv6" would be rejected unless "tun-ipv6" was also configured, 
and now this dependency is gone - if you configure (or push) ifconfig-ipv6,
you get dual-stack v4+v6, if not, you get a dual-stacked tun interface
with only IPv4 active.

gert
-- 
USENET is *not* the non-clickable part of WWW!
   //www.muc.de/~gert/
Gert Doering - Munich, Germany g...@greenie.muc.de
fax: +49-89-35655025g...@net.informatik.tu-muenchen.de


signature.asc
Description: PGP signature
--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH v4] Remove tun-ipv6 Option. Instead assume that IPv6 is always supported.

[Jonathan K. Bullard]

Thanks, Arne. Sorry if I wasn't a clear as I should have been.

On Wed, Oct 12, 2016 at 8:08 AM, Arne Schwabe  wrote:
>
> Am 12.10.16 um 13:17 schrieb Jonathan K. Bullard:
> > Hi.
> >
> > On Wed, Oct 12, 2016 at 5:13 AM, Arne Schwabe  wrote:
> >> This option was useful when Ipv6 tun support was
> >> non standard and was an internal/user specified flag
> >> that tracked the Ipv6 capability of the tun device.
> >>
> >> All supported OS support IPv6. Also tun-ipv6 is
> >> pushable by the remote so not putting tun-ipv6
> >> does not forbid ipv6 addresses.
> > How will this patch affect a VPN on a system that has IPv6 disabled?
> >
> >
> Short version: Fail as miserable as before.

Connections don't fail in the situation I describe (IPv6 disabled at
the OS level). At least not when there are no IPv6 options enabled in
the OpenVPN configuration or pushed from the server, which is the
setup that many VPN service providers use.


> You might think that leaving out tun-ipv6 might fix your
> problem but tun-ipv6 is a pushable option and the server-ipv6 macro will
> push it, so you end up with tun-ipv6 without having it in the client config.

The problem was not that the server was pushing tun-ipv6 (the
configurations and server pushes did not have any IPv6 references).
The problem was that the OS prefers IPv6 over IPv4 when both were
available. So the OS was sending out IPv6 packets, which caused
information leakage. The solution was not leaving out the tun-ipv6
option, but disabling IPv6 in the OS.

What I should have asked is: with this patch will an OpenVPN client
still send out IPv4 packets if there are no IPv6 options specified or
pulled from the server?

If yes, the connection will succeed. If no, then disabling IPv6 in the
OS will cause failed connections. (Unless with IPv6 disabled the OS
translates IPv6 packets to IPv4 and sends them, which seems unlikely
to me.)

--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH v4] Remove tun-ipv6 Option. Instead assume that IPv6 is always supported.

[Arne Schwabe]

Am 12.10.16 um 13:17 schrieb Jonathan K. Bullard:
> Hi.
>
> On Wed, Oct 12, 2016 at 5:13 AM, Arne Schwabe  wrote:
>> This option was useful when Ipv6 tun support was
>> non standard and was an internal/user specified flag
>> that tracked the Ipv6 capability of the tun device.
>>
>> All supported OS support IPv6. Also tun-ipv6 is
>> pushable by the remote so not putting tun-ipv6
>> does not forbid ipv6 addresses.
> How will this patch affect a VPN on a system that has IPv6 disabled?
>
>
Short version: Fail as miserable as before.

tun-ipv6 is not saying "My OS can do IPv6" but more "My OS has the
required calls to configure a IPv6 tun". It came from a time when
configuring/sending IPv6 packets into a non IPv6 prepared tun screwed
things ups. You might think that leaving out tun-ipv6 might fix your
problem but tun-ipv6 is a pushable option and the server-ipv6 macro will
push it, so you end up with tun-ipv6 without having it in the client config.

You can do pull-filter tun-ipv6 or disable pulling all together but then
again you can do also pull-filter ifconfig-ipv6 and pull-filter
route-ipv6 which is a cleaner way then letting those commands fails (and
probably also the connection attempt).

The option really serves no good purposse anymore. If someone really
wants a disable IPv6 option this option isn't it.

Arne

--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH v4] Remove tun-ipv6 Option. Instead assume that IPv6 is always supported.

[Jonathan K. Bullard]

Hi.

On Wed, Oct 12, 2016 at 5:13 AM, Arne Schwabe  wrote:
>
> This option was useful when Ipv6 tun support was
> non standard and was an internal/user specified flag
> that tracked the Ipv6 capability of the tun device.
>
> All supported OS support IPv6. Also tun-ipv6 is
> pushable by the remote so not putting tun-ipv6
> does not forbid ipv6 addresses.

How will this patch affect a VPN on a system that has IPv6 disabled?

To prevent information leakage, Tunnelblick has an option in tun mode
that forces the OS to disable IPv6 (via a "networksetup -setv6off" OS
X command.)

The information leakage when using IPv6 in a VPN is described in [1].
As of the date of the article (June 2015), the problem was common
among VPN service providers. The "disable IPv6" feature was added to
Tunnelblick because disabling IPv6 was the only way that a user of
such services could protect themselves. It isn't clear if all VPN
service providers have fixed their configurations yet (or will ever
fix their configurations).

Best regards,

Jon Bullard

[1] http://www.eecs.qmul.ac.uk/~hamed/papers/PETS2015VPN.pdf

--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] Help testing OpenVPN 2.4-alpha1 preview installers?

[Илья Шипицин]

yes, https://github.com/OpenVPN/openvpn-gui/pull/45

2016-10-12 15:56 GMT+05:00 Samuli Seppänen :

> Hi Ilya,
>
> Did you issue a PR with that fix? I don't see that commit in Git logs for
> OpenVPN/OpenVPN-GUI on GitHub.
>
> --
> Samuli Seppänen
> Community Manager
> OpenVPN Technologies, Inc
>
> irc freenode net: mattock
>
>
> Il 12/10/2016 13:43, Илья Шипицин ha scritto:
>
>> it should have been fixed with
>> https://github.com/OpenVPN/openvpn-gui/commit/727eaee0c54b0a
>> ee01ad28f622c1da7011e7b7c1
>>
>> @mattock ?
>>
>> 2016-10-12 15:30 GMT+05:00 Ton van Vliet > >:
>>
>> On 11-10-16 12:36, Samuli Seppänen wrote:
>>
>>> However, we'd need to help with testing these preview installers:
>>>
>>
>> 64 bit version on Win7 Home Premium installation process without
>> issues.
>>
>> Observed a small issue when looking at the 'Settings...' of the new
>> GUI:
>>
>> 1st tab: labeled 'Proxy' content in English(as expected)
>> 2nd tab: labeled 'Geral' content in Portuguese?
>> 3rd tab: labeled 'About' content in English
>>
>> Ton.
>>
>>
>> 
>> --
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>> ___
>> Openvpn-devel mailing list
>> Openvpn-devel@lists.sourceforge.net
>> 
>> https://lists.sourceforge.net/lists/listinfo/openvpn-devel
>> 
>>
>>
>>
>>
>> 
>> --
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>>
>>
>>
>> ___
>> Openvpn-devel mailing list
>> Openvpn-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/openvpn-devel
>>
>>
>
--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] Help testing OpenVPN 2.4-alpha1 preview installers?

[Samuli Seppänen]

Il 12/10/2016 13:30, Ton van Vliet ha scritto:
> On 11-10-16 12:36, Samuli Seppänen wrote:
>> However, we'd need to help with testing these preview installers:
>
> 64 bit version on Win7 Home Premium installation process without issues.
>
> Observed a small issue when looking at the 'Settings...' of the new GUI:
>
> 1st tab: labeled 'Proxy' content in English(as expected)
> 2nd tab: labeled 'Geral' content in Portuguese?
> 3rd tab: labeled 'About' content in English
>
> Ton.

Great, thanks for testing. Did you try connecting to any servers? Any 
issues there?

-- 
Samuli Seppänen
Community Manager
OpenVPN Technologies, Inc

irc freenode net: mattock

--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

[Openvpn-devel] [PATCH v2] Change the hold command to communicate the time that OpenVPN would wait to the UI.

[Arne Schwabe]

Before the connect-retry change to do exponential backup this was not necessary
since the time was fixed. With the exponential backoff the UI needs either to
implement its own exponential backoff mechansim or needs a way of knowing the
value of OpenVPN internal mechansim.

Patch V2: Fixed typos noticed by Selva(
---
 doc/management-notes.txt |  7 +--
 src/openvpn/init.c   | 15 +--
 src/openvpn/manage.c |  8 ++--
 src/openvpn/manage.h |  2 +-
 4 files changed, 21 insertions(+), 11 deletions(-)

diff --git a/doc/management-notes.txt b/doc/management-notes.txt
index f68f3db..dd870eb 100644
--- a/doc/management-notes.txt
+++ b/doc/management-notes.txt
@@ -168,9 +168,12 @@ be reset by restarts.
 
 OpenVPN will indicate that it is in a hold state by
 sending a real-time notification to the management
-client:
+client, the parameter indicates how long OpenVPN would
+wait without UI (as influenced by connect-retry exponential
+backoff). The UI needs to wait for releasing the hold if it
+wants similar behavior:
 
-  >HOLD:Waiting for hold release
+  >HOLD:Waiting for hold release:10
 
 Command examples:
 
diff --git a/src/openvpn/init.c b/src/openvpn/init.c
index 7684a96..73f8c6d 100644
--- a/src/openvpn/init.c
+++ b/src/openvpn/init.c
@@ -1954,16 +1954,17 @@ do_deferred_options (struct context *c, const unsigned 
int found)
 }
 
 /*
- * Possible hold on initialization
+ * Possible hold on initialization, holdtime is the
+ * time OpenVPN would wait without management
  */
 static bool
-do_hold (void)
+do_hold (int holdtime)
 {
 #ifdef ENABLE_MANAGEMENT
   if (management)
 {
   /* block until management hold is released */
-  if (management_hold (management))
+if (management_hold (management, holdtime))
return true;
 }
 #endif
@@ -2021,8 +2022,10 @@ socket_restart_pause (struct context *c)
   c->persist.restart_sleep_seconds = 0;
 
   /* do managment hold on context restart, i.e. second, third, fourth, etc. 
initialization */
-  if (do_hold ())
+  if (do_hold (sec))
+  {
 sec = 0;
+  }
 
   if (sec)
 {
@@ -2040,7 +2043,7 @@ do_startup_pause (struct context *c)
   if (!c->first_time)
 socket_restart_pause (c);
   else
-do_hold (); /* do management hold on first context initialization */
+do_hold (0); /* do management hold on first context initialization */
 }
 
 /*
@@ -3425,7 +3428,7 @@ open_management (struct context *c)
}
 
  /* initial management hold, called early, before first context 
initialization */
- do_hold ();
+ do_hold (0);
  if (IS_SIG (c))
{
  msg (M_WARN, "Signal received from management interface, 
exiting");
diff --git a/src/openvpn/manage.c b/src/openvpn/manage.c
index dcb1bc1..206aaf4 100644
--- a/src/openvpn/manage.c
+++ b/src/openvpn/manage.c
@@ -3332,12 +3332,13 @@ management_should_daemonize (struct management *man)
  * Return true if the caller should not sleep for an additional time interval.
  */
 bool
-management_hold (struct management *man)
+management_hold (struct management *man, int holdtime)
 {
   if (management_would_hold (man))
 {
   volatile int signal_received = 0;
   const bool standalone_disabled_save = man->persist.standalone_disabled;
+  struct gc_arena gc = gc_new ();
 
   man->persist.standalone_disabled = false; /* This is so M_CLIENT 
messages will be correctly passed through msg() */
   man->persist.special_state_msg = NULL;
@@ -3347,7 +3348,9 @@ management_hold (struct management *man)
 
   if (!signal_received)
{
- man->persist.special_state_msg = ">HOLD:Waiting for hold release";
+  struct buffer out = alloc_buf_gc (128, );
+  buf_printf (, ">HOLD:Waiting for hold release:%d", holdtime);
+ man->persist.special_state_msg = BSTR ();
  msg (M_CLIENT, "%s", man->persist.special_state_msg);
 
  /* run command processing event loop until we get our 
username/password */
@@ -3366,6 +3369,7 @@ management_hold (struct management *man)
   man->persist.special_state_msg = NULL;
   man->settings.mansig &= ~MANSIG_IGNORE_USR1_HUP;
 
+  gc_free ();
   return true;
 }
   return false;
diff --git a/src/openvpn/manage.h b/src/openvpn/manage.h
index 988600f..50db38c 100644
--- a/src/openvpn/manage.h
+++ b/src/openvpn/manage.h
@@ -396,7 +396,7 @@ int managment_android_persisttun_action (struct management 
*man);
 
 bool management_should_daemonize (struct management *man);
 bool management_would_hold (struct management *man);
-bool management_hold (struct management *man);
+bool management_hold (struct management *man, int holdtime);
 
 void management_event_loop_n_seconds (struct management *man, int sec);
 
-- 
2.8.4 (Apple Git-73)


--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot

Re: [Openvpn-devel] Help testing OpenVPN 2.4-alpha1 preview installers?

[Илья Шипицин]

it should have been fixed with
https://github.com/OpenVPN/openvpn-gui/commit/727eaee0c54b0aee01ad28f622c1da7011e7b7c1

@mattock ?

2016-10-12 15:30 GMT+05:00 Ton van Vliet :

> On 11-10-16 12:36, Samuli Seppänen wrote:
>
> However, we'd need to help with testing these preview installers:
>
>
> 64 bit version on Win7 Home Premium installation process without issues.
>
> Observed a small issue when looking at the 'Settings...' of the new GUI:
>
> 1st tab: labeled 'Proxy' content in English(as expected)
> 2nd tab: labeled 'Geral' content in Portuguese?
> 3rd tab: labeled 'About' content in English
>
> Ton.
>
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> ___
> Openvpn-devel mailing list
> Openvpn-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openvpn-devel
>
>
--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

[Openvpn-devel] [PATCH v4] Remove tun-ipv6 Option. Instead assume that IPv6 is always supported.

[Arne Schwabe]

This option was useful when Ipv6 tun support was non standard and was an 
internal/user specified flag that tracked the Ipv6 capability of the tun device.

All supported OS support IPv6. Also tun-ipv6 is pushable by the remote so not 
putting tun-ipv6 does not forbid ipv6 addresses.

This commit also clean up a bit of the ipv6 related tun.c. Changes for most 
platforms are minimal.

For linux a bit more cleanup is done:
- Remove compatibility defines that were added 2008
- Always use IFF_NO_PI for the linux tun and not only for IPv4 only tun setups 
(Android also always IFF_NO_PI works fine with Ipv6).

This commit also remove a non ipv6 fallback for tap driver from OpenVPN 
2.2-beta or earlier and only warns.

Patch V2: Integrate Gert's comments
Patch V3: Remove tun_ipv4 option. It only used for MTU discovery and there it 
was wrong since it should on the transport protocol if at all
Patch V4: Completely remove support for NetBSD <= 4.0 and remove 
NETBSD_MULTI_AF defines
---
 Changes.rst   |   3 ++
 src/openvpn/forward.c |   2 +-
 src/openvpn/helper.c  |   2 -
 src/openvpn/init.c|   6 ---
 src/openvpn/multi.c   |   8 ++-
 src/openvpn/openvpn.h |   5 --
 src/openvpn/options.c |  11 +---
 src/openvpn/options.h |   1 -
 src/openvpn/route.c   |  13 ++---
 src/openvpn/tun.c | 139 +++---
 src/openvpn/tun.h |   2 -
 11 files changed, 30 insertions(+), 162 deletions(-)

diff --git a/Changes.rst b/Changes.rst
index 9fcba75..2956003 100644
--- a/Changes.rst
+++ b/Changes.rst
@@ -135,6 +135,9 @@ User-visible Changes
   ciphers configured in the config file.  Use --ncp-disable if you don't want
   that.
 
+- ALl tun devices on all platforms are considered always IPv6 capable. The 
--tun-ipv6
+  option is ignored (behaves like it is always on).
+
 
 Maintainer-visible changes
 --
diff --git a/src/openvpn/forward.c b/src/openvpn/forward.c
index 6c11439..b3077ed 100644
--- a/src/openvpn/forward.c
+++ b/src/openvpn/forward.c
@@ -391,7 +391,7 @@ check_fragment_dowork (struct context *c)
   struct link_socket_info *lsi = get_link_socket_info (c);
 
   /* OS MTU Hint? */
-  if (lsi->mtu_changed && c->c2.ipv4_tun)
+  if (lsi->mtu_changed)
 {
   frame_adjust_path_mtu (>c2.frame_fragment, c->c2.link_socket->mtu,
 c->options.ce.proto);
diff --git a/src/openvpn/helper.c b/src/openvpn/helper.c
index 62f88ec..229523d 100644
--- a/src/openvpn/helper.c
+++ b/src/openvpn/helper.c
@@ -200,8 +200,6 @@ helper_client_server (struct options *o)
add_in6_addr( o->server_network_ipv6, 0x1000 );
o->ifconfig_ipv6_pool_netbits = o->server_netbits_ipv6;
 
-   o->tun_ipv6 = true;
-
push_option( o, "tun-ipv6", M_USAGE );
  }
 
diff --git a/src/openvpn/init.c b/src/openvpn/init.c
index cc8e945..73f8c6d 100644
--- a/src/openvpn/init.c
+++ b/src/openvpn/init.c
@@ -1400,9 +1400,6 @@ do_init_tun (struct context *c)
   !c->options.ifconfig_nowarn,
   c->c2.es);
 
-  /* flag tunnel for IPv6 config if --tun-ipv6 is set */
-  c->c1.tuntap->ipv6 = c->options.tun_ipv6;
-
   init_tun_post (c->c1.tuntap,
 >c2.frame,
 >options.tuntap_options);
@@ -1420,9 +1417,6 @@ do_open_tun (struct context *c)
   struct gc_arena gc = gc_new ();
   bool ret = false;
 
-  c->c2.ipv4_tun = (!c->options.tun_ipv6
-   && is_dev_type (c->options.dev, c->options.dev_type, 
"tun"));
-
 #ifndef TARGET_ANDROID
   if (!c->c1.tuntap)
 {
diff --git a/src/openvpn/multi.c b/src/openvpn/multi.c
index 3bc6ee9..93a554d 100644
--- a/src/openvpn/multi.c
+++ b/src/openvpn/multi.c
@@ -1378,8 +1378,7 @@ multi_select_virtual_addr (struct multi_context *m, 
struct multi_instance *mi)
* (see below) so issue a warning if that happens - don't break the
* session, though, as we don't even know if this client WANTS IPv6
*/
-  if ( mi->context.c1.tuntap->ipv6 &&
-  mi->context.options.ifconfig_ipv6_pool_defined &&
+  if ( mi->context.options.ifconfig_ipv6_pool_defined &&
   ! mi->context.options.push_ifconfig_ipv6_defined )
{
  msg( M_INFO, "MULTI_sva: WARNING: if --ifconfig-push is used for 
IPv4, automatic IPv6 assignment from --ifconfig-ipv6-pool does not work.  Use 
--ifconfig-ipv6-push for IPv6 then." );
@@ -1452,8 +1451,7 @@ multi_select_virtual_addr (struct multi_context *m, 
struct multi_instance *mi)
* way round ("dynamic IPv4, static IPv6") or "both static" makes sense
* -> and so it's implemented right now
*/
-  if ( mi->context.c1.tuntap->ipv6 &&
-   mi->context.options.push_ifconfig_ipv6_defined )
+  if ( mi->context.options.push_ifconfig_ipv6_defined )
 {
   mi->context.c2.push_ifconfig_ipv6_local = 
mi->context.options.push_ifconfig_ipv6_local;
@@ -1511,7 +1509,7 @@ multi_set_virtual_addr_env (struct multi_context *m, 
struct