Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unsigned kext kernel extensions on Mac OS 10.11 (El Capitan) #179

Open
codebudo opened this issue Mar 13, 2016 · 0 comments
Open

Unsigned kext kernel extensions on Mac OS 10.11 (El Capitan) #179

codebudo opened this issue Mar 13, 2016 · 0 comments

Comments

@codebudo
Copy link

codebudo commented Mar 13, 2016

Medtronic hasn't been proactive in getting CareLink to work on Mac OS. I'd like to collect what I've discovered here and suggest a possible fix.

CareLink not identified as a USB device by default and gives this error message in /var/log/system.log:

IOUSBHostDevice@14200000: IOUSBHostDevice::start: device descriptor request completed with 0xe00002e8 and bytesTransferred 0

This appears to be a problem with the CareLink USB stick not being identified as a generic serial device. To fix this, we should be able to add hints to the OS to tell it what type of device we'd like it to be identified as. @bewest has already discovered what these hints are and posted them in issue #21 .

Here's the steps to reproduce:

Add the hints to the serial driver: Open the file /System/Library/Extensions/FTDIUSBSerialDriver.kext/Contents/Info.plist in your favorite text editor (sudo vim /System/Library/Extensions/FTDIUSBSerialDriver.kext/Contents/Info.plist) and add this block of text toward the bottom, leaving the last two closing tag lines in place:

<key>Medtronic</key>
<dict>
  <key>CFBundleIdentifier</key>
  <string>com.FTDI.driver.FTDIUSBSerialDriver</string>
  <key>ConfigData</key>
  <dict>
    <key>PortName</key>
    <string>Carelink</string>
  </dict>
  <key>IOClass</key>
  <string>FTDIUSBSerialDriver</string>
  <key>IOProviderClass</key>
  <string>IOUSBInterface</string>
  <key>bConfigurationValue</key>
  <integer>1</integer>
  <key>bInterfaceNumber</key>
  <integer>0</integer>
  <key>idProduct</key>
  <integer>32769</integer>
  <key>idVendor</key>
  <integer>2593</integer>
</dict>

Reload the USB serial driver as root:

sudo kextunload /System/Library/Extensions/FTDIUSBSerialDriver.kext
sudo kextload /System/Library/Extensions/FTDIUSBSerialDriver.kext

Now we see the source of the trouble in /var/log/system.log

com.apple.kextd[47]: Untrusted kexts are not allowed
com.apple.kextd[47]: ERROR: invalid signature for com.FTDI.driver.FTDIUSBSerialDriver, will not load

We've modified a signed kext. In El Capitan all kexts must be signed regardless of weather they are in /Library/Extensions or /System/Library/Extensions. In previous versions of OS X we could load unsigned kexts in /System/Library/Extensions.

Possible fix: It sees the most supported path forward is to sign a kext with a Apple Developer key. The wrong way forward is to disable the code signing security features. I'd be happy to pay the $99 for the developer license but details on signing kernel modules is slim. It does appear to be possible with other OSS applications. Additionally, if we can get this going Decocare will be ahead of Medtronic in supporting El Capitan.

Side Note: Some have reported success with USB 2 hubs and failure with the USB 3 ports on Macbook Pros. The source of this problem is likely a hardware issue as pointed out by this thread on microchip.com

--- Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/31845392-unsigned-kext-kernel-extensions-on-mac-os-10-11-el-capitan?utm_campaign=plugin&utm_content=tracker%2F522759&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F522759&utm_medium=issues&utm_source=github).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant