Re: [Openvpn-devel] OpenVPN-GUI now on GitHub + other Windows team things

[debbie10t]

Today - I _finally_ managed to cross-compile openvpn for windows (including
GUI+service) I strongly recommend, *if* you try this, use Ubuntu 14.04 64bit 
!

I tried and failed with other *nix.

https://community.openvpn.net/openvpn/wiki/BuildingUsingGenericBuildsystem

Building for Linux with Linux is relatively simple by comparison.

Regards

- Original Message - 
From: "Samuli Seppänen" 
To: "Morris, Russell" ; 


Sent: Tuesday, November 17, 2015 5:55 PM
Subject: Re: [Openvpn-devel] OpenVPN-GUI now on GitHub + other Windows team 
things



Hi,

I personally don't build openvpn-gui as-is. Instead, it gets built
during the openvpn-build build process, which builds OpenVPN and all its
dependencies.

We should definitely document this option in the openvpn-gui readme.
Currently it's only documented in Trac.

Samuli




Hi,

I do see the notes about " Building OpenVPN GUI from source" - but is 
there a way to build this under Linux (may be easier for some)?


Thanks,
... Russell


-Original Message-
From: Samuli Seppänen [mailto:sam...@openvpn.net]
Sent: Tuesday, November 17, 2015 4:01 AM
To: openvpn-devel@lists.sourceforge.net
Subject: [Openvpn-devel] OpenVPN-GUI now on GitHub + other Windows team 
things


Hi all,

I migrated my private fork of openvpn-gui on GitHub to the OpenVPN
organization:



You can now issue pull requests and all that. An official
CONTRIBUTING.rst file is still missing so we need to create one.

---

I also officially announced the #openvpn-windows IRC channel on forums:



I also asked opinions about having a separate forum board for Windows
questions:



Feel free to chime in!

Best regards,





--
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel 

[Openvpn-devel] Take me offfff

[Emil Rudka]

I don't want to receive these emails! Can you please take me off the
mailing list!!!

Re: [Openvpn-devel] OpenVPN-GUI now on GitHub + other Windows team things

[Samuli Seppänen]

Hi,

I personally don't build openvpn-gui as-is. Instead, it gets built 
during the openvpn-build build process, which builds OpenVPN and all its 
dependencies.


We should definitely document this option in the openvpn-gui readme. 
Currently it's only documented in Trac.


Samuli




Hi,

I do see the notes about " Building OpenVPN GUI from source" - but is there a 
way to build this under Linux (may be easier for some)?

Thanks,
... Russell


-Original Message-
From: Samuli Seppänen [mailto:sam...@openvpn.net]
Sent: Tuesday, November 17, 2015 4:01 AM
To: openvpn-devel@lists.sourceforge.net
Subject: [Openvpn-devel] OpenVPN-GUI now on GitHub + other Windows team things

Hi all,

I migrated my private fork of openvpn-gui on GitHub to the OpenVPN
organization:



You can now issue pull requests and all that. An official
CONTRIBUTING.rst file is still missing so we need to create one.

---

I also officially announced the #openvpn-windows IRC channel on forums:



I also asked opinions about having a separate forum board for Windows
questions:



Feel free to chime in!

Best regards,

Re: [Openvpn-devel] [PATCH] Fix info.af == AF_UNSPEC case after commit 2bed089d31a12c2d0277e36a64964ebab6640f75

[Gert Doering]

Hi,

On Tue, Nov 17, 2015 at 01:43:50PM +, Christian Pellegrin wrote:
> I also see: "Could not determine IPv4/IPv6 protocol. Using AF_INET" in
> the logs (which points in an quite explicative conditional in
> socket.c). The configuration entries that might affect this and that
> are present in my configuration are:
> 
> local [IPv4 address]
> lport 443
> mode server
> proto udp
> server [IPv4 subnet]
> topology subnet

I had the suspicion that this happens for the server side - "proto udp"
is the giveaway, as it will pass AF_UNSPEC to getaddrinfo() to get 
"what is needed for dual-stack"  (which does not always work, but that's
a different story).  So, starting out with AF_UNSPEC is good, but the
actual socket later on isn't (it is what getaddrinfo() returns)...

The client side should be sorted out quite nicely now, but seems the
server side could need some more polishing - so thanks for your patch,
and since it already got an ACK by our master of socket.c, I'll merge 
it ASAP.

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

Re: [Openvpn-devel] OpenVPN-GUI now on GitHub + other Windows team things

[Morris, Russell]

Hi,

I do see the notes about " Building OpenVPN GUI from source" - but is there a 
way to build this under Linux (may be easier for some)?

Thanks,
... Russell


