Re: [Openvpn-devel] [PATCH] Add support of utun devices under Mac OS X

[Arne Schwabe]

Am 01.04.13 19:03, schrieb Jonathan K. Bullard:

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



smime.p7s
Description: S/MIME Kryptografische Unterschrift

Re: [Openvpn-devel] [PATCH] Add support of utun devices under Mac OS X

[Jonathan K. Bullard]

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?)

On Mon, Apr 1, 2013 at 11:30 AM, Arne Schwabe  wrote:

> Am 01.04.13 17:18, schrieb Jonathan K. Bullard:
>
>  On Mon, Apr 1, 2013 at 11:06 AM, Arne Schwabe  wrote:
>>
>>>
>>>  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.

>>> 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?
>>
> Yeah exactly that one.
>
> Arne
>
>

Re: [Openvpn-devel] [PATCH] Add support of utun devices under Mac OS X

[Arne Schwabe]

Am 01.04.13 17:18, schrieb Jonathan K. Bullard:

On Mon, Apr 1, 2013 at 11:06 AM, Arne Schwabe  wrote:



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.

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?

Yeah exactly that one.

Arne



smime.p7s
Description: S/MIME Kryptografische Unterschrift

Re: [Openvpn-devel] [PATCH] Add support of utun devices under Mac OS X

[Jonathan K. Bullard]

On Mon, Apr 1, 2013 at 11:06 AM, Arne Schwabe  wrote:
>
>
>> 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.
>
> 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?

Re: [Openvpn-devel] [PATCH] Add support of utun devices under Mac OS X

[Arne Schwabe]

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.
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



smime.p7s
Description: S/MIME Kryptografische Unterschrift

Re: [Openvpn-devel] [PATCH] Add support of utun devices under Mac OS X

[Jonathan K. Bullard]

On Mon, Apr 1, 2013 at 10:29 AM, Arne Schwabe  wrote:
>
> Am 01.04.13 15:26, schrieb Jonathan K. Bullard:
>
>> On Mon, Apr 1, 2013 at 7:12 AM, Gert Doering  wrote:
>>>
>>> Hi,
>>>
>>> On Sun, Mar 31, 2013 at 10:43:29PM +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).

 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.
>
>> 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.

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

 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.

Re: [Openvpn-devel] [PATCH] Add support of utun devices under Mac OS X

[Arne Schwabe]

Am 01.04.13 15:26, schrieb Jonathan K. Bullard:

On Mon, Apr 1, 2013 at 7:12 AM, Gert Doering  wrote:

Hi,

On Sun, Mar 31, 2013 at 10:43:29PM +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).

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.

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



smime.p7s
Description: S/MIME Kryptografische Unterschrift

Re: [Openvpn-devel] [PATCH] Add support of utun devices under Mac OS X

[Jonathan K. Bullard]

On Mon, Apr 1, 2013 at 7:12 AM, Gert Doering  wrote:
> Hi,
>
> On Sun, Mar 31, 2013 at 10:43:29PM +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).
>>
>> 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.

>
> 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.

>
> gert
> --
> USENET is *not* the non-clickable part of WWW!
>//www.muc.de/~gert/
> Gert Doering - Munich, Germany g...@greenie.muc.de
> fax: +49-89-35655025g...@net.informatik.tu-muenchen.de

Re: [Openvpn-devel] [PATCH] Add support of utun devices under Mac OS X

[Gert Doering]

Hi,

On Sun, Mar 31, 2013 at 10:43:29PM +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).
> 
> 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
-- 
USENET is *not* the non-clickable part of WWW!
   //www.muc.de/~gert/
Gert Doering - Munich, Germany g...@greenie.muc.de
fax: +49-89-35655025g...@net.informatik.tu-muenchen.de


pgpQNBSyQgQSZ.pgp
Description: PGP signature

[Openvpn-devel] [PATCH] Add support of utun devices under Mac OS X

[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

Signed-off-by: Arne Schwabe 
---
 configure.ac  |2 +-
 src/openvpn/tun.c |  294 -
 src/openvpn/tun.h |5 +-
 3 files changed, 231 insertions(+), 70 deletions(-)

diff --git a/configure.ac b/configure.ac
index 7b35e50..5994991 100644
--- a/configure.ac
+++ b/configure.ac
@@ -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}]]
diff --git a/src/openvpn/tun.c b/src/openvpn/tun.c
index a361233..089fe59 100644
--- a/src/openvpn/tun.c
+++ b/src/openvpn/tun.c
@@ -673,7 +673,7 @@ do_ifconfig (struct tuntap *tt,
 }
 #endif

-
+  
 #if defined(TARGET_LINUX)
 #ifdef ENABLE_IPROUTE
/*
@@ -1248,6 +1248,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 
+#include 
+
+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 = 
+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 = 
+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,
@@ -1972,23 +2053,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)
 {
@@ -2055,59 +2119,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 = 
-  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));
-}
-