Empty serial port details on OS X 10.11 (El Capitan) Beta 3 #552

otherguy · 2015-07-14T08:53:36Z

Hey,

I just wanted to let you know that on OS X 10.11 (El Capitan, Beta 3), the serial ports can be enumerated correctly, but vendorId, productId, etc. are always empty:

[ { comName: '/dev/cu.Bluetooth-Incoming-Port',
    manufacturer: '',
    serialNumber: '',
    pnpId: '',
    locationId: '',
    vendorId: '',
    productId: '' },
  { comName: '/dev/cu.AlexiPhone-WirelessiAP',
    manufacturer: '',
    serialNumber: '',
    pnpId: '',
    locationId: '',
    vendorId: '',
    productId: '' } ]

Anything I can do to help debug this?

The text was updated successfully, but these errors were encountered:

jacobrosenthal · 2015-07-17T02:29:17Z

Some drivers dont seem make the information available to the same/right place for certain devices. Try a regular ftdi style device which is what we're mainly concerned with atm. See below on Yosemite:

{ comName: '/dev/cu.Bluetooth-Incoming-Port',
  manufacturer: '',
  serialNumber: '',
  pnpId: '',
  locationId: '',
  vendorId: '',
  productId: '' }
{ comName: '/dev/cu.Bluetooth-Modem',
  manufacturer: '',
  serialNumber: '',
  pnpId: '',
  locationId: '',
  vendorId: '',
  productId: '' }
{ comName: '/dev/cu.JCobra-WirelessiAP',
  manufacturer: '',
  serialNumber: '',
  pnpId: '',
  locationId: '',
  vendorId: '',
  productId: '' }
{ comName: '/dev/cu.usbmodem1412',
  manufacturer: 'MBED',
  serialNumber: '1090020354D04E416BB6CFEC',
  pnpId: '',
  locationId: '0x14100000',
  vendorId: '0x0d28',
  productId: '0x0204' }

The requisite code is here if you want to take a look: https://github.com/voodootikigod/node-serialport/blob/master/src/serialport_unix.cpp#L496

otherguy · 2015-07-18T21:10:35Z

I did try with an FTDI device (Particle Photon). That's where I discovered the "bug" at first. When posting this issue, the Photon wasn't plugged in, so the list was incomplete. Here's the list with the Photon plugged in:

[ { comName: '/dev/cu.Bluetooth-Incoming-Port',
    manufacturer: '',
    serialNumber: '',
    pnpId: '',
    locationId: '',
    vendorId: '',
    productId: '' },
  { comName: '/dev/cu.AlexiPhone-WirelessiAP',
    manufacturer: '',
    serialNumber: '',
    pnpId: '',
    locationId: '',
    vendorId: '',
    productId: '' },
  { comName: '/dev/cu.usbmodem1a121000.1,
    manufacturer: '',
    serialNumber: '',
    pnpId: '',
    locationId: '',
    vendorId: '',
    productId: '' } ]

Installed driver is the FTDI VCP driver version 2.3 (which is the most recent).

The only other thing that I noticed is different is the file name of the FTDI device.

jacobrosenthal · 2015-07-18T22:46:05Z

Yosemite resolves my Photon correctly.

{ comName: '/dev/cu.Bluetooth-Incoming-Port',
  manufacturer: '',
  serialNumber: '',
  pnpId: '',
  locationId: '',
  vendorId: '',
  productId: '' }
{ comName: '/dev/cu.Bluetooth-Modem',
  manufacturer: '',
  serialNumber: '',
  pnpId: '',
  locationId: '',
  vendorId: '',
  productId: '' }
{ comName: '/dev/cu.JCobra-WirelessiAP',
  manufacturer: '',
  serialNumber: '',
  pnpId: '',
  locationId: '',
  vendorId: '',
  productId: '' }
{ comName: '/dev/cu.usbmodem1421',
  manufacturer: 'Spark Devices',
  serialNumber: '00000000050C',
  pnpId: '',
  locationId: '0x14200000',
  vendorId: '0x2b04',
  productId: '0xc006' }

otherguy · 2015-07-18T22:51:43Z

Yeah, both my Spark Core and Photon work fine on Yosemite. Since you also have experience with the Photon: the initial setup has you do particle setup which uses this library. Hacking the device name (which, in my case, changed to /dev/cu.usbmodem1a121000.1 from /dev/cu.usbmodemXXXX) into the code directly allows to me to continue the setup of the Photon. This leads me to believe that the communication with the device is fine.

