Re: [Openvpn-devel] [PATCH v2 9/9] client-connect: Add deferred support to the client-connect plugin v1 handler

[Heikki Hannikainen]

Fabian,

Have you by any chance ported this patch set forward to the current
OpenVPN master / 2.4. beta?

We have used a variation of it, and gained a noticeable performance boost,
for a long time. Thanks to the deferred client-connect handling the
openvpn server does not stop packet processing while a client-connect
handler plugin is doing what it needs to do, reducing jitter and packet 
loss for other clients.

It'd be great to have this merged in the master tree at some point.


On Sat, 17 Jan 2015, Fabian Knittel wrote:

> Uses the infrastructure provided and used in the previous patch to provide
> deferral support to the v1 client-connect plugin handler as well.
>
> Signed-off-by: Fabian Knittel 
> ---
> src/openvpn/multi.c | 32 
> 1 file changed, 20 insertions(+), 12 deletions(-)
>
> diff --git a/src/openvpn/multi.c b/src/openvpn/multi.c
> index 68a7248..ab73034 100644
> --- a/src/openvpn/multi.c
> +++ b/src/openvpn/multi.c
> @@ -1814,6 +1814,7 @@ multi_client_connect_call_plugin_v1 (struct 
> multi_context *m,
> {
>   enum client_connect_return ret = CC_RET_SKIPPED;
> #ifdef ENABLE_PLUGIN
> +  struct client_connect_state *ccs = mi->client_connect_state;
>   ASSERT (m);
>   ASSERT (mi);
>   ASSERT (option_types_found);
> @@ -1821,34 +1822,41 @@ multi_client_connect_call_plugin_v1 (struct 
> multi_context *m,
>   if (plugin_defined (mi->context.plugins, OPENVPN_PLUGIN_CLIENT_CONNECT))
> {
>   int plug_ret;
> -  struct gc_arena gc = gc_new ();
>   struct argv argv = argv_new ();
> -  const char *dc_file = create_temp_file (mi->context.options.tmp_dir, 
> "cc", );
>
> -  if (!dc_file)
> +  if (!ccs_gen_config_file (mi) ||
> +   !ccs_gen_deferred_ret_file (mi))
>   {
> ret = CC_RET_FAILED;
> -   goto script_depr_failed;
> +   goto cleanup;
>   }
>
> -  argv_printf (, "%s", dc_file);
> +  argv_printf (, "%s", ccs->config_file);
>
>   plug_ret = plugin_call (mi->context.plugins,
> OPENVPN_PLUGIN_CLIENT_CONNECT,
> , NULL, mi->context.c2.es);
>   argv_reset ();
> -  if (plug_ret != OPENVPN_PLUGIN_FUNC_SUCCESS)
> +  if (plug_ret == OPENVPN_PLUGIN_FUNC_SUCCESS)
> + {
> +   multi_client_connect_post (m, mi, ccs->config_file,
> +  option_types_found);
> +   ret = CC_RET_SUCCEEDED;
> + }
> +  else if (plug_ret == OPENVPN_PLUGIN_FUNC_DEFERRED)
> + ret = CC_RET_DEFERRED;
> +  else
>   {
> msg (M_WARN, "WARNING: client-connect plugin call failed");
> ret = CC_RET_FAILED;
>   }
> -  else
> +
> +cleanup:
> +  if (ret != CC_RET_DEFERRED)
>   {
> -   multi_client_connect_post (m, mi, dc_file, option_types_found);
> -   ret = CC_RET_SUCCEEDED;
> +   ccs_delete_config_file (mi);
> +   ccs_delete_deferred_ret_file (mi);
>   }
> -script_depr_failed:
> -  gc_free ();
> }
> #endif
>   return ret;
> @@ -2141,7 +2149,7 @@ static const struct client_connect_handlers 
> client_connect_handlers[] = {
>   },
>   {
> main: multi_client_connect_call_plugin_v1,
> -deferred: multi_client_connect_fail
> +deferred: multi_client_handle_deferred
>   },
>   {
> main: multi_client_connect_call_plugin_v2,
> -- 
> 2.1.4
>
>
> --
> New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
> GigeNET is offering a free month of service with a new server in Ashburn.
> Choose from 2 high performing configs, both with 100TB of bandwidth.
> Higher redundancy.Lower latency.Increased capacity.Completely compliant.
> http://p.sf.net/sfu/gigenet
> ___
> Openvpn-devel mailing list
> Openvpn-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openvpn-devel
>

   - Hessu


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

Re: [Openvpn-devel] session-id implementation

[Heikki Hannikainen]

On Wed, 9 Jul 2014, Arne Schwabe wrote:


Am 29.06.14 18:13, schrieb Arne Schwabe:

Am 27.03.14 09:57, schrieb Lev Stipakov:

Hi,

Same patch with added NULL check in push.c:308. Turns out that
peer_info might be NULL.


I looked at the patched, a few minor nitpicks:


One more little nitpick:

  uint32_t sess;

   ...

  sess = ((P_DATA_V2 << P_OPCODE_SHIFT) | ks->key_id) | (multi->vpn_session_id 
<< 8);
  ASSERT (buf_write_prepend (buf, , 4));

I think this will cause byte sex issues when talking between big and 
little endian machines.


A strategically placed htonl() + ntohl() pair might help.  Have to make 
sure that the opcode really goes in as the first byte on the wire, and 
that the next 3 bytes are the 3 least significant bytes of the session ID.


  uint32_t sess = htonl(
(((P_DATA_V2 << P_OPCODE_SHIFT) | ks->key_id) << 24)
| (multi->vpn_session_id & 0xFF)
  );
  ASSERT (buf_write_prepend (buf, , 4));

Right? Maybe? :)

I suppose this patch will improve things quite a bit for mobile clients 
which switch from network to another.


  - Hessu

Re: [Openvpn-devel] [PATCH v3] Floating: Add support for floating in TLS mode

[Heikki Hannikainen]

On Mon, Dec 23, 2013 at 4:43 PM, André Valentin  wrote:
> On 23.12.2013 12:32, Gert Doering wrote:
>> We've discussed the patch on the Munich Hackathon, and we intend to do
>> it in a different way.  James wants to change the packet format for
>> data packets anyway (due to bad alignment in the current packet format),
>> and the new format would have the option to send the session ID in the
>> data packet as well, like "normally it's not sent, but if we have't heard
>> from the server longer than  time units, send a session ID so that
>> hmac-float will work".
>
> Of course, this is a better idea and should have less problems with scaling.
> But there should be an option for the client to always send the session id,
> so that there are no timeouts if the user decides to do so.

+1 to that - it'd be really neat if floating would work seamlessly
without timeouts + retransmissions. It'd be very useful on mobile
devices, which often get hit by NAT timeouts on UDP (around 30 or 60
seconds typically), switches between WIFI and 3G, and keepalive pings
with tight timers (sub-30-second range) consume a lot of battery.

The regular SSL session ID is maybe a bit long to be sent with each
and every packet, though.

Which other enhancements to the packet format are necessary? I
gathered that the encrypted data needs to be aligned for AES-NI to
work, which probably means that either the packet headers need to be
padded so that the data starts on a nice word boundary, or that the
data packet needs to begin with the encrypted data and all the headers
need to be placed in the end of the packet. Right?

And then some backwards compatibility in the handshake - it'd be good
if old clients could optionally be allowed on new servers using the
new packet format.

>> This code has not been written yet, though, and we have no specific
>> timelines when it will happen.
> So what does this mean for my work and the current format? Is there still
> a possibility that it will be integrated for the 'old packet format'?

We could also start working on the new packet format, do a prototype
if you'd like. Just need to figure out what the exact requirements
would be.

 - Hessu