OS X 10.11 (El Capitan), Basilisk II, tuntap, & networking

About BasiliskII, a 68k Mac emulator for Windows, MacOSX, and Linux that can run System 7.x through MacOS 8.1.

Moderators: Cat_7, Ronald P. Regensburg

Post Reply
User avatar
jollyroger
Student Driver
Posts: 14
Joined: Sat Mar 07, 2015 3:21 pm

OS X 10.11 (El Capitan), Basilisk II, tuntap, & networking

Post by jollyroger »

Hi again,

As mentioned previously, I'm currently running MacHTTP in System 7.5.5 in Basilisk II on OS X 10.10 (Yosemite) with tuntaposx on a Mac mini server, and it works very well. It allows me to assign a static IP address to System 7.5.5 in the TCP/IP control panel, so that I can reach the web server easily outside of my LAN.

I'm evaluating whether or not this setup will work correctly in OS X 10.11 El Capitan. I've got El Capitan running in a VMware Fusion virtual machine that I am using for this purpose.

I've installed the latest version of tuntaposx (tuntap_20150118.tar.gz) from here:

https://sourceforge.net/projects/tuntap ... es/tuntap/

I'm using BasiliskII_32bit-etherhelper-SDL.zip from here:

http://www.emaculation.com/forum/viewto ... f=6&t=8067

My Ethernet interface on this machine is using a static IP address I've reserved for the virtual machine. I can SSH into El Capitan on that IP address without issue from other machines on the LAN. So I know networking is functioning correctly in El Capitan in the virtual machine.

I see these messages in the system log during startup, which seem to indicate startup of tuntaposx:

Code: Select all

Dec 14 09:06:20 localhost kernel[0]: tun kernel extension version 20150118 <mattias.nissler@gmx.de>
Dec 14 09:06:21 localhost kernel[0]: 0x1face000, 0x00000000  Intel82574L::setLinkStatus - not active
Dec 14 09:06:21 Administrators-Mac kernel[0]: tap kernel extension version 20150118 <mattias.nissler@gmx.de>
Dec 14 09:06:21 Administrators-Mac kernel[0]: Ethernet [Intel82574L]: Link up on en0, 1-Gigabit, Full-duplex, No flow-control, Debug [796d,ac08,01e1,0200,41e1,7c00]
Dec 14 09:06:21 Administrators-Mac kernel[0]: 0x1face000, 0x0000000a  Intel82574L::setLinkStatus - active
The typical tuntaposx interfaces seem to be missing, though. There is no tap0 interface, nor is there a bridge0 interface like there is on Yosemite. I do see a bridge1 interface, though:

Code: Select all

# ifconfig
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
	options=3<RXCSUM,TXCSUM>
	inet6 ::1 prefixlen 128 
	inet 127.0.0.1 netmask 0xff000000 
	inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1 
	nd6 options=1<PERFORMNUD>
gif0: flags=8010<POINTOPOINT,MULTICAST> mtu 1280
stf0: flags=0<> mtu 1280
en0: flags=8963<UP,BROADCAST,SMART,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500
	options=b<RXCSUM,TXCSUM,VLAN_HWTAGGING>
	ether 00:0c:29:6c:c2:46 
	inet6 fe80::20c:29ff:fe6c:c246%en0 prefixlen 64 scopeid 0x4 
	inet6 2601:1c0:4300:9900:20c:29ff:fe6c:c246 prefixlen 64 autoconf 
	inet6 2601:1c0:4300:9900:b8b1:fbcc:20e0:639e prefixlen 64 autoconf temporary 
	inet 10.0.0.8 netmask 0xffffff00 broadcast 10.0.0.255
	nd6 options=1<PERFORMNUD>
	media: autoselect (1000baseT <full-duplex>)
	status: active
bridge1: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
	options=3<RXCSUM,TXCSUM>
	ether 02:0c:29:c6:6a:01 
	Configuration:
		id 0:0:0:0:0:0 priority 0 hellotime 0 fwddelay 0
		maxage 0 holdcnt 0 proto stp maxaddr 100 timeout 1200
		root id 0:0:0:0:0:0 priority 0 ifcost 0 port 0
		ipfilter disabled flags 0x2
	member: en0 flags=3<LEARNING,DISCOVER>
	        ifmaxaddr 0 port 4 priority 0 path cost 0
	media: autoselect
	status: active
This seems to be the problem. Is anyone else here running tuntaposx in El Capitan?

In case it helps:

In Basilisk II settings, under Serial/Network, I have the Ethernet Interface set to etherhelper/tap0/bridge1/en0. (Note: I tried setting Basilisk II settings > Serial/Network > Ethernet Interface to slirp just as a test, and still cannot connect to any web sites from within Basilisk II. Not sure why that is just yet.)

In System 7.5.5, the AppleTalk and TCP/IP control panels are set correctly for my network.

