openvpn-devel Mailing List for OpenVPN

Am 25.12.12 13:48, schrieb Gert Doering: > Hi, > > On Sun, Dec 23, 2012 at 01:11:22PM +0100, Arne Schwabe wrote: >> I fear we may have to delay the final release. While debugging a problem >> with a user of my app I found a nasty bug which causes OpenVPN to crash >> if two PUSH_CONTROL messages are received. > The appended patch fixes this for me (Client on Linux/i386, but that > should be OS and architecture agnostic). > ACK. Also works on Android/ARMv7a. Arne 

Hi, On Sun, Dec 23, 2012 at 01:11:22PM +0100, Arne Schwabe wrote: > I fear we may have to delay the final release. While debugging a problem > with a user of my app I found a nasty bug which causes OpenVPN to crash > if two PUSH_CONTROL messages are received. The appended patch fixes this for me (Client on Linux/i386, but that should be OS and architecture agnostic). gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany ge...@gr... fax: +49-89-35655025 ge...@ne... 

Hi, On Sun, Dec 23, 2012 at 01:11:22PM +0100, Arne Schwabe wrote: > I fear we may have to delay the final release. While debugging a problem > with a user of my app I found a nasty bug which causes OpenVPN to crash > if two PUSH_CONTROL messages are received. > > from push.c: > > if (!c->c2.did_pre_pull_restore) > { > pre_pull_restore (&c->options); > md5_state_init (&c->c2.pulled_options_state); > c->c2.did_pre_pull_restore = true; > } > > This is executed on the first push message and initializes the md5 > state. On further push messages (continuation or new) this is not > executed again. Indeed, this is coupling two things - "pre-pull options saving" (to restore to the state before pulling, which only ever needs to be executed once), and "md5 state init", which needs to be executed for every round of PUSH_REPLY... Assuming there is only one PUSH_REPLY ever, this is no problem, but with the new server side code plus mobile networks, this can indeed be triggered. I'd propose to fix this by adding "bool c->c2.pulled_options_md5_init", using that for md5_state_init() *and resetting it* after md5_state_final(). For a single PUSH_REPLY, this should not make a difference (except for a few bytes of code), and for multiple PUSH_REPLY messages this will re-init the md5_state properly. (I'll send a patch as soon as I can test this - Arne, could you send me login credentials + config for your "will crash client!" server, please?) gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany ge...@gr... fax: +49-89-35655025 ge...@ne... 

