search

bewest / decoding-carelink

python serial driver for mm comlink2 protocol
http://bewest.github.io/decoding-carelink
Other
71 stars 52 forks source link

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

Open codebudo opened 8 years ago

codebudo commented 8 years ago

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).