-Original Message-
From: Samuli Seppänen [mailto:sam...@openvpn.net] 
Sent: Tuesday, November 17, 2015 4:01 AM
To: openvpn-devel@lists.sourceforge.net
Subject: [Openvpn-devel] OpenVPN-GUI now on GitHub + other Windows team things

Hi all,

I migrated my private fork of openvpn-gui on GitHub to the OpenVPN 
organization:



You can now issue pull requests and all that. An official 
CONTRIBUTING.rst file is still missing so we need to create one.

---

I also officially announced the #openvpn-windows IRC channel on forums:



I also asked opinions about having a separate forum board for Windows 
questions:



Feel free to chime in!

Best regards,

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

irc freenode net: mattock

--
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH] Fix info.af == AF_UNSPEC case after commit 2bed089d31a12c2d0277e36a64964ebab6640f75

[Christian Pellegrin]

On Tue, Nov 17, 2015 at 1:03 PM, Gert Doering  wrote:
> Why are you seeing AF_UNSPEC there?  This is actually more interesting
> to me right now than debating possible avenues to fix this :-)

I also see: "Could not determine IPv4/IPv6 protocol. Using AF_INET" in
the logs (which points in an quite explicative conditional in
socket.c). The configuration entries that might affect this and that
are present in my configuration are:

local [IPv4 address]
lport 443
mode server
proto udp
server [IPv4 subnet]
topology subnet

and this happens on a host where I configured just IPv4 (even if the
host itself is dual homed). Interestingly, if I configure full IPv6,
i.e. I add:

local [IPv6 address]
proto udp6
server [IPv6 netblock]

the problem (and of course above message) goes away. I mistakenly
assumed that seeing AF_UNSPEC is OK (from various comments when you
grep for AF_UNSPEC). If you think the root of all evil is this value,
I will dig further.

Thanks!

Re: [Openvpn-devel] [PATCH] Fix info.af == AF_UNSPEC case after commit 2bed089d31a12c2d0277e36a64964ebab6640f75

[Gert Doering]

Hi,

On Tue, Nov 17, 2015 at 12:32:16PM +, Christian Pellegrin wrote:
> Looks better than just adding AF_UNSPEC case but I noted many other
> FIXMEs about AF_UNSPEC that could be solved this way. So let me know
> if there is any reason to not use the ai_family field (and just add
> the AF_UNSPEC case in set_mtu_discovery)

Why are you seeing AF_UNSPEC there?  This is actually more interesting
to me right now than debating possible avenues to fix this :-)

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

Re: [Openvpn-devel] [PATCH] Fix info.af == AF_UNSPEC case after commit 2bed089d31a12c2d0277e36a64964ebab6640f75

[Arne Schwabe]

Am 17.11.15 um 13:32 schrieb Christian Pellegrin:
> Looks better than just adding AF_UNSPEC case but I noted many other
> FIXMEs about AF_UNSPEC that could be solved this way. So let me know
> if there is any reason to not use the ai_family field (and just add
> the AF_UNSPEC case in set_mtu_discovery)
> 

Still not very pretty but this is better than failing so ACK from me.

Arne

[Openvpn-devel] [PATCH] Fix info.af == AF_UNSPEC case after commit 2bed089d31a12c2d0277e36a64964ebab6640f75

[Christian Pellegrin]

Looks better than just adding AF_UNSPEC case but I noted many other
FIXMEs about AF_UNSPEC that could be solved this way. So let me know
if there is any reason to not use the ai_family field (and just add
the AF_UNSPEC case in set_mtu_discovery)

Thanks!
From 7044e2731eeafcc7f877c7d8b77676fb5d4dbd67 Mon Sep 17 00:00:00 2001
From: Christian Pellegrin 
Date: Tue, 17 Nov 2015 12:12:10 +
Subject: [PATCH] Fix info.af == AF_UNSPEC case after commit
 2bed089d31a12c2d0277e36a64964ebab6640f75

Signed-off-by: Christian Pellegrin 
---
 src/openvpn/socket.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/openvpn/socket.c b/src/openvpn/socket.c
index 3ef7279..c7885fd 100644
--- a/src/openvpn/socket.c
+++ b/src/openvpn/socket.c
@@ -1670,7 +1670,7 @@ phase2_set_socket_flags (struct link_socket* sock)
 set_cloexec (sock->ctrl_sd);
 
   /* set Path MTU discovery options on the socket */
-  set_mtu_discover_type (sock->sd, sock->mtu_discover_type, sock->info.af);
+  set_mtu_discover_type (sock->sd, sock->mtu_discover_type, sock->info.lsa->bind_local->ai_family);
 
 #if EXTENDED_SOCKET_ERROR_CAPABILITY
   /* if the OS supports it, enable extended error passing on the socket */
-- 
2.6.0.rc2.230.g3dd15c0

[Openvpn-devel] OpenVPN-GUI now on GitHub + other Windows team things

