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