Now it's possible the FTDI driver is broken on El Capitan and just doesn't publish the manufacturer, serial number etc. or this library needs a fix for El Capitan.

In any case, it's not really urgent. There will probably be several more El Capitan betas before the final release and who knows what's going to change.

I just thought I'd let you guys know that there is a possible issue.

jacobrosenthal · 2015-07-18T22:55:33Z

Yeah sure, definitely happy to reopen and track it here as it changes. Are you sure you're using the FTDI VCP drivers. What if you remove them and let the default Apple ftdi plist match?

otherguy · 2015-07-19T10:44:20Z

Ok, so with the Apple driver loaded I get pretty much the same:

 ~  $  kextstat | grep AppleUSBFTDI
  210    0 0xffffff7f830ed000 0x7000     0x7000     com.apple.driver.AppleUSBFTDI (5.0.0) CABF5567-F3DD-346E-943E-D66F4293171D <137 15 5 4 3 1>

[ { comName: '/dev/cu.Bluetooth-Incoming-Port',
    manufacturer: '',
    serialNumber: '',
    pnpId: '',
    locationId: '',
    vendorId: '',
    productId: '' },
  { comName: '/dev/cu.AlexiPhone-WirelessiAP',
    manufacturer: '',
    serialNumber: '',
    pnpId: '',
    locationId: '',
    vendorId: '',
    productId: '' },
  { comName: '/dev/cu.usbmodem1a121000.1',
    manufacturer: '',
    serialNumber: '',
    pnpId: '',
    locationId: '',
    vendorId: '',
    productId: '' } ]

If I unload the Apple driver and load the FTDI driver:

~  $  sudo kextload /System/Library/Extensions/FTDIUSBSerialDriver.kext/
~  $  kextstat | grep AppleUSBFTDI
~  $  kextstat | grep FTDI
  214    0 0xffffff7f830ed000 0x7000     0x7000     com.FTDI.driver.FTDIUSBSerialDriver (2.3) ECC3AF36-431D-370D-86F2-5237785E9CF8 <137 71 5 4 3 1>

[ { comName: '/dev/cu.Bluetooth-Incoming-Port',
    manufacturer: '',
    serialNumber: '',
    pnpId: '',
    locationId: '',
    vendorId: '',
    productId: '' },
  { comName: '/dev/cu.AlexiPhone-WirelessiAP',
    manufacturer: '',
    serialNumber: '',
    pnpId: '',
    locationId: '',
    vendorId: '',
    productId: '' },
  { comName: '/dev/cu.usbmodem1a121000.1',
    manufacturer: '',
    serialNumber: '',
    pnpId: '',
    locationId: '',
    vendorId: '',
    productId: '' } ]

I'm a bit out of my depth here since I have never worked with drivers directly. Besides unloading/loading the kext and replugging the device in between there is nothing else I'd have to do, right?

masto · 2015-07-25T21:48:04Z

I'm seeing this as well with the 10.11 beta (15A226f). It's preventing communication with my X-Carve.

I took a stab at debugging it yesterday but I went into a rathole of trying to get the right dependencies to compile and ended up with a bit of a mental breakdown.

masto · 2015-07-26T19:55:43Z

So the problem here is that IOUSBDevice has turned into IOUSBHostDevice in the IO Registry and the search algorithm in GetUsbDevice() is failing to find the right entries. The data is there, but I'm not sure how to find it.