[Samuli Seppänen]

Hi all,

I migrated my private fork of openvpn-gui on GitHub to the OpenVPN 
organization:




You can now issue pull requests and all that. An official 
CONTRIBUTING.rst file is still missing so we need to create one.


---

I also officially announced the #openvpn-windows IRC channel on forums:



I also asked opinions about having a separate forum board for Windows 
questions:




Feel free to chime in!

Best regards,

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

irc freenode net: mattock

[Openvpn-devel] [PATCH v4] Notify clients about server's exit/restart

[Lev Stipakov]

When server exits / restarts (gets SIGUSR1, SIGTERM, SIGHUP, SIGINT) and
explicit-exit-notify is set, server sends RESTART control channel
command to all clients and reschedules received signal in 2 secs.

When client receives RESTART command, it either reconnects to the same
server or advances to the new one, depends on parameter comes with
RESTART command - behavior is controlled by explicit-exit-notify in the
server config.

v4:
- Rebase on top of master
- Remove #ifdef ENABLE_OCC around connection_entry->explicit_exit_notification
since it is also used outside of OCC context
- Update usage message

v3:
- Use control channel "RESTART" command instead of new OCC code to
notify clients
- Configure on the server side (by value of explicit-exit-notify) if
client should reconnect to the same server or advance to the next one
- Fix compilation when OCC is disabled (--enable-small)
- Update man page

v2:
- Take into use explicit-exit-notify on the server side
- OCC_SHUTTING_DOWN renamed to OCC_SERVER_EXIT
- Code prettifying

Signed-off-by: Lev Stipakov 
---
 doc/openvpn.8 | 15 ++--
 src/openvpn/multi.c   | 66 ---
 src/openvpn/multi.h   |  9 +++
 src/openvpn/options.c |  7 +++---
 src/openvpn/options.h |  4 +---
 src/openvpn/push.c|  6 +
 6 files changed, 95 insertions(+), 12 deletions(-)

diff --git a/doc/openvpn.8 b/doc/openvpn.8
index 2978b7f..dfb63fc 100644
--- a/doc/openvpn.8
+++ b/doc/openvpn.8
@@ -3886,8 +3886,19 @@ option will tell the server to immediately close its 
client instance object
 rather than waiting for a timeout.  The
 .B n
 parameter (default=1) controls the maximum number of attempts that the client
-will try to resend the exit notification message.  OpenVPN will not send any 
exit
-notifications unless this option is enabled.
+will try to resend the exit notification message. 
+
+In UDP server mode, send RESTART control channel command to connected clients. 
The
+.B n
+parameter (default=1) controls client behavior. With
+.B n
+= 1 client will attempt to reconnect
+to the same server, with
+.B n
+= 2 client will advance to the next server.
+
+OpenVPN will not send any exit
+notifications unless this option is enabled. 
 .\"*
 .SS Data Channel Encryption Options:
 These options are meaningful for both Static & TLS-negotiated key modes
diff --git a/src/openvpn/multi.c b/src/openvpn/multi.c
index 7c3aaac..e153be7 100644
--- a/src/openvpn/multi.c
+++ b/src/openvpn/multi.c
@@ -429,6 +429,8 @@ multi_init (struct multi_context *m, struct context *t, 
bool tcp_mode, int threa
 t->options.stale_routes_check_interval, 
t->options.stale_routes_ageing_time);
   event_timeout_init (>stale_routes_check_et, 
t->options.stale_routes_check_interval, 0);
 }
+
+  m->deferred_shutdown_signal.signal_received = 0;
 }

 const char *
@@ -2721,10 +2723,18 @@ multi_process_timeout (struct multi_context *m, const 
unsigned int mpp_flags)
   /* instance marked for wakeup? */
   if (m->earliest_wakeup)
 {
-  set_prefix (m->earliest_wakeup);
-  ret = multi_process_post (m, m->earliest_wakeup, mpp_flags);
+  if (m->earliest_wakeup == (struct 
multi_instance*)>deferred_shutdown_signal)
+   {
+ schedule_remove_entry(m->schedule, (struct schedule_entry*) 
>deferred_shutdown_signal);
+ throw_signal(m->deferred_shutdown_signal.signal_received);
+   }
+  else
+   {
+ set_prefix (m->earliest_wakeup);
+ ret = multi_process_post (m, m->earliest_wakeup, mpp_flags);
+ clear_prefix ();
+   }
   m->earliest_wakeup = NULL;
-  clear_prefix ();
 }
   return ret;
 }
@@ -2849,6 +2859,48 @@ multi_top_free (struct multi_context *m)
   free_context_buffers (m->top.c2.buffers);
 }

