openvpn2: "Cannot allocate TUN/TAP dev dynamically"

Kevin Ballard eridius at
Fri Aug 29 03:02:17 PDT 2008

If the kext is meant to be loaded by the system at startup, it has to  
go in the System-provided folder. The macfuse port just follows the  
lead of the official MacFuse project and puts it where the official  
MacFuse project designates - this works, because MacFuse apps  
explicitly load the kext when they need it.

-Kevin Ballard

On Aug 29, 2008, at 1:12 AM, Uwe Schwartz wrote:

> The only other port that mentions "kext" is macfuse,
> according to rgrep. And that contains a Framework, and
> I would imagine that places the kext into a well-known
> place and takes care of everything. And least it has
> no special means to start it.
> Macfuse is a good hint. It seems the Port takes a completely  
> different approach. So I set eridius at (the maintainer of  
> macfuse) to CC.
> @eridius: What's best practics on handling Kexts?
> > Another problem could be a conflict with an already installed Kext  
> (maybe
> > the legacy TUN/TAP driver or Tunnelblick).
> MacPorts does not overwrite files but rather fails before doing so.
> And then you just have to know how you manually configured your
> system.
> What is the "legacy TUN/TAP" btw?
> With legacy I just mean the prebuild/compiled package from tuntaposx  
> (which e.g. come with Tunnelblick or maybe some other VPN solution).  
> And with conflict I mean the error on loading the extension when  
> there is already the "legacy" Kext loaded. Indeed this is not a big  
> problem but slightly unclean. The outcome of this is an issue with  
> the dependencies of openvpn2.
> At the moment I'm pinched of time and during work hours I'm on a Win  
> machine, so I can't help a lot.
> Maybe you just create a Port Submission and upload your Portfile. I  
> will test it during the next days.

Kevin Ballard
eridius at

-------------- next part --------------
An HTML attachment was scrubbed...

More information about the macports-dev mailing list