----- Original Message ----- > From: "Arne Schwabe" <ar...@rf...> > To: ope...@li... > Sent: Sunday, 23 December, 2012 1:11:22 PM > Subject: [Openvpn-devel] Crash on duplicate PUSH_CONTROL message > > Hello, > > I fear we may have to delay the final release. While debugging a > problem > with a user of my app I found a nasty bug which causes OpenVPN to > crash > if two PUSH_CONTROL messages are received. This is not good news :( Well, I agree, we need to sort this one out. We can't release with this bug. Having that said, I'm not sure if the commit 5d4f5435a421299ed047485d8d99bdf9a0d22fd1 is the core issue to this bug, or if it just flushes out another corner case. That commit was added to solve an issue introduced in commit ff65da3a230b658b2c1d52dc1a48612e80a2eb42, but James pointed me at some other things to check out as well. But I've never had enough time to dig deeper on that topic. Without commit 5d4f5435a421299ed047485d8d99bdf9a0d22fd1, the client will never be able to re-connect to the server before its SSL context expires and is re-created. Which leads me to think that we're having a new corner case. Anyhow, we need to fix this ... and I'm going offline now until after new year, so I have no chance digging into this topic now, unfortunately. But I would prefer to solve both commit 5d4f5435a421299ed047485d8d99bdf9a0d22fd1 and this new issue in a better way then. kind regards, David Sommerseth > from push.c: > > if (!c->c2.did_pre_pull_restore) > { > pre_pull_restore (&c->options); > md5_state_init (&c->c2.pulled_options_state); > c->c2.did_pre_pull_restore = true; > } > > This is executed on the first push message and initializes the md5 > state. On further push messages (continuation or new) this is not > executed again. > > if (apply_push_options (&c->options, > &buf, > permission_mask, > option_types_found, > c->c2.es)) > switch (c->options.push_continuation) > { > case 0: > case 1: > md5_state_update (&c->c2.pulled_options_state, > BPTR(&buf_orig), > BLEN(&buf_orig)); > md5_state_final (&c->c2.pulled_options_state, > &c->c2.pulled_options_digest); > ret = PUSH_MSG_REPLY; > > This finalizes the md5 state. leaving pulled_options_state in a > uninitialized or at least undefined state. If a second push message > after a final message is received md5_state_update will use this > undefined context > > break; > case 2: > md5_state_update (&c->c2.pulled_options_state, > BPTR(&buf_orig), > BLEN(&buf_orig)); > ret = PUSH_MSG_CONTINUATION; > break; > } > > To trigger this issue there have multiple things. > > * A OpenVPN 2.3 server (commit > 5d4f5435a421299ed047485d8d99bdf9a0d22fd1 > allows duplicate sending of this message), you can also simply > duplicate > the send_push_something method call to trigger this bug on clients > * A bit flaky connection. The GSM/UMTS networks are great for this. > They > sometimes wait a very long time to deliver the packet (like 30s) > without > dropping packets > > I think the bug also exists in 2.2 clients but I have not done > extensive > checks. Since push_control messages have no sequence number or such > it > is difficult to determine how to only apply the push messages only > once. > > A quick&dirty hack is to simply md5_state_init the state after the > md5_state_final. > > Arne 

Hello, I fear we may have to delay the final release. While debugging a problem with a user of my app I found a nasty bug which causes OpenVPN to crash if two PUSH_CONTROL messages are received. from push.c: if (!c->c2.did_pre_pull_restore) { pre_pull_restore (&c->options); md5_state_init (&c->c2.pulled_options_state); c->c2.did_pre_pull_restore = true; } This is executed on the first push message and initializes the md5 state. On further push messages (continuation or new) this is not executed again. if (apply_push_options (&c->options, &buf, permission_mask, option_types_found, c->c2.es)) switch (c->options.push_continuation) { case 0: case 1: md5_state_update (&c->c2.pulled_options_state, BPTR(&buf_orig), BLEN(&buf_orig)); md5_state_final (&c->c2.pulled_options_state, &c->c2.pulled_options_digest); ret = PUSH_MSG_REPLY; This finalizes the md5 state. leaving pulled_options_state in a uninitialized or at least undefined state. If a second push message after a final message is received md5_state_update will use this undefined context break; case 2: md5_state_update (&c->c2.pulled_options_state, BPTR(&buf_orig), BLEN(&buf_orig)); ret = PUSH_MSG_CONTINUATION; break; } To trigger this issue there have multiple things. * A OpenVPN 2.3 server (commit 5d4f5435a421299ed047485d8d99bdf9a0d22fd1 allows duplicate sending of this message), you can also simply duplicate the send_push_something method call to trigger this bug on clients * A bit flaky connection. The GSM/UMTS networks are great for this. They sometimes wait a very long time to deliver the packet (like 30s) without dropping packets I think the bug also exists in 2.2 clients but I have not done extensive checks. Since push_control messages have no sequence number or such it is difficult to determine how to only apply the push messages only once. A quick&dirty hack is to simply md5_state_init the state after the md5_state_final. Arne 

Hi, On Thu, Dec 20, 2012 at 10:10:40AM +0100, David Sommerseth wrote: > > Cleanup in 2.4? > > Does it hurt to have this "dead code"? Agreed, if all the flags are > covered, we'll never see 'default' in action. But is it possible that > these flags can be extended at some point in the future, which we need > to account for? I somehow find confidence in having this "trap" with > msg(M_FATAL,...) for future scenarios. Not because I strongly believe > it will be needed, but more like a precaution (as in "Yes, we have > thought about this") Well, I'd completely get rid of the switch/case here - we only have 4 different cases, 2 of which are handled in the same subcase, so "setting up flags and then switch(flags), plus default: handler" seems to add more confusion than just handling possible cases directly in the if() statements... In general, having a "must not happen" handler to validate assumptions is a good thing, but if those preconditions are set by code 5 lines up, it's a bit over the top... gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany ge...@gr... fax: +49-89-35655025 ge...@ne... 

Hi, On Wed, Dec 19, 2012 at 11:13:05PM +0100, Jeremie Le Hen wrote: > > so I'd propose to #ifdef it differently, patch appended. > > Your patch looks fine to me. I went that way because I grep'ed the > source for TARGET_ and saw similar occurences of what I did, though each > part contained more lines :). Yeah, some of the existing bits are seriously ugly... :) gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany ge...@gr... fax: +49-89-35655025 ge...@ne... 

