[Openvpn-devel] [PATCH applied] Re: Fix typo in cipher_kt_mode_{cbc, ofb_cfb}() doxygen.

[Gert Doering]

ACK.

Your patch has been applied to the master and release/2.3 branches.

commit 38cd1ed5ee89218415c5edfc990cfd47fd879d55 (master)
commit d6865ba92eaff015fa5c5707186f4a9d52a68e25 (release/2.3)

Author: Steffan Karger
List-Post: openvpn-devel@lists.sourceforge.net
Date:   Tue Jul 29 23:04:26 2014 +0200

 Fix typo in cipher_kt_mode_{cbc, ofb_cfb}() doxygen.

 Signed-off-by: Steffan Karger 
 Acked-by: Gert Doering 
 Message-Id: <1406667866-14226-1-git-send-email-stef...@karger.me>
 URL: http://article.gmane.org/gmane.network.openvpn.devel/8953
 Signed-off-by: Gert Doering 


--
kind regards,

Gert Doering

Re: [Openvpn-devel] [PATCH] Fix --mtu-disc option with IPv6 transport

[Gert Doering]

Hi,

On Tue, Jul 29, 2014 at 10:27:42PM +0200, Julien Muchembled wrote:
> > Is there documentation for that socket option somewhere?
> 
> 'man 7 ip' and 'man 7 ipv6'

Thanks, will read up.

> For example:
>   A --[mtu=1500]-- B --[mtu=1400]-- C
> 
> Given a UDP6 socket on A with IPV6_MTU_DISCOVER=IP_PMTUDISC_DO,
> sendto(1452 bytes, B) will succeed
> but sendto(1452 bytes, C) will return EMSGSIZE (except for the first send to 
> C)
> Yes, at some point, there are icmp packets.

So (being lazy again, sorry) how is the maximum message size communicated
back to OpenVPN?  Ancilliary data again?

> > (Last not least, because I'm too lazy to look: is that patch against
> > git master or against release/2.3?)
> 
> master

Thanks.  I'll need to look at the code paths, but I think it warrants
inclusion in 2.3 as well - it's not affecting anything that is IPv4, 
and fixes a bug for IPv6.

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


pgpXkeOYa8gnD.pgp
Description: PGP signature

[Openvpn-devel] [PATCH] Fix typo in cipher_kt_mode_{cbc, ofb_cfb}() doxygen.

[Steffan Karger]

Signed-off-by: Steffan Karger 
---
 src/openvpn/crypto_backend.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/openvpn/crypto_backend.h b/src/openvpn/crypto_backend.h
