Add support of utun devices under Mac OS X
PATCH 1/1 Add support of utun devices under Mac OS X
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
--- configure.ac | 2 +- src/openvpn/tun.c | 294 ++++++++++++++++++++++++++++++++++++++++------------- src/openvpn/tun.h | 5 +- 3 files changed, 231 insertions(+), 70 deletions(-)
configure.ac +1 -1
@@ -454,7 +454,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}]]
src/openvpn/tun.c +226 -68
344 lines not on this page · raw message
src/openvpn/tun.h +4 -1
@@ -180,7 +180,10 @@ struct tuntap#ifdef TARGET_SOLARIS int ip_fd;#endif - + +#ifdef HAVE_NET_IF_UTUN_H +bool is_utun; +#endif /* used for printing status info only */ unsigned int rwflags_debug;
Signature · 1 line
1.7.9.5
Hi,
Quoted 3 lines · Arne Schwabe
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
I'm not fully sure whether I like this or not, but I can see the necessity if tun.ko is just not working in certain circumstances.
I'd very much like to hear from "GUI authors" for MacOS X about this, though - copying Jonathan: what do you think is the way forward here, and should this go into a soon-to-be-released 2.3.2, or is this "long-term future" material for 2.4?
gert
Signature · 4 lines
USENET is *not* the non-clickable part of WWW!
//www.muc.de/~gert/
Gert Doering - Munich, Germany [email protected]...
fax: +49-89-35655025 [email protected]...Quoted 6 lines · Gert Doering
Hi,
Quoted 3 lines · Arne Schwabe
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
The "utun" stuff is new to me; all I can find is the source code for it. Is this one of the "hidden features" of iOS that that OpenVPN for iOS app uses, and that is also in OS X 10.7 and up?
Most configuration files I've seen do not include a dev-node option. Does a "dev tun" option in the file imply, for this purpose, "dev-type tun"?
If I understand this correctly, a user who updates to 10.7+ will be using utun instead of tun. That may be problematic (I don't know).
Wouldn't it be better to use the legacy tun if it exists, and if not, then use the utun? That would be backward-compatible with such configuration files.
Quoted 8 lines
I'm not fully sure whether I like this or not, but I can see the necessity if tun.ko is just not working in certain circumstances.
I'd very much like to hear from "GUI authors" for MacOS X about this, though - copying Jonathan: what do you think is the way forward here, and should this go into a soon-to-be-released 2.3.2, or is this "long-term future" material for 2.4?
I don't have an opinion about including it in 2.3.2 vs. 2.4 -- I still can't get anything after 2.3alpha1 to build properly for Tunnelblick! I gave up on that several months ago, but last week someone else started working on it and is making progress.
Quoted 7 lines
gert
--
USENET is *not* the non-clickable part of WWW!//www.muc.de/~gert/Gert Doering - Munich, Germany [email protected]...
fax: +49-89-35655025 [email protected]...
Am 01.04.13 15:26, schrieb Jonathan K. Bullard:
Quoted 11 lines · Gert Doering
Quoted 6 lines
Hi,
Quoted 3 lines · Arne Schwabe
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
The "utun" stuff is new to me; all I can find is the source code for it. Is this one of the "hidden features" of iOS that that OpenVPN for iOS app uses, and that is also in OS X 10.7 and up?
Basically yes.
Quoted 10 lines
Most configuration files I've seen do not include a dev-node option. Does a "dev tun" option in the file imply, for this purpose, "dev-type tun"?
If I understand this correctly, a user who updates to 10.7+ will be using utun instead of tun. That may be problematic (I don't know).
Wouldn't it be better to use the legacy tun if it exists, and if not, then use the utun? That would be backward-compatible with such configuration files.
Currently the patch tries to open utun first and if that fails it will try to open tun. If you specify something like dev-node tun17 or dev-node utun23 it will only try to open that specific kind of tun node.
Arne
Quoted 31 lines · Arne Schwabe
Am 01.04.13 15:26, schrieb Jonathan K. Bullard:
Quoted 10 lines · Gert Doering
Quoted 9 lines
Hi,
Quoted 5 lines · Arne Schwabe
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).
Quoted 8 lines
Quoted 3 lines
Quoted 3 lines
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
The "utun" stuff is new to me; all I can find is the source code for it. Is this one of the "hidden features" of iOS that that OpenVPN for iOS app uses, and that is also in OS X 10.7 and up?
Basically yes.
Quoted 7 lines
Most configuration files I've seen do not include a dev-node option. Does a "dev tun" option in the file imply, for this purpose, "dev-type tun"?
If I understand this correctly, a user who updates to 10.7+ will be using utun instead of tun. That may be problematic (I don't know).
Quoted 8 lines
Quoted 3 lines
Wouldn't it be better to use the legacy tun if it exists, and if not, then use the utun? That would be backward-compatible with such configuration files.
Currently the patch tries to open utun first and if that fails it will try to open tun. If you specify something like dev-node tun17 or dev-node utun23 it will only try to open that specific kind of tun node.
Yes. The point I was trying to make was that most configuration files that I've seen don't have 'dev-node' options, so they will try utun first and only if that fails will they try try to open tun. So when they update to 10.7+, OpenVPN will start to use utun instead of tun (since it will be available in 10.7+), and that may break backward compatibility if the utun doesn't work exactly the same way that tun works, which I gather from the comment that
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
The "standard" utun.ko driver is sometimes problematic (e.g. VmWare Fusion 5 and tun.ko do not work together).
If it is the other way around (use tun if it is available and if not, try utun) then anybody who has loaded tun will continue to work with that tun, and anybody who hasn't loaded tun will get utun if it is available. So nothing breaks.
It's hard for a GUI like Tunnelblick that doesn't parse the configuration file to detect the situation (no dev-type option) to add a "dev-type tun" to force the use of tun.
But if we know that utun works for OpenVPN, then I don't have any problem with the patch. But that utun "is sometimes problematic" makes me worried that this may not be the case.
Quoted 7 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
The "standard" utun.ko driver is sometimes problematic (e.g. VmWare Fusion 5 and tun.ko do not work together).
If it is the other way around (use tun if it is available and if not, try utun) then anybody who has loaded tun will continue to work with that tun, and anybody who hasn't loaded tun will get utun if it is available. So nothing breaks.
Quoted 7 lines
It's hard for a GUI like Tunnelblick that doesn't parse the configuration file to detect the situation (no dev-type option) to add a "dev-type tun" to force the use of tun.
But if we know that utun works for OpenVPN, then I don't have any problem with the patch. But that utun "is sometimes problematic" makes me worried that this may not be the case.
The short history behind the patch: I was investing why Tunnelblick was not working on a collegues Macbook and as it turned out that you can have tun.ko loaded or the VmWare Fusion network driver (at least on his Macbook). Otherwise you get errors on loading the module. But I remembered something about the utun stuff, found the example code again and come up with the patch. The setence from the commit should have been:
The "standard" tun.ko driver is sometimes problematic (e.g. VmWare Fusion 5 and tun.ko do not work together).
The utun driver not be fully compatbile with behaviour of the standard tun.ko driver but all my tests (IPv6, IPv4) worked so far. For 2.3.x I fine with try utun first or try tun first behaviour but for -master/2.4 I would like to have try utun first so more people actually use utun so we get to know if it is really 100% compatible/working.
Arne
Quoted 17 lines · Arne Schwabe
Quoted 9 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
The "standard" utun.ko driver is sometimes problematic (e.g. VmWare Fusion 5 and tun.ko do not work together).
If it is the other way around (use tun if it is available and if not, try utun) then anybody who has loaded tun will continue to work with that tun, and anybody who hasn't loaded tun will get utun if it is available. So nothing breaks.
Quoted 7 lines
It's hard for a GUI like Tunnelblick that doesn't parse the configuration file to detect the situation (no dev-type option) to add a "dev-type tun" to force the use of tun.
But if we know that utun works for OpenVPN, then I don't have any problem with the patch. But that utun "is sometimes problematic" makes me worried that this may not be the case.
Quoted 5 lines
The short history behind the patch: I was investing why Tunnelblick was not working on a collegues Macbook and as it turned out that you can have tun.ko loaded or the VmWare Fusion network driver (at least on his Macbook). Otherwise you get errors on loading the module. But I remembered something about the utun stuff, found the example code again and come up with the patch. The setence from the commit should have been:
The "standard" tun.ko driver is sometimes problematic (e.g. VmWare Fusion 5 and tun.ko do not work together).
The utun driver not be fully compatbile with behaviour of the standard tun.ko driver but all my tests (IPv6, IPv4) worked so far. For 2.3.x I fine with try utun first or try tun first behaviour but for -master/2.4 I would like to have try utun first so more people actually use utun so we get to know if it is really 100% compatible/working.
Thanks; I get it. So it is the "standard" tun driver that is a problem, and the utun driver fixes that problem. In that case, patch is OK with me.
By "the 'standard' tun.ko driver", do you mean "tun.kext" from tuntaposx (http://tuntaposx.sourceforge.net), which is what Tunnelblick uses, or are you talking about something else?
Am 01.04.13 17:18, schrieb Jonathan K. Bullard:
Quoted 19 lines · Arne Schwabe
Quoted 18 lines
Quoted 7 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
The "standard" utun.ko driver is sometimes problematic (e.g. VmWare Fusion 5 and tun.ko do not work together).
If it is the other way around (use tun if it is available and if not, try utun) then anybody who has loaded tun will continue to work with that tun, and anybody who hasn't loaded tun will get utun if it is available. So nothing breaks.
Quoted 7 lines
It's hard for a GUI like Tunnelblick that doesn't parse the configuration file to detect the situation (no dev-type option) to add a "dev-type tun" to force the use of tun.
But if we know that utun works for OpenVPN, then I don't have any problem with the patch. But that utun "is sometimes problematic" makes me worried that this may not be the case.
The short history behind the patch: I was investing why Tunnelblick was not working on a collegues Macbook and as it turned out that you can have tun.ko loaded or the VmWare Fusion network driver (at least on his Macbook). Otherwise you get errors on loading the module. But I remembered something about the utun stuff, found the example code again and come up with the patch. The setence from the commit should have been:
The "standard" tun.ko driver is sometimes problematic (e.g. VmWare Fusion 5 and tun.ko do not work together).
Quoted 8 lines
Quoted 1 line
The utun driver not be fully compatbile with behaviour of the standard tun.ko driver but all my tests (IPv6, IPv4) worked so far. For 2.3.x I fine with try utun first or try tun first behaviour but for -master/2.4 I would like to have try utun first so more people actually use utun so we get to know if it is really 100% compatible/working.
Thanks; I get it. So it is the "standard" tun driver that is a problem, and the utun driver fixes that problem. In that case, patch is OK with me.
By "the 'standard' tun.ko driver", do you mean "tun.kext" from tuntaposx (http://tuntaposx.sourceforge.net), which is what Tunnelblick uses, or are you talking about something else?
Yeah exactly that one.
Arne
Thanks; now that I understand the patch, I support it.
This is the first I've heard of 'utun' -- can you tell me how to load it?
(I assume via "sudo kextload xxx", but what is xxx -- that is, where is the kext located?)
Quoted 51 lines · Arne Schwabe
Am 01.04.13 17:18, schrieb Jonathan K. Bullard:
Quoted 34 lines · Arne Schwabe
Quoted 25 lines
The "standard" utun.ko driver is sometimes problematic (e.g. VmWare
Quoted 7 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 2 lines
Fusion 5 and tun.ko do not work together).
If it is the other way around (use tun if it is available and if not,
try utun) then anybody who has loaded tun will continue to work with that tun, and anybody who hasn't loaded tun will get utun if it is available. So nothing breaks.
Quoted 8 lines
It's hard for a GUI like Tunnelblick that doesn't parse the configuration file to detect the situation (no dev-type option) to add a "dev-type tun" to force the use of tun.
But if we know that utun works for OpenVPN, then I don't have any problem with the patch. But that utun "is sometimes problematic" makes me worried that this may not be the case.
The short history behind the patch: I was investing why Tunnelblick was not working on a collegues Macbook and as it turned out that you can have tun.ko loaded or the VmWare Fusion network driver (at least on his Macbook). Otherwise you get errors on loading the module. But I remembered something about the utun stuff, found the example code again and come up with the patch. The setence from the commit should have been:
Quoted 9 lines
The "standard" tun.ko driver is sometimes problematic (e.g. VmWare Fusion 5 and tun.ko do not work together).
The utun driver not be fully compatbile with behaviour of the standard tun.ko driver but all my tests (IPv6, IPv4) worked so far. For 2.3.x I fine with try utun first or try tun first behaviour but for -master/2.4 I would like to have try utun first so more people actually use utun so we get to know if it is really 100% compatible/working.
Quoted 9 lines
Thanks; I get it. So it is the "standard" tun driver that is a problem, and the utun driver fixes that problem. In that case, patch is OK with me.
By "the 'standard' tun.ko driver", do you mean "tun.kext" from tuntaposx (http://tuntaposx.sourceforge.**net<http://tuntaposx.sourceforge.net>),
which is what
Tunnelblick uses, or are you talking about something else?Yeah exactly that one.
Arne
Am 01.04.13 19:03, schrieb Jonathan K. Bullard:
Quoted 5 lines
Thanks; now that I understand the patch, I support it.
This is the first I've heard of 'utun' -- can you tell me how to load it?
There is no need for any extra kextload. Using the socket magic my patch does is enough and you need to be root.
Arne
Re: [Openvpn-devel] building on OSX (for Tunnelblick) (was: [PATCH] Add support of utun devices under Mac OS X)
In reply to Jonathan K. BullardHi,
(detouring from tun/utun, but don't let me stop you and Arne from discussing this in the original thread)
Quoted 2 lines · Jonathan K. Bullard
I don't have an opinion about including it in 2.3.2 vs. 2.4 -- I still can't get anything after 2.3alpha1 to build properly for Tunnelblick!
Uh. I've seen some issues reported by you, but I thought it had been resolved in time for 2.3_RC and 2.3.0 - since we're at 2.3.1 now, I really want to see this fixed :-)
So what is still breaking for you?
(I'm especially surprised since I know Arne is building and testing on OSX, so it *should* work - but maybe it's "it works on 10.7 and 10.8, but fails on 10.6", which we might have overlooked as our pool of OSX machines with various OS releases to build on is a bit limited - how do other open source projects handle this??)
gert
Signature · 4 lines
USENET is *not* the non-clickable part of WWW!
//www.muc.de/~gert/
Gert Doering - Munich, Germany [email protected]...
fax: +49-89-35655025 [email protected]...Re: [Openvpn-devel] building on OSX (for Tunnelblick) (was: [PATCH] Add support of utun devices under Mac OS X)
Quoted 8 lines · Gert Doering
Quoted 2 lines · Jonathan K. Bullard
I don't have an opinion about including it in 2.3.2 vs. 2.4 -- I still can't get anything after 2.3alpha1 to build properly for Tunnelblick!
Uh. I've seen some issues reported by you, but I thought it had been resolved in time for 2.3_RC and 2.3.0 - since we're at 2.3.1 now, I really want to see this fixed :-)
Quoted 8 lines
So what is still breaking for you?
(I'm especially surprised since I know Arne is building and testing on OSX, so it *should* work - but maybe it's "it works on 10.7 and 10.8, but fails on 10.6", which we might have overlooked as our pool of OSX machines with various OS releases to build on is a bit limited - how do other open source projects handle this??)
Thanks for your inquiry.
Tunnelblick is still being built on OS X 10.6.8 with Xcode 3.2.2 because it still supports PowerPC, which later versions of Xcode (which are required for use on 10.7+) don't support. (For simplicity, Tunnelblick and its dependencies are all built as a single Xcode project. Tunnelblick usually includes at least two or three versions of OpenVPN, and lets the user select which version they want to use with a couple of clicks, but of course it is limited to the versions that we can build!)
I doubt that the issues are in OpenVPN itself, or its build system. I think I couldn't get it working because of my unfamiliarity with make and the toolset that is required to build OpenVPN. As I remember:
- The problems happen for 2.3alpha2 but not 2.3alpha1, and I finally figured out they were triggered not by the major build-system changes, but by the initial patch that added PolarSSL.
- The problems were in getting openvpn to static link with lzo and openssl. (There may have been a similar issue with pkcs11-helper, but it is broken in Tunnelblick and I later found out that it shouldn't be static linked, so that wasn't a major concern.)
Harold Molina-Bulla has taken over the effort to get Tunnelblick building with OpenVPN 2.3. I've added him as a cc: to this thread.
Re: [Openvpn-devel] building on OSX (for Tunnelblick)
Quoted 5 lines
Tunnelblick is still being built on OS X 10.6.8 with Xcode 3.2.2 because it still supports PowerPC, which later versions of Xcode (which are required for use on 10.7+) don't support.
Is there a specific reason for Xcode 3.2.2? I set up a 10.6.8 snow leopard with 3.2.2 and did not have net/if_utun.h. However Xcode 3.2.6 includes net/if_utun.h and utun works on the test machine (and also include the powerpc-* gcc binaries)
Arne
Re: [Openvpn-devel] building on OSX (for Tunnelblick)
Quoted 8 lines · Arne Schwabe
Quoted 3 lines
Tunnelblick is still being built on OS X 10.6.8 with Xcode 3.2.2 because it still supports PowerPC, which later versions of Xcode (which are required for use on 10.7+) don't support.
Is there a specific reason for Xcode 3.2.2? I set up a 10.6.8 snow leopard with 3.2.2 and did not have
net/if_utun.h. However Xcode 3.2.6 includesnet/if_utun.hand utun works on the test machine (and also include the powerpc-* gcc binaries)
Xcode 3.2.6 does not generate PPC code for the *Tunnelblick* part (written in Objective-C).
At least, it doesn't have a way to select an architecture of "Universal 32-bit" (meaning 32-bit PPC & i386), only "32-bit Intel", "64-bit Intel", or "Standard (32/64-bit Intel)".
There is an "Other" setting, but I haven't been able to set that to anything that makes "Universal 32-bit" (meaning 32-bit PPC & i386).
In the past I've been willing to forego 64-bit to get 32-bit PPC/Intel, but of course 32/64 PPC/Intel would be great.
PATCH v2 1/1 Add support of utun devices under Mac OS X
In reply to Arne SchwabeMac 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
Parts of the patches are inspired from Peter Sagerson's <[email protected]...> utun patch
--- configure.ac | 2 +- doc/openvpn.8 | 11 ++ src/openvpn/tun.c | 307 +++++++++++++++++++++++++++++++++++++++++------------ src/openvpn/tun.h | 5 +- 4 files changed, 255 insertions(+), 70 deletions(-)
configure.ac +1 -1
@@ -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}]]
doc/openvpn.8 +11 -0
@@ -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 speficic utun instance. To force using the tun.kext (/dev/tunX) use +.B \-\-dev\-node tun +. When not speicifying a +.B \-\-dev\-node +option openvpn will try to first open utun first fallback to tun.kext. + On Windows systems, select the TAP-Win32 adapter which is named .B node
src/openvpn/tun.c +239 -68
357 lines not on this page · raw message
src/openvpn/tun.h +4 -1
@@ -180,7 +180,10 @@ struct tuntap#ifdef TARGET_SOLARIS int ip_fd;#endif - + +#ifdef HAVE_NET_IF_UTUN_H +bool is_utun; +#endif /* used for printing status info only */ unsigned int rwflags_debug;
Signature · 1 line
1.7.9.5
Quoted 7 lines · Arne Schwabe
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
Parts of the patches are inspired from Peter Sagerson's <[email protected]...> utun patch
Signed-off-by Arne Schwabe <[email protected]...>
I am anxious to see utun incorporated into OpenVPN and like the functionality this patch provides. I have several comments, all based on the updated patch in Arne's 2013-06-18 email.
(Because I am using an old version of OpenVPN, the line numbers in my files don't correspond to those Arne's patch was based on, so the code/patches I show below are pseudo-diffs from the code as patched by Arne's patch, not diffs from any existing code or diffs from his patch.)
First, I propose three minor wording changes:
Two changes in doc/openvpn.8:
-to select a speficic utun instance. To force using the tun.kext (/dev/tunX) use +to select a specific utun instance. To force using the tun.kext (/dev/tunX) use
and
-option openvpn will try to first open utun first fallback to tun.kext. +option openvpn will first try to open utun, and fall back to tun.kext.
One change in src/openvpn/tun.c
- msg (M_INFO, "Openend utun device %s", utunname);
+ msg (M_INFO, "Opened utun device %s", utunname);
--------------------------------
Second, I created an experimental build of Tunnelblick that incorporates this patch into OpenVPN 2.3.2. Because Tunnelblick is built in OS X 10.6.8 with Xcode 3.2.2 with the 10.6 SDK (to support PPC and OS X 10.4 - 10.9), it doesn't have /net/if_utun.h, so it doesn't set HAVE_NET_IF_UTUN_H. That combination (TARGET_DARWIN is set, but not HAVE_NET_IF_UTUN_H) generates errors that require some changes:
The "}" at the end of open_tun() needs to be conditionalized (Here is the entire routine to clarify why):
open_tun (const char *dev, const char *dev_type, const char*dev_node, struct tuntap *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);
/* No explicit utun and utun failed, try the generic way) */
if (!dev_node && !tt->is_utun)
{
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
{
#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);
+#ifdef HAVE_NET_IF_UTUN_H
}+#endif
}
(Or, if you want, you can move the existing #endif up one line instead.)
The changes to write_tun and read_tun need to be conditioned on HAVE_NET_IF_UTUN_H being defined:
int
write_tun (struct tuntap* tt, uint8_t *buf, int 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) {
+#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);}
The resulting binary works on 10.5.8, 10.6.8, and 10.7.5. (Of course, it uses tun, not utun.)
--------------------------------
I removed all the the references to HAVE_NET_IF_UTUN_H (so the utun code is compiled even though it is not it is available in the SDK being used) and changed:
-#include <net/if_utun.h>
+#define UTUN_CONTROL_NAME "com.apple.net.utun_control"
+#define UTUN_OPT_IFNAME 2
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Note: This change should not be put in an OpenVPN patch; it is solely to allow me to compile it with the 10.6 SDK.
(The values for the UTUN_* variables are taken from 10.7), and it built without problems.
--------------------------------
The resulting binary works fine and uses utun on 10.6.8 and 10.7.5.
(Interesting that utun isn't in the 10.6 SDK but utun works on 10.6.8. Since it isn't in the SDK, I assume it may be flakey and/or only in some OS X > 10.6.0. If it is flakey in 10.6.8, that's a problem because it will be used by default, but if it is just that it isn't in all of 10.6.*, that should be OK.)
On 10.5.8, however, attempting to connect to a server fails with the following messages from the OpenVPN log:
2013-06-19 10:06:28 Opening utun (ioctl(CTLIOCGINFO)): No such file or directory: No such file or directory (errno=2) 2013-06-19 10:06:28 Exiting due to fatal error
Someone should build with the patch properly (i.e. not like I did) on 10.7 or 10.8 and test it on 10.5 (and 10.4, ideally) to make sure the fallback really works. (I may be misunderstanding the code, but if "msg (M_ERR..." doesn't return, then that's at least part of the problem.)
If fallback doesn't work in 10.4 and 10.5, then my view is that it should be changed so it does work (mostly because Tunnelblick supports 10.4 - 10.8 with a single OpenVPN binary). If OpenVPN doesn't want to support 10.5 or 10.4 to this extent, or if the fallback failure is caused by with the way I worked around not using the 10.7 SDK, I guess I'll just have to deal with it.
PATCH v3 1/1 Add support of utun devices under Mac OS X
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
Parts of the patches are inspired from Peter Sagerson's <[email protected]...> utun patch
--- configure.ac | 2 +- doc/openvpn.8 | 11 ++ src/openvpn/tun.c | 305 +++++++++++++++++++++++++++++++++++++++++------------ src/openvpn/tun.h | 3 + 4 files changed, 253 insertions(+), 68 deletions(-)
configure.ac +1 -1
@@ -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}]]
doc/openvpn.8 +11 -0
@@ -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 speficic utun instance. To force using the tun.kext (/dev/tunX) use +.B \-\-dev\-node tun +. When not speicifying a +.B \-\-dev\-node +option openvpn will try to first open utun first fallback to tun.kext. + On Windows systems, select the TAP-Win32 adapter which is named .B node
src/openvpn/tun.c +238 -67
349 lines not on this page · raw message
src/openvpn/tun.h +3 -0
@@ -181,6 +181,9 @@ struct tuntapint ip_fd;#endif +#ifdef HAVE_NET_IF_UTUN_H +bool is_utun; +#endif /* used for printing status info only */ unsigned int rwflags_debug;
Signature · 1 line
1.7.9.5
PATCH 1/1 Add support of utun devices under Mac OS X
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
Parts of the patches are inspired from Peter Sagerson's <[email protected]...> utun patch
--- configure.ac | 2 +- doc/openvpn.8 | 11 ++ src/openvpn/tun.c | 310 +++++++++++++++++++++++++++++++++++++++++------------ src/openvpn/tun.h | 3 + 4 files changed, 258 insertions(+), 68 deletions(-)
configure.ac +1 -1
@@ -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}]]
doc/openvpn.8 +11 -0
@@ -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
src/openvpn/tun.c +243 -67
354 lines not on this page · raw message
src/openvpn/tun.h +3 -0
@@ -181,6 +181,9 @@ struct tuntapint ip_fd;#endif +#ifdef HAVE_NET_IF_UTUN_H +bool is_utun; +#endif /* used for printing status info only */ unsigned int rwflags_debug;
Signature · 1 line
1.7.9.5
Quoted 2 lines · Arne Schwabe
I have a OS X 10.6 VM with Xcode 3.2.6 installed and this VM has the
if/utun.hheader. I probably was added somewhere between 10.6.0 and 10.6.8.
Ah. Thanks for mentioning this. That makes sense.
Quoted 2 lines
I changed the
M_ERRtoM_WARN. It should now work on 10.5.x but without a 10.5 to test on it is difficult to say...
OK, thanks; now I better understand how the error handling works.
Quoted 6 lines · Arne Schwabe
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
Parts of the patches are inspired from Peter Sagerson's <[email protected]...> utun patch
Signed-off-by Arne Schwabe <[email protected]...>
First, I should mention that the most recent version of this patch (in your Thu, Jun 20, 2013 at 5:05 AM email) seems to make some other, major changes, too, at least when compared to the earlier version (in your email of Tue, Jun 18, 2013 at 1:23 AM). I have ignored those changes (I don't really understand them), and I have just made the changes that I mentioned, plus one typo that you caught that I missed, and the M_ERR to M_WARN changes.
Unfortunately, this patch still fails if the utun code is included and executed on 10.5.
A minor problem is that for each of the 255 attempts to get a utun device (device #0 through device #254), it generates the following warning message:
Opening utun (ioctl(CTLIOCGINFO)): No such file or directory
It's ugly, but cosmetic. Perhaps it could be displayed only at verb=4 and higher? (I don't know how to do that.)
The larger problem is that it still fails to connect, with the error message:
Error retrieving utun interface name: Bad file descriptor (errno=9)
I think this is because open_darwin_utun ignores the error (fd == -1) returned from utun_open_helper.
If so, it can be fixed by changing open_darwin_utun as follows:
else
{
fd = utun_open_helper (ctlInfo, utunnum);
}+ if (fd==-1)
+ tt->is_utun = false;
+ 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);(I added the " tt->is_utun = false;" just to be sure; I'm not clear on the initialization of tt->is_utun, and it is used in the test that follows the call to open_darwin_utun to test for success/failure.)
After making that change, it works on OS X 10.5.8 and 10.4.11.
Am 20.06.13 15:32, schrieb Jonathan K. Bullard:
Quoted 6 lines
A minor problem is that for each of the 255 attempts to get a utun device (device #0 through device #254), it generates the following warning message:
Opening utun (ioctl(CTLIOCGINFO)): No such file or directory
It's ugly, but cosmetic. Perhaps it could be displayed only at verb=4 and higher? (I don't know how to do that.)
I have changed the patch to only try to open that once in case of early initialization failure. I also change the log level to M_INFO.
Quoted 6 lines
The larger problem is that it still fails to connect, with the error message:
Error retrieving utun interface name: Bad file descriptor (errno=9)I think this is because
open_darwin_utunignores the error (fd == -1) returned fromutun_open_helper.
fd == -1 was overloaded in
- utun failed to open at all
- this specific utun failed (like utun1, utun2, ....)
Quoted 15 lines
If so, it can be fixed by changing
open_darwin_utunas follows:else { fd = utun_open_helper (ctlInfo, utunnum); }(quoted diff) +4
-0+ if (fd==-1) + tt->is_utun = false; + return; + /* Retrieve the assigned interface name. */ if (getsockopt (fd, SYSPROTO_CONTROL, UTUN_OPT_IFNAME, utunname,
&utunname_len))
Quoted 8 lines
msg (M_ERR | M_ERRNO, "Error retrieving utun interface name"); tt->actual_name = string_alloc (utunname, NULL);(I added the "
tt->is_utun= false;" just to be sure; I'm not clear on the initialization oftt->is_utun, and it is used in the test that follows the call toopen_darwin_utunto test for success/failure.)
Thanks for spotting this.
Arne
PATCH v4 1/1 Add support of utun devices under Mac OS X
In reply to Jonathan K. BullardMac 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 <[email protected]...>
Parts of the patches are inspired from Peter Sagerson's <[email protected]...> utun patch
--- configure.ac | 2 +- doc/openvpn.8 | 11 ++ src/openvpn/tun.c | 326 ++++++++++++++++++++++++++++++++++++++++++----------- src/openvpn/tun.h | 3 + 4 files changed, 274 insertions(+), 68 deletions(-)
configure.ac +1 -1
@@ -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}]]
doc/openvpn.8 +11 -0
@@ -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
src/openvpn/tun.c +259 -67
370 lines not on this page · raw message
src/openvpn/tun.h +3 -0
@@ -181,6 +181,9 @@ struct tuntapint ip_fd;#endif +#ifdef HAVE_NET_IF_UTUN_H +bool is_utun; +#endif /* used for printing status info only */ unsigned int rwflags_debug;
Signature · 1 line
1.7.9.5
PATCH v5 1/1 Add support of utun devices under Mac OS X
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 <[email protected]...>
Parts of the patches are inspired from Peter Sagerson's <[email protected]...> utun patch
--- configure.ac | 2 +- doc/openvpn.8 | 11 ++ src/openvpn/tun.c | 330 ++++++++++++++++++++++++++++++++++++++++++----------- src/openvpn/tun.h | 3 + 4 files changed, 278 insertions(+), 68 deletions(-)
configure.ac +1 -1
@@ -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}]]
doc/openvpn.8 +11 -0
@@ -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
src/openvpn/tun.c +263 -67
374 lines not on this page · raw message
src/openvpn/tun.h +3 -0
@@ -181,6 +181,9 @@ struct tuntapint ip_fd;#endif +#ifdef HAVE_NET_IF_UTUN_H +bool is_utun; +#endif /* used for printing status info only */ unsigned int rwflags_debug;
Signature · 1 line
1.7.9.5
PATCH v6 1/1 Add support of utun devices under Mac OS X
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 <[email protected]...>
Parts of the patches are inspired from Peter Sagerson's <[email protected]...> utun patch
--- configure.ac | 2 +- doc/openvpn.8 | 11 ++ src/openvpn/tun.c | 333 ++++++++++++++++++++++++++++++++++++++++++----------- src/openvpn/tun.h | 3 + 4 files changed, 281 insertions(+), 68 deletions(-)
configure.ac +1 -1
@@ -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}]]
doc/openvpn.8 +11 -0
@@ -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
src/openvpn/tun.c +266 -67
383 lines not on this page · raw message
src/openvpn/tun.h +3 -0
@@ -181,6 +181,9 @@ struct tuntapint ip_fd;#endif +#ifdef HAVE_NET_IF_UTUN_H +bool is_utun; +#endif /* used for printing status info only */ unsigned int rwflags_debug;
Signature · 1 line
1.7.9.5
Hi,
Quoted 2 lines · Arne Schwabe
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
Signature · 4 lines
USENET is *not* the non-clickable part of WWW!
//www.muc.de/~gert/
Gert Doering - Munich, Germany [email protected]...
fax: +49-89-35655025 [email protected]...Quoted 11 lines · Gert Doering
Hi,
Quoted 2 lines · Arne Schwabe
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,
Quoted 2 lines · Jonathan K. Bullard
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
Signature · 4 lines
USENET is *not* the non-clickable part of WWW!
//www.muc.de/~gert/
Gert Doering - Munich, Germany [email protected]...
fax: +49-89-35655025 [email protected]...Hi,
Quoted 1 line · Arne Schwabe
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
Signature · 4 lines
USENET is *not* the non-clickable part of WWW!
//www.muc.de/~gert/
Gert Doering - Munich, Germany [email protected]...
fax: +49-89-35655025 [email protected]...PATCH v7 1/1 Add support of utun devices under Mac OS X
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 <[email protected]...>
Parts of the patches are inspired from Peter Sagerson's <[email protected]...> utun patch
--- configure.ac | 2 +- doc/openvpn.8 | 11 ++ src/openvpn/tun.c | 338 ++++++++++++++++++++++++++++++++++++++++++----------- src/openvpn/tun.h | 3 + 4 files changed, 286 insertions(+), 68 deletions(-)
configure.ac +1 -1
@@ -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}]]
doc/openvpn.8 +11 -0
@@ -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
src/openvpn/tun.c +271 -67
388 lines not on this page · raw message
src/openvpn/tun.h +3 -0
@@ -181,6 +181,9 @@ struct tuntapint ip_fd;#endif +#ifdef HAVE_NET_IF_UTUN_H +bool is_utun; +#endif /* used for printing status info only */ unsigned int rwflags_debug;
Signature · 1 line
1.7.9.5
Quoted 9 lines · Arne Schwabe
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 withoutif/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.
ACK (based on discussion on the patch, feature-ack, and code testing from Jonathan).
Patch has been applied to the master and release/2.3 branches, with the usual whitespace fixing :-)
commit fbc04bedbcce02fc625357b7475ddbc7164cabbf (master) commit bdfd4ee4c0e3bcd46222b8425cea87a4c83bb37c (release/2.3)
Author: Arne Schwabe Date: Fri Jun 21 12:48:28 2013 +0200
Add support of utun devices under Mac OS X
Signed-off-by: Arne Schwabe <[email protected]...>
Tested-by: Jonathan K. Bullard <[email protected]...>
Acked-by: Gert Doering <[email protected]...>
Message-Id: <[email protected]...>
URL: http://article.gmane.org/gmane.network.openvpn.devel/7739
Signed-off-by: Gert Doering <[email protected]...>--
kind regards,
Gert Doering
Am 21.06.13 12:48, schrieb Arne Schwabe:
doc/openvpn.8 also specify · line 817
Quoted 5 lines
doc/openvpn.8 +5
-0+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.
I just noticed that this does not work because man does ignore the line starting with a ".".
Does anyone know how to fix this? My attempts of escaping the . were not fruitful.
Arne
-.B \-\-dev\-node tun
-. When not specifying a
+.B \-\-dev\-node tun\fR.
+When not specifying a
Should do the trick.
--
Thomas
On January 23, 2014 at 1:12:41 PM, Arne Schwabe ([email protected]...) wrote:
Am 21.06.13 12:48, schrieb Arne Schwabe:
doc/openvpn.8 also specify · line 817
Quoted 5 lines
doc/openvpn.8 +5
-0+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.
I just noticed that this does not work because man does ignore the line starting with a ".".
Does anyone know how to fix this? My attempts of escaping the . were not fruitful.
Arne
------------------------------------------------------------------------------
CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments & Everything In Between. Get a Quote or Start a Free Trial Today.
http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
_______________________________________________
Openvpn-devel mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Am 20.06.13 05:17, schrieb Jonathan K. Bullard:
Quoted 7 lines · Arne Schwabe
Quoted 6 lines
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
Parts of the patches are inspired from Peter Sagerson's <[email protected]...> utun patch
Signed-off-by Arne Schwabe <[email protected]...>
Thanks for looking at the patch. I fixed all the bugs you found.
Quoted 9 lines
The resulting binary works fine and uses utun on 10.6.8 and 10.7.5.
(Interesting that utun isn't in the 10.6 SDK but utun works on 10.6.8. Since it isn't in the SDK, I assume it may be flakey and/or only in some OS X > 10.6.0. If it is flakey in 10.6.8, that's a problem because it will be used by default, but if it is just that it isn't in all of 10.6.*, that should be OK.)
I have a OS X 10.6 VM with Xcode 3.2.6 installed and this VM has the if/utun.h header. I probably was added somewhere between 10.6.0 and 10.6.8.
Quoted 14 lines
On 10.5.8, however, attempting to connect to a server fails with the following messages from the OpenVPN log:
2013-06-19 10:06:28 Opening utun (ioctl(CTLIOCGINFO)): No such file or directory: No such file or directory (errno=2) 2013-06-19 10:06:28 Exiting due to fatal errorSomeone should build with the patch properly (i.e. not like I did) on 10.7 or 10.8 and test it on 10.5 (and 10.4, ideally) to make sure the fallback really works. (I may be misunderstanding the code, but if "msg (
M_ERR..." doesn't return, then that's at least part of the problem.)
Quoted 6 lines
If fallback doesn't work in 10.4 and 10.5, then my view is that it should be changed so it does work (mostly because Tunnelblick supports 10.4 - 10.8 with a single OpenVPN binary). If OpenVPN doesn't want to support 10.5 or 10.4 to this extent, or if the fallback failure is caused by with the way I worked around not using the 10.7 SDK, I guess I'll just have to deal with it.
I changed the M_ERR to M_WARN. It should now work on 10.5.x but without a 10.5 to test on it is difficult to say...
Arne