On 14/12/12 19:18, Gert Doering wrote: > Hi, > > next one: mtcp.c, about line 470: > > unsigned int flags = MTP_NONE; > > if (TUN_OUT(c)) > flags |= MTP_TUN_OUT; > if (LINK_OUT(c)) > flags |= MTP_LINK_OUT; > > switch (flags) > { > case MTP_TUN_OUT|MTP_LINK_OUT: > case MTP_TUN_OUT: > newaction = TA_TUN_WRITE; > break; > case MTP_LINK_OUT: > newaction = TA_SOCKET_WRITE; > break; > case MTP_NONE: > if (mi && socket_read_residual (c->c2.link_socket)) > newaction = TA_SOCKET_READ_RESIDUAL; > else > multi_tcp_set_global_rw_flags (m, mi); > break; > default: > { > struct gc_arena gc = gc_new (); > msg (M_FATAL, "MULTI TCP: multi_tcp_post bad state, mi=%s flags=%d", > multi_instance_string (mi, false, &gc), > flags); > gc_free (&gc); > break; > } > } > > > > coverity is complaining that the "default:" clause can never be reached, > as all the possible values for "flags" are covered - and it's obviously > right. It's not something critical, more a "code cleanup" thing. > > (The whole usage of switch/case here reeks a bit, given that I think the > code would be simpler by directly setting "newaction" depending on > "if (TUN_OUT(c))" etc., not bothering with "flags" in the first place) > > Cleanup in 2.4? Does it hurt to have this "dead code"? Agreed, if all the flags are covered, we'll never see 'default' in action. But is it possible that these flags can be extended at some point in the future, which we need to account for? I somehow find confidence in having this "trap" with msg(M_FATAL,...) for future scenarios. Not because I strongly believe it will be needed, but more like a precaution (as in "Yes, we have thought about this") -- kind regards, David Sommerseth 

On 19/12/12 22:26, Gert Doering wrote: > Hi, > > On Mon, Dec 17, 2012 at 11:03:55PM +0100, Jeremie Le Hen wrote: >> I thereby kindly ask you to bring this patch in the source tree. I >> don't know about your release procedure, but it would be really nice if >> it could hit the tree before 2.3 is released. > > Thanks for the excessive links to documentation - it helps verifying > things. I agree that this is a useful last-minute correction and should > go in (feature-ACK). > > I don't particularily like the way your patch is coded, though, as it's > "all of them but Linux" that have "int" here (except Windows, which uses > DWORD, but the docs say "use QoS API instead") - too many #ifdefs. > > http://msdn.microsoft.com/en-us/library/windows/desktop/ms738586(v=vs.85).aspx > > so I'd propose to #ifdef it differently, patch appended. > > From b6e0f27b4e6965de14cf0ec3e901a52d256cc88a Mon Sep 17 00:00:00 2001 > From: Gert Doering <ge...@gr...> > Date: Wed, 19 Dec 2012 22:12:41 +0100 > Subject: [PATCH] Fix parameter type for IP_TOS setsockopt on non-Linux > systems. > > Linux uses uint8_t, all BSD based stacks and Solaris use "int" (Windows > documentation says "DWORD" and "do not use, use QoS API instead"). > > Bug reported and fix provided by Torsten Vielhak and Jeremie Le Hen. > > Signed-off-by: Gert Doering <ge...@gr...> > --- > src/openvpn/socket.h | 4 ++++ > 1 files changed, 4 insertions(+), 0 deletions(-) ACK. Applied to master and beta/2.3 commit d39f31d96378aa5eeade74670ffd9e08bf4c7234 (master) commit a28048a20f46f718c3df3af95e230ab72234f915 (beta/2.3) Author: Gert Doering <ge...@gr...> Date: Wed Dec 19 22:12:41 2012 +0100 Fix parameter type for IP_TOS setsockopt on non-Linux systems. Signed-off-by: Gert Doering <ge...@gr...> Acked-by: David Sommerseth <da...@re...> Message-Id: 201...@gr... URL: http://article.gmane.org/gmane.network.openvpn.devel/7207 Signed-off-by: David Sommerseth <da...@re...> -- kind regards, David Sommerseth 