~ ❯ ioreg -r -n IOUSBHostDevice@1a131000 -c IOUSBDevice
+-o IOUSBHostDevice@1a131000  <class AppleUSBDevice, id 0x100001539, registered, matched, active, busy 0 (34 ms), retain 17>
  | {
  |   "sessionID" = 85798492193864
  |   "iManufacturer" = 1
  |   "bNumConfigurations" = 1
  |   "Built-In" = No
  |   "bcdDevice" = 1
  |   "Bus Power Available" = 500
  |   "idProduct" = 67
  |   "bMaxPacketSize0" = 8
  |   "iProduct" = 2
  |   "iSerialNumber" = 220
  |   "USB Address" = 4
  |   "bDeviceClass" = 2
  |   "locationID" = 437456896
  |   "bDeviceSubClass" = 0
  |   "bcdUSB" = 272
  |   "USB Product Name" = "IOUSBHostDevice"
  |   "non-removable" = "no"
  |   "IOCFPlugInTypes" = {"9dc7b780-9ec0-11d4-a54f-000a27052861"="IOUSBFamily.kext/Contents/PlugIns/IOUSBLib.bundle"}
  |   "IOUserClientClass" = "IOUSBDeviceUserClientV2"
  |   "bDeviceProtocol" = 0
  |   "IOPowerManagement" = {"DevicePowerState"=0,"CurrentPowerState"=3,"CapabilityFlags"=65536,"MaxPowerState"=4,"DriverPowerState"=3}
  |   "Device Speed" = 1
  |   "USB Vendor Name" = "Arduino (www.arduino.cc)"
  |   "idVendor" = 9025
  |   "IOGeneralInterest" = "IOCommand is not serializable"
  |   "USB Serial Number" = "754393239353510191C2"
  |   "IOClassNameOverride" = "IOUSBDevice"
  | }
  | 
  +-o PenCommService  <class IOUSBDeviceUserClientV2, id 0x10000153f, !registered, !matched, active, busy 0, retain 7>
  +-o AppleUSBInterface@0  <class AppleUSBInterface, id 0x100001546, registered, matched, active, busy 0 (16 ms), retain 5>
  +-o AppleUSBInterface@1  <class AppleUSBInterface, id 0x100001548, registered, matched, active, busy 0 (16 ms), retain 5>

~ ❯ ioreg -r -n IOUSBHostDevice@1a131000 -c IOUSBHostDevice
+-o IOUSBHostDevice@1a131000  <class IOUSBHostDevice, id 0x100001537, registered, matched, active, busy 0 (532 ms), retain 22>
  | {
  |   "sessionID" = 85798492193864
  |   "USBSpeed" = 1
  |   "idProduct" = 67
  |   "bDeviceClass" = 2
  |   "IOPowerManagement" = {"PowerOverrideOn"=Yes,"CapabilityFlags"=32768,"MaxPowerState"=2,"DevicePowerState"=2,"ChildrenPowerState"=2,"DriverPowerState"=0,"CurrentPowerState"=2}
  |   "bcdDevice" = 1
  |   "USB Product Name" = "Generic CDC"
  |   "AppleUSBAlternateServiceRegistryID" = 4294972729
  |   "locationID" = 437456896
  |   "kUSBSerialNumberString" = "754393239353510191C2"
  |   "bDeviceSubClass" = 0
  |   "kUSBCurrentConfiguration" = 1
  |   "IOCFPlugInTypes" = {"9dc7b780-9ec0-11d4-a54f-000a27052861"="IOUSBFamily.kext/Contents/PlugIns/IOUSBLib.bundle"}
  |   "bDeviceProtocol" = 0
  |   "USBPortType" = 0
  |   "USB Vendor Name" = "Arduino (www.arduino.cc)"
  |   "idVendor" = 9025
  |   "USB Serial Number" = "754393239353510191C2"
  |   "IOGeneralInterest" = "IOCommand is not serializable"
  |   "kUSBVendorString" = "Arduino (www.arduino.cc)"
  |   "IOClassNameOverride" = "IOUSBDevice"
  | }
  | 
  +-o AppleUSBHostLegacyClient  <class AppleUSBHostLegacyClient, id 0x10000153a, !registered, !matched, active, busy 0, retain 8>
  +-o IOUSBHostInterface@0  <class IOUSBHostInterface, id 0x100001544, registered, matched, active, busy 0 (76 ms), retain 10>
  | +-o AppleUSBACMControl  <class AppleUSBACMControl, id 0x10000154c, registered, matched, active, busy 0 (0 ms), retain 7>
  +-o IOUSBHostInterface@1  <class IOUSBHostInterface, id 0x100001545, registered, matched, active, busy 0 (377 ms), retain 8>
    +-o AppleUSBACMData  <class AppleUSBACMData, id 0x10000154e, registered, matched, active, busy 0 (0 ms), retain 6>
      +-o IOModemSerialStreamSync  <class IOModemSerialStreamSync, id 0x100001550, registered, matched, active, busy 0 (0 ms), retain 6>
        +-o IOSerialBSDClient  <class IOSerialBSDClient, id 0x100001551, registered, matched, active, busy 0 (0 ms), retain 5>

There's no kIOUSBHostDevice, and various stabs I've made at making tiny tweaks to the code have failed to do the right thing. I'm wondering if it might be better to restructure this to start with the serial node and work up the tree from there.

nevernormal1 · 2015-09-28T17:26:05Z

