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 <a...@rfc2549.org> wrote: > Am 01.04.13 17:18, schrieb Jonathan K. Bullard: > > On Mon, Apr 1, 2013 at 11:06 AM, Arne Schwabe <a...@rfc2549.org> 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<http://tuntaposx.sourceforge.net>), >> which is what >> Tunnelblick uses, or are you talking about something else? >> > Yeah exactly that one. > > Arne > >