Hi Gert, On Wed, Dec 19, 2012 at 10:26:20PM +0100, Gert Doering wrote: > > On Mon, Dec 17, 2012 at 11:03:55PM +0100, Jeremie Le Hen wrote: > > I thereby kindly ask you to bring this patch in the source tree. I > > don't know about your release procedure, but it would be really nice if > > it could hit the tree before 2.3 is released. > > Thanks for the excessive links to documentation - it helps verifying > things. I agree that this is a useful last-minute correction and should > go in (feature-ACK). > > I don't particularily like the way your patch is coded, though, as it's > "all of them but Linux" that have "int" here (except Windows, which uses > DWORD, but the docs say "use QoS API instead") - too many #ifdefs. > > http://msdn.microsoft.com/en-us/library/windows/desktop/ms738586(v=vs.85).aspx > > so I'd propose to #ifdef it differently, patch appended. Your patch looks fine to me. I went that way because I grep'ed the source for TARGET_ and saw similar occurences of what I did, though each part contained more lines :). Thanks for your review. Regards, -- Jeremie Le Hen Scientists say the world is made up of Protons, Neutrons and Electrons. They forgot to mention Morons. 

Hi, On Mon, Dec 17, 2012 at 11:03:55PM +0100, Jeremie Le Hen wrote: > I thereby kindly ask you to bring this patch in the source tree. I > don't know about your release procedure, but it would be really nice if > it could hit the tree before 2.3 is released. Thanks for the excessive links to documentation - it helps verifying things. I agree that this is a useful last-minute correction and should go in (feature-ACK). I don't particularily like the way your patch is coded, though, as it's "all of them but Linux" that have "int" here (except Windows, which uses DWORD, but the docs say "use QoS API instead") - too many #ifdefs. http://msdn.microsoft.com/en-us/library/windows/desktop/ms738586(v=vs.85).aspx so I'd propose to #ifdef it differently, patch appended. gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany ge...@gr... fax: +49-89-35655025 ge...@ne... 

Hi Jeremie, I think this could and should be included in 2.3.0. Do any developers have an opinion? -- Samuli Seppänen Community Manager OpenVPN Technologies, Inc irc freenode net: mattock PS. The Trac ticket is here: <https://community.openvpn.net/openvpn/ticket/135> > Hi again, > > I saw that 2.3-RC2 has been released. Any chance to get this committed > before the release? > > Regards, > > On Mon, Dec 17, 2012 at 11:03:55PM +0100, Jeremie Le Hen wrote: >> Hi! >> >> On non-Linux systems (that is I checked on FreeBSD, NetBSD, OpenBSD, >> DragonflyBSD, Darwin, Solaris and IllumOS), setsockopt(2) with the >> IP_TOS option expects a pointer to a int rather than a char. Therefore >> this doesn't work on little-endian systems (x86 is the main victim). >> >> The problem is well understood, a fix has been posted by Torsten Vielhak >> on the bug tracker nearly 2 years ago but the problem has remained >> ignored, probably because the author didn't bring it to your attention. >> The patch only handled FreeBSD though. See ticket/135. >> >> I thereby kindly ask you to bring this patch in the source tree. I >> don't know about your release procedure, but it would be really nice if >> it could hit the tree before 2.3 is released. >> >> Relevant manpages: >> http://www.freebsd.org/cgi/man.cgi?query=ip&format=html >> http://netbsd.gw.com/cgi-bin/man-cgi?ip >> http://www.openbsd.org/cgi-bin/man.cgi?query=ip&format=html >> http://leaf.dragonflybsd.org/cgi/web-man?command=ip&section=ANY >> https://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManPages/man4/ip.4.html >> http://docs.oracle.com/cd/E19082-01/819-2254/ip-7p/index.html >> http://illumos.org/man/7p/ip >> >> >> diff --git a/src/openvpn/socket.h b/src/openvpn/socket.h >> index 9cb01fa..07224c4 100644 >> --- a/src/openvpn/socket.h >> +++ b/src/openvpn/socket.h >> @@ -237,7 +237,21 @@ struct link_socket >> >> #if PASSTOS_CAPABILITY >> /* used to get/set TOS. */ >> +#if defined(TARGET_LINUX) >> uint8_t ptos; >> +#elif defined(TARGET_SOLARIS) >> + int ptos; >> +#elif defined(TARGET_OPENBSD) >> + int ptos; >> +#elif defined(TARGET_NETBSD) >> + int ptos; >> +#elif defined(TARGET_FREEBSD) >> + int ptos; >> +#elif defined(TARGET_DRAGONFLY) >> + int ptos; >> +#elif defined(TARGET_DARWIN) >> + int ptos; >> +#endif >> bool ptos_defined; >> #endif >> >> >> Cheers, >> -- >> Jeremie Le Hen jeremie.le-hen.org jlh.freebsd.org >> (emails above use SOA record-style format) >> Scientists say the world is made up of Protons, Neutrons and Electrons. >> They forgot to mention Morons. 

