Viscosity 1.60 beta still loads tap/tun driver

Got a problem with Viscosity or need help? Ask here!

ikonst

Posts: 7
Joined: Fri Feb 12, 2016 12:48 pm

Post by ikonst » Fri Feb 12, 2016 12:51 pm
Hi,

Although you guys have switched to use the built-in utun interface, you still:
a) ship the tuntaposx drivers
b) force them to load every time you start VPN
c) if the drivers fail to load, fail the whole VPN connection

In our organization, the drivers are problematic since we're also using VMWare and it creates contention over the very few char major device numbers in OS X (yes, there can be only a handful of non-Apple drivers that can create devices in /dev).

This causes periodic failures to start VMWare, which requires developers to restart their machines.

Can you fix it so that the beta allows us to inhibit loading the tuntaposx drivers?

Thanks,
Ilya

James

User avatar
Posts: 2313
Joined: Thu Sep 04, 2008 9:27 pm

Post by James » Sat Feb 13, 2016 12:36 am
Hi Ilya,

The tun/tap drivers are still required in many instances, such as when using a tap (bridged) connection, or as a fallback if a utun interface cannot be created, which is why they're still loaded by Viscosity.

We'll take a look at adding a hidden setting to optionally disable the use of the tun/tap drivers. However I'm afraid any such option won't make it into the 1.6.0 beta as it's frozen for release (which is should any day now).

Cheers,
James
Web: https://www.sparklabs.com
Support: https://www.sparklabs.com/support
Twitter: https://twitter.com/sparklabs

ikonst

Posts: 7
Joined: Fri Feb 12, 2016 12:48 pm

Post by ikonst » Sat Feb 13, 2016 6:34 am
Is there any hack we can do in the interim, such as somehow replace kextload with a dummy or anything like that? It's been bogging down quite a few people among the developers.

James

User avatar
Posts: 2313
Joined: Thu Sep 04, 2008 9:27 pm

Post by James » Wed Feb 17, 2016 10:35 am
Hi ikonst,

It'd probably be possible to replace the kexts with dummy ones with no functionality (as long as the permissions are the same), however that's obviously not something we can provide support for.

That said, we here at SparkLabs all use VMWare Fusion to aid with development and testing alongside Viscosity without ever seeing an issue. About the only comment I can make in that regard is that bridged networking (rather than sharing mode) is used on the network adapters for most VMs.

Cheers,
James
Web: https://www.sparklabs.com
Support: https://www.sparklabs.com/support
Twitter: https://twitter.com/sparklabs

ikonst

Posts: 7
Joined: Fri Feb 12, 2016 12:48 pm

Post by ikonst » Wed Feb 17, 2016 7:28 pm
Our issue is simply that vmmon can't load due to running out of character device major numbers -- see my first initial. It has nothing to do with VMWare networking, in fact.

I think developing dummy .kexts is out of scope for our organization, so we'd be waiting for a build of Viscosity which allows the loading of .kexts to be disabled.

ikonst

Posts: 7
Joined: Fri Feb 12, 2016 12:48 pm

Post by ikonst » Sat Mar 05, 2016 2:01 pm
Any news on that?

Even a simple hidden switch will suffice.

James

User avatar
Posts: 2313
Joined: Thu Sep 04, 2008 9:27 pm

Post by James » Mon Mar 07, 2016 5:31 pm
Hi ikonst,

After doing some investigation it's likely we'll wait to fully deprecate the tun driver, rather than add an elevated option to unload it. Feedback regarding the use of utun is thus far positive, but we're still looking into a few instances where fallback to the tun driver was still required. Once this is determined it's likely we'll release an update without the tun driver present.

There does appear to be some misinformation floating around on the Internet regarding to use of major device numbers, Viscosity, and VMWare Fusion. Mac OS X (tested with El Capitan) will allow for the allocation of major device numbers up to an index of 42. An average install of OS X will use up 32. Viscosity's drivers will use up 2. While VMWare Fusion will also use up 2. This should still allow for a headroom for 6 additional major device classes.

On a normal machine Viscosity and VMWare Fusion will both be able to operate without a problem. For VMWare to be having trouble loading it'll mean another third-party kernel extension/s must be using 7+ major device classes. I'd recommend focusing on what this could be, as it seems excessive, and ultimately the cause of the problem.

Cheers,
James
Web: https://www.sparklabs.com
Support: https://www.sparklabs.com/support
Twitter: https://twitter.com/sparklabs

ikonst

Posts: 7
Joined: Fri Feb 12, 2016 12:48 pm

Post by ikonst » Tue Mar 08, 2016 8:03 pm
That's also what I'm seeing, as per:
https://github.com/opensource-apple/xnu ... onf.c#L281

I'm not 100% sure what's been gobbling up char major device numbers on my system, since 'kextstat | grep -v apple' shows only VMware and Viscosity's copy of osxtuntap.

Perhaps something on my system — maybe some peripheral — is causing more of Apple's drivers to load up than on an average system: https://gist.github.com/ikonst/dbbdc507caf89d8f6830

I'll try to compare it with kextstats from other systems to find anomalies.
8 posts Page 1 of 1