Getting devices that have OS drivers via chrome.usb.findDevices

[Jason Kridner]

Is it necessary and sufficient for a Chrome packaged app to use NaCL to gain access to USB devices that already have OS-level drivers across platforms (ChromeOS, Linux, Windows, Mac)?

Background:

Vlad and I are trying to port his BeagleBone Black USB bootloader to be a Chrome app/extension. The original app (non-Chrome) uses libusb and works well on Linux hosts, but still has issues with Mac and Windows hosts. The issues seem to go right down to the libusb level, but seem sufficiently fundamental that platforms like Chrome's API must be looking at them at the system level to resolve them. You can check out my current hacking to try to connect to the target device and Vlad's fork where he'll be trying to add NaCL here:

https://github.com/jadonk/beagleboot

https://github.com/ungureanuvladvictor/beagleboot

My observation is that no devices are ever returned by chrome.usb.getDevices() or chrome.usb.findDevices().

When I run https://github.com/jadonk/beagleboot/tree/c2abbbedce57cd142f74b6f241703bc8660edbc0, I get the following:

BeagleBoot initialized.

BeagleBoot started.

BeagleBoot searching for devices in ROM bootloader mode.

BeagleBoot found no USB devices.

BeagleBoot searching for devices in ROM bootloader mode.

BeagleBoot found no USB devices.

...

I confirm the device does show up in my System Report:

AM335x USB:
Product ID: 0x6141
Vendor ID: 0x0451 (Texas Instruments)
Version: 0.00
Speed: Up to 12 Mb/sec
Manufacturer: Texas Instruments
Location ID: 0xfd110000 / 3
Current Available (mA): 500
Current Required (mA): 100
BSD Name: en4

Any thoughts on claiming this device?

Do I need to be asking in https://groups.google.com/a/chromium.org/forum/#!topic/chromium-apps instead?

Per https://code.google.com/p/chromium/issues/detail?id=148836, is it not possible to claim devices already claimed by the OS? This would be rather sad.

[Mike Frysinger]

yes, if the system has claimed it and associated it with a device, you will not be able to access it via Chrome's USB API.

my guess in this case is it's being associated with the USB serial driver and you're getting a ttyUSB0 device.  that would be accessible via the Chrome Serial API though.  you can check that assumption by installing an app like:

https://chrome.google.com/webstore/detail/beagle-term/gkdofhllgfohlddimiiildbgoggdpoea

if that shows ttyUSB0 under PORT when you launch it while the device is connected, and it doesn't show it while the device is not connected, then that's the issue.

the short answer is that we currently don't have a way of unloading devices from the UI which would free up the device.  fwiw, Windows (and afaik OS X) have the same behavior -- once a USB device is claimed by a driver, libusb doesn't get access to it.

follow up question is, if it's really just a serial device, why do you need to bang on it directly with libusb (he asks knowing nothing about beaglebone boot) ?

-mike

--
--
Chromium OS Developers mailing list: chromiu...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-os-dev?hl=en

[Vlad Ungureanu]

Hello all,

It is not a serial device. The bootloader emulates a network interface over usb *implements RNDIS* and we need to drive it via usb calls. I tried long time ago to send raw IP packets to it but it not work so that is why I ended up using libusb and going directly at the source. My idea is to use https://developer.chrome.com/native-client and ship libusb with the app and everything in one package. Any comments on this ? For win/osx we need a couple of custom drivers anyway so I am not getting my hopes high for that to work out of the box.

[Jason Kridner]

Yeah, this isn't a serial device. I find it very frustrating that
there isn't a solution to recover a device for libusb. I would think
this would be a high priority for libusb developers and people using
that API in their platforms. For this type of device, handling it in a
cross-platform userspace way is the only way we'll ever be able to
scale a solution.

[Mike Frysinger]

so it's a USB networking device ?  then the USB ethernet driver will claim it and you'll get a eth# interface in CrOS just like you would in Linux.  i don't think there's any API currently to configure that directly as all ethernet devices get managed by shill in CrOS.

it's hard to say when i don't have the actual device in question to see what's happening with it.  maybe load up chrome://system, look at the dmesg field, and attach an example log message here to the thread with the device plugged in.  usually when a device is claimed by a driver, kernel messages are generated associated with it.

-mike

[ggg]

On Monday, November 17, 2014 2:46:40 PM UTC-8, Jason Kridner wrote:

Is it necessary and sufficient for a Chrome packaged app to use NaCL to gain access to USB devices that already have OS-level drivers across platforms (ChromeOS, Linux, Windows, Mac)?

... 

