openvpn-devel Mailing List for OpenVPN

Hi, On Sun, Jun 30, 2013 at 10:32:31PM +0200, Max Muster wrote: > So maybe it would be a simple idea to think of a switch in "bug > handling". Why not simply use this list as "#1 input" for bug reports. This list isn't always working better or quicker... it really comes down to whoever has time to go through open issues. (We *do* have plans to improve the ticket handling...) So - as I said before, things have improved as far as community involvement and feedback goes, but still have quite a way to go. Working on it. 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 Gert, schrieb Gert Doering: > Hi, > > On Sun, Jun 30, 2013 at 08:00:39PM +0200, Max Muster wrote: >> please forgive me if I'm wrong, but there seems quite "little activity" >> on bug tracking page from the developers. >> E.g. one month ago I opened a bug report for a (suspected) bug present >> in file checking (bug #299) which is still "new" and even not commented. >> >> I don't want to be rude, but I think this is somewhat discouraging for >> someone trying to give some feedback. >> >> Even if in you opinion a ticket is a complete waste of (your) time, it >> would be kind to react and point out your point of view. > > David has answered a similar mail a few weeks on this very list - we're > sorry that we're all humans and only have 24hrs a day to balance life, > work, family, and open source work. it was not my intention to insult you or any of the developers or ask to work more than 24 hours a day ;-). > > OpenVPN has improved quite a lot in the past three years, and we *do* > have a fairly active developer group these days, but we still have much > work on our roadmaps, too many open tickets, and not enough time to do > all of it. I highly appreciate your work. But I would also like to take some of your precious time to see it from the "outsider" of the active developer group: You finally figured out why something went wrong and it seems it was not "your fault" but you identified a bug in the application. So you take a look on the site and see: "If you find a bug in this release, please file a bug report to our Trac bug tracker." So you do as you are asked and then you are "nervously waiting": Did you write something stupid? Did you really find a bug? > We do appreciate bug reports, and we're sorry that we're slow in working > on them (and they *do* get handled faster if there's a patch in 'em, but > even that does not always ensure quick handling, if everybody is too > busy to take a closer look and ACK the change). What I _wanted_ to express is that from my "external" point of view (how to tell without making someone angry again, what is just the opposite of my request ?) there seems to be some sort of a "lack of attention on input from outside this list". So maybe it would be a simple idea to think of a switch in "bug handling". Why not simply use this list as "#1 input" for bug reports. Once again, sorry if I took the wrong words for my request, I really wanted to do some "constructive criticism". > > gert > > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by Windows: > > Build for Windows Store. > > http://p.sf.net/sfu/windows-dev2dev > > > > _______________________________________________ > Openvpn-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/openvpn-devel > 

Hi, On Sun, Jun 30, 2013 at 08:00:39PM +0200, Max Muster wrote: > please forgive me if I'm wrong, but there seems quite "little activity" > on bug tracking page from the developers. > E.g. one month ago I opened a bug report for a (suspected) bug present > in file checking (bug #299) which is still "new" and even not commented. > > I don't want to be rude, but I think this is somewhat discouraging for > someone trying to give some feedback. > > Even if in you opinion a ticket is a complete waste of (your) time, it > would be kind to react and point out your point of view. David has answered a similar mail a few weeks on this very list - we're sorry that we're all humans and only have 24hrs a day to balance life, work, family, and open source work. OpenVPN has improved quite a lot in the past three years, and we *do* have a fairly active developer group these days, but we still have much work on our roadmaps, too many open tickets, and not enough time to do all of it. We do appreciate bug reports, and we're sorry that we're slow in working on them (and they *do* get handled faster if there's a patch in 'em, but even that does not always ensure quick handling, if everybody is too busy to take a closer look and ACK the change). 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 all, please forgive me if I'm wrong, but there seems quite "little activity" on bug tracking page from the developers. E.g. one month ago I opened a bug report for a (suspected) bug present in file checking (bug #299) which is still "new" and even not commented. I don't want to be rude, but I think this is somewhat discouraging for someone trying to give some feedback. Even if in you opinion a ticket is a complete waste of (your) time, it would be kind to react and point out your point of view. Thanks for your great work and kind regards Joerg 

>From James Yonan <ja...@op...>: > This is the TLS versioning patch as discussed in last Thursday's IRC > meeting. > > It combines these two patches: > > https://github.com/jamesyonan/openvpn/commit/03a5599202bdc3ba07983dc4ef > dae387fb8fb436 > > https://github.com/jamesyonan/openvpn/commit/d23005413b0e0f28a3c48a6342 > f494763d5c9b40 For completeness: looks good to me, I have no comments that have not already been seen on this list.	Joachim 

On Fri, Jun 21, 2013 at 6:48 AM, Arne Schwabe <ar...@rf...> wrote: > Mac OS X 10.7+ natively supports tun devices (called utun). The "standard" utun.ko driver is sometimes problematic (e.g. VmWare Fusion 5 and tun.ko do not work together). > > When OpenVPN is compiled with utun support it will if no dev-node is given first try to use utun and if that is not available will try the traditional tun devices > > v2: Fixed tap support, get device name via ioctl, add manage > v3.1: Fix compiling without if/utun.h, fix manage errors > v4/v5: Don't try open to dynamically open utun0 -255 when early utun initialization fails, fix fallback to tun, give fatal error message when utun fails but no tun fallback should be done > v6: add commit message change log, replace strstr with strncmp, move #includes to the top of the file > v7: Throw error if a user does the strange combination of --dev tun --dev-type tap and --dev-node utun v7 works on 10.4 through 10.9, tested several different situations on each. I didn't test it on an actual tap connection, but all the tun/utun connections I tried worked, and the fallback to tun on 10.4 and 10.5 worked, and the misconfiguration of "--dev tun --dev-type tap --dev-node utun" was caught. This looks good to me, for either 2.3.x (because it will fix problems people have with tuntaposx) or 2.4 (because it is a new feature). Thanks, Arne. 

Hi, Here's the summary of the previous IRC meeting. --- COMMUNITY MEETING Place: #openvpn-devel on irc.freenode.net Date: Thursday 20th Jun 2013 Time: 18:00 UTC Planned meeting topics for this meeting were on this page: <https://community.openvpn.net/openvpn/wiki/Topics-2013-06-20> Next meeting is scheduled for Thursday 4th July at 18:00 UTC. Your local meeting time is easy to check from services such as <http://www.timeanddate.com/worldclock> or with $ date -u SUMMARY cron2, dazo, hes, jamesyonan, mattock, plaisthos and syzzer participated in this meeting. -- Discussed the "Added "setenv opt" directive prefix" patch: <http://article.gmane.org/gmane.network.openvpn.devel/7678> Cron2 and plaisthos gave this patch an ACK. Also agreed to add an "ignore-option" patch later. -- Discussed the "​Updated the TLS negotiation logic to adaptively try to connect using..." patch: ​ <http://article.gmane.org/gmane.network.openvpn.devel/7678> After a long discussion agreed that the functionality and the implementation make sense. -- Discussed the "Add support of utun devices under Mac OS X" patch: <http://thread.gmane.org/gmane.network.openvpn.devel/7464> As utun does not support tap, decided to modify the patch to use tuntap as a fallback when tap is requested. -- Discussed the possibility of organizing an OpenVPN hackathon in Munich in late autumn/early winter, instead of meeting in FOSDEM in early February. Agreed that this was a good idea. --- Full chatlog as an attachment -- Samuli Seppänen Community Manager OpenVPN Technologies, Inc irc freenode net: mattock 

This is the TLS versioning patch as discussed in last Thursday's IRC meeting. It combines these two patches: https://github.com/jamesyonan/openvpn/commit/03a5599202bdc3ba07983dc4efdae387fb8fb436 https://github.com/jamesyonan/openvpn/commit/d23005413b0e0f28a3c48a6342f494763d5c9b40 James 

Am 22.06.13 12:48, schrieb Tore Anderson: > It's been half a year, so I was wondering if this patch has been > forgotten about? I don't see it in either the master branch of either > the openvpn or openvpn-testing git repo. > > FWIW, I'd like to push the GNOME NetworkManager folks some more to > implement IPv6 support in their OpenVPN plugin, which is currently IPv4 > only. This patch breaks one of the assumptions made there, in particular > that IPv4 transport will always be used when OpenVPN is started > "--remote <dns-hostname> --proto [tcp|udp]". I'm hoping that when > dealing with that, which they'll have to do anyway, they'll seize the > opportunity to implement IPv6 payload support as well. > > However in order to do so it would be very nice to have a 2.4-alpha1 or > at least a git master commit that I could point to, that could be used > for testing interoperability with the new behaviour. Not really forgotten about. The dual stack patches are rather large. There has been lack of time of the OpenVPN core team member to review the patches. I still maintain the dualstack patches for my client: https://github.com/schwabe/openvpn/commits/ds10 The branch name sometimes changes when I rebase the patches. If someone steps up and has time to review the patches I can send another patch set. Arne 

* Samuli Seppänen >> 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. Hi, It's been half a year, so I was wondering if this patch has been forgotten about? I don't see it in either the master branch of either the openvpn or openvpn-testing git repo. FWIW, I'd like to push the GNOME NetworkManager folks some more to implement IPv6 support in their OpenVPN plugin, which is currently IPv4 only. This patch breaks one of the assumptions made there, in particular that IPv4 transport will always be used when OpenVPN is started "--remote <dns-hostname> --proto [tcp|udp]". I'm hoping that when dealing with that, which they'll have to do anyway, they'll seize the opportunity to implement IPv6 payload support as well. However in order to do so it would be very nice to have a 2.4-alpha1 or at least a git master commit that I could point to, that could be used for testing interoperability with the new behaviour. Tore 

--- doc/openvpn.8 | 24 ++++++++++++++++++++- src/openvpn/options.c | 56 +++++++++++++++++++++++++++++++++++++++++++++++-- src/openvpn/options.h | 2 ++ 3 files changed, 79 insertions(+), 3 deletions(-) diff --git a/doc/openvpn.8 b/doc/openvpn.8 index 949577b..d384252 100644 --- a/doc/openvpn.8 +++ b/doc/openvpn.8 @@ -1888,9 +1888,31 @@ in future OpenVPN versions. This option should be used with caution, as there are good security reasons for having OpenVPN fail if it detects problems in a -config file. Having said that, there are valid reasons for wanting +config file. Having said that, there are valid reasons for wanting new software features to gracefully degrade when encountered by older software versions. + +See also +.B \-\-ignore-unknown-option +.\"********************************************************* +.TP +.B \-\-ignore-unknown-option opt1 opt2 opt3 ... optN +When one of options +.B opt1 ... optN +is encountered in the configuration file the configuration +file parsing does not fail if this OpenVPN version does not +support the option. Multiple +.B \-\-ignore-unknown-option +options can be given to support a larger number of options to ignore. + +This option should be used with caution, as there are good security +reasons for having OpenVPN fail if it detects problems in a +config file. Having said that, there are valid reasons for wanting +new software features to gracefully degrade when encountered by +older software versions. + +.B \-\-ignore-unknown-option +is available since OpenVPN 2.3.3. .\"********************************************************* .TP .B \-\-setenv-safe name value diff --git a/src/openvpn/options.c b/src/openvpn/options.c index 883136f..2f31a62 100644 --- a/src/openvpn/options.c +++ b/src/openvpn/options.c @@ -255,6 +255,8 @@ static const char usage_message[] = "--setenv name value : Set a custom environmental variable to pass to script.\n" "--setenv FORWARD_COMPATIBLE 1 : Relax config file syntax checking to allow\n" " directives for future OpenVPN versions to be ignored.\n" + "--ignore-unkown-option opt1 opt2 ...: Relax config file syntax. Allow\n" + " these options to be ignored when unknown\n" "--script-security level: Where level can be:\n" " 0 -- strictly no calling of external programs\n" " 1 -- (default) only call built-ins such as ifconfig\n" @@ -4405,6 +4407,44 @@ add_option (struct options *options, uninit_options (&sub);	} } + else if (streq (p[0], "ignore-unknown-option") && p[1]) + { + int i; + int j; + int numignored=0; + const char **ignore; + + VERIFY_PERMISSION (OPT_P_GENERAL); + /* Find out how many options to be ignored */ + for (i=1;p[i];i++) + numignored++; + + numignored=i; + /* add number of options already ignored */ + for (i=0;options->ignore_unknown_option && + options->ignore_unknown_option[i]; i++) + numignored++; + + /* Allocate array */ + ALLOC_ARRAY_GC (ignore, const char*, numignored+1, &options->gc); + for (i=0;options->ignore_unknown_option && + options->ignore_unknown_option[i]; i++) + ignore[i]=options->ignore_unknown_option[i]; + + options->ignore_unknown_option=ignore; + + for (j=1;p[j];j++) + { + /* Allow the user to specify ignore-unknown-option --opt too */ + if (p[j][0]=='-' && p[j][1]=='-') + options->ignore_unknown_option[i] = p[j]+2; + else + options->ignore_unknown_option[i] = p[j]; + i++; + } + + options->ignore_unknown_option[i] = NULL; + } else if (streq (p[0], "remote-ip-hint") && p[1]) { VERIFY_PERMISSION (OPT_P_GENERAL); @@ -6891,10 +6931,22 @@ add_option (struct options *options, #endif else { + int msglevel= msglevel_fc; + int i; + for(i=0; options->ignore_unknown_option && options->ignore_unknown_option[i]; i++) + { + const char* opt = options->ignore_unknown_option[i]; + + if (streq(p[0], opt)) + { + msglevel = M_WARN; + break; + } + } if (file) -	msg (msglevel_fc, "Unrecognized option or missing parameter(s) in %s:%d: %s (%s)", file, line, p[0], PACKAGE_VERSION); +	msg (msglevel, "Unrecognized option or missing parameter(s) in %s:%d: %s (%s)", file, line, p[0], PACKAGE_VERSION); else -	msg (msglevel_fc, "Unrecognized option or missing parameter(s): --%s (%s)", p[0], PACKAGE_VERSION); +	msg (msglevel, "Unrecognized option or missing parameter(s): --%s (%s)", p[0], PACKAGE_VERSION); } err: gc_free (&gc); diff --git a/src/openvpn/options.h b/src/openvpn/options.h index 6a132a6..8e0e367 100644 --- a/src/openvpn/options.h +++ b/src/openvpn/options.h @@ -186,6 +186,8 @@ struct options /* enable forward compatibility for post-2.1 features */ bool forward_compatible; + /* list of options that should be ignored even if unkown */ + const char ** ignore_unknown_option; /* persist parms */ bool persist_config; -- 1.7.9.5 

Mac OS X 10.7+ natively supports tun devices (called utun). The "standard" utun.ko driver is sometimes problematic (e.g. VmWare Fusion 5 and tun.ko do not work together). When OpenVPN is compiled with utun support it will if no dev-node is given first try to use utun and if that is not available will try the traditional tun devices v2: Fixed tap support, get device name via ioctl, add manage v3.1: Fix compiling without if/utun.h, fix manage errors v4/v5: Don't try open to dynamically open utun0 -255 when early utun initialization fails, fix fallback to tun, give fatal error message when utun fails but no tun fallback should be done v6: add commit message change log, replace strstr with strncmp, move #includes to the top of the file v7: Throw error if a user does the strange combination of --dev tun --dev-type tap and --dev-node utun A lot good input on earlier patches by Jonathan K. Bullard <jkb...@gm...> Parts of the patches are inspired from Peter Sagerson's <ps...@ig...> utun patch Signed-off-by: Arne Schwabe <ar...@rf...> --- configure.ac | 2 +- doc/openvpn.8 | 11 ++ src/openvpn/tun.c | 338 ++++++++++++++++++++++++++++++++++++++++++----------- src/openvpn/tun.h | 3 + 4 files changed, 286 insertions(+), 68 deletions(-) diff --git a/configure.ac b/configure.ac index 5da5772..854cfbb 100644 --- a/configure.ac +++ b/configure.ac @@ -459,7 +459,7 @@ SOCKET_INCLUDES=" " AC_CHECK_HEADERS( -	[net/if.h netinet/ip.h netinet/if_ether.h resolv.h sys/un.h], +	[net/if.h netinet/ip.h netinet/if_ether.h resolv.h sys/un.h net/if_utun.h sys/kern_control.h],	,	,	[[${SOCKET_INCLUDES}]] diff --git a/doc/openvpn.8 b/doc/openvpn.8 index 174fd6d..949577b 100644 --- a/doc/openvpn.8 +++ b/doc/openvpn.8 @@ -805,6 +805,17 @@ also specify or .B \-\-dev-type tap. +Under Mac OS X this option can be used to specify the default tun +implementation. Using +.B \-\-dev\-node utun +forces usage of the native Darwin tun kernel support. Use +.B \-\-dev\-node utunN +to select a specific utun instance. To force using the tun.kext (/dev/tunX) use +.B \-\-dev\-node tun +. When not specifying a +.B \-\-dev\-node +option openvpn will first try to open utun, and fall back to tun.kext. + On Windows systems, select the TAP-Win32 adapter which is named .B node diff --git a/src/openvpn/tun.c b/src/openvpn/tun.c index f7443b4..18afa3f 100644 --- a/src/openvpn/tun.c +++ b/src/openvpn/tun.c @@ -74,6 +74,12 @@ static void solaris_error_close (struct tuntap *tt, const struct env_set *es, co #include <stropts.h> #endif +#if defined(TARGET_DARWIN) && HAVE_NET_IF_UTUN_H +#include <sys/kern_control.h> +#include <net/if_utun.h> +#include <sys/sys_domain.h> +#endif + static void clear_tuntap (struct tuntap *tuntap); bool @@ -1277,6 +1283,87 @@ open_null (struct tuntap *tt) tt->actual_name = string_alloc ("null", NULL); } + +#if defined (TARGET_OPENBSD) || (defined(TARGET_DARWIN) && HAVE_NET_IF_UTUN_H) + +/* + * OpenBSD and Mac OS X when using utun + * have a slightly incompatible TUN device from + * the rest of the world, in that it prepends a + * uint32 to the beginning of the IP header + * to designate the protocol (why not just + * look at the version field in the IP header to + * determine v4 or v6?). + * + * We strip off this field on reads and + * put it back on writes. + * + * I have not tested TAP devices on OpenBSD, + * but I have conditionalized the special + * TUN handling code described above to + * go away for TAP devices. + */ + +#include <netinet/ip.h> +#include <sys/uio.h> + +static inline int +header_modify_read_write_return (int len) +{ + if (len > 0) + return len > sizeof (u_int32_t) ? len - sizeof (u_int32_t) : 0; + else + return len; +} + +int +write_tun_header (struct tuntap* tt, uint8_t *buf, int len) +{ + if (tt->type == DEV_TYPE_TUN) + { + u_int32_t type; + struct iovec iv[2]; + struct ip *iph; + + iph = (struct ip *) buf; + + if (tt->ipv6 && iph->ip_v == 6) + type = htonl (AF_INET6); + else + type = htonl (AF_INET); + + iv[0].iov_base = &type; + iv[0].iov_len = sizeof (type); + iv[1].iov_base = buf; + iv[1].iov_len = len; + + return header_modify_read_write_return (writev (tt->fd, iv, 2)); + } + else + return write (tt->fd, buf, len); +} + +int +read_tun_header (struct tuntap* tt, uint8_t *buf, int len) +{ + if (tt->type == DEV_TYPE_TUN) + { + u_int32_t type; + struct iovec iv[2]; + + iv[0].iov_base = &type; + iv[0].iov_len = sizeof (type); + iv[1].iov_base = buf; + iv[1].iov_len = len; + + return header_modify_read_write_return (readv (tt->fd, iv, 2)); + } + else + return read (tt->fd, buf, len); +} +#endif + + #ifndef WIN32 static void open_tun_generic (const char *dev, const char *dev_type, const char *dev_node, @@ -2055,23 +2142,6 @@ read_tun (struct tuntap* tt, uint8_t *buf, int len) #elif defined(TARGET_OPENBSD) -/* - * OpenBSD has a slightly incompatible TUN device from - * the rest of the world, in that it prepends a - * uint32 to the beginning of the IP header - * to designate the protocol (why not just - * look at the version field in the IP header to - * determine v4 or v6?). - * - * We strip off this field on reads and - * put it back on writes. - * - * I have not tested TAP devices on OpenBSD, - * but I have conditionalized the special - * TUN handling code described above to - * go away for TAP devices. - */ - void open_tun (const char *dev, const char *dev_type, const char *dev_node, struct tuntap *tt) { @@ -2138,59 +2208,16 @@ close_tun (struct tuntap* tt) } } -static inline int -openbsd_modify_read_write_return (int len) -{ - if (len > 0) - return len > sizeof (u_int32_t) ? len - sizeof (u_int32_t) : 0; - else - return len; -} - int -write_tun (struct tuntap* tt, uint8_t *buf, int len) +write_tun(struct tuntap *tt, uint8_t *buf, int len) { - if (tt->type == DEV_TYPE_TUN) - { - u_int32_t type; - struct iovec iv[2]; - struct ip *iph; - - iph = (struct ip *) buf; - - if (tt->ipv6 && iph->ip_v == 6) -	type = htonl (AF_INET6); - else -	type = htonl (AF_INET); - - iv[0].iov_base = &type; - iv[0].iov_len = sizeof (type); - iv[1].iov_base = buf; - iv[1].iov_len = len; - - return openbsd_modify_read_write_return (writev (tt->fd, iv, 2)); - } - else - return write (tt->fd, buf, len); + return write_tun_header (tt, buf, len); } int -read_tun (struct tuntap* tt, uint8_t *buf, int len) +read_tun (struct tuntap *tt, uint8_t *buf, int len) { - if (tt->type == DEV_TYPE_TUN) - { - u_int32_t type; - struct iovec iv[2]; - - iv[0].iov_base = &type; - iv[0].iov_len = sizeof (type); - iv[1].iov_base = buf; - iv[1].iov_len = len; - - return openbsd_modify_read_write_return (readv (tt->fd, iv, 2)); - } - else - return read (tt->fd, buf, len); + return read_tun_header (tt, buf, len); } #elif defined(TARGET_NETBSD) @@ -2550,10 +2577,177 @@ read_tun (struct tuntap* tt, uint8_t *buf, int len) * pointing to lo0. Need to unconfigure... (observed on 10.5) */ +/* + * utun is the native Darwin tun driver present since at least 10.7 + * Thanks goes to Jonathan Levin for providing an example how to utun + * (http://newosxbook.com/src.jl?tree=listings&file=17-15-utun.c) + */ + +#ifdef HAVE_NET_IF_UTUN_H + +/* Helper functions that tries to open utun device + return -2 on early initialization failures (utun not supported + at all (old OS X) and -1 on initlization failure of utun + device (utun works but utunX is already used */ +static +int utun_open_helper (struct ctl_info ctlInfo, int utunnum) +{ + struct sockaddr_ctl sc; + int fd; + + fd = socket(PF_SYSTEM, SOCK_DGRAM, SYSPROTO_CONTROL); + + if (fd < 0) + { + msg (M_INFO, "Opening utun (%s): %s", "socket(SYSPROTO_CONTROL)", + strerror (errno)); + return -2; + } + + if (ioctl(fd, CTLIOCGINFO, &ctlInfo) == -1) + { + close (fd); + msg (M_INFO, "Opening utun (%s): %s", "ioctl(CTLIOCGINFO)", + strerror (errno)); + return -2; + } + + + sc.sc_id = ctlInfo.ctl_id; + sc.sc_len = sizeof(sc); + sc.sc_family = AF_SYSTEM; + sc.ss_sysaddr = AF_SYS_CONTROL; + + sc.sc_unit = utunnum+1; + + + /* If the connect is successful, a utun%d device will be created, where "%d" + * is (sc.sc_unit - 1) */ + + if (connect (fd, (struct sockaddr *)&sc, sizeof(sc)) < 0) + { + msg (M_INFO, "Opening utun (%s): %s", "connect(AF_SYS_CONTROL)", + strerror (errno)); + close(fd); + return -1; + } + + set_nonblock (fd); + set_cloexec (fd); /* don't pass fd to scripts */ + + return fd; +} + +void +open_darwin_utun (const char *dev, const char *dev_type, const char *dev_node, struct tuntap *tt) +{ + struct ctl_info ctlInfo; + int fd; + char utunname[20]; + int utunnum =-1; + socklen_t utunname_len = sizeof(utunname); + + /* dev_node is simply utun, do the normal dynamic utun + * otherwise try to parse the utun number */ + if (dev_node && !strcmp ("utun", dev_node)==0) + { + if (!sscanf (dev_node, "utun%d", &utunnum)==1) + msg (M_FATAL, "Cannot parse 'dev-node %s' please use 'dev-node utunX'" + "to use a utun device number X", dev_node); + } + + + + CLEAR (ctlInfo); + if (strlcpy(ctlInfo.ctl_name, UTUN_CONTROL_NAME, sizeof(ctlInfo.ctl_name)) >= + sizeof(ctlInfo.ctl_name)) + { + msg (M_ERR, "Opening utun: UTUN_CONTROL_NAME too long"); + } + + /* try to open first available utun device if no specific utun is requested */ + if (utunnum == -1) + { + for (utunnum=0; utunnum<255; utunnum++) + { + fd = utun_open_helper (ctlInfo, utunnum); + /* Break if the fd is valid, + * or if early initalization failed (-2) */ + if (fd !=-1) + break; + } + } + else + { + fd = utun_open_helper (ctlInfo, utunnum); + } + + /* opening an utun device failed */ + tt->fd = fd; + + if (fd < 0) + return; + + /* Retrieve the assigned interface name. */ + if (getsockopt (fd, SYSPROTO_CONTROL, UTUN_OPT_IFNAME, utunname, &utunname_len)) + msg (M_ERR | M_ERRNO, "Error retrieving utun interface name"); + + tt->actual_name = string_alloc (utunname, NULL); + + msg (M_INFO, "Opened utun device %s", utunname); + tt->is_utun = true; +} + +#endif + void open_tun (const char *dev, const char *dev_type, const char *dev_node, struct tuntap *tt) { - open_tun_generic (dev, dev_type, dev_node, true, true, tt); +#ifdef HAVE_NET_IF_UTUN_H + /* If dev_node does not start start with utun assume regular tun/tap */ + if ((!dev_node && tt->type==DEV_TYPE_TUN) || + (dev_node && !strncmp (dev_node, "utun", 4))) + { + + /* Check if user has specific dev_type tap and forced utun with + dev-node utun */ + if (tt->type!=DEV_TYPE_TUN) + msg (M_FATAL, "Cannot use utun devices with --dev-type %s", + dev_type_string (dev, dev_type)); + + /* Try utun first and fall back to normal tun if utun fails + and dev_node is not specified */ + open_darwin_utun(dev, dev_type, dev_node, tt); + + if (!tt->is_utun) + { + if (!dev_node) + { + /* No explicit utun and utun failed, try the generic way) */ + msg (M_INFO, "Failed to open utun device. Falling back to /dev/tun device"); + open_tun_generic (dev, dev_type, NULL, true, true, tt); + } + else + { + /* Specific utun device or generic utun request with no tun + fall back failed, consider this a fatal failure */ + msg (M_FATAL, "Cannot open utun device"); + } + } + } + else +#endif + { + + /* Use plain dev-node tun to select /dev/tun style + * Unset dev_node variable prior to passing to open_tun_generic to + * let open_tun_generic pick the first available tun device */ + + if (dev_node && strcmp (dev_node, "tun")==0) + dev_node=NULL; + + open_tun_generic (dev, dev_type, dev_node, true, true, tt); + } } void @@ -2586,13 +2780,23 @@ close_tun (struct tuntap* tt) int write_tun (struct tuntap* tt, uint8_t *buf, int len) { - return write (tt->fd, buf, len); +#ifdef HAVE_NET_IF_UTUN_H + if (tt->is_utun) + return write_tun_header (tt, buf, len); + else +#endif + return write (tt->fd, buf, len); } int read_tun (struct tuntap* tt, uint8_t *buf, int len) { - return read (tt->fd, buf, len); +#ifdef HAVE_NET_IF_UTUN_H + if (tt->is_utun) + return read_tun_header (tt, buf, len); + else +#endif + return read (tt->fd, buf, len); } #elif defined(WIN32) diff --git a/src/openvpn/tun.h b/src/openvpn/tun.h index 956ad8d..2c97ffe 100644 --- a/src/openvpn/tun.h +++ b/src/openvpn/tun.h @@ -181,6 +181,9 @@ struct tuntap int ip_fd; #endif +#ifdef HAVE_NET_IF_UTUN_H + bool is_utun; +#endif /* used for printing status info only */ unsigned int rwflags_debug; -- 1.7.9.5 

Hi, On Thu, Jun 20, 2013 at 08:39:20PM +0200, David Sommerseth wrote: > From: David Sommerseth <da...@re...> > > OpenVPN would segfault unexpectedly if it would be compiled against PolarSSL > and the plug-in would expect OpenSSL, or vice-versa. This segfault would > not appear before the plug-in would try to access functions which would > be available if the plug-in and OpenVPN uses the same SSL implementation. [..] > v3 - fix bug in plug-in init, as the SSLAPI was located wrong in the > args struct sent to the openvpn_plugin_open_v3() function. ACK. As, I think, 2.3.x will be with us for quite a while, I'd consider this a bugfix to the new feature in 2.3.x (namely, polarSSL support) and would put it into master and 2.3 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 Thu, Jun 20, 2013 at 04:38:43PM +0200, Arne Schwabe wrote: > Mac OS X 10.7+ natively supports tun devices (called utun). The "standard" utun.ko driver is sometimes problematic (e.g. VmWare Fusion 5 and tun.ko do not work together). James brought up a "we need a v7 here"... If you call "openvpn --dev tap --dev-node utun0", I think the current code will open an utun device, but the rest of OpenVPN will expect it to be tappish... 21:18 <@jamesyonan> if utun doesn't support tap, then we need to make sure that code will fall back to tuntap driver for tap tunnels ... so, two options a) utun can do TAP - in that case we need to add the necessary magic bits to convert the newly created utun into an utap b) it can not do TAP (which I'd expect, tbh), so we should never open an utun device if the user wants a tap. Arne, your call :-) 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... 

ACK. Lightly compile-tested with default options on Linux, but except for the last chunk, nothing seems to depend on #ifdefs, so if it indeed breaks some weird combination of options, buildbot will tell... Patch has been applied to the master branch. commit d0c4c442a44f85c18903b4edba9c1d726f6983c0 (master) Author: Arne Schwabe Date: Mon Apr 15 23:06:39 2013 +0200 PATCHv3 Remove unused variables or put them to the defines they are being used in Acked-by: Gert Doering <ge...@gr...> Message-Id: <136...@rf...> URL: http://article.gmane.org/gmane.network.openvpn.devel/7511 Signed-off-by: Gert Doering <ge...@gr...> -- kind regards, Gert Doering 

From: David Sommerseth <da...@re...> OpenVPN would segfault unexpectedly if it would be compiled against PolarSSL and the plug-in would expect OpenSSL, or vice-versa. This segfault would not appear before the plug-in would try to access functions which would be available if the plug-in and OpenVPN uses the same SSL implementation. This patch adds a member to the plug-in initialisation function, which identifies the SSL implementation. The log_v3 plug-in is updated accordingly + a simple fix to make it buildable again using the ./build script. A minor documentation error in the openvpn-plugin.h was also corrected, where it mentioned OPENVPN_PLUGIN_VERSION instead of OPENVPN_PLUGINv3_STRUCTVER. v2 - add const ovpnSSLAPI ssl_api at the end of struct openvpn_plugin_args_open_in and not in the "middle" v3 - fix bug in plug-in init, as the SSLAPI was located wrong in the args struct sent to the openvpn_plugin_open_v3() function. Signed-off-by: David Sommerseth <da...@re...> --- include/openvpn-plugin.h | 24 +++++++++++++++++++++--- sample/sample-plugins/log/build | 2 +- sample/sample-plugins/log/log_v3.c | 5 +++++ src/openvpn/plugin.c | 5 +++-- src/openvpn/ssl_backend.h | 2 ++ 5 files changed, 32 insertions(+), 6 deletions(-) diff --git a/include/openvpn-plugin.h b/include/openvpn-plugin.h index 0879f49..36e3240 100644 --- a/include/openvpn-plugin.h +++ b/include/openvpn-plugin.h @@ -201,10 +201,15 @@ struct openvpn_plugin_string_list * * Version Comment * 1 Initial plugin v3 structures providing the same API as - * the v2 plugin interface + X509 certificate information. + * the v2 plugin interface, X509 certificate information + + * a logging API for plug-ins. + * + * 2 Added ssl_api member in struct openvpn_plugin_args_open_in + * which identifies the SSL implementation OpenVPN is compiled + * against. * */ -#define OPENVPN_PLUGINv3_STRUCTVER 1 +#define OPENVPN_PLUGINv3_STRUCTVER 2 /** * Definitions needed for the plug-in callback functions. @@ -260,6 +265,17 @@ struct openvpn_plugin_callbacks }; /** + * Used by the openvpn_plugin_open_v3() function to indicate to the + * plug-in what kind of SSL implementation OpenVPN uses. This is + * to avoid SEGV issues when OpenVPN is complied against PolarSSL + * and the plug-in against OpenSSL. + */ +typedef enum { + SSLAPI_OPENSSL, + SSLAPI_POLARSSL +} ovpnSSLAPI; + +/** * Arguments used to transport variables to the plug-in. * The struct openvpn_plugin_args_open_in is only used * by the openvpn_plugin_open_v3() function. @@ -286,6 +302,7 @@ struct openvpn_plugin_args_open_in const char ** const argv; const char ** const envp; struct openvpn_plugin_callbacks *callbacks; + const ovpnSSLAPI ssl_api; }; @@ -557,7 +574,8 @@ OPENVPN_PLUGIN_DEF int OPENVPN_PLUGIN_FUNC(openvpn_plugin_func_v2) * ARGUMENTS * * version : fixed value, defines the API version of the OpenVPN plug-in API. The plug-in - * should validate that this value is matching the OPENVPN_PLUGIN_VERSION value. + * should validate that this value is matching the OPENVPN_PLUGINv3_STRUCTVER + * value. * * arguments : Structure with all arguments available to the plug-in. * diff --git a/sample/sample-plugins/log/build b/sample/sample-plugins/log/build index bbb05f7..c07ec40 100755 --- a/sample/sample-plugins/log/build +++ b/sample/sample-plugins/log/build @@ -6,7 +6,7 @@ # # This directory is where we will look for openvpn-plugin.h -CPPFLAGS="${CPPFLAGS:--I../../..}" +CPPFLAGS="${CPPFLAGS:--I../../../include}" CC="${CC:-gcc}" CFLAGS="${CFLAGS:--O2 -Wall -g}" diff --git a/sample/sample-plugins/log/log_v3.c b/sample/sample-plugins/log/log_v3.c index 742c756..4d3af91 100644 --- a/sample/sample-plugins/log/log_v3.c +++ b/sample/sample-plugins/log/log_v3.c @@ -85,6 +85,11 @@ openvpn_plugin_open_v3 (const int v3structver, return OPENVPN_PLUGIN_FUNC_ERROR; } + if( args->ssl_api != SSLAPI_OPENSSL ) { + printf("This plug-in can only be used against OpenVPN with OpenSSL\n"); + return OPENVPN_PLUGIN_FUNC_ERROR; + } + /* Which callbacks to intercept. */ ret->type_mask = OPENVPN_PLUGIN_MASK (OPENVPN_PLUGIN_UP) | diff --git a/src/openvpn/plugin.c b/src/openvpn/plugin.c index c96c121..0948f23 100644 --- a/src/openvpn/plugin.c +++ b/src/openvpn/plugin.c @@ -40,8 +40,8 @@ #include "error.h" #include "misc.h" #include "plugin.h" +#include "ssl_backend.h" #include "win32.h" - #include "memdbg.h" #define PLUGIN_SYMBOL_REQUIRED (1<<0) @@ -374,7 +374,8 @@ plugin_open_item (struct plugin *p, struct openvpn_plugin_args_open_in args = { p->plugin_type_mask, (const char ** const) o->argv, (const char ** const) envp, - &callbacks }; + &callbacks, + SSLAPI }; struct openvpn_plugin_args_open_return retargs; CLEAR(retargs); diff --git a/src/openvpn/ssl_backend.h b/src/openvpn/ssl_backend.h index 72235ae..413e4d4 100644 --- a/src/openvpn/ssl_backend.h +++ b/src/openvpn/ssl_backend.h @@ -36,10 +36,12 @@ #ifdef ENABLE_CRYPTO_OPENSSL #include "ssl_openssl.h" #include "ssl_verify_openssl.h" +#define SSLAPI SSLAPI_OPENSSL #endif #ifdef ENABLE_CRYPTO_POLARSSL #include "ssl_polarssl.h" #include "ssl_verify_polarssl.h" +#define SSLAPI SSLAPI_POLARSSL #endif /** -- 1.7.10.2 

Hi, On Wed, Jun 12, 2013 at 12:18:36PM +0200, David Sommerseth wrote: > v2 - add const ovpnSSLAPI ssl_api at the end of > struct openvpn_plugin_args_open_in and not in the "middle" NAK, because: > @@ -372,6 +372,7 @@ plugin_open_item (struct plugin *p, > */ > if (p->open3) { > struct openvpn_plugin_args_open_in args = { p->plugin_type_mask, > + SSLAPI, > (const char ** const) o->argv, > (const char ** const) envp, > &callbacks }; ... it's still sitting in the middle in the init function... 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 Fri, Jun 07, 2013 at 12:15:30PM +0200, David Sommerseth wrote: > From: David Sommerseth <da...@re...> > > In config.h, it would state: > > /* Enable systemd support */ > #define ENABLE_PLUGIN 1 > > instead of > > /* Enable plug-in support */ > #define ENABLE_PLUGIN 1 Wherever that came from :-) ACK for 2.3 and 2.4 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 Fri, Jun 07, 2013 at 12:15:11PM +0200, David Sommerseth wrote: > From: David Sommerseth <da...@re...> > > Signed-off-by: David Sommerseth <da...@re...> ACK - 2.3.3 and 2.4. (If you put this in 2.3.3, but not the "removal of #ifdef EUREPHIA" patch, then it would need a note that this is only enabled if compiled with eurephia support. So better remove all the #ifdef from 2.3 as well :) ) 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 Fri, Jun 07, 2013 at 12:15:23PM +0200, David Sommerseth wrote: > From: David Sommerseth <da...@re...> > > This "feature" has been enabled since OpenVPN 2.2 without any reports that > this has been causing issues. All it does is to add an extra environment > variable 'tls_digest_{n}' with the certificate SHA1 fingerprint/digest hash. > > Lets just simplify things by removing the possibility to disable this > environment variable. ACK. I'd say this is good for 2.3.3 and 2.4. 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 Thu, Jun 20, 2013 at 01:44:04PM -0400, Jonathan K. Bullard wrote: > I am building now, but it will be a few hours before I can do all the > testing. I will report back to this thread. Cool, thanks in advance! 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 Thu, Jun 20, 2013 at 1:28 PM, Gert Doering <ge...@gr...> wrote: > > Hi, > > On Thu, Jun 20, 2013 at 04:38:43PM +0200, Arne Schwabe wrote: > > v6: add commit message change log, replace strstr with strncmp, move #includes to the top of the file > > > > This looks good to me. It would be great if Jonathan could test this > again to verify that all OSX versions are properly covered (I only have > a limited set to test with), but if that all works, I'm happy to move > it in and ACK it code-wise and feature-wise. I am building now, but it will be a few hours before I can do all the testing. I will report back to this thread. 

Hi, On Thu, Jun 20, 2013 at 04:38:43PM +0200, Arne Schwabe wrote: > v6: add commit message change log, replace strstr with strncmp, move #includes to the top of the file > This looks good to me. It would be great if Jonathan could test this again to verify that all OSX versions are properly covered (I only have a limited set to test with), but if that all works, I'm happy to move it in and ACK it code-wise and feature-wise. (There's a few more platform cleanups lurking in here, with more sharing of the read_tun_header()/write_tun_header() functions with other BSDs, but that's an independent opportunity for improval) 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... 

Mac OS X 10.7+ natively supports tun devices (called utun). The "standard" utun.ko driver is sometimes problematic (e.g. VmWare Fusion 5 and tun.ko do not work together). When OpenVPN is compiled with utun support it will if no dev-node is given first try to use utun and if that is not available will try the traditional tun devices v2: Fixed tap support, get device name via ioctl, add manage v3.1: Fix compiling without if/utun.h, fix manage errors v4/v5: Don't try open to dynamically open utun0 -255 when early utun initialization fails, fix fallback to tun, give fatal error message when utun fails but no tun fallback should be done v6: add commit message change log, replace strstr with strncmp, move #includes to the top of the file A lot good input on earlier patches by Jonathan K. Bullard <jkb...@gm...> Parts of the patches are inspired from Peter Sagerson's <ps...@ig...> utun patch Signed-off-by: Arne Schwabe <ar...@rf...> --- configure.ac | 2 +- doc/openvpn.8 | 11 ++ src/openvpn/tun.c | 333 ++++++++++++++++++++++++++++++++++++++++++----------- src/openvpn/tun.h | 3 + 4 files changed, 281 insertions(+), 68 deletions(-) diff --git a/configure.ac b/configure.ac index 5da5772..854cfbb 100644 --- a/configure.ac +++ b/configure.ac @@ -459,7 +459,7 @@ SOCKET_INCLUDES=" " AC_CHECK_HEADERS( -	[net/if.h netinet/ip.h netinet/if_ether.h resolv.h sys/un.h], +	[net/if.h netinet/ip.h netinet/if_ether.h resolv.h sys/un.h net/if_utun.h sys/kern_control.h],	,	,	[[${SOCKET_INCLUDES}]] diff --git a/doc/openvpn.8 b/doc/openvpn.8 index 397e2bf..1877294 100644 --- a/doc/openvpn.8 +++ b/doc/openvpn.8 @@ -805,6 +805,17 @@ also specify or .B \-\-dev-type tap. +Under Mac OS X this option can be used to specify the default tun +implementation. Using +.B \-\-dev\-node utun +forces usage of the native Darwin tun kernel support. Use +.B \-\-dev\-node utunN +to select a specific utun instance. To force using the tun.kext (/dev/tunX) use +.B \-\-dev\-node tun +. When not specifying a +.B \-\-dev\-node +option openvpn will first try to open utun, and fall back to tun.kext. + On Windows systems, select the TAP-Win32 adapter which is named .B node diff --git a/src/openvpn/tun.c b/src/openvpn/tun.c index f7443b4..3316bc6 100644 --- a/src/openvpn/tun.c +++ b/src/openvpn/tun.c @@ -74,6 +74,12 @@ static void solaris_error_close (struct tuntap *tt, const struct env_set *es, co #include <stropts.h> #endif +#if defined(TARGET_DARWIN) && HAVE_NET_IF_UTUN_H +#include <sys/kern_control.h> +#include <net/if_utun.h> +#include <sys/sys_domain.h> +#endif + static void clear_tuntap (struct tuntap *tuntap); bool @@ -1277,6 +1283,87 @@ open_null (struct tuntap *tt) tt->actual_name = string_alloc ("null", NULL); } + +#if defined (TARGET_OPENBSD) || (defined(TARGET_DARWIN) && HAVE_NET_IF_UTUN_H) + +/* + * OpenBSD and Mac OS X when using utun + * have a slightly incompatible TUN device from + * the rest of the world, in that it prepends a + * uint32 to the beginning of the IP header + * to designate the protocol (why not just + * look at the version field in the IP header to + * determine v4 or v6?). + * + * We strip off this field on reads and + * put it back on writes. + * + * I have not tested TAP devices on OpenBSD, + * but I have conditionalized the special + * TUN handling code described above to + * go away for TAP devices. + */ + +#include <netinet/ip.h> +#include <sys/uio.h> + +static inline int +header_modify_read_write_return (int len) +{ + if (len > 0) + return len > sizeof (u_int32_t) ? len - sizeof (u_int32_t) : 0; + else + return len; +} + +int +write_tun_header (struct tuntap* tt, uint8_t *buf, int len) +{ + if (tt->type == DEV_TYPE_TUN) + { + u_int32_t type; + struct iovec iv[2]; + struct ip *iph; + + iph = (struct ip *) buf; + + if (tt->ipv6 && iph->ip_v == 6) + type = htonl (AF_INET6); + else + type = htonl (AF_INET); + + iv[0].iov_base = &type; + iv[0].iov_len = sizeof (type); + iv[1].iov_base = buf; + iv[1].iov_len = len; + + return header_modify_read_write_return (writev (tt->fd, iv, 2)); + } + else + return write (tt->fd, buf, len); +} + +int +read_tun_header (struct tuntap* tt, uint8_t *buf, int len) +{ + if (tt->type == DEV_TYPE_TUN) + { + u_int32_t type; + struct iovec iv[2]; + + iv[0].iov_base = &type; + iv[0].iov_len = sizeof (type); + iv[1].iov_base = buf; + iv[1].iov_len = len; + + return header_modify_read_write_return (readv (tt->fd, iv, 2)); + } + else + return read (tt->fd, buf, len); +} +#endif + + #ifndef WIN32 static void open_tun_generic (const char *dev, const char *dev_type, const char *dev_node, @@ -2055,23 +2142,6 @@ read_tun (struct tuntap* tt, uint8_t *buf, int len) #elif defined(TARGET_OPENBSD) -/* - * OpenBSD has a slightly incompatible TUN device from - * the rest of the world, in that it prepends a - * uint32 to the beginning of the IP header - * to designate the protocol (why not just - * look at the version field in the IP header to - * determine v4 or v6?). - * - * We strip off this field on reads and - * put it back on writes. - * - * I have not tested TAP devices on OpenBSD, - * but I have conditionalized the special - * TUN handling code described above to - * go away for TAP devices. - */ - void open_tun (const char *dev, const char *dev_type, const char *dev_node, struct tuntap *tt) { @@ -2138,59 +2208,16 @@ close_tun (struct tuntap* tt) } } -static inline int -openbsd_modify_read_write_return (int len) -{ - if (len > 0) - return len > sizeof (u_int32_t) ? len - sizeof (u_int32_t) : 0; - else - return len; -} - int -write_tun (struct tuntap* tt, uint8_t *buf, int len) +write_tun(struct tuntap *tt, uint8_t *buf, int len) { - if (tt->type == DEV_TYPE_TUN) - { - u_int32_t type; - struct iovec iv[2]; - struct ip *iph; - - iph = (struct ip *) buf; - - if (tt->ipv6 && iph->ip_v == 6) -	type = htonl (AF_INET6); - else -	type = htonl (AF_INET); - - iv[0].iov_base = &type; - iv[0].iov_len = sizeof (type); - iv[1].iov_base = buf; - iv[1].iov_len = len; - - return openbsd_modify_read_write_return (writev (tt->fd, iv, 2)); - } - else - return write (tt->fd, buf, len); + return write_tun_header (tt, buf, len); } int -read_tun (struct tuntap* tt, uint8_t *buf, int len) +read_tun (struct tuntap *tt, uint8_t *buf, int len) { - if (tt->type == DEV_TYPE_TUN) - { - u_int32_t type; - struct iovec iv[2]; - - iv[0].iov_base = &type; - iv[0].iov_len = sizeof (type); - iv[1].iov_base = buf; - iv[1].iov_len = len; - - return openbsd_modify_read_write_return (readv (tt->fd, iv, 2)); - } - else - return read (tt->fd, buf, len); + return read_tun_header (tt, buf, len); } #elif defined(TARGET_NETBSD) @@ -2550,10 +2577,172 @@ read_tun (struct tuntap* tt, uint8_t *buf, int len) * pointing to lo0. Need to unconfigure... (observed on 10.5) */ + +/* + * utun is the native Darwin tun driver present since at least 10.7 + * Thanks goes to Jonathan Levin for providing an example how to utun + * (http://newosxbook.com/src.jl?tree=listings&file=17-15-utun.c) + */ + +#ifdef HAVE_NET_IF_UTUN_H + +/* Helper functions that tries to open utun device + return -2 on early initialization failures (utun not supported + at all (old OS X) and -1 on initlization failure of utun + device (utun works but utunX is already used */ +static +int utun_open_helper (struct ctl_info ctlInfo, int utunnum) +{ + struct sockaddr_ctl sc; + int fd; + + fd = socket(PF_SYSTEM, SOCK_DGRAM, SYSPROTO_CONTROL); + + if (fd < 0) + { + msg (M_INFO, "Opening utun (%s): %s", "socket(SYSPROTO_CONTROL)", + strerror (errno)); + return -2; + } + + if (ioctl(fd, CTLIOCGINFO, &ctlInfo) == -1) + { + close (fd); + msg (M_INFO, "Opening utun (%s): %s", "ioctl(CTLIOCGINFO)", + strerror (errno)); + return -2; + } + + + sc.sc_id = ctlInfo.ctl_id; + sc.sc_len = sizeof(sc); + sc.sc_family = AF_SYSTEM; + sc.ss_sysaddr = AF_SYS_CONTROL; + + sc.sc_unit = utunnum+1; + + + /* If the connect is successful, a utun%d device will be created, where "%d" + * is (sc.sc_unit - 1) */ + + if (connect (fd, (struct sockaddr *)&sc, sizeof(sc)) < 0) + { + msg (M_INFO, "Opening utun (%s): %s", "connect(AF_SYS_CONTROL)", + strerror (errno)); + close(fd); + return -1; + } + + set_nonblock (fd); + set_cloexec (fd); /* don't pass fd to scripts */ + + return fd; +} + +void +open_darwin_utun (const char *dev, const char *dev_type, const char *dev_node, struct tuntap *tt) +{ + struct ctl_info ctlInfo; + int fd; + char utunname[20]; + int utunnum =-1; + socklen_t utunname_len = sizeof(utunname); + + /* dev_node is simply utun, do the normal dynamic utun + * otherwise try to parse the utun number */ + if (dev_node && !strcmp ("utun", dev_node)==0) + { + if (!sscanf (dev_node, "utun%d", &utunnum)==1) + msg (M_FATAL, "Cannot parse 'dev-node %s' please use 'dev-node utunX'" + "to use a utun device number X", dev_node); + } + + + + CLEAR (ctlInfo); + if (strlcpy(ctlInfo.ctl_name, UTUN_CONTROL_NAME, sizeof(ctlInfo.ctl_name)) >= + sizeof(ctlInfo.ctl_name)) + { + msg (M_ERR, "Opening utun: UTUN_CONTROL_NAME too long"); + } + + /* try to open first available utun device if no specific utun is requested */ + if (utunnum == -1) + { + for (utunnum=0; utunnum<255; utunnum++) + { + fd = utun_open_helper (ctlInfo, utunnum); + /* Break if the fd is valid, + * or if early initalization failed (-2) */ + if (fd !=-1) + break; + } + } + else + { + fd = utun_open_helper (ctlInfo, utunnum); + } + + /* opening an utun device failed */ + tt->fd = fd; + + if (fd < 0) + return; + + /* Retrieve the assigned interface name. */ + if (getsockopt (fd, SYSPROTO_CONTROL, UTUN_OPT_IFNAME, utunname, &utunname_len)) + msg (M_ERR | M_ERRNO, "Error retrieving utun interface name"); + + tt->actual_name = string_alloc (utunname, NULL); + + msg (M_INFO, "Opened utun device %s", utunname); + tt->is_utun = true; +} + +#endif + void open_tun (const char *dev, const char *dev_type, const char *dev_node, struct tuntap *tt) { - open_tun_generic (dev, dev_type, dev_node, true, true, tt); +#ifdef HAVE_NET_IF_UTUN_H + /* If dev_node does not start start with utun assume regular tun/tap */ + if ((!dev_node && strcmp (dev, "tun")==0) || + (dev_node && !strncmp (dev_node, "utun", 4))) + { + /* Try utun first and fall back to normal tun if utun fails + and dev_node is not specified */ + open_darwin_utun(dev, dev_type, dev_node, tt); + + + if (!tt->is_utun) + { + if (!dev_node) + { + /* No explicit utun and utun failed, try the generic way) */ + msg (M_INFO, "Failed to open utun device. Falling back to /dev/tun device"); + open_tun_generic (dev, dev_type, NULL, true, true, tt); + } + else + { + /* Specific utun device or generic utun request failed, + consider this a fatal failure */ + msg (M_FATAL, "Cannot open utun device"); + } + } + } + else +#endif + { + + /* Use plain dev-node tun to select /dev/tun style + * Unset dev_node variable prior to passing to open_tun_generic to + * let open_tun_generic pick the first available tun device */ + + if (dev_node && strcmp (dev_node, "tun")==0) + dev_node=NULL; + + open_tun_generic (dev, dev_type, dev_node, true, true, tt); + } } void @@ -2586,13 +2775,23 @@ close_tun (struct tuntap* tt) int write_tun (struct tuntap* tt, uint8_t *buf, int len) { - return write (tt->fd, buf, len); +#ifdef HAVE_NET_IF_UTUN_H + if (tt->is_utun) + return write_tun_header (tt, buf, len); + else +#endif + return write (tt->fd, buf, len); } int read_tun (struct tuntap* tt, uint8_t *buf, int len) { - return read (tt->fd, buf, len); +#ifdef HAVE_NET_IF_UTUN_H + if (tt->is_utun) + return read_tun_header (tt, buf, len); + else +#endif + return read (tt->fd, buf, len); } #elif defined(WIN32) diff --git a/src/openvpn/tun.h b/src/openvpn/tun.h index 956ad8d..2c97ffe 100644 --- a/src/openvpn/tun.h +++ b/src/openvpn/tun.h @@ -181,6 +181,9 @@ struct tuntap int ip_fd; #endif +#ifdef HAVE_NET_IF_UTUN_H + bool is_utun; +#endif /* used for printing status info only */ unsigned int rwflags_debug; -- 1.7.9.5 

Mac OS X 10.7+ natively supports tun devices (called utun). The "standard" utun.ko driver is sometimes problematic (e.g. VmWare Fusion 5 and tun.ko do not work together). When OpenVPN is compiled with utun support it will if no dev-node is given first try to use utun and if that is not available will try the traditional tun devices A lot good input on earlier patches by Jonathan K. Bullard <jkb...@gm...> Parts of the patches are inspired from Peter Sagerson's <ps...@ig...> utun patch Signed-off-by: Arne Schwabe <ar...@rf...> --- configure.ac | 2 +- doc/openvpn.8 | 11 ++ src/openvpn/tun.c | 330 ++++++++++++++++++++++++++++++++++++++++++----------- src/openvpn/tun.h | 3 + 4 files changed, 278 insertions(+), 68 deletions(-) diff --git a/configure.ac b/configure.ac index 5da5772..854cfbb 100644 --- a/configure.ac +++ b/configure.ac @@ -459,7 +459,7 @@ SOCKET_INCLUDES=" " AC_CHECK_HEADERS( -	[net/if.h netinet/ip.h netinet/if_ether.h resolv.h sys/un.h], +	[net/if.h netinet/ip.h netinet/if_ether.h resolv.h sys/un.h net/if_utun.h sys/kern_control.h],	,	,	[[${SOCKET_INCLUDES}]] diff --git a/doc/openvpn.8 b/doc/openvpn.8 index 397e2bf..1877294 100644 --- a/doc/openvpn.8 +++ b/doc/openvpn.8 @@ -805,6 +805,17 @@ also specify or .B \-\-dev-type tap. +Under Mac OS X this option can be used to specify the default tun +implementation. Using +.B \-\-dev\-node utun +forces usage of the native Darwin tun kernel support. Use +.B \-\-dev\-node utunN +to select a specific utun instance. To force using the tun.kext (/dev/tunX) use +.B \-\-dev\-node tun +. When not specifying a +.B \-\-dev\-node +option openvpn will first try to open utun, and fall back to tun.kext. + On Windows systems, select the TAP-Win32 adapter which is named .B node diff --git a/src/openvpn/tun.c b/src/openvpn/tun.c index f7443b4..80a75b4 100644 --- a/src/openvpn/tun.c +++ b/src/openvpn/tun.c @@ -1277,6 +1277,87 @@ open_null (struct tuntap *tt) tt->actual_name = string_alloc ("null", NULL); } + +#if defined (TARGET_OPENBSD) || (defined(TARGET_DARWIN) && HAVE_NET_IF_UTUN_H) + +/* + * OpenBSD and Mac OS X when using utun + * have a slightly incompatible TUN device from + * the rest of the world, in that it prepends a + * uint32 to the beginning of the IP header + * to designate the protocol (why not just + * look at the version field in the IP header to + * determine v4 or v6?). + * + * We strip off this field on reads and + * put it back on writes. + * + * I have not tested TAP devices on OpenBSD, + * but I have conditionalized the special + * TUN handling code described above to + * go away for TAP devices. + */ + +#include <netinet/ip.h> +#include <sys/uio.h> + +static inline int +header_modify_read_write_return (int len) +{ + if (len > 0) + return len > sizeof (u_int32_t) ? len - sizeof (u_int32_t) : 0; + else + return len; +} + +int +write_tun_header (struct tuntap* tt, uint8_t *buf, int len) +{ + if (tt->type == DEV_TYPE_TUN) + { + u_int32_t type; + struct iovec iv[2]; + struct ip *iph; + + iph = (struct ip *) buf; + + if (tt->ipv6 && iph->ip_v == 6) + type = htonl (AF_INET6); + else + type = htonl (AF_INET); + + iv[0].iov_base = &type; + iv[0].iov_len = sizeof (type); + iv[1].iov_base = buf; + iv[1].iov_len = len; + + return header_modify_read_write_return (writev (tt->fd, iv, 2)); + } + else + return write (tt->fd, buf, len); +} + +int +read_tun_header (struct tuntap* tt, uint8_t *buf, int len) +{ + if (tt->type == DEV_TYPE_TUN) + { + u_int32_t type; + struct iovec iv[2]; + + iv[0].iov_base = &type; + iv[0].iov_len = sizeof (type); + iv[1].iov_base = buf; + iv[1].iov_len = len; + + return header_modify_read_write_return (readv (tt->fd, iv, 2)); + } + else + return read (tt->fd, buf, len); +} +#endif + + #ifndef WIN32 static void open_tun_generic (const char *dev, const char *dev_type, const char *dev_node, @@ -2055,23 +2136,6 @@ read_tun (struct tuntap* tt, uint8_t *buf, int len) #elif defined(TARGET_OPENBSD) -/* - * OpenBSD has a slightly incompatible TUN device from - * the rest of the world, in that it prepends a - * uint32 to the beginning of the IP header - * to designate the protocol (why not just - * look at the version field in the IP header to - * determine v4 or v6?). - * - * We strip off this field on reads and - * put it back on writes. - * - * I have not tested TAP devices on OpenBSD, - * but I have conditionalized the special - * TUN handling code described above to - * go away for TAP devices. - */ - void open_tun (const char *dev, const char *dev_type, const char *dev_node, struct tuntap *tt) { @@ -2138,59 +2202,16 @@ close_tun (struct tuntap* tt) } } -static inline int -openbsd_modify_read_write_return (int len) -{ - if (len > 0) - return len > sizeof (u_int32_t) ? len - sizeof (u_int32_t) : 0; - else - return len; -} - int -write_tun (struct tuntap* tt, uint8_t *buf, int len) +write_tun(struct tuntap *tt, uint8_t *buf, int len) { - if (tt->type == DEV_TYPE_TUN) - { - u_int32_t type; - struct iovec iv[2]; - struct ip *iph; - - iph = (struct ip *) buf; - - if (tt->ipv6 && iph->ip_v == 6) -	type = htonl (AF_INET6); - else -	type = htonl (AF_INET); - - iv[0].iov_base = &type; - iv[0].iov_len = sizeof (type); - iv[1].iov_base = buf; - iv[1].iov_len = len; - - return openbsd_modify_read_write_return (writev (tt->fd, iv, 2)); - } - else - return write (tt->fd, buf, len); + return write_tun_header (tt, buf, len); } int -read_tun (struct tuntap* tt, uint8_t *buf, int len) +read_tun (struct tuntap *tt, uint8_t *buf, int len) { - if (tt->type == DEV_TYPE_TUN) - { - u_int32_t type; - struct iovec iv[2]; - - iv[0].iov_base = &type; - iv[0].iov_len = sizeof (type); - iv[1].iov_base = buf; - iv[1].iov_len = len; - - return openbsd_modify_read_write_return (readv (tt->fd, iv, 2)); - } - else - return read (tt->fd, buf, len); + return read_tun_header (tt, buf, len); } #elif defined(TARGET_NETBSD) @@ -2550,10 +2571,175 @@ read_tun (struct tuntap* tt, uint8_t *buf, int len) * pointing to lo0. Need to unconfigure... (observed on 10.5) */ + +/* + * utun is the native Darwin tun driver present since at least 10.7 + * Thanks goes to Jonathan Levin for providing an example how to utun + * (http://newosxbook.com/src.jl?tree=listings&file=17-15-utun.c) + */ + +#ifdef HAVE_NET_IF_UTUN_H +#include <sys/kern_control.h> +#include <net/if_utun.h> +#include <sys/sys_domain.h> + +/* Helper functions that tries to open utun device + return -2 on early initialization failures (utun not supported + at all (old OS X) and -1 on initlization failure of utun + device (utun works but utunX is already used */ +static +int utun_open_helper (struct ctl_info ctlInfo, int utunnum) +{ + struct sockaddr_ctl sc; + int fd; + + fd = socket(PF_SYSTEM, SOCK_DGRAM, SYSPROTO_CONTROL); + + if (fd < 0) + { + msg (M_INFO, "Opening utun (%s): %s", "socket(SYSPROTO_CONTROL)", + strerror (errno)); + return -2; + } + + if (ioctl(fd, CTLIOCGINFO, &ctlInfo) == -1) + { + close (fd); + msg (M_INFO, "Opening utun (%s): %s", "ioctl(CTLIOCGINFO)", + strerror (errno)); + return -2; + } + + + sc.sc_id = ctlInfo.ctl_id; + sc.sc_len = sizeof(sc); + sc.sc_family = AF_SYSTEM; + sc.ss_sysaddr = AF_SYS_CONTROL; + + sc.sc_unit = utunnum+1; + + + /* If the connect is successful, a utun%d device will be created, where "%d" + * is (sc.sc_unit - 1) */ + + if (connect (fd, (struct sockaddr *)&sc, sizeof(sc)) < 0) + { + msg (M_INFO, "Opening utun (%s): %s", "connect(AF_SYS_CONTROL)", + strerror (errno)); + close(fd); + return -1; + } + + set_nonblock (fd); + set_cloexec (fd); /* don't pass fd to scripts */ + + return fd; +} + +void +open_darwin_utun (const char *dev, const char *dev_type, const char *dev_node, struct tuntap *tt) +{ + struct ctl_info ctlInfo; + int fd; + char utunname[20]; + int utunnum =-1; + socklen_t utunname_len = sizeof(utunname); + + /* dev_node is simply utun, do the normal dynamic utun + * otherwise try to parse the utun number */ + if (dev_node && !strcmp ("utun", dev_node)==0) + { + if (!sscanf (dev_node, "utun%d", &utunnum)==1) + msg (M_FATAL, "Cannot parse 'dev-node %s' please use 'dev-node utunX'" + "to use a utun device number X", dev_node); + } + + + + CLEAR (ctlInfo); + if (strlcpy(ctlInfo.ctl_name, UTUN_CONTROL_NAME, sizeof(ctlInfo.ctl_name)) >= + sizeof(ctlInfo.ctl_name)) + { + msg (M_ERR, "Opening utun: UTUN_CONTROL_NAME too long"); + } + + /* try to open first available utun device if no specific utun is requested */ + if (utunnum == -1) + { + for (utunnum=0; utunnum<255; utunnum++) + { + fd = utun_open_helper (ctlInfo, utunnum); + /* Break if the fd is valid, + * or if early initalization failed (-2) */ + if (fd !=-1) + break; + } + } + else + { + fd = utun_open_helper (ctlInfo, utunnum); + } + + /* opening an utun device failed */ + tt->fd = fd; + + if (fd < 0) + return; + + /* Retrieve the assigned interface name. */ + if (getsockopt (fd, SYSPROTO_CONTROL, UTUN_OPT_IFNAME, utunname, &utunname_len)) + msg (M_ERR | M_ERRNO, "Error retrieving utun interface name"); + + tt->actual_name = string_alloc (utunname, NULL); + + msg (M_INFO, "Opened utun device %s", utunname); + tt->is_utun = true; +} + +#endif + void open_tun (const char *dev, const char *dev_type, const char *dev_node, struct tuntap *tt) { - open_tun_generic (dev, dev_type, dev_node, true, true, tt); +#ifdef HAVE_NET_IF_UTUN_H + /* If dev_node does not start start with utun assume regular tun/tap */ + if ((!dev_node && strcmp (dev, "tun")==0) || + (dev_node && (strstr (dev_node, "utun") == dev_node))) + { + /* Try utun first and fall back to normal tun if utun fails + and dev_node is not specified */ + open_darwin_utun(dev, dev_type, dev_node, tt); + + + if (!tt->is_utun) + { + if (!dev_node) + { + /* No explicit utun and utun failed, try the generic way) */ + msg (M_INFO, "Failed to open utun device. Falling back to /dev/tun device"); + open_tun_generic (dev, dev_type, NULL, true, true, tt); + } + else + { + /* Specific utun device or generic utun request failed, + consider this a fatal failure */ + msg (M_FATAL, "Cannot open utun device"); + } + } + } + else +#endif + { + + /* Use plain dev-node tun to select /dev/tun style + * Unset dev_node variable prior to passing to open_tun_generic to + * let open_tun_generic pick the first available tun device */ + + if (dev_node && strcmp (dev_node, "tun")==0) + dev_node=NULL; + + open_tun_generic (dev, dev_type, dev_node, true, true, tt); + } } void @@ -2586,13 +2772,23 @@ close_tun (struct tuntap* tt) int write_tun (struct tuntap* tt, uint8_t *buf, int len) { - return write (tt->fd, buf, len); +#ifdef HAVE_NET_IF_UTUN_H + if (tt->is_utun) + return write_tun_header (tt, buf, len); + else +#endif + return write (tt->fd, buf, len); } int read_tun (struct tuntap* tt, uint8_t *buf, int len) { - return read (tt->fd, buf, len); +#ifdef HAVE_NET_IF_UTUN_H + if (tt->is_utun) + return read_tun_header (tt, buf, len); + else +#endif + return read (tt->fd, buf, len); } #elif defined(WIN32) diff --git a/src/openvpn/tun.h b/src/openvpn/tun.h index 956ad8d..2c97ffe 100644 --- a/src/openvpn/tun.h +++ b/src/openvpn/tun.h @@ -181,6 +181,9 @@ struct tuntap int ip_fd; #endif +#ifdef HAVE_NET_IF_UTUN_H + bool is_utun; +#endif /* used for printing status info only */ unsigned int rwflags_debug; -- 1.7.9.5