Hi again, I saw that 2.3-RC2 has been released. Any chance to get this committed before the release? Regards, On Mon, Dec 17, 2012 at 11:03:55PM +0100, Jeremie Le Hen wrote: > Hi! > > On non-Linux systems (that is I checked on FreeBSD, NetBSD, OpenBSD, > DragonflyBSD, Darwin, Solaris and IllumOS), setsockopt(2) with the > IP_TOS option expects a pointer to a int rather than a char. Therefore > this doesn't work on little-endian systems (x86 is the main victim). > > The problem is well understood, a fix has been posted by Torsten Vielhak > on the bug tracker nearly 2 years ago but the problem has remained > ignored, probably because the author didn't bring it to your attention. > The patch only handled FreeBSD though. See ticket/135. > > I thereby kindly ask you to bring this patch in the source tree. I > don't know about your release procedure, but it would be really nice if > it could hit the tree before 2.3 is released. > > Relevant manpages: > http://www.freebsd.org/cgi/man.cgi?query=ip&format=html > http://netbsd.gw.com/cgi-bin/man-cgi?ip > http://www.openbsd.org/cgi-bin/man.cgi?query=ip&format=html > http://leaf.dragonflybsd.org/cgi/web-man?command=ip&section=ANY > https://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManPages/man4/ip.4.html > http://docs.oracle.com/cd/E19082-01/819-2254/ip-7p/index.html > http://illumos.org/man/7p/ip > > > diff --git a/src/openvpn/socket.h b/src/openvpn/socket.h > index 9cb01fa..07224c4 100644 > --- a/src/openvpn/socket.h > +++ b/src/openvpn/socket.h > @@ -237,7 +237,21 @@ struct link_socket > > #if PASSTOS_CAPABILITY > /* used to get/set TOS. */ > +#if defined(TARGET_LINUX) > uint8_t ptos; > +#elif defined(TARGET_SOLARIS) > + int ptos; > +#elif defined(TARGET_OPENBSD) > + int ptos; > +#elif defined(TARGET_NETBSD) > + int ptos; > +#elif defined(TARGET_FREEBSD) > + int ptos; > +#elif defined(TARGET_DRAGONFLY) > + int ptos; > +#elif defined(TARGET_DARWIN) > + int ptos; > +#endif > bool ptos_defined; > #endif > > > Cheers, > -- > Jeremie Le Hen jeremie.le-hen.org jlh.freebsd.org > (emails above use SOA record-style format) > Scientists say the world is made up of Protons, Neutrons and Electrons. > They forgot to mention Morons. -- Jeremie Le Hen Scientists say the world is made up of Protons, Neutrons and Electrons. They forgot to mention Morons. 