AM335x USB:
Product ID: 0x6141
Vendor ID: 0x0451 (Texas Instruments)
Version: 0.00
Speed: Up to 12 Mb/sec
Manufacturer: Texas Instruments
Location ID: 0xfd110000 / 3
Current Available (mA): 500
Current Required (mA): 100
BSD Name: en4

Any thoughts on claiming this device?

Do you control SW running on this device and could maybe pick a device class that isn't automagically claimed by the OS controlling the USB port it's plugged into?

 

Per https://code.google.com/p/chromium/issues/detail?id=148836, is it not possible to claim devices already claimed by the OS? This would be rather sad.

Maybe...but I can imagine a lot of mischief if someone could install an app to took control of USB ethernet (for example) that was primary route for traffic.

The "workaround" would be to blacklist the device driver or port the device is connect to - a manual step in either case that requires admin priveleges. I'm assuming that's feasible from Windows/MacOSX/Linux...but not from ChromeOS (unless it's in dev mode).

cheers,

grant

[Vlad Ungureanu]

On Tuesday, November 18, 2014 4:29:54 AM UTC+1, ggg wrote:

On Monday, November 17, 2014 2:46:40 PM UTC-8, Jason Kridner wrote:

Is it necessary and sufficient for a Chrome packaged app to use NaCL to gain access to USB devices that already have OS-level drivers across platforms (ChromeOS, Linux, Windows, Mac)?

... 

AM335x USB:
Product ID: 0x6141
Vendor ID: 0x0451 (Texas Instruments)
Version: 0.00
Speed: Up to 12 Mb/sec
Manufacturer: Texas Instruments
Location ID: 0xfd110000 / 3
Current Available (mA): 500
Current Required (mA): 100
BSD Name: en4

Any thoughts on claiming this device?

Do you control SW running on this device and could maybe pick a device class that isn't automagically claimed by the OS controlling the USB port it's plugged into?

The bootloader does that and it is written into ROM so no.

 

 

Per https://code.google.com/p/chromium/issues/detail?id=148836, is it not possible to claim devices already claimed by the OS? This would be rather sad.

Maybe...but I can imagine a lot of mischief if someone could install an app to took control of USB ethernet (for example) that was primary route for traffic.

The "workaround" would be to blacklist the device driver or port the device is connect to - a manual step in either case that requires admin priveleges. I'm assuming that's feasible from Windows/MacOSX/Linux...but not from ChromeOS (unless it's in dev mode).

For MacOSX we are looking at a "codeless kext" which is an empty driver that prevents the kernel to take control over the device.

 

cheers,

grant

[Mike Frysinger]

i wonder if we can add a hook to debugd where Chrome would send a signal "please release this device" (identified via bus/device and not vid/pid), and the system would take of detaching it.  i don't think we can just unload the relevant USB driver (since you might have a "real" USB ethernet or serial device connected).  does USB sysfs provide knobs here we can poke to detach ?

-mike

[ggg]

On Monday, November 17, 2014 7:39:27 PM UTC-8, Mike Frysinger wrote:

On Mon, Nov 17, 2014 at 7:29 PM, ggg <grun...@chromium.org> wrote:

... 

The "workaround" would be to blacklist the device driver or port the device is connect to - a manual step in either case that requires admin priveleges. I'm assuming that's feasible from Windows/MacOSX/Linux...but not from ChromeOS (unless it's in dev mode).

i wonder if we can add a hook to debugd where Chrome would send a signal "please release this device" (identified via bus/device and not vid/pid), and the system would take of detaching it.  i don't think we can just unload the relevant USB driver (since you might have a "real" USB ethernet or serial device connected).

 Yes - definitely don't want to just unload arbitrary kernel modules. Referencing by bus/port is ideal since we could then whitelist external facing ports to allow the unbinding.

 does USB sysfs provide knobs here we can poke to detach?

Yes. http://lwn.net/Articles/143397/ : "Manual driver binding and unbinding"

    In order to unbind a device from a driver, simply write the bus id of the device to the unbind file:

        echo -n "1-1:1.0" > /sys/bus/usb/drivers/ub/unbind

cheers,

grant

[Mike Frysinger]

sounds like we have a reasonable path, now "just" to figure out how to plumb it into Chrome w/out violating security boundaries :).  like when the Chrome USB API goes to grab a VID:PID that's in use, it should prompt the user first "Warning: device in use; continue anyways?".

this topic should get moved to a bug now too for tracking.

-mike

[Jason Kridner]

Was a bug ever created and/or closed? Search engine isn't finding it for me.

[Mike Frysinger]

Was a bug ever created and/or closed? Search engine isn't finding it for me.

http://crbug.com/148836

-mike