Basilisk II appears to launch just fine, and Mac OS 7.5.5 boots up normally. Unfortunately, though, apps such as web browsers cannot communicate with anything over the network, and the interface doesn't respond to pings from other machines like it should - regardless of the Basilisk II > Serial/Network setting used (etherhelper/tap0/bridge1/en0 or slirp).

When I launch Basilisk II, I see this in the system log:

Code: Select all

Dec 14 10:08:28 vm launchservicesd[87]: SecTaskLoadEntitlements failed error=22
Dec 14 10:08:28 --- last message repeated 1 time ---
Dec 14 10:08:28 vm BasiliskII[1170]: CPSGetCurrentProcess(): This call is deprecated and should not be called anymore.
Dec 14 10:08:28 vm BasiliskII[1170]: set_foreground_operation_state(): This call is deprecated and should not be called anymore.
Dec 14 10:08:28 vm launchservicesd[87]: SecTaskLoadEntitlements failed error=22
Dec 14 10:08:28 vm kernel[0]: gfx: surf 4ed6e4f: SetIDMode: id=658375918 mode=0x24
Dec 14 10:08:28 vm kernel[0]: gfx: surf 4ed6e4f: clientClose: 
Dec 14 10:08:28 vm appleeventsd[59]: SecTaskLoadEntitlements failed error=22
Dec 14 10:08:28 vm BasiliskII[1170]: WARNING: The Gestalt selector gestaltSystemVersion is returning 10.9.2 instead of 10.11.2. This is not a bug in Gestalt -- it is a documented limitation. Use NSProcessInfo's operatingSystemVersion property to get correct system version number.
	Call location:
Dec 14 10:08:28 vm BasiliskII[1170]: 0   CarbonCore                          0x907c7913 ___Gestalt_SystemVersion_block_invoke + 135
Dec 14 10:08:28 vm BasiliskII[1170]: 1   libdispatch.dylib                   0x92f24763 _dispatch_client_callout + 50
Dec 14 10:08:28 vm BasiliskII[1170]: 2   libdispatch.dylib                   0x92f2463f dispatch_once_f + 78
Dec 14 10:08:28 vm BasiliskII[1170]: 3   libdispatch.dylib                   0x92f25ec9 dispatch_once + 31
Dec 14 10:08:28 vm BasiliskII[1170]: 4   CarbonCore                          0x90743576 _Gestalt_SystemVersion + 1047
Dec 14 10:08:28 vm BasiliskII[1170]: 5   CarbonCore                          0x907426a5 Gestalt + 154
Dec 14 10:08:28 vm BasiliskII[1170]: 6   BasiliskII                          0x781e9f2d SDL_LoadObject + 15197
At this point I am asked to supply administrator credentials, assumedly so that Basilisk II can configure the network interface. Here are the rest of the log entries after that:

Code: Select all

Dec 14 10:08:38 vm authexec[1174]: executing /Applications/Basilisk II/BasiliskII.app/Contents/Resources/etherhelpertool
Dec 14 10:08:38 vm coreaudiod[156]: SecTaskLoadEntitlements failed error=22
Dec 14 10:08:38 vm BasiliskII[1170]: 10:08:38.668 WARNING:  140: This application, or a library it uses, is using the deprecated Carbon Component Manager for hosting Audio Units. Support for this will be removed in a future release. Also, this makes the host incompatible with version 3 audio units. Please transition to the API's in AudioComponent.h.
Dec 14 10:08:43 vm launchservicesd[87]: SecTaskLoadEntitlements failed error=22
As you can see, there are a bunch of SecTaskLoadEntitlements failure messages.

Does anyone else using tuntaposx in El Capitan have any idea what is going wrong with tuntaposx?
User avatar
adespoton
Forum All-Star
Posts: 4226
Joined: Fri Nov 27, 2009 5:11 am
Location: Emaculation.com
Contact:

Re: OS X 10.11 (El Capitan), Basilisk II, tuntap, & networki

Post by adespoton »

The only thing I can think of is that tuntaposx is attempting to run outside the El Cap sandbox. SecTaskLoadEntitlements errors seem to affirm this might be the issue.

Where are your tun/tap components located, and are their permissions set correctly?

More information on the sandbox ("System Integrity Protection") can be found here: https://apple.stackexchange.com/questio ... tan-really
User avatar
jollyroger
Student Driver
Posts: 14
Joined: Sat Mar 07, 2015 3:21 pm

Re: OS X 10.11 (El Capitan), Basilisk II, tuntap, & networki

Post by jollyroger »

According to the tuntap_20150118.pkg installer package, these are the install locations:

/Library/Extensions/tap.kext
/Library/Extensions/tun.kext
/Library/LaunchDaemons/net.sf.tuntaposx.tap.plist
/Library/LaunchDaemons/net.sf.tuntaposx.tun.plist