The OpenVPN community project team is proud to release OpenVPN 2.3_rc2. It can be downloaded from here: <http://openvpn.net/index.php/open-source/downloads.html> This release includes a number of bug fixes and cleanups. The Windows installer is bundled with upgraded OpenSSL (1.0.1c), OpenVPN-GUI (2.0.0) and libpkcs11-helper (latest Git version). A full list of changes is available here: <https://community.openvpn.net/openvpn/wiki/ChangesInOpenvpn23> The changelog is also attached to this email. For generic help use these support channels: - Official documentation: <http://openvpn.net/index.php/open-source/documentation/howto.html> - Wiki: <https://community.openvpn.net> - Forums: <https://forums.openvpn.net> - User mailing list: <http://sourceforge.net/mail/?group_id=48978> - User IRC channel: #openvpn at irc.freenode.net Please report bugs and ask development questions here: - Bug tracker and Wiki: <https://community.openvpn.net> - Developer mailing list: <http://sourceforge.net/mail/?group_id=48978> - Developer IRC channel: #openvpn-devel at irc.freenode.net (requires Freenode registration) -- Samuli Seppänen Community Manager OpenVPN Technologies, Inc irc freenode net: mattock 

Hi! On non-Linux systems (that is I checked on FreeBSD, NetBSD, OpenBSD, DragonflyBSD, Darwin, Solaris and IllumOS), setsockopt(2) with the IP_TOS option expects a pointer to a int rather than a char. Therefore this doesn't work on little-endian systems (x86 is the main victim). The problem is well understood, a fix has been posted by Torsten Vielhak on the bug tracker nearly 2 years ago but the problem has remained ignored, probably because the author didn't bring it to your attention. The patch only handled FreeBSD though. See ticket/135. I thereby kindly ask you to bring this patch in the source tree. I don't know about your release procedure, but it would be really nice if it could hit the tree before 2.3 is released. Relevant manpages: http://www.freebsd.org/cgi/man.cgi?query=ip&format=html http://netbsd.gw.com/cgi-bin/man-cgi?ip http://www.openbsd.org/cgi-bin/man.cgi?query=ip&format=html http://leaf.dragonflybsd.org/cgi/web-man?command=ip&section=ANY https://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManPages/man4/ip.4.html http://docs.oracle.com/cd/E19082-01/819-2254/ip-7p/index.html http://illumos.org/man/7p/ip diff --git a/src/openvpn/socket.h b/src/openvpn/socket.h index 9cb01fa..07224c4 100644 --- a/src/openvpn/socket.h +++ b/src/openvpn/socket.h @@ -237,7 +237,21 @@ struct link_socket #if PASSTOS_CAPABILITY /* used to get/set TOS. */ +#if defined(TARGET_LINUX) uint8_t ptos; +#elif defined(TARGET_SOLARIS) + int ptos; +#elif defined(TARGET_OPENBSD) + int ptos; +#elif defined(TARGET_NETBSD) + int ptos; +#elif defined(TARGET_FREEBSD) + int ptos; +#elif defined(TARGET_DRAGONFLY) + int ptos; +#elif defined(TARGET_DARWIN) + int ptos; +#endif bool ptos_defined; #endif Cheers, -- Jeremie Le Hen jeremie.le-hen.org jlh.freebsd.org (emails above use SOA record-style format) Scientists say the world is made up of Protons, Neutrons and Electrons. They forgot to mention Morons. 

Hi, On Mon, Dec 17, 2012 at 06:01:11AM -0800, ehsan enayati wrote: > Thanks for your replies. I just checked OpenVPN access server > and saw that in "server network setting" and in protocol selection > you can select Multi-Daemon mode. I thinks that's what exactly I > need. Is it implemented via tun + routing? No idea about AS -> ask your support contacts. gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany ge...@gr... fax: +49-89-35655025 ge...@ne... 

