Defaulting to it in unreleased builds also sounds like a fine idea. I don't know how large your pre-release testing population is. The speed and directness of a utun migration is really a judgement call. Naturally I defer to those who are more involved in the project; it sounds like things are well in hand.
I'll leave my fork up for a while in case any part of my diff is helpful. I get the impression that 2.4 is not a date-driven release, so if it's not imminent, there's a possibility that we'll begin releasing the functionality in our own product before it's more widely available. Thanks, Peter On Jun 16, 2013, at 2:14 PM, Arne Schwabe <a...@rfc2549.org> wrote: > Am 16.06.13 01:41, schrieb Peter Sagerson: >> Nice, glad to see I'm not the only one working on this. Apple has been >> pretty clear that they're aware of the kext conflicts but don't have much >> interest in addressing the situation. If we can get native tunnel support in >> one way or another, we can stop the insanity. >> >> I toyed with the idea of various auto-detect or fallback modes, but I ended >> up opting for explicit behavior and backward compatibility. With the >> inherent uncertainties in a change like this, my inclination would be to >> start with a release that calls it an experimental feature, which users can >> turn on if they want to. Given the substantial benefits of not having to >> deal with kernel extensions, I think we would see both users and vendors >> promoting its use. If all goes well, the question of making it the default >> behavior probably belongs in the context of a major release. > > I think using utun as default at least for -master and 2.4rc candidates is a > good way to get the feature tested. I hope there is time in the next OpenVPN > developer IRC meeting to decide if my or your patch should be included. > > Arne >
signature.asc
Description: Message signed with OpenPGP using GPGMail