+static bool
+is_exit_restart(int sig)
+{
+  return (sig == SIGUSR1 || sig == SIGTERM || sig == SIGHUP || sig == SIGINT);
+}
+
+static void
+multi_push_restart_schedule_exit(struct multi_context *m, bool next_server)
+{
+  struct hash_iterator hi;
+  struct hash_element *he;
+  struct timeval tv;
+
+  /* tell all clients to restart */
+  hash_iterator_init (m->iter, );
+  while ((he = hash_iterator_next ()))
+{
+  struct multi_instance *mi = (struct multi_instance *) he->value;
+  if (!mi->halt)
+{
+ send_control_channel_string (>context, next_server ? 
"RESTART,[N]" : "RESTART", D_PUSH);
+ multi_schedule_context_wakeup(m, mi);
+}
+}
+  hash_iterator_free ();
+
+  /* reschedule signal */
+  ASSERT (!openvpn_gettimeofday (>deferred_shutdown_signal.wakeup, NULL));
+  tv.tv_sec = 2;
+  tv.tv_usec = 0;
+  tv_add (>deferred_shutdown_signal.wakeup, );
+
+  m->deferred_shutdown_signal.signal_received = m->top.sig->signal_received;
+
+  schedule_add_entry (m->schedule,
+ (struct schedule_entry *) >deferred_shutdown_signal,
+ 

[Openvpn-devel] [PATCH] Handle ctrl-C and ctrl-break events on Windows

[Selva Nair]

v2 changes
 - cleaner, hopefully easier to get a code review :)
 - handles both console mode and service mode
-- >8 --

Handle ctrl-C or ctrl-Break sent to the console as a SIGTERM.
Depending on the console mode, windows delivers ctrl-C as a
keyboard input or as a signal. We handle both cases. This allows
graceful termination of openvpn from programs such as nssm.
Works in both console mode and service mode.

Signed-off-by: Selva Nair 
---
 src/openvpn/win32.c | 53 +
 1 file changed, 52 insertions(+)

diff --git a/src/openvpn/win32.c b/src/openvpn/win32.c
index d06b41f..1f9bda0 100644
--- a/src/openvpn/win32.c
+++ b/src/openvpn/win32.c
@@ -324,6 +324,53 @@ net_event_win32_close (struct net_event_win32 *ne)
  * (2) Service mode -- map Windows event object to SIGTERM
  */

+static void
+win_trigger_event(struct win32_signal *ws)
+{
+  if (ws->mode == WSO_MODE_SERVICE && HANDLE_DEFINED(ws->in.read))
+SetEvent (ws->in.read);
+  else /* generate a key-press event */
+{
+  DWORD tmp;
+  INPUT_RECORD ir;
+  HANDLE stdin_handle = GetStdHandle(STD_INPUT_HANDLE);
+
+  CLEAR(ir);
+  ir.EventType = KEY_EVENT;
+  ir.Event.KeyEvent.bKeyDown = true;
+  if (!stdin_handle || !WriteConsoleInput(stdin_handle, , 1, ))
+msg(M_WARN|M_ERRNO, "WARN: win_trigger_event: WriteConsoleInput");
+}
+}
+
+/*
+ * Callback to handle console ctrl events
+ */
+static bool WINAPI
+win_ctrl_handler (DWORD signum)
+{
+  msg(D_LOW, "win_ctrl_handler: signal received (code=%lu)", (unsigned long) 
signum);
+
+  if (siginfo_static.signal_received == SIGTERM)
+ return true;
+
+  switch (signum)
+{
+case CTRL_C_EVENT:
+case CTRL_BREAK_EVENT:
+  throw_signal(SIGTERM);
+  /* trigget the win32_signal to interrupt the event loop */
+  win_trigger_event(_signal);
+  return true;
+  break;
+default:
+  msg(D_LOW, "win_ctrl_handler: signal (code=%lu) not handled", (unsigned 
long) signum);
+  break;
+}
+  /* pass all other signals to the next handler */
+  return false;
+}
+
 void
 win32_signal_clear (struct win32_signal *ws)
 {
@@ -403,6 +450,9 @@ win32_signal_open (struct win32_signal *ws,
ws->mode = WSO_MODE_SERVICE;
}
 }
+/* set the ctrl handler in both console and service modes */
+if (!SetConsoleCtrlHandler ((PHANDLER_ROUTINE) win_ctrl_handler, true))
+   msg (M_WARN|M_ERRNO, "WARN: SetConsoleCtrlHandler failed");
 }

 static bool
@@ -512,6 +562,9 @@ win32_signal_get (struct win32_signal *ws)
case 0x3E: /* F4 -> TERM */
  ret = SIGTERM;
  break;
+   case 0x03: /* CTRL-C -> TERM */
+ ret = SIGTERM;
+ break;
}
}
   if (ret)
-- 
2.6.2