Thanks for your replies. I just checked OpenVPN access server and saw that in "server network setting" and in protocol selection you can select Multi-Daemon mode. I thinks that's what exactly I need. Is it implemented via tun + routing? ________________________________ From: David Sommerseth <ope...@to...> To: ope...@li... Sent: Monday, December 17, 2012 12:28 PM Subject: Re: [Openvpn-devel] multiple OpenVPN instances on a single tun On 17/12/12 09:31, ehsan enayati wrote: > Hi, > I need to run multiple instances of OpenVPN server on just one tun > device driver (say tun0) all on same subnets. I tried editing the > open_tun function in tun.c file, first instance goes well and creates > tun0 but when the second one comes along it cannot use tun0 and I get > the error "ioctl(TUNSETIFF): Device or resource busy". I really need > this functionality. Please give me some hints. It is not possible to do what you try to do.  Only one application can bind to a tun or tap socket.  It's basically the same issue if you try to have more applications bind and listen to, say port 80, at the same time.  It's impossible.  And it's restricted by the OS. If you need OpenVPN instances to be on the same subnet, you can use TAP and bridge tap0 and tap1 together.  *But* I 'd rather recommend to use tun devices, have them on separate subnets and do the rest with routing. Using tun + routing is by far the cleanest and easiest configuration setups.  It also gives the lowest traffic overhead and least headache while debugging the configuration when it fails. -- kind regards, David Sommerseth ------------------------------------------------------------------------------ LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d _______________________________________________ Openvpn-devel mailing list Ope...@li... https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Hi, On Mon, Dec 17, 2012 at 02:14:33AM -0800, ehsan enayati wrote: > Thanks for your quick reply, > I'm running multiple OVPN instances on different subnets but the traffic isn't the same on all of these instances. some of them tolerate huge amount of traffic, hence I want to assign more than one OVPN to those subnets to balance traffic on them. I don't know it's possible or not. It's not. As David wrote: if it has to be the very same subnet, you could do multiple tap instances (tap0, tap1, tap2) and bridge them together (brctl). Alternatively, you could split the subnet into smaller networks, and use multiple tuns. gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany ge...@gr... fax: +49-89-35655025 ge...@ne... 

Hi, On Mon, Dec 17, 2012 at 12:31:33AM -0800, ehsan enayati wrote: > I need to run multiple instances of OpenVPN server on just one tun device driver (say tun0) all on same subnets. I tried editing the open_tun function in tun.c file, first instance goes well and creates tun0 but when the second one comes along it cannot use tun0 and I get the error "ioctl(TUNSETIFF): > Device or resource busy ". I really need this functionality. Please give me some hints. There is no way to do this, as the tun device is exclusive-open - only a single process can open it (in theory, you might be able to open() it and then fork, sharing the file descriptor between all childs, but then you have the problem of ensuring that the "right" process gets the packets sent from the kernel to tun0, and there is no way to influence that). Maybe you can explain to us what you want to achieve, and then we can see how it can be done (if at all). gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany ge...@gr... fax: +49-89-35655025 ge...@ne... 

On 16/12/12 22:15, Gert Doering wrote: > "tun-ipv6" is only sent in option string if running in point-to-point > mode (= not --server and not --client or --pull), because in those > scenarios it's usually pushed by the server, and the client does not > yet have it when comparing options -> needless warning. > > Completely ignore "proto" values when comparing option strings - this > is in preparation for removing proto from the option string in a future > release, and to avoid warnings when 2.3 talks to this future release. > > Signed-off-by: Gert Doering <ge...@gr...> > --- > src/openvpn/options.c | 12 +++++++++++- > 1 files changed, 11 insertions(+), 1 deletions(-) ACK. Applied to master and beta/2.3 commit 3b860cf27b9374f6ebe67ff21011661f8ec391c6 (master) commit f21410729e68b553f391dc036c0372fd3690714e (beta/2.3) Author: Gert Doering <ge...@gr...> Date: Sun Dec 16 22:15:20 2012 +0100 Fix option inconsistency warnings about "proto" and "tun-ipv6" Signed-off-by: Gert Doering <ge...@gr...> Acked-by: David Sommerseth <da...@re...> Message-Id: 135...@gr... URL: http://article.gmane.org/gmane.network.openvpn.devel/7194 Signed-off-by: David Sommerseth <da...@re...> -- kind regards, David Sommerseth 

 > Hi, > > On Sat, Dec 15, 2012 at 11:23:52AM +0100, Tore Anderson wrote: >> * Arne Schwabe >> >>> This patch contains a number of changes. I did not further spit this >>> since some changes make only sense being changed together. > [..] >> ACK, I tested several different fail-over scenarios and all worked fine. >> Also all my pre-existing VPNs (maintained by GNOME NetworkManager) >> worked just fine. > Thanks for testing. > > Nevertheless, as this is a HUGE change (and needs patch 02/10...09/10 as > prerequisites), I'd put this in 2.4 - so we can release 2.3 "real soon now", > without an even longer test/beta/RC phase. > > (And yes, this is important work!) > > gert ACK for "getting 2.3.0 out real soon". I'd also push 2.4-alpha1 out very soon after 2.3.0, so that we get this new features/cleanups into wider circulation. -- Samuli Seppänen Community Manager OpenVPN Technologies, Inc irc freenode net: mattock 