According to Apple, SIP doesn't restrict access to /Library.

Permissions are:

# ls -l /Library/Extensions/ | grep -E '(tun|tap)'
drwxr-xr-x 3 root wheel 102B Jan 18 2015 tap.kext
drwxr-xr-x 3 root wheel 102B Jan 18 2015 tun.kext

# ls -l /Library/LaunchDaemons/ | grep tuntap
-rw-r--r-- 1 root wheel 527B Jan 18 2015 net.sf.tuntaposx.tap.plist
-rw-r--r-- 1 root wheel 527B Jan 18 2015 net.sf.tuntaposx.tun.plist

The SecTaskLoadEntitlements messages occur during Basilisk II launch, which may point to a problem with the way Basilisk attempts to set up the tuntaposx interface, rather than the tuntaposx installation itself.

Apple says /Applications isn't restricted. So Basilisk II should be okay there.

I recall the first time I attempted to launch Basilisk II, OS X refused stating it was not signed. I bypassed that by right-clicking Basilisk II and choosing Open from the resulting contextual menu.

So I tried disabling SIP by booting into the recovery partition and running csrutil disable.

After doing that and rebooting, Basilisk II was able to set up the interface, and networking worked as expected:

Code: Select all

Dec 14 17:54:58 vm launchservicesd[87]: SecTaskLoadEntitlements failed error=22
Dec 14 17:54:58 --- last message repeated 1 time ---
Dec 14 17:54:58 vm BasiliskII[529]: CPSGetCurrentProcess(): This call is deprecated and should not be called anymore.
Dec 14 17:54:58 vm BasiliskII[529]: set_foreground_operation_state(): This call is deprecated and should not be called anymore.
Dec 14 17:54:58 vm launchservicesd[87]: SecTaskLoadEntitlements failed error=22
Dec 14 17:54:59 vm kernel[0]: gfx: surf 3c1a16f: SetIDMode: id=685863091 mode=0x24
Dec 14 17:54:59 vm kernel[0]: gfx: surf 3c1a16f: clientClose: 
Dec 14 17:54:59 vm appleeventsd[59]: SecTaskLoadEntitlements failed error=22
Dec 14 17:54:59 vm BasiliskII[529]: WARNING: The Gestalt selector gestaltSystemVersion is returning 10.9.2 instead of 10.11.2. This is not a bug in Gestalt -- it is a documented limitation. Use NSProcessInfo's operatingSystemVersion property to get correct system version number.
	Call location:
Dec 14 17:54:59 vm BasiliskII[529]: 0   CarbonCore                          0x907c7913 ___Gestalt_SystemVersion_block_invoke + 135
Dec 14 17:54:59 vm BasiliskII[529]: 1   libdispatch.dylib                   0x92f24763 _dispatch_client_callout + 50
Dec 14 17:54:59 vm BasiliskII[529]: 2   libdispatch.dylib                   0x92f2463f dispatch_once_f + 78
Dec 14 17:54:59 vm BasiliskII[529]: 3   libdispatch.dylib                   0x92f25ec9 dispatch_once + 31
Dec 14 17:54:59 vm BasiliskII[529]: 4   CarbonCore                          0x90743576 _Gestalt_SystemVersion + 1047
Dec 14 17:54:59 vm BasiliskII[529]: 5   CarbonCore                          0x907426a5 Gestalt + 154
Dec 14 17:54:59 vm BasiliskII[529]: 6   BasiliskII                          0x781e9f2d SDL_LoadObject + 15197
Dec 14 17:55:06 --- last message repeated 1 time ---
Dec 14 17:55:06 vm authexec[536]: executing /Applications/Basilisk II/BasiliskII.app/Contents/Resources/etherhelpertool
Dec 14 17:55:06 vm kernel[0]: 0x1face000, 0x00000001  Intel82574L::setPromiscuousMode
Dec 14 17:55:06 vm kernel[0]: en0: promiscuous mode enable succeeded
Dec 14 17:55:06 vm kernel[0]: tap0: promiscuous mode enable succeeded
Dec 14 17:55:06 vm coreaudiod[151]: SecTaskLoadEntitlements failed error=22
Dec 14 17:55:06 vm BasiliskII[529]: 17:55:06.934 WARNING:  140: This application, or a library it uses, is using the deprecated Carbon Component Manager for hosting Audio Units. Support for this will be removed in a future release. Also, this makes the host incompatible with version 3 audio units. Please transition to the API's in AudioComponent.h.
Dec 14 17:55:12 vm launchservicesd[87]: SecTaskLoadEntitlements failed error=22
Dec 14 17:55:12 --- last message repeated 1 time ---
Then I re-enabled SIP and rebooted, and Basilisk II is still able to set up the network interface through tuntaposx! :) So it appears temporarily disabling SIP was all that was needed!

Thanks for the help! :)
Post Reply