index a48ad6c..bc067a7 100644
--- a/src/openvpn/crypto_backend.h
+++ b/src/openvpn/crypto_backend.h
@@ -231,7 +231,7 @@ int cipher_kt_block_size (const cipher_kt_t *cipher_kt);
 int cipher_kt_mode (const cipher_kt_t *cipher_kt);

 /**
- * Check of the supplied cipher is a supported CBC mode cipher.
+ * Check if the supplied cipher is a supported CBC mode cipher.
  *
  * @param cipher   Static cipher parameters. May not be NULL.
  *
@@ -241,7 +241,7 @@ bool cipher_kt_mode_cbc(const cipher_kt_t *cipher)
   __attribute__((nonnull));

 /**
- * Check of the supplied cipher is a supported OFB or CFB mode cipher.
+ * Check if the supplied cipher is a supported OFB or CFB mode cipher.
  *
  * @param cipher   Static cipher parameters. May not be NULL.
  *
-- 
1.9.1

[Openvpn-devel] [PATCH] Fix frame size calculation for non-CBC modes.

[Steffan Karger]

CBC mode is the only mode that OpenVPN supports that needs padding. So,
only include the worst case padding size in the frame size calculation when
using CBC mode.

While doing so, rewrite crypto_adjust_frame_parameters() to be better
readable, and provide debug output (for high debug levels).

Signed-off-by: Steffan Karger 
---
 src/openvpn/crypto.c | 26 +-
 1 file changed, 21 insertions(+), 5 deletions(-)

diff --git a/src/openvpn/crypto.c b/src/openvpn/crypto.c
index ef2bde1..2ba8487 100644
--- a/src/openvpn/crypto.c
+++ b/src/openvpn/crypto.c
@@ -403,11 +403,27 @@ crypto_adjust_frame_parameters(struct frame *frame,
   bool packet_id,
   bool packet_id_long_form)
 {
-  frame_add_to_extra_frame (frame,
-   (packet_id ? packet_id_size (packet_id_long_form) : 
0) +
-   ((cipher_defined && use_iv) ? cipher_kt_iv_size 
(kt->cipher) : 0) +
-   (cipher_defined ? cipher_kt_block_size (kt->cipher) 
: 0) + /* worst case padding expansion */
-   kt->hmac_length);
+  size_t crypto_overhead = 0;
+
+  if (packet_id)
+crypto_overhead += packet_id_size (packet_id_long_form);
+
+  if (cipher_defined)
+{
+  if (use_iv)
+   crypto_overhead += cipher_kt_iv_size (kt->cipher);
+
+  if (cipher_kt_mode_cbc (kt->cipher))
+   /* worst case padding expansion */
+   crypto_overhead += cipher_kt_block_size (kt->cipher);
+}
+
+  crypto_overhead += kt->hmac_length;
+
+  frame_add_to_extra_frame (frame, crypto_overhead);
+
+  msg(D_MTU_DEBUG, "%s: Adjusting frame parameters for crypto by %zu bytes",
+  __func__, crypto_overhead);
 }

 /*
-- 
1.9.1

Re: [Openvpn-devel] [PATCH] Fix --mtu-disc option with IPv6 transport

[Julien Muchembled]

Le 07/29/14 20:57, Gert Doering a écrit :
> On Tue, Jul 29, 2014 at 07:28:49PM +0200, Julien Muchembled wrote:
>> Socket configuration of MTU discovery was done unconditionally at IP level,
>> which has no effect for other protocols. This fixes the issue of OpenVPN
>> sending fragmented tcp6/udp6 packets even when 'mtu-disc yes' option is 
>> passed.
> 
> Sounds good.  I'm not sure I understand what that socket option *does*,
> though...  will it make the kernel report back any ICMP packet too big
> messages received?  Or will it not honour those unless IPV6_MTU_DISCOVER
> is set?
> 
> Is there documentation for that socket option somewhere?

'man 7 ip' and 'man 7 ipv6'

For example:
  A --[mtu=1500]-- B --[mtu=1400]-- C

Given a UDP6 socket on A with IPV6_MTU_DISCOVER=IP_PMTUDISC_DO,
sendto(1452 bytes, B) will succeed
but sendto(1452 bytes, C) will return EMSGSIZE (except for the first send to C)

Yes, at some point, there are icmp packets.

> (Last not least, because I'm too lazy to look: is that patch against
> git master or against release/2.3?)

master



signature.asc
Description: OpenPGP digital signature

Re: [Openvpn-devel] [PATCH] Fix --mtu-disc option with IPv6 transport

[Gert Doering]

Hi,

On Tue, Jul 29, 2014 at 07:28:49PM +0200, Julien Muchembled wrote:
> Socket configuration of MTU discovery was done unconditionally at IP level,
> which has no effect for other protocols. This fixes the issue of OpenVPN
> sending fragmented tcp6/udp6 packets even when 'mtu-disc yes' option is 
> passed.

Sounds good.  I'm not sure I understand what that socket option *does*,
though...  will it make the kernel report back any ICMP packet too big
messages received?  Or will it not honour those unless IPV6_MTU_DISCOVER
is set?

Is there documentation for that socket option somewhere?

(Last not least, because I'm too lazy to look: is that patch against
git master or against release/2.3?)

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


pgpPOoJJ5pEDp.pgp
Description: PGP signature

[Openvpn-devel] [PATCH] Fix --mtu-disc option with IPv6 transport

[Julien Muchembled]

Socket configuration of MTU discovery was done unconditionally at IP level,
which has no effect for other protocols. This fixes the issue of OpenVPN
sending fragmented tcp6/udp6 packets even when 'mtu-disc yes' option is passed.

Signed-off-by: Julien Muchembled 
---
 src/openvpn/mtu.c| 23 +--
 src/openvpn/mtu.h|  2 +-
 src/openvpn/socket.c |  2 +-
 3 files changed, 19 insertions(+), 8 deletions(-)

diff --git a/src/openvpn/mtu.c b/src/openvpn/mtu.c
index 13f3f6c..426c487 100644
--- a/src/openvpn/mtu.c
+++ b/src/openvpn/mtu.c
@@ -153,15 +153,26 @@ frame_print (const struct frame *frame,
 #define MTUDISC_NOT_SUPPORTED_MSG "--mtu-disc is not supported on this OS"

 void
-set_mtu_discover_type (int sd, int mtu_type)
+set_mtu_discover_type (int sd, int mtu_type, sa_family_t proto_af)
 {
   if (mtu_type >= 0)
 {
-#if defined(HAVE_SETSOCKOPT) && defined(SOL_IP) && defined(IP_MTU_DISCOVER)
-  if (setsockopt
- (sd, SOL_IP, IP_MTU_DISCOVER, _type, sizeof (mtu_type)))
-   msg (M_ERR, "Error setting IP_MTU_DISCOVER type=%d on TCP/UDP socket",
-mtu_type);
+#if defined(HAVE_SETSOCKOPT) && defined(IP_MTU_DISCOVER) && 
defined(IPV6_MTU_DISCOVER)
+  switch (proto_af)
+   {
+   case AF_INET:
+ if (setsockopt
+ (sd, IPPROTO_IP, IP_MTU_DISCOVER, _type, sizeof (mtu_type)))
+   msg (M_ERR, "Error setting IP_MTU_DISCOVER type=%d on TCP/UDP 
socket",
+mtu_type);
+ break;
+   case AF_INET6:
+ if (setsockopt
+ (sd, IPPROTO_IPV6, IPV6_MTU_DISCOVER, _type, sizeof 
(mtu_type)))
+   msg (M_ERR, "Error setting IPV6_MTU_DISCOVER type=%d on TCP6/UDP6 
socket",
+mtu_type);
+ break;
+   }
 #else
   msg (M_FATAL, MTUDISC_NOT_SUPPORTED_MSG);
 #endif
diff --git a/src/openvpn/mtu.h b/src/openvpn/mtu.h
index 29ec21f..cb41dc6 100644
--- a/src/openvpn/mtu.h
+++ b/src/openvpn/mtu.h
@@ -207,7 +207,7 @@ void frame_print (const struct frame *frame,
  int level,
  const char *prefix);

-void set_mtu_discover_type (int sd, int mtu_type);
+void set_mtu_discover_type (int sd, int mtu_type, sa_family_t proto_af);
 int translate_mtu_discover_type_name (const char *name);

 /*
diff --git a/src/openvpn/socket.c b/src/openvpn/socket.c
index 9e6bd10..344a9f7 100644
--- a/src/openvpn/socket.c
+++ b/src/openvpn/socket.c
@@ -1685,7 +1685,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);
+  set_mtu_discover_type (sock->sd, sock->mtu_discover_type, sock->info.af);

 #if EXTENDED_SOCKET_ERROR_CAPABILITY
   /* if the OS supports it, enable extended error passing on the socket */
-- 
1.8.5.2.988.g9b015e5.dirty

[Openvpn-devel] Async OPENVPN_PLUGIN_CLIENT_CONNECT plugin support

[Lev Stipakov]

Hello,

I am pondering about asynchronous OPENVPN_PLUGIN_CLIENT_CONNECT
callback. Basically, I want _not_ to establish connection until
response is received and ofcI  don't want to block rest of traffic.

My idea is to have some kind of connect_control_file (similar to
auth_conrol_file) and pass its path via env to
OPENVPN_PLUGIN_CLIENT_CONNECT. In case of plugin (or maybe script
too?) has returned OPENVPN_PLUGIN_FUNC_DEFERRED, I continue executing
"multi_connection_established" as usual except I don't set
"push_reply_deferred" to False (to prevent push response from being
sent) and I set some "connect-deferred" flag.

Next, when "process_incoming_push_msg" get called and flag
"connect-deferred" is set, I check the state of connect_control_file.
If there is, say, "1" - I send push reply and connection got
established.

What do you think about that? Does that approach sound reasonable?

-- 
-Lev