On 17/12/12 09:31, ehsan enayati wrote: > Hi, > I need to run multiple instances of OpenVPN server on just one tun > device driver (say tun0) all on same subnets. I tried editing the > open_tun function in tun.c file, first instance goes well and creates > tun0 but when the second one comes along it cannot use tun0 and I get > the error "ioctl(TUNSETIFF): Device or resource busy". I really need > this functionality. Please give me some hints. It is not possible to do what you try to do. Only one application can bind to a tun or tap socket. It's basically the same issue if you try to have more applications bind and listen to, say port 80, at the same time. It's impossible. And it's restricted by the OS. If you need OpenVPN instances to be on the same subnet, you can use TAP and bridge tap0 and tap1 together. *But* I 'd rather recommend to use tun devices, have them on separate subnets and do the rest with routing. Using tun + routing is by far the cleanest and easiest configuration setups. It also gives the lowest traffic overhead and least headache while debugging the configuration when it fails. -- kind regards, David Sommerseth 

Hi, I need to run multiple instances of OpenVPN server on just one tun device driver (say tun0) all on same subnets. I tried editing the open_tun function in tun.c file, first instance goes well and creates tun0 but when the second one comes along it cannot use tun0 and I get the error "ioctl(TUNSETIFF): Device or resource busy ". I really need this functionality. Please give me some hints. Thanks 

"tun-ipv6" is only sent in option string if running in point-to-point mode (= not --server and not --client or --pull), because in those scenarios it's usually pushed by the server, and the client does not yet have it when comparing options -> needless warning. Completely ignore "proto" values when comparing option strings - this is in preparation for removing proto from the option string in a future release, and to avoid warnings when 2.3 talks to this future release. Signed-off-by: Gert Doering <ge...@gr...> --- src/openvpn/options.c | 12 +++++++++++- 1 files changed, 11 insertions(+), 1 deletions(-) diff --git a/src/openvpn/options.c b/src/openvpn/options.c index 33dbf51..a07ff49 100644 --- a/src/openvpn/options.c +++ b/src/openvpn/options.c @@ -2917,7 +2917,11 @@ options_string (const struct options *o, buf_printf (&out, ",link-mtu %d", EXPANDED_SIZE (frame)); buf_printf (&out, ",tun-mtu %d", PAYLOAD_SIZE (frame)); buf_printf (&out, ",proto %s", proto2ascii (proto_remote (o->ce.proto, remote), true)); - if (o->tun_ipv6) + + /* send tun_ipv6 only in peer2peer mode - in client/server mode, it + * is usually pushed by the server, triggering a non-helpful warning + */ + if (o->tun_ipv6 && o->mode == MODE_POINT_TO_POINT && !PULL_DEFINED(o)) buf_printf (&out, ",tun-ipv6"); /* @@ -3097,6 +3101,12 @@ options_warning_safe_scan2 (const int msglevel, const char *b1_name, const char *b2_name) { + /* we will stop sending 'proto xxx' in OCC in a future version + * (because it's not useful), and to reduce questions when + * interoperating, we start not-printing a warning about it today + */ + if (strncmp(p1, "proto ", 6) == 0 ) return; + if (strlen (p1) > 0) { struct gc_arena gc = gc_new (); -- 1.7.8.6 

Hi, On Fri, Dec 14, 2012 at 07:14:27PM +0100, Gert Doering wrote: > Issue #1: "logical dead code", in options.c, line 2277: This has already been fixed, I just hit the gap between "fix, ack, forget", "coverity checks" and "david pushes the fix". commit feca0900dd005777 -> issue solved. Easy. gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany ge...@gr... fax: +49-89-35655025 ge...@ne...