Wondering what the current status of this is? El Capitan is scheduled for release in 2 days.

wingrunr21 · 2015-09-29T02:40:00Z

Apple claims that IOUSBDevice should continue to work in El Capitan (https://developer.apple.com/library/prerelease/mac/releasenotes/Darwin/RN_USB/Articles/10_11Changes.html#//apple_ref/doc/uid/TP40007739-CH3-SW1) so I'm curious what's going on here.

I can confirm this is still an issue on the El Capitan Gold Master though.

dcohen613 · 2015-10-07T21:03:58Z

Confirming that this is an issue after release...

ArekSredzki · 2015-10-07T23:14:06Z

Double confirmed

richlangston007 · 2015-10-09T04:16:01Z

I also have this problem. Why am I always so eager to upgrade?

techninja · 2015-10-09T05:27:06Z

That's why they call it "the bleeding edge"!

And to make my comment be nearly useful, @oskay has done some digging on Pyserial and found some kind of fix in reading twice. evil-mad/wcb-ink#42

Might possibly lead to a better understanding of what it could take to get the right information, or it's a red herring ;) 🐟

helenvholmes · 2015-10-09T15:03:36Z

Yeah, both my Spark Core and Photon work fine on Yosemite. Since you also have experience with the Photon: the initial setup has you do particle setup which uses this library. Hacking the device name (which, in my case, changed to /dev/cu.usbmodem1a121000.1 from /dev/cu.usbmodemXXXX) into the code directly allows to me to continue the setup of the Photon. This leads me to believe that the communication with the device is fine.

@darkwinternight, where exactly did you change the name of your device—in the node-serial package, or in the Particle code? I'd love to be able to work on my core this weekend but this has halted all worked, unfortunately 😢

masto · 2015-10-09T16:37:21Z

Back in July when I was playing with this and wanted to get my milling machine working, I made some local hacks and got it to the "works for me" stage. I remember thinking I needed to do a bunch more work before submitting a pull request, but now it's October and I've forgotten everything about it. So I'm just dropping this here on the off chance it helps somebody: masto/node-serialport@113378b

[edit] Ah, looking at it I see now why it's not production-worthy. I just look for a node where "USB Product Name" = "Generic CDC". That isn't necessarily going to find all serial ports, just the ones I'm interested in.

Probably the whole device matching logic needs to be rewritten to change the assumptions, if it's going to work on both pre-and-post El Capitan.

otherguy · 2015-10-09T20:00:40Z

@helenvholmes inside the node-serial package

xvoland · 2015-10-10T02:40:49Z

Look at this https://www.youtube.com/watch?v=0zuRukW7o0A
I think it's solution.
Disable kext signing:

Reboot and press CMD+R immediately after reboot to enter in Recovery Mode
Open Terminal from Recovery mode
Run the command csrutil enable --without kext
Reboot
Install

noopkat · 2015-10-10T03:59:13Z

@xvoland this is a great find 😄

Sadly this did not resolve the problem for me on El Capitan. Still getting empty port objects when listing. This might solve for unsigned drivers that SIP is blocking and hence the devices not showing up, but this is slightly different - the devices show up but no info about them is being returned.

I can verify that my Arduino IDE still works with an Uno, but not listing correctly in serialport. Does anyone have the same experience as this?

oskay · 2015-10-10T05:37:36Z

We have also confirmed that the issues are independent of SIP.

tmpvar · 2015-10-10T22:21:59Z

I've traced this issue down to IORegistryEntrySearchCFProperty (src/serialport_unix.cpp#L460) which appears to always return nil.

related: https://forums.developer.apple.com/message/19670

Plungestep · 2015-10-11T02:14:57Z

Similar issue here, although I am having a hard time following the content of this thread. I'll just watch.

masto · 2015-10-11T02:35:30Z

If you want to hack around it locally, I think the code I posted earlier should work (maybe you need to change the product name to match your device). I've been using it for several months. IMO there are too many assumptions about the structure of the IO Registry tree in the current code to get a "proper" fix (i.e. one that works for all devices, on all OS versions) by just changing a line or two. If nobody else is particularly excited by that, I may take a stab at it tomorrow.

iyerkm · 2015-10-20T00:00:45Z

I tried pluggin in my intel edison with my mac running el capitan. Cant see the cu.usbserial in /dev
I tried the "disable kext signing" method, but that didnt work.

gramss · 2015-11-25T00:18:01Z

has anyone got a working solution?
this issue is also preventing my mac of getting into sleep mode automatically

jacobrosenthal · 2015-11-25T06:13:07Z

The solution was pulled into master some time ago #607

Just update to latest. If you don't want 2.x.x for some reason, youre going to have to back port that patch.

It appears as though the registry topology has changed in 10.11. In order to fix that, this code assumes nothing about the path, but instead works on the assumption that we can already find the registry entry as soon as the device is enumerated. By increasing the bounds of the search we have a better chance of finding the registry entry that we are looking for refs: serialport/node-serialport#552

otherguy changed the title ~~Problems on OS X 10.11 (El Capitan) Beta 3~~ Empty serial port details on OS X 10.11 (El Capitan) Beta 3 Jul 14, 2015

jacobrosenthal closed this as completed Jul 17, 2015

jacobrosenthal reopened this Jul 18, 2015

jacobrosenthal mentioned this issue Sep 12, 2015

State of nodejs 4.0 support - ie NOT supported until this closed #578

Closed

kennethlimcp mentioned this issue Sep 15, 2015

Serial does not work on El Capitan particle-iot/particle-cli#131

Closed

oskay mentioned this issue Oct 5, 2015

Mac OS X El Capitan: RoboPaint not connecting evil-mad/robopaint#235

Closed

noopkat mentioned this issue Oct 8, 2015

Auto-detecting boards not working on OSX El Capitan noopkat/avrgirl-arduino#17

Closed

tmpvar mentioned this issue Oct 11, 2015

add listing support for el capitan #607

Merged

jacobrosenthal closed this as completed in #607 Oct 13, 2015

brightredchilli mentioned this issue Oct 20, 2015

npm particle-cli failing. particle-iot/particle-cli#119

Closed

lock bot locked as resolved and limited conversation to collaborators May 6, 2018

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Empty serial port details on OS X 10.11 (El Capitan) Beta 3 #552

Empty serial port details on OS X 10.11 (El Capitan) Beta 3 #552

otherguy commented Jul 14, 2015

jacobrosenthal commented Jul 17, 2015

otherguy commented Jul 18, 2015

jacobrosenthal commented Jul 18, 2015

otherguy commented Jul 18, 2015

jacobrosenthal commented Jul 18, 2015

otherguy commented Jul 19, 2015

masto commented Jul 25, 2015

masto commented Jul 26, 2015

nevernormal1 commented Sep 28, 2015

wingrunr21 commented Sep 29, 2015

dcohen613 commented Oct 7, 2015

ArekSredzki commented Oct 7, 2015

richlangston007 commented Oct 9, 2015

techninja commented Oct 9, 2015

helenvholmes commented Oct 9, 2015

masto commented Oct 9, 2015

otherguy commented Oct 9, 2015

xvoland commented Oct 10, 2015

noopkat commented Oct 10, 2015

oskay commented Oct 10, 2015

tmpvar commented Oct 10, 2015

Plungestep commented Oct 11, 2015

masto commented Oct 11, 2015

iyerkm commented Oct 20, 2015

gramss commented Nov 25, 2015

jacobrosenthal commented Nov 25, 2015

Empty serial port details on OS X 10.11 (El Capitan) Beta 3 #552

Empty serial port details on OS X 10.11 (El Capitan) Beta 3 #552

Comments

otherguy commented Jul 14, 2015

jacobrosenthal commented Jul 17, 2015

otherguy commented Jul 18, 2015

jacobrosenthal commented Jul 18, 2015

otherguy commented Jul 18, 2015

jacobrosenthal commented Jul 18, 2015

otherguy commented Jul 19, 2015

masto commented Jul 25, 2015

masto commented Jul 26, 2015

nevernormal1 commented Sep 28, 2015

wingrunr21 commented Sep 29, 2015

dcohen613 commented Oct 7, 2015

ArekSredzki commented Oct 7, 2015

richlangston007 commented Oct 9, 2015

techninja commented Oct 9, 2015

helenvholmes commented Oct 9, 2015

masto commented Oct 9, 2015

otherguy commented Oct 9, 2015

xvoland commented Oct 10, 2015

noopkat commented Oct 10, 2015

oskay commented Oct 10, 2015

tmpvar commented Oct 10, 2015

Plungestep commented Oct 11, 2015

masto commented Oct 11, 2015

iyerkm commented Oct 20, 2015

gramss commented Nov 25, 2015

jacobrosenthal commented Nov 25, 2015