[systemd-devel] WebUSB

[Lars Knudsen]

Hi,

I am currently looking into how we can make using WebUSB devices less
painful for users on Linux.

The main purpose of WebUSB (as far as I can see) is to enable certain CDC
(in particular - but not limited to) devices communicate directly with
browsers visiting certain trusted sites (listed inside a binary object
store - sent on initial handshake).

The spec is here: https://wicg.github.io/webusb/ (already running fine in
chrome stable)
Examples:

https://twitter.com/denladeside/status/817451203076427783

I'm guessing the solution will consist of 2 parts:

1. make sure no WebUSB device is picked up by modemmanager (modemmanager
task)

2. make sure that webusb devices will be somehow accessible to be used by a
browser running with user permissions (current temp solution listed here:
adding user to plugdev, adding 0664 permissions to device:
https://developers.google.com/web/updates/2016/03/access-usb-devices-on-the-web
) (udev/systemd task).

For 2. we need to either making all webusb devices accessible or find some
other way the browsers can - in a generic way - gain access. In all cases,
it's important that no USB interfaces has been pre-claimed by the system
(e.g. by cdc_acm) or it should be possible for the browser to throw off the
claims.

thoughts?

br
Lars

[Greg KH]

Hi,
I am currently looking into how we can make using WebUSB devices less painful
for users on Linux.
The main purpose of WebUSB (as far as I can see) is to enable certain CDC (in
particular - but not limited to) devices communicate directly with browsers
visiting certain trusted sites (listed inside a binary object store - sent on
initial handshake).
The spec is here: https://wicg.github.io/webusb/ (already running fine in
chrome stable)
http://youtu.be/Z1Nk2hH2wFE
http://youtu.be/o7wGt9RfHVA
https://twitter.com/denladeside/status/817451203076427783
1. make sure no WebUSB device is picked up by modemmanager (modemmanager task)

Given that webusb can grab any device, how are you going to do that?

2. make sure that webusb devices will be somehow accessible to be used by a
adding user to plugdev, adding 0664 permissions to device: https://
developers.google.com/web/updates/2016/03/access-usb-devices-on-the-web )  
(udev/systemd task).
For 2. we need to either making all webusb devices accessible or find some
other way the browsers can - in a generic way - gain access.  In all cases,
it's important that no USB interfaces has been pre-claimed by the system (e.g.
by cdc_acm) or it should be possible for the browser to throw off the claims.

Userspace can disconnect any device from a driver if it wants to, but
you aren't going to be able to "beat" the kernel at binding to a device
if the driver.

thanks,

greg k-h

[Greg KH]

Web USB can only grab devices which has special Web USB headers. It can not
grab any USB device.
https://wicg.github.io/webusb/#webusb-descriptors

Ah, fun :(

So, we can add a quirk into the kernel cdc-acm driver to never bind to a
device that has the wusb platform capability descriptor, which will
prevent you from having to disconnect the driver from the device (and
the permissions issues involved in that.)

Would that help out?

And just do the same thing in modem manager, never grab a device with
this descriptor, and let the browser/webusb handle the control of the
device if it so desires.

thanks,

greg k-h

[Lars Knudsen]

I have som more input - but really need Reilly's comments on this:

As hardware manufacturers most often want to make it possible for users to
use their hardware in a WebUSB setting as well as in a "normal" app mode,
we will most likely see composite devices that could have the following
interfaces defined:

1. INT IF (for std CDC)
2. BULK CDC (non-webusb - e.g. for normal serial port bindings)
3. WebUSB CDC/bulk

In this case - ideally - the system should be allowed to grab 1 and 2 (but
most probably not modemmanager - as it's very unlikely that a modem will be
a webusb device.. as webusb devices assume internet) but leave 3 untouched
(unclaimed) for WebUSB bulk communication. This means that the udev rules
need to be made on an interface level and not "blanket cover" the whole
device.

Beware that I might not be 100% correct on these assumptions and really
need some input on the intentions from Reilly or others with more knowledge
in the area (let's give California time to wake up :))

br
Lars


On Mon, Jan 9, 2017 at 11:29 AM, Aleksander Morgado <

On Mon, Jan 09, 2017 at 09:40:59AM +0000, Kenneth Rohde Christiansen

Web USB can only grab devices which has special Web USB headers. It can

not

grab any USB device.
https://wicg.github.io/webusb/#webusb-descriptors

Ah, fun :(
So, we can add a quirk into the kernel cdc-acm driver to never bind to a
device that has the wusb platform capability descriptor, which will
prevent you from having to disconnect the driver from the device (and
the permissions issues involved in that.)
Would that help out?
And just do the same thing in modem manager, never grab a device with
this descriptor, and let the browser/webusb handle the control of the
device if it so desires.

Not sure anything would be required in ModemManager if the kernel
already skips the binding to cdc-acm; i.e. ModemManager won't do
anything unless the TTY is exposed.
--
Aleksander
https://aleksander.es

[Greg KH]

Post by Greg KH

Web USB can only grab devices which has special Web USB headers. It can not
grab any USB device.
https://wicg.github.io/webusb/#webusb-descriptors

Ah, fun :(
So, we can add a quirk into the kernel cdc-acm driver to never bind to a
device that has the wusb platform capability descriptor, which will
prevent you from having to disconnect the driver from the device (and
the permissions issues involved in that.)
Would that help out?
And just do the same thing in modem manager, never grab a device with
this descriptor, and let the browser/webusb handle the control of the
device if it so desires.

Not sure anything would be required in ModemManager if the kernel
already skips the binding to cdc-acm; i.e. ModemManager won't do
anything unless the TTY is exposed.

Great, that was easy then!

So, who is going to send in the kernel patch for this? :)

thanks,

greg k-h

[Lars Knudsen]

On Mon, Jan 09, 2017 at 09:40:59AM +0000, Kenneth Rohde Christiansen

Web USB can only grab devices which has special Web USB headers. It

can not

grab any USB device.
https://wicg.github.io/webusb/#webusb-descriptors

Ah, fun :(
So, we can add a quirk into the kernel cdc-acm driver to never bind to

a

device that has the wusb platform capability descriptor, which will
prevent you from having to disconnect the driver from the device (and
the permissions issues involved in that.)
Would that help out?
And just do the same thing in modem manager, never grab a device with
this descriptor, and let the browser/webusb handle the control of the
device if it so desires.

Not sure anything would be required in ModemManager if the kernel
already skips the binding to cdc-acm; i.e. ModemManager won't do
anything unless the TTY is exposed.

Great, that was easy then!
So, who is going to send in the kernel patch for this? :)

To be sure we don't miss anything, let's give the folks in California a
chance to give their input.

In any case, WebUSB looks very cool and looks like a starting point for
finally getting an easy way (a bit like BLE vs Bluetooth) for average users
connecting USB devices in a secure and cross-platform compliant way to the
web.

br
Lars

thanks,
greg k-h

[Lars Knudsen]

It seemed like if just one interface in the description list was somehow
compliant with modem manager, the full device seemed claimed.

I may have missed something in my headers while experimenting. Can you give
an example of a header structure that will not be assumed to be a modem by
MM while still accessible as a proper CDC serial device - without
blacklisting anything?

BR
Lars

Post by Greg KH

Web USB can only grab devices which has special Web USB headers. It can not
grab any USB device.
https://wicg.github.io/webusb/#webusb-descriptors

Ah, fun :(
So, we can add a quirk into the kernel cdc-acm driver to never bind to a
device that has the wusb platform capability descriptor,

I fail to see why a quirk should be necessary. New device classes are
expected to use new class/subclass codes distintly different from
anything handled by existing class drivers.


BjÞrn

[Lars Knudsen]

Post by Lars Knudsen
It seemed like if just one interface in the description list was somehow
compliant with modem manager, the full device seemed claimed.
I may have missed something in my headers while experimenting. Can you

give

Post by Lars Knudsen
an example of a header structure that will not be assumed to be a modem

by

Post by Lars Knudsen
MM while still accessible as a proper CDC serial device - without
blacklisting anything?

I am slowly starting to wonder if the concern is about composite devices
where you want a subset of the functions to be used in one context (MM)
and another subset to be used in another context (WebUSB)? Is this
correct?

Well, ideally, any WebUSB device that exposes a CDC interface (e.g.
configured with [0]CDC INT, [1]CDC BULK and [2]WebUSB CDC/BULK) would:

1) not be considered a modem (it would not make sense to do a modem
including webusb headers - in the same device mode at least)
2) provide standard /dev/ttyUSBx serial functionality on the standard CDC
endpoints (e.g. interface 1 above)
3) provide full user access to the WebUSB CDC/BULK interface (2 above)

What I was asking before is for an example header/configuration descriptors
where MM would *not* pick up the CDC interface but the system still
creating a /dev/ttyUSBx device (or ttyACMx - which it's called when MM is
installed) - without creating blacklisting rules specifically for e.g.
*that* VID/PID combo.
When I was experimenting the last few days - this did not seem possible. I
had to completely wipe any indication of this device being CDC before MM
stopped claiming it. Surely, MM should not pick it up if the device
indicates it doesn't have call functionality?

If so, then I believe you won't be able handle that in a single
configuration. If you mix all functions in a single configuration then
you are correct that MM will take control of the device based on the
functions it (or the kernel) supports.
Split the function subsets in different configurations and make the OS
and/or userspace select the active one if you need to support these
different use cases. Anything else is going to be an endless mess of
workarounds and quirk lists all over the place.
BjÞrn

[Dan Williams]

Post by Lars Knudsen

Post by Lars Knudsen
It seemed like if just one interface in the description list was somehow
compliant with modem manager, the full device seemed claimed.
I may have missed something in my headers while experimenting. Can you

give

Post by Lars Knudsen
an example of a header structure that will not be assumed to be a modem

by

Post by Lars Knudsen
MM while still accessible as a proper CDC serial device - without
blacklisting anything?

I am slowly starting to wonder if the concern is about composite devices
where you want a subset of the functions to be used in one context (MM)
and another subset to be used in another context (WebUSB)?  Is this
correct?

Well, ideally, any WebUSB device that exposes a CDC interface (e.g.
1) not be considered a modem (it would not make sense to do a modem
including webusb headers - in the same device mode at least)
2) provide standard /dev/ttyUSBx serial functionality on the standard CDC
endpoints (e.g. interface 1 above)
3) provide full user access to the WebUSB CDC/BULK interface (2 above)

So I read the spec quickly but clearly not well enough.

Is the separate WebUSB interface parallel to the others in
functionality? eg, it's just another conduit for the same information
as the other interfaces? Or is it some other completely separate
protocol?

Let's take two-tty CDC-ACM, one cdc-ether modem normally controlled
with AT commands, like a Nokia 21M-02. It exposes 8 interfaces; 3 ttys
and one ethernet device:

0 - cdc-acm commc
1 - cdc-acm data
2 - cdc-acm commc
3 - cdc-acm data
4 - cdc-acm commc
5 - cdc-acm data
6 - cdc-ether commc
7 - cdc-ether data

Now if that supported webusb, would you have:

8 - webusb

If that is true, then what is supposed to happen with this modem when
you plug it in? Just because it has a WebUSB descriptor, should it be
automatically "claimed" by a running browser or such, and be
unavailable to the rest of the system? Would all the ttys and ethernet
devs be re-permissioned to the browser user?

Or, could you expand on "it wouldn't make sense" to do a modem with
WebUSB descriptors? Why not?

Post by Lars Knudsen
What I was asking before is for an example header/configuration descriptors
where MM would *not* pick up the CDC interface but the system still
creating a /dev/ttyUSBx device (or ttyACMx - which it's called when MM is
installed) - without creating blacklisting rules specifically for e.g.
*that* VID/PID combo.

It depends. If MM is running and MM has been configured to probe
devices (which can be easily changed with udev rules) then MM will
probe and claim any device that it determines is a modem, including
devices that expose ttys that respond to queries like AT+GCAP
indicating they support WWAN standards. Also including cdc-wdm devices
that speak QMI or MBIM or AT.

So it's certianly possible to configure the scenario you're trying, if
you use udev rules to blacklist devices or if you disable probing
entirely.

If you can write udev rules that detect the presence of a webusb
descriptor, then you can disable MM probing for that device too.

Post by Lars Knudsen
When I was experimenting the last few days - this did not seem
possible.  I
had to completely wipe any indication of this device being CDC before MM
stopped claiming it.  Surely, MM should not pick it up if the device
indicates it doesn't have call functionality?

MM disregards the "call functionality" part because only Nokia and
Ericsson ever actually filled that in. Nobody really cares about
getting the detailed parts of cdc-acm correct, and because there's no
real certification or anything, nobody bothered. So these fields are
essentially useless in the real world.

Same reason some vendors put "0123456789abcdef" into the USB serial
number field for *every single device* of a given VID/PID. You simply
cannot rely on vendors getting descriptors correct.

Dan

Post by Lars Knudsen

If so, then I believe you won't be able handle that in a single
configuration.  If you mix all functions in a single configuration
then
you are correct that MM will take control of the device based on the
functions it (or the kernel) supports.
Split the function subsets in different configurations and make the OS
and/or userspace select the active one if you need to support these
different use cases.  Anything else is going to be an endless mess
of
workarounds and quirk lists all over the place.
Bjørn

_______________________________________________
systemd-devel mailing list
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[Lars Knudsen]

For all practical reasons and looking ahead, I truly believe that there
will be no reason to have a WebUSB header in any of the few coming modem
devices (what are the stats on new USB CDC modems for these years in
general? - still enough to justify a "blanket claim as modem"?) as having a
functioning/practical webusb header requires an existing internet
connection letting you access the hardware from a trusted URL.

In any case - even if some few would decide to try the combo - the far
majority would not and the same logic (the user can just make a udev
rule...Not sure how to explain my wife how ;)) to whitelist those would be
the logical approach.

Even if it is decided that MM should still try to claim the CDC interface
(which I think would be very wrong as a default in this case), the
remaining WebUSB, custom class (yet CDC style), Bulk interface should be
left untouched and available to user space browsers.

Btw on the Mac, they seem to have fixed it nicely by creating two logical
tty devices and not claiming anything before the user tries to access
either the modem one or pure data one (same physical interface - different
protocol "on demand").

Post by Dan Williams

Post by Lars Knudsen

Post by Lars Knudsen
It seemed like if just one interface in the description list was somehow
compliant with modem manager, the full device seemed claimed.
I may have missed something in my headers while experimenting. Can you

give

Post by Lars Knudsen
an example of a header structure that will not be assumed to be a modem

by

Post by Lars Knudsen
MM while still accessible as a proper CDC serial device - without
blacklisting anything?

I am slowly starting to wonder if the concern is about composite devices
where you want a subset of the functions to be used in one context (MM)
and another subset to be used in another context (WebUSB)? Is this
correct?

Well, ideally, any WebUSB device that exposes a CDC interface (e.g.
1) not be considered a modem (it would not make sense to do a modem
including webusb headers - in the same device mode at least)
2) provide standard /dev/ttyUSBx serial functionality on the standard CDC
endpoints (e.g. interface 1 above)
3) provide full user access to the WebUSB CDC/BULK interface (2 above)

So I read the spec quickly but clearly not well enough.
Is the separate WebUSB interface parallel to the others in
functionality? eg, it's just another conduit for the same information
as the other interfaces? Or is it some other completely separate
protocol?
Let's take two-tty CDC-ACM, one cdc-ether modem normally controlled
with AT commands, like a Nokia 21M-02. It exposes 8 interfaces; 3 ttys
0 - cdc-acm commc
1 - cdc-acm data
2 - cdc-acm commc
3 - cdc-acm data
4 - cdc-acm commc
5 - cdc-acm data
6 - cdc-ether commc
7 - cdc-ether data
8 - webusb
If that is true, then what is supposed to happen with this modem when
you plug it in? Just because it has a WebUSB descriptor, should it be
automatically "claimed" by a running browser or such, and be
unavailable to the rest of the system? Would all the ttys and ethernet
devs be re-permissioned to the browser user?
Or, could you expand on "it wouldn't make sense" to do a modem with
WebUSB descriptors? Why not?

Post by Lars Knudsen
What I was asking before is for an example header/configuration descriptors
where MM would *not* pick up the CDC interface but the system still
creating a /dev/ttyUSBx device (or ttyACMx - which it's called when MM is
installed) - without creating blacklisting rules specifically for e.g.
*that* VID/PID combo.

It depends. If MM is running and MM has been configured to probe
devices (which can be easily changed with udev rules) then MM will
probe and claim any device that it determines is a modem, including
devices that expose ttys that respond to queries like AT+GCAP
indicating they support WWAN standards. Also including cdc-wdm devices
that speak QMI or MBIM or AT.
So it's certianly possible to configure the scenario you're trying, if
you use udev rules to blacklist devices or if you disable probing
entirely.
If you can write udev rules that detect the presence of a webusb
descriptor, then you can disable MM probing for that device too.

Post by Lars Knudsen
When I was experimenting the last few days - this did not seem possible. I
had to completely wipe any indication of this device being CDC before MM
stopped claiming it. Surely, MM should not pick it up if the device
indicates it doesn't have call functionality?

MM disregards the "call functionality" part because only Nokia and
Ericsson ever actually filled that in. Nobody really cares about
getting the detailed parts of cdc-acm correct, and because there's no
real certification or anything, nobody bothered. So these fields are
essentially useless in the real world.
Same reason some vendors put "0123456789abcdef" into the USB serial
number field for *every single device* of a given VID/PID. You simply
cannot rely on vendors getting descriptors correct.
Dan

Post by Lars Knudsen

If so, then I believe you won't be able handle that in a single
configuration. If you mix all functions in a single configuration then
you are correct that MM will take control of the device based on the
functions it (or the kernel) supports.
Split the function subsets in different configurations and make the OS
and/or userspace select the active one if you need to support these
different use cases. Anything else is going to be an endless mess of
workarounds and quirk lists all over the place.
BjÞrn

_______________________________________________
systemd-devel mailing list
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[Dan Williams]

Post by Lars Knudsen
For all practical reasons and looking ahead, I truly believe that there
will be no reason to have a WebUSB header in any of the few coming modem
devices (what are the stats on new USB CDC modems for these years in
general? - still enough to justify a "blanket claim as modem"?) as having a
functioning/practical webusb header requires an existing internet
connection letting you access the hardware from a trusted URL.

Ok... I'm clearly not putting together the pieces here.

When I read the spec at wicg.github.io, it's a bit light on actual use-
cases. I get that; it's a protocol spec. But having some context
would be useful.

Would any device type be a candidate for webusb?

Can you describe in a bit more detail how the WebUSB descriptors get
used by a UA?

Do they get exposed to the web app running in the UA?

What do the URLs get used for and could you give me some examples? eg,
somebody writes a node.js library, hosts it at http://www.foobar.com/ca
meracontrol and only that URL is allowed to access a USB-connected
camera?

Post by Lars Knudsen
In any case - even if some few would decide to try the combo - the far
majority would not and the same logic (the user can just make a udev
rule...Not sure how to explain my wife how ;)) to whitelist those would be
the logical approach.
Even if it is decided that MM should still try to claim the CDC interface
(which I think would be very wrong as a default in this case), the
remaining WebUSB, custom class (yet CDC style), Bulk interface should be
left untouched and available to user space browsers.
Btw on the Mac, they seem to have fixed it nicely by creating two logical
tty devices and not claiming anything before the user tries to access
either the modem one or pure data one (same physical interface - different
protocol "on demand").

Can you describe this a bit more? I'm not completely clear on what
this looks like. Typically a 'tty' would only be used for AT-style
communication, since most modems these days don't use PPP-over-tty.

At least in the Mac/Windows world you typically install drivers and a
connection manager on first-plug and then, of course, you know from
then on that it's a modem or WiFi dongle or camera or whatever. So
it's easy to not touch the device after that.

But on Linux, you typically don't do this for various reasons, so tools
like MM have to probe the device to find out it's a modem first, and
that clearly involves touching it.

But after the probing process, MM stops talking to the modem and does
nothing else until the user (or the desktop environment configuration)
tells MM to do something.

Dan

Post by Lars Knudsen

Post by Dan Williams

Post by Lars Knudsen

Post by Lars Knudsen
It seemed like if just one interface in the description list
was
somehow
compliant with modem manager, the full device seemed claimed.
I may have missed something in my headers while
experimenting.
Can you

give

Post by Lars Knudsen
an example of a header structure that will not be assumed to
be a
modem

by

Post by Lars Knudsen
MM while still accessible as a proper CDC serial device - without
blacklisting anything?

I am slowly starting to wonder if the concern is about
composite
devices
where you want a subset of the functions to be used in one
context
(MM)
and another subset to be used in another context (WebUSB)?  Is this
correct?

Well, ideally, any WebUSB device that exposes a CDC interface (e.g.
1) not be considered a modem (it would not make sense to do a modem
including webusb headers - in the same device mode at least)
2) provide standard /dev/ttyUSBx serial functionality on the
standard
CDC
endpoints (e.g. interface 1 above)
3) provide full user access to the WebUSB CDC/BULK interface (2 above)

So I read the spec quickly but clearly not well enough.
Is the separate WebUSB interface parallel to the others in
functionality?  eg, it's just another conduit for the same
information
as the other interfaces?  Or is it some other completely separate
protocol?
Let's take two-tty CDC-ACM, one cdc-ether modem normally controlled
with AT commands, like a Nokia 21M-02.  It exposes 8 interfaces; 3
ttys
0 - cdc-acm commc
1 - cdc-acm data
2 - cdc-acm commc
3 - cdc-acm data
4 - cdc-acm commc
5 - cdc-acm data
6 - cdc-ether commc
7 - cdc-ether data
8 - webusb
If that is true, then what is supposed to happen with this modem when
you plug it in?  Just because it has a WebUSB descriptor, should it
be
automatically "claimed" by a running browser or such, and be
unavailable to the rest of the system?  Would all the ttys and
ethernet
devs be re-permissioned to the browser user?
Or, could you expand on "it wouldn't make sense" to do a modem with
WebUSB descriptors?  Why not?

Post by Lars Knudsen
What I was asking before is for an example header/configuration descriptors
where MM would *not* pick up the CDC interface but the system still
creating a /dev/ttyUSBx device (or ttyACMx - which it's called
when
MM is
installed) - without creating blacklisting rules specifically for e.g.
*that* VID/PID combo.

It depends. If MM is running and MM has been configured to probe
devices (which can be easily changed with udev rules) then MM will
probe and claim any device that it determines is a modem, including
devices that expose ttys that respond to queries like AT+GCAP
indicating they support WWAN standards.  Also including cdc-wdm
devices
that speak QMI or MBIM or AT.
So it's certianly possible to configure the scenario you're trying, if
you use udev rules to blacklist devices or if you disable probing
entirely.
If you can write udev rules that detect the presence of a webusb
descriptor, then you can disable MM probing for that device too.

Post by Lars Knudsen
When I was experimenting the last few days - this did not seem
possible.  I
had to completely wipe any indication of this device being CDC
before
MM
stopped claiming it.  Surely, MM should not pick it up if the device
indicates it doesn't have call functionality?

MM disregards the "call functionality" part because only Nokia and
Ericsson ever actually filled that in.  Nobody really cares about
getting the detailed parts of cdc-acm correct, and because there's no
real certification or anything, nobody bothered.  So these fields
are
essentially useless in the real world.
Same reason some vendors put "0123456789abcdef" into the USB serial
number field for *every single device* of a given VID/PID.  You
simply
cannot rely on vendors getting descriptors correct.
Dan

Post by Lars Knudsen

If so, then I believe you won't be able handle that in a single
configuration.  If you mix all functions in a single
configuration
then
you are correct that MM will take control of the device based
on
the
functions it (or the kernel) supports.
Split the function subsets in different configurations and make
the
OS
and/or userspace select the active one if you need to support these
different use cases.  Anything else is going to be an endless mess
of
workarounds and quirk lists all over the place.
Bjørn

_______________________________________________
systemd-devel mailing list
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[Lars Knudsen]

Post by Lars Knudsen

Post by Lars Knudsen
1) not be considered a modem (it would not make sense to do a modem
including webusb headers - in the same device mode at least)
2) provide standard /dev/ttyUSBx serial functionality on the standard CDC
endpoints (e.g. interface 1 above)
3) provide full user access to the WebUSB CDC/BULK interface (2 above)
What I was asking before is for an example header/configuration

descriptors

Post by Lars Knudsen
where MM would *not* pick up the CDC interface but the system still
creating a /dev/ttyUSBx device (or ttyACMx - which it's called when MM is
installed) - without creating blacklisting rules specifically for e.g.
*that* VID/PID combo.
When I was experimenting the last few days - this did not seem

possible. I

Post by Lars Knudsen
had to completely wipe any indication of this device being CDC before MM
stopped claiming it. Surely, MM should not pick it up if the device
indicates it doesn't have call functionality?

This is hard to decipher.
I tend to interprete "a CDC interface" as a "Communications Class
Interface" as defined by "Universal Serial Bus Class Definitions for
Communications Devices". But this makes no sense in the context you are
using it, so I guess I am misunderstanding?
I don't think any current kernel driver will create /dev/ttyUSBx devices
for any type of CDC function, so that makes no sense either.
/dev/ttyACMx devices are created by the CDC ACM driver, and has nothing
to do with MM being installed or not.

Thanks for clearing that upi - I was wondering why on some devices we have
without MM, the USB serial devices are called /dev/ttyUSBx until MM is
installed (but maybe it pulls cdc_acm?)

Post by Lars Knudsen
In short: I don't understand anything of the above. I believe the
requested descriptor samples would clear up some of this. As would some
references to the CDC spec if you are going to continue using parts of
if to describe the device.

Ok - one example would be taking e.g. the USBCDC descriptors from mbed:

https://developer.mbed.org/users/mbed_official/code/USBDevice/file/4f589e246b9e/USBSerial/USBCDC.cpp

and adding a bulk WebUSB interface or the ones from Zephyr/Intel:

https://github.com/nagineni/zephyr-webusb/blob/master/samples/usb/webusb/src/webusb_serial.c

(where the webusb interface is added)

I'd like if we by default:

1. assume it's not a modem (I still can't think of any practical examples
where WebUSB descriptors [that requires online] would be added in a modem
[to get online?]) - this would be
2. could have user space access to the endpoints (at least the WebUSB
endpoints - the desired behavior could probably be to have the system
create a serial device on the CDC port andlet the firmware tie the two up
functionality wise, Reilly?) - this is probably udev/systemd

does this make more sense?

br
Lars

Post by Lars Knudsen
BjÞrn

[Greg KH]

Post by Lars Knudsen

Post by Greg KH

Web USB can only grab devices which has special Web USB headers. It can not
grab any USB device.
https://wicg.github.io/webusb/#webusb-descriptors

Ah, fun :(
So, we can add a quirk into the kernel cdc-acm driver to never bind to a
device that has the wusb platform capability descriptor,

I fail to see why a quirk should be necessary. New device classes are
expected to use new class/subclass codes distintly different from
anything handled by existing class drivers.

One would hope, but it seems like they want to piggy-back on the cdc-acm
spec. But I could be totally wrong here, does anyone have the actual
descriptor dump of a device anywhere?

thanks,

greg k-h

[Lars Knudsen]

I finally managed to make a configuration that *seems* to work and I
realize that I may have had something else blocking the WebUSB interface
(2) while modemmanager was communicating with the CDC_ACM interface (1).

I made a clean arbitrary VID/PID and get what seems to be a functioning
WebUSB (now) while modemmanager sends "AT...AT..." to the CDC interface -
so while I thought the modemmanager grabbed my WebUSB interface part, it
must have been because of a faulty combination on my side - my apologies.
WebUSB actually *does* seem to give immediate "bulk" access to a device
otherwise claimed by modemmanager - a very nice option to have and sorry
for the confusion I had that modemmanager grabbed more interfaces than it
should have.

Still, the original request still stands and please tell me if it's a
viable path:

1. If a device has a WebUSB descriptor, it's most probably *not* a modem -
and should in stead be considered a device that in this rare case needs to
be whitelisted (as modem), while defaulting to not being it. This is to
ease the usage from non-browsers to the same hardware, which can then
happen immediately and not be required to fail and wait over the
modemmanager probing period (30 sec?) - related to modemmanager
2. If a device has a WebUSB descriptor, at least the interface linked to
WebUSB should be made accessible in user land by default so no average user
has to figure out how to do udev rules - related to udev/systemd

my headers that seem to work now for the case above:

Bus 002 Device 089: ID 1209:d010 InterBiometrics
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.10
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
idVendor 0x1209 InterBiometrics
idProduct 0xd010
bcdDevice 0.01
iManufacturer 1 empriKit
iProduct 2 empriKit|MOTION
iSerial 3 00.01
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 90
bNumInterfaces 3
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xc0
Self Powered
MaxPower 100mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 2 Communications
bInterfaceSubClass 2 Abstract (modem)
bInterfaceProtocol 1 AT-commands (v.25ter)
iInterface 0
CDC Header:
bcdCDC 1.10
CDC Call Management:
bmCapabilities 0x03
call management
use DataInterface
bDataInterface 1
CDC ACM:
bmCapabilities 0x02
line coding and serial state
CDC Union:
bMasterInterface 0
bSlaveInterface 1
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0010 1x 16 bytes
bInterval 16
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 10 CDC Data
bInterfaceSubClass 0 Unused
bInterfaceProtocol 0
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x82 EP 2 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02 EP 2 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 2
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 0
bInterfaceProtocol 0
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x85 EP 5 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x05 EP 5 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
Binary Object Store Descriptor:
bLength 5
bDescriptorType 15
wTotalLength 29
bNumDeviceCaps 1
** UNRECOGNIZED: 18 10 05 00 38 b6 08 34 a9 09 a0 47 8b fd a0 76 88 15
b6 65 00 01 57 02
Device Status: 0x0001
Self Powered

Post by Greg KH

On Mon, Jan 09, 2017 at 09:40:59AM +0000, Kenneth Rohde Christiansen

Web USB can only grab devices which has special Web USB headers. It

can not

grab any USB device.
https://wicg.github.io/webusb/#webusb-descriptors

Ah, fun :(
So, we can add a quirk into the kernel cdc-acm driver to never bind to

a

device that has the wusb platform capability descriptor,

I fail to see why a quirk should be necessary. New device classes are
expected to use new class/subclass codes distintly different from
anything handled by existing class drivers.

One would hope, but it seems like they want to piggy-back on the cdc-acm
spec. But I could be totally wrong here, does anyone have the actual
descriptor dump of a device anywhere?

We don't want to piggy-back on the CDC-ACM spec. A WebUSB device should
always have its interfaces marked vendor-specific. Below is an example of a
device which implements both a CDC-ACM interface and a WebUSB interface. As
far as I've noticed ModemManager has not interfered with the browser
accessing this device but Lars has observed this behavior. What I have had
to do, however, is add a udev rule which sets ownership on the devnode so
that the browser can access it as an unprivileged user-space application.
What would be nice to have from systemd-udevd is a way to write a rule that
will detect the presence of WebUSB descriptors (which is a BOS capability
descriptor) and set ownership accordingly.
Bus 002 Device 040: ID 2341:8037 Arduino SA
bLength 18
bDescriptorType 1
bcdUSB 2.10
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
idVendor 0x2341 Arduino SA
idProduct 0x8037
bcdDevice 1.00
iManufacturer 1 Arduino LLC
iProduct 2 Arduino Micro
iSerial 3 WUARTR
bNumConfigurations 1
bLength 9
bDescriptorType 2
wTotalLength 98
bNumInterfaces 3
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xa0
(Bus Powered)
Remote Wakeup
MaxPower 500mA
bLength 8
bDescriptorType 11
bFirstInterface 0
bInterfaceCount 2
bFunctionClass 2 Communications
bFunctionSubClass 2 Abstract (modem)
bFunctionProtocol 1 AT-commands (v.25ter)
iFunction 0
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 2 Communications
bInterfaceSubClass 2 Abstract (modem)
bInterfaceProtocol 0 None
iInterface 0
bcdCDC 1.10
bmCapabilities 0x01
call management
bDataInterface 1
bmCapabilities 0x06
sends break
line coding and serial state
bMasterInterface 0
bSlaveInterface 1
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0010 1x 16 bytes
bInterval 64
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 10 CDC Data
bInterfaceSubClass 0 Unused
bInterfaceProtocol 0
iInterface 0
bLength 7
bDescriptorType 5
bEndpointAddress 0x02 EP 2 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
bLength 9
bDescriptorType 4
bInterfaceNumber 2
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 0
bInterfaceProtocol 0
iInterface 0
bLength 7
bDescriptorType 5
bEndpointAddress 0x04 EP 4 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
bLength 7
bDescriptorType 5
bEndpointAddress 0x85 EP 5 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
bLength 5
bDescriptorType 15
wTotalLength 57
bNumDeviceCaps 2
FIXME: alloc bigger buffer for device capability descriptors
Device Status: 0x0000
(Bus Powered)

[Lars Knudsen]

A small update: When the modemmanager finishes probing (~16 secs after
connection) data seems to stop flowing in from the WebUSB bulk endpoint
also. It is, however, possible to reconnect and get data again - so I need
to see if there should be anything in the mbed firmware causing that
behavior or there is some sort of silent reset of interfaces/endpoints
happening on the linux side when probing is done.

Post by Lars Knudsen
I finally managed to make a configuration that *seems* to work and I
realize that I may have had something else blocking the WebUSB interface
(2) while modemmanager was communicating with the CDC_ACM interface (1).
I made a clean arbitrary VID/PID and get what seems to be a functioning
WebUSB (now) while modemmanager sends "AT...AT..." to the CDC interface -
so while I thought the modemmanager grabbed my WebUSB interface part, it
must have been because of a faulty combination on my side - my apologies.
WebUSB actually *does* seem to give immediate "bulk" access to a device
otherwise claimed by modemmanager - a very nice option to have and sorry
for the confusion I had that modemmanager grabbed more interfaces than it
should have.
Still, the original request still stands and please tell me if it's a
1. If a device has a WebUSB descriptor, it's most probably *not* a modem
- and should in stead be considered a device that in this rare case needs
to be whitelisted (as modem), while defaulting to not being it. This is to
ease the usage from non-browsers to the same hardware, which can then
happen immediately and not be required to fail and wait over the
modemmanager probing period (30 sec?) - related to modemmanager
2. If a device has a WebUSB descriptor, at least the interface linked to
WebUSB should be made accessible in user land by default so no average user
has to figure out how to do udev rules - related to udev/systemd
Bus 002 Device 089: ID 1209:d010 InterBiometrics
bLength 18
bDescriptorType 1
bcdUSB 2.10
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
idVendor 0x1209 InterBiometrics
idProduct 0xd010
bcdDevice 0.01
iManufacturer 1 empriKit
iProduct 2 empriKit|MOTION
iSerial 3 00.01
bNumConfigurations 1
bLength 9
bDescriptorType 2
wTotalLength 90
bNumInterfaces 3
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xc0
Self Powered
MaxPower 100mA
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 2 Communications
bInterfaceSubClass 2 Abstract (modem)
bInterfaceProtocol 1 AT-commands (v.25ter)
iInterface 0
bcdCDC 1.10
bmCapabilities 0x03
call management
use DataInterface
bDataInterface 1
bmCapabilities 0x02
line coding and serial state
bMasterInterface 0
bSlaveInterface 1
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0010 1x 16 bytes
bInterval 16
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 10 CDC Data
bInterfaceSubClass 0 Unused
bInterfaceProtocol 0
iInterface 0
bLength 7
bDescriptorType 5
bEndpointAddress 0x82 EP 2 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
bLength 7
bDescriptorType 5
bEndpointAddress 0x02 EP 2 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
bLength 9
bDescriptorType 4
bInterfaceNumber 2
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 0
bInterfaceProtocol 0
iInterface 0
bLength 7
bDescriptorType 5
bEndpointAddress 0x85 EP 5 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
bLength 7
bDescriptorType 5
bEndpointAddress 0x05 EP 5 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
bLength 5
bDescriptorType 15
wTotalLength 29
bNumDeviceCaps 1
** UNRECOGNIZED: 18 10 05 00 38 b6 08 34 a9 09 a0 47 8b fd a0 76 88 15
b6 65 00 01 57 02
Device Status: 0x0001
Self Powered

Post by Greg KH

On Mon, Jan 09, 2017 at 09:40:59AM +0000, Kenneth Rohde Christiansen

Web USB can only grab devices which has special Web USB headers. It

can not

grab any USB device.
https://wicg.github.io/webusb/#webusb-descriptors

Ah, fun :(
So, we can add a quirk into the kernel cdc-acm driver to never bind

to a

device that has the wusb platform capability descriptor,

I fail to see why a quirk should be necessary. New device classes are
expected to use new class/subclass codes distintly different from
anything handled by existing class drivers.

One would hope, but it seems like they want to piggy-back on the cdc-acm
spec. But I could be totally wrong here, does anyone have the actual
descriptor dump of a device anywhere?

We don't want to piggy-back on the CDC-ACM spec. A WebUSB device should
always have its interfaces marked vendor-specific. Below is an example of a
device which implements both a CDC-ACM interface and a WebUSB interface. As
far as I've noticed ModemManager has not interfered with the browser
accessing this device but Lars has observed this behavior. What I have had
to do, however, is add a udev rule which sets ownership on the devnode so
that the browser can access it as an unprivileged user-space application.
What would be nice to have from systemd-udevd is a way to write a rule that
will detect the presence of WebUSB descriptors (which is a BOS capability
descriptor) and set ownership accordingly.
Bus 002 Device 040: ID 2341:8037 Arduino SA
bLength 18
bDescriptorType 1
bcdUSB 2.10
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
idVendor 0x2341 Arduino SA
idProduct 0x8037
bcdDevice 1.00
iManufacturer 1 Arduino LLC
iProduct 2 Arduino Micro
iSerial 3 WUARTR
bNumConfigurations 1
bLength 9
bDescriptorType 2
wTotalLength 98
bNumInterfaces 3
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xa0
(Bus Powered)
Remote Wakeup
MaxPower 500mA
bLength 8
bDescriptorType 11
bFirstInterface 0
bInterfaceCount 2
bFunctionClass 2 Communications
bFunctionSubClass 2 Abstract (modem)
bFunctionProtocol 1 AT-commands (v.25ter)
iFunction 0
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 2 Communications
bInterfaceSubClass 2 Abstract (modem)
bInterfaceProtocol 0 None
iInterface 0
bcdCDC 1.10
bmCapabilities 0x01
call management
bDataInterface 1
bmCapabilities 0x06
sends break
line coding and serial state
bMasterInterface 0
bSlaveInterface 1
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0010 1x 16 bytes
bInterval 64
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 10 CDC Data
bInterfaceSubClass 0 Unused
bInterfaceProtocol 0
iInterface 0
bLength 7
bDescriptorType 5
bEndpointAddress 0x02 EP 2 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
bLength 9
bDescriptorType 4
bInterfaceNumber 2
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 0
bInterfaceProtocol 0
iInterface 0
bLength 7
bDescriptorType 5
bEndpointAddress 0x04 EP 4 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
bLength 7
bDescriptorType 5
bEndpointAddress 0x85 EP 5 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
bLength 5
bDescriptorType 15
wTotalLength 57
bNumDeviceCaps 2
FIXME: alloc bigger buffer for device capability descriptors
Device Status: 0x0000
(Bus Powered)

[Lars Knudsen]

Post by Lars Knudsen
A small update: When the modemmanager finishes probing (~16 secs after
connection) data seems to stop flowing in from the WebUSB bulk endpoint
also. It is, however, possible to reconnect and get data again - so I need
to see if there should be anything in the mbed firmware causing that
behavior or there is some sort of silent reset of interfaces/endpoints
happening on the linux side when probing is done.

Had to separate the CDC and WebUSB serial control signals completely in the
firmware driver. - now survives

Post by Lars Knudsen

Post by Lars Knudsen
I finally managed to make a configuration that *seems* to work and I
realize that I may have had something else blocking the WebUSB interface
(2) while modemmanager was communicating with the CDC_ACM interface (1).
I made a clean arbitrary VID/PID and get what seems to be a functioning
WebUSB (now) while modemmanager sends "AT...AT..." to the CDC interface -
so while I thought the modemmanager grabbed my WebUSB interface part, it
must have been because of a faulty combination on my side - my apologies.
WebUSB actually *does* seem to give immediate "bulk" access to a device
otherwise claimed by modemmanager - a very nice option to have and sorry
for the confusion I had that modemmanager grabbed more interfaces than it
should have.
Still, the original request still stands and please tell me if it's a
1. If a device has a WebUSB descriptor, it's most probably *not* a modem
- and should in stead be considered a device that in this rare case needs
to be whitelisted (as modem), while defaulting to not being it. This is to
ease the usage from non-browsers to the same hardware, which can then
happen immediately and not be required to fail and wait over the
modemmanager probing period (30 sec?) - related to modemmanager
2. If a device has a WebUSB descriptor, at least the interface linked to
WebUSB should be made accessible in user land by default so no average user
has to figure out how to do udev rules - related to udev/systemd
Bus 002 Device 089: ID 1209:d010 InterBiometrics
bLength 18
bDescriptorType 1
bcdUSB 2.10
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
idVendor 0x1209 InterBiometrics
idProduct 0xd010
bcdDevice 0.01
iManufacturer 1 empriKit
iProduct 2 empriKit|MOTION
iSerial 3 00.01
bNumConfigurations 1
bLength 9
bDescriptorType 2
wTotalLength 90
bNumInterfaces 3
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xc0
Self Powered
MaxPower 100mA
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 2 Communications
bInterfaceSubClass 2 Abstract (modem)
bInterfaceProtocol 1 AT-commands (v.25ter)
iInterface 0
bcdCDC 1.10
bmCapabilities 0x03
call management
use DataInterface
bDataInterface 1
bmCapabilities 0x02
line coding and serial state
bMasterInterface 0
bSlaveInterface 1
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0010 1x 16 bytes
bInterval 16
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 10 CDC Data
bInterfaceSubClass 0 Unused
bInterfaceProtocol 0
iInterface 0
bLength 7
bDescriptorType 5
bEndpointAddress 0x82 EP 2 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
bLength 7
bDescriptorType 5
bEndpointAddress 0x02 EP 2 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
bLength 9
bDescriptorType 4
bInterfaceNumber 2
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 0
bInterfaceProtocol 0
iInterface 0
bLength 7
bDescriptorType 5
bEndpointAddress 0x85 EP 5 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
bLength 7
bDescriptorType 5
bEndpointAddress 0x05 EP 5 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
bLength 5
bDescriptorType 15
wTotalLength 29
bNumDeviceCaps 1
** UNRECOGNIZED: 18 10 05 00 38 b6 08 34 a9 09 a0 47 8b fd a0 76 88 15
b6 65 00 01 57 02
Device Status: 0x0001
Self Powered

Post by Greg KH

On Mon, Jan 09, 2017 at 09:40:59AM +0000, Kenneth Rohde Christiansen

Web USB can only grab devices which has special Web USB headers. It

can not

grab any USB device.
https://wicg.github.io/webusb/#webusb-descriptors

Ah, fun :(
So, we can add a quirk into the kernel cdc-acm driver to never bind

to a

device that has the wusb platform capability descriptor,

I fail to see why a quirk should be necessary. New device classes are
expected to use new class/subclass codes distintly different from
anything handled by existing class drivers.

One would hope, but it seems like they want to piggy-back on the cdc-acm
spec. But I could be totally wrong here, does anyone have the actual
descriptor dump of a device anywhere?

We don't want to piggy-back on the CDC-ACM spec. A WebUSB device should
always have its interfaces marked vendor-specific. Below is an example of a
device which implements both a CDC-ACM interface and a WebUSB interface. As
far as I've noticed ModemManager has not interfered with the browser
accessing this device but Lars has observed this behavior. What I have had
to do, however, is add a udev rule which sets ownership on the devnode so
that the browser can access it as an unprivileged user-space application.
What would be nice to have from systemd-udevd is a way to write a rule that
will detect the presence of WebUSB descriptors (which is a BOS capability
descriptor) and set ownership accordingly.
Bus 002 Device 040: ID 2341:8037 Arduino SA
bLength 18
bDescriptorType 1
bcdUSB 2.10
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
idVendor 0x2341 Arduino SA
idProduct 0x8037
bcdDevice 1.00
iManufacturer 1 Arduino LLC
iProduct 2 Arduino Micro
iSerial 3 WUARTR
bNumConfigurations 1
bLength 9
bDescriptorType 2
wTotalLength 98
bNumInterfaces 3
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xa0
(Bus Powered)
Remote Wakeup
MaxPower 500mA
bLength 8
bDescriptorType 11
bFirstInterface 0
bInterfaceCount 2
bFunctionClass 2 Communications
bFunctionSubClass 2 Abstract (modem)
bFunctionProtocol 1 AT-commands (v.25ter)
iFunction 0
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 2 Communications
bInterfaceSubClass 2 Abstract (modem)
bInterfaceProtocol 0 None
iInterface 0
bcdCDC 1.10
bmCapabilities 0x01
call management
bDataInterface 1
bmCapabilities 0x06
sends break
line coding and serial state
bMasterInterface 0
bSlaveInterface 1
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0010 1x 16 bytes
bInterval 64
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 10 CDC Data
bInterfaceSubClass 0 Unused
bInterfaceProtocol 0
iInterface 0
bLength 7
bDescriptorType 5
bEndpointAddress 0x02 EP 2 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
bLength 9
bDescriptorType 4
bInterfaceNumber 2
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 0
bInterfaceProtocol 0
iInterface 0
bLength 7
bDescriptorType 5
bEndpointAddress 0x04 EP 4 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
bLength 7
bDescriptorType 5
bEndpointAddress 0x85 EP 5 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
bLength 5
bDescriptorType 15
wTotalLength 57
bNumDeviceCaps 2
FIXME: alloc bigger buffer for device capability descriptors
Device Status: 0x0000
(Bus Powered)

[Dan Williams]

Post by Lars Knudsen

A small update:  When the modemmanager finishes probing (~16 secs
after
connection) data seems to stop flowing in from the WebUSB bulk endpoint
also.  It is, however, possible to reconnect and get data again -
so I need
to see if there should be anything in the mbed firmware causing that
behavior or there is some sort of silent reset of
interfaces/endpoints
happening on the linux side when probing is done.

Had to separate the CDC and WebUSB serial control signals completely in the
firmware driver. - now survives

Yes, if you expose two USB interfaces that can be bound by two
different drivers, then you must expect they could be used
independently. Not only by MM, but by anything.

Most devices that expose multiple ttys (eg, modems) treat the ttys as
completely separate at the link layer (serial signals) but commands
issued on separate ttys obviously affect internal firmware state
concurrently.

Dan

Post by Lars Knudsen

Post by Lars Knudsen
I finally managed to make a configuration that *seems* to work and I
realize that I may have had something else blocking the WebUSB interface
(2) while modemmanager was communicating with the CDC_ACM
interface (1).
I made a clean arbitrary VID/PID and get what seems to be a functioning
WebUSB (now) while modemmanager sends "AT...AT..." to the CDC interface -
so while I thought the modemmanager grabbed my WebUSB interface part, it
must have been because of a faulty combination on my side - my apologies.
WebUSB actually *does* seem to give immediate "bulk" access to a device
otherwise claimed by modemmanager - a very nice option to have and sorry
for the confusion I had that modemmanager grabbed more interfaces than it
should have.
Still, the original request still stands and please tell me if it's a
1.  If a device has a WebUSB descriptor, it's most probably *not*
a modem
- and should in stead be considered a device that in this rare case needs
to be whitelisted (as modem), while defaulting to not being
it.  This is to
ease the usage from non-browsers to the same hardware, which can then
happen immediately and not be required to fail and wait over the
modemmanager probing period (30 sec?) - related to modemmanager
2. If a device has a WebUSB descriptor, at least the interface linked to
WebUSB should be made accessible in user land by default so no average user
has to figure out how to do udev rules - related to udev/systemd
Bus 002 Device 089: ID 1209:d010 InterBiometrics
  bLength                18
  bDescriptorType         1
  bcdUSB               2.10
  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0
  bDeviceProtocol         0
  bMaxPacketSize0        64
  idVendor           0x1209 InterBiometrics
  idProduct          0xd010
  bcdDevice            0.01
  iManufacturer           1 empriKit
  iProduct                2 empriKit|MOTION
  iSerial                 3 00.01
  bNumConfigurations      1
    bLength                 9
    bDescriptorType         2
    wTotalLength           90
    bNumInterfaces          3
    bConfigurationValue     1
    iConfiguration          0
    bmAttributes         0xc0
      Self Powered
    MaxPower              100mA
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           1
      bInterfaceClass         2 Communications
      bInterfaceSubClass      2 Abstract (modem)
      bInterfaceProtocol      1 AT-commands (v.25ter)
      iInterface              0
        bcdCDC               1.10
        bmCapabilities       0x03
          call management
          use DataInterface
        bDataInterface          1
        bmCapabilities       0x02
          line coding and serial state
        bMasterInterface        0
        bSlaveInterface         1
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0010  1x 16 bytes
        bInterval              16
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        1
      bAlternateSetting       0
      bNumEndpoints           2
      bInterfaceClass        10 CDC Data
      bInterfaceSubClass      0 Unused
      bInterfaceProtocol      0
      iInterface              0
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x82  EP 2 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               0
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x02  EP 2 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               0
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        2
      bAlternateSetting       0
      bNumEndpoints           2
      bInterfaceClass       255 Vendor Specific Class
      bInterfaceSubClass      0
      bInterfaceProtocol      0
      iInterface              0
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x85  EP 5 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               0
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x05  EP 5 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               0
  bLength                 5
  bDescriptorType        15
  wTotalLength           29
  bNumDeviceCaps          1
  ** UNRECOGNIZED:  18 10 05 00 38 b6 08 34 a9 09 a0 47 8b fd a0
76 88 15
b6 65 00 01 57 02
Device Status:     0x0001
  Self Powered

Post by Greg KH

On Mon, Jan 09, 2017 at 09:40:59AM +0000, Kenneth Rohde
Christiansen

Web USB can only grab devices which has special Web USB
headers. It

can not

grab any USB device.
https://wicg.github.io/webusb/#webusb-descriptors

Ah, fun :(
So, we can add a quirk into the kernel cdc-acm driver to never bind

to a

device that has the wusb platform capability descriptor,

I fail to see why a quirk should be necessary. New device classes are
expected to use new class/subclass codes distintly
different from
anything handled by existing class drivers.

One would hope, but it seems like they want to piggy-back on the cdc-acm
spec.  But I could be totally wrong here, does anyone have
the actual
descriptor dump of a device anywhere?

We don't want to piggy-back on the CDC-ACM spec. A WebUSB device should
always have its interfaces marked vendor-specific. Below is an example of a
device which implements both a CDC-ACM interface and a WebUSB interface. As
far as I've noticed ModemManager has not interfered with the browser
accessing this device but Lars has observed this behavior. What I have had
to do, however, is add a udev rule which sets ownership on the devnode so
that the browser can access it as an unprivileged user-space application.
What would be nice to have from systemd-udevd is a way to write a rule that
will detect the presence of WebUSB descriptors (which is a BOS capability
descriptor) and set ownership accordingly.
Bus 002 Device 040: ID 2341:8037 Arduino SA
  bLength                18
  bDescriptorType         1
  bcdUSB               2.10
  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0
  bDeviceProtocol         0
  bMaxPacketSize0        64
  idVendor           0x2341 Arduino SA
  idProduct          0x8037
  bcdDevice            1.00
  iManufacturer           1 Arduino LLC
  iProduct                2 Arduino Micro
  iSerial                 3 WUARTR
  bNumConfigurations      1
    bLength                 9
    bDescriptorType         2
    wTotalLength           98
    bNumInterfaces          3
    bConfigurationValue     1
    iConfiguration          0
    bmAttributes         0xa0
      (Bus Powered)
      Remote Wakeup
    MaxPower              500mA
      bLength                 8
      bDescriptorType        11
      bFirstInterface         0
      bInterfaceCount         2
      bFunctionClass          2 Communications
      bFunctionSubClass       2 Abstract (modem)
      bFunctionProtocol       1 AT-commands (v.25ter)
      iFunction               0
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           1
      bInterfaceClass         2 Communications
      bInterfaceSubClass      2 Abstract (modem)
      bInterfaceProtocol      0 None
      iInterface              0
        bcdCDC               1.10
        bmCapabilities       0x01
          call management
        bDataInterface          1
        bmCapabilities       0x06
          sends break
          line coding and serial state
        bMasterInterface        0
        bSlaveInterface         1
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0010  1x 16 bytes
        bInterval              64
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        1
      bAlternateSetting       0
      bNumEndpoints           2
      bInterfaceClass        10 CDC Data
      bInterfaceSubClass      0 Unused
      bInterfaceProtocol      0
      iInterface              0
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x02  EP 2 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               0
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x83  EP 3 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               0
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        2
      bAlternateSetting       0
      bNumEndpoints           2
      bInterfaceClass       255 Vendor Specific Class
      bInterfaceSubClass      0
      bInterfaceProtocol      0
      iInterface              0
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x04  EP 4 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               0
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x85  EP 5 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               0
  bLength                 5
  bDescriptorType        15
  wTotalLength           57
  bNumDeviceCaps          2
FIXME: alloc bigger buffer for device capability descriptors
Device Status:     0x0000
  (Bus Powered)

_______________________________________________
systemd-devel mailing list
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[Lars Knudsen]

I figured that made most sense :)

Still, it would be good if we could have a rule to not grab the CDC
interface part if the device includes WebUSB functionality. The likelihood
of a modem+WebUSB combo is so small that it must fall in the category where
potential rare exotic devices combining it must be whitelisted and the rest
be left alone.

Also (probably more a generic udev/systemd patch) always give user (or at
least browser - if that differentiation is possible) access to WebUSB
devices.

Btw: Afaik, Chromebooks are still using modemmanager, where not even
experts have easy access to creating udev rules

Br
Lars

Br
Lars

Post by Lars Knudsen

Post by Lars Knudsen
A small update: When the modemmanager finishes probing (~16 secs after
connection) data seems to stop flowing in from the WebUSB bulk endpoint
also. It is, however, possible to reconnect and get data again - so I need
to see if there should be anything in the mbed firmware causing that
behavior or there is some sort of silent reset of
interfaces/endpoints
happening on the linux side when probing is done.

Had to separate the CDC and WebUSB serial control signals completely in the
firmware driver. - now survives

Yes, if you expose two USB interfaces that can be bound by two
different drivers, then you must expect they could be used
independently. Not only by MM, but by anything.

Most devices that expose multiple ttys (eg, modems) treat the ttys as
completely separate at the link layer (serial signals) but commands
issued on separate ttys obviously affect internal firmware state
concurrently.

Dan

Post by Lars Knudsen

Post by Lars Knudsen

Post by Lars Knudsen
I finally managed to make a configuration that *seems* to work and I
realize that I may have had something else blocking the WebUSB interface
(2) while modemmanager was communicating with the CDC_ACM
interface (1).
I made a clean arbitrary VID/PID and get what seems to be a functioning
WebUSB (now) while modemmanager sends "AT...AT..." to the CDC interface -
so while I thought the modemmanager grabbed my WebUSB interface part, it
must have been because of a faulty combination on my side - my apologies.
WebUSB actually *does* seem to give immediate "bulk" access to a device
otherwise claimed by modemmanager - a very nice option to have and sorry
for the confusion I had that modemmanager grabbed more interfaces than it
should have.
Still, the original request still stands and please tell me if it's a
1. If a device has a WebUSB descriptor, it's most probably *not* a modem
- and should in stead be considered a device that in this rare case needs
to be whitelisted (as modem), while defaulting to not being it. This is to
ease the usage from non-browsers to the same hardware, which can then
happen immediately and not be required to fail and wait over the
modemmanager probing period (30 sec?) - related to modemmanager
2. If a device has a WebUSB descriptor, at least the interface linked to
WebUSB should be made accessible in user land by default so no average user
has to figure out how to do udev rules - related to udev/systemd
Bus 002 Device 089: ID 1209:d010 InterBiometrics
bLength 18
bDescriptorType 1
bcdUSB 2.10
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
idVendor 0x1209 InterBiometrics
idProduct 0xd010
bcdDevice 0.01
iManufacturer 1 empriKit
iProduct 2 empriKit|MOTION
iSerial 3 00.01
bNumConfigurations 1
bLength 9
bDescriptorType 2
wTotalLength 90
bNumInterfaces 3
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xc0
Self Powered
MaxPower 100mA
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 2 Communications
bInterfaceSubClass 2 Abstract (modem)
bInterfaceProtocol 1 AT-commands (v.25ter)
iInterface 0
bcdCDC 1.10
bmCapabilities 0x03
call management
use DataInterface
bDataInterface 1
bmCapabilities 0x02
line coding and serial state
bMasterInterface 0
bSlaveInterface 1
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0010 1x 16 bytes
bInterval 16
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 10 CDC Data
bInterfaceSubClass 0 Unused
bInterfaceProtocol 0
iInterface 0
bLength 7
bDescriptorType 5
bEndpointAddress 0x82 EP 2 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
bLength 7
bDescriptorType 5
bEndpointAddress 0x02 EP 2 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
bLength 9
bDescriptorType 4
bInterfaceNumber 2
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 0
bInterfaceProtocol 0
iInterface 0
bLength 7
bDescriptorType 5
bEndpointAddress 0x85 EP 5 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
bLength 7
bDescriptorType 5
bEndpointAddress 0x05 EP 5 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
bLength 5
bDescriptorType 15
wTotalLength 29
bNumDeviceCaps 1
** UNRECOGNIZED: 18 10 05 00 38 b6 08 34 a9 09 a0 47 8b fd a0 76 88 15
b6 65 00 01 57 02
Device Status: 0x0001
Self Powered

Post by Greg KH

On Mon, Jan 09, 2017 at 09:40:59AM +0000, Kenneth Rohde
Christiansen

Web USB can only grab devices which has special Web USB
headers. It

can not

grab any USB device.
https://wicg.github.io/webusb/#webusb-descriptors

Ah, fun :(
So, we can add a quirk into the kernel cdc-acm driver to never bind

to a

device that has the wusb platform capability descriptor,

I fail to see why a quirk should be necessary. New device classes are
expected to use new class/subclass codes distintly
different from
anything handled by existing class drivers.

One would hope, but it seems like they want to piggy-back on the cdc-acm
spec. But I could be totally wrong here, does anyone have the actual
descriptor dump of a device anywhere?

We don't want to piggy-back on the CDC-ACM spec. A WebUSB device should
always have its interfaces marked vendor-specific. Below is an example of a
device which implements both a CDC-ACM interface and a WebUSB interface. As
far as I've noticed ModemManager has not interfered with the browser
accessing this device but Lars has observed this behavior. What I have had
to do, however, is add a udev rule which sets ownership on the devnode so
that the browser can access it as an unprivileged user-space application.
What would be nice to have from systemd-udevd is a way to write a rule that
will detect the presence of WebUSB descriptors (which is a BOS capability
descriptor) and set ownership accordingly.
Bus 002 Device 040: ID 2341:8037 Arduino SA
bLength 18
bDescriptorType 1
bcdUSB 2.10
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
idVendor 0x2341 Arduino SA
idProduct 0x8037
bcdDevice 1.00
iManufacturer 1 Arduino LLC
iProduct 2 Arduino Micro
iSerial 3 WUARTR
bNumConfigurations 1
bLength 9
bDescriptorType 2
wTotalLength 98
bNumInterfaces 3
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xa0
(Bus Powered)
Remote Wakeup
MaxPower 500mA
bLength 8
bDescriptorType 11
bFirstInterface 0
bInterfaceCount 2
bFunctionClass 2 Communications
bFunctionSubClass 2 Abstract (modem)
bFunctionProtocol 1 AT-commands (v.25ter)
iFunction 0
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 2 Communications
bInterfaceSubClass 2 Abstract (modem)
bInterfaceProtocol 0 None
iInterface 0
bcdCDC 1.10
bmCapabilities 0x01
call management
bDataInterface 1
bmCapabilities 0x06
sends break
line coding and serial state
bMasterInterface 0
bSlaveInterface 1
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0010 1x 16 bytes
bInterval 64
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 10 CDC Data
bInterfaceSubClass 0 Unused
bInterfaceProtocol 0
iInterface 0
bLength 7
bDescriptorType 5
bEndpointAddress 0x02 EP 2 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
bLength 9
bDescriptorType 4
bInterfaceNumber 2
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 0
bInterfaceProtocol 0
iInterface 0
bLength 7
bDescriptorType 5
bEndpointAddress 0x04 EP 4 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
bLength 7
bDescriptorType 5
bEndpointAddress 0x85 EP 5 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
bLength 5
bDescriptorType 15
wTotalLength 57
bNumDeviceCaps 2
FIXME: alloc bigger buffer for device capability descriptors
Device Status: 0x0000
(Bus Powered)

_______________________________________________
systemd-devel mailing list
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[Greg KH]

Post by Lars Knudsen
I figured that made most sense :)
Still, it would be good if we could have a rule to not grab the CDC interface
part if the device includes WebUSB functionality.

What exactly do you mean by "grab"?

Post by Lars Knudsen
The likelihood of a modem+WebUSB combo is so small that it must fall
in the category where potential rare exotic devices combining it must
be whitelisted and the rest be left alone.

I think you misunderstand just how crazy firmware authors can be. I'm
sure we will see those types of devices in the wild.

Post by Lars Knudsen
Also (probably more a generic udev/systemd patch) always give user (or at least
browser - if that differentiation is possible) access to WebUSB devices.

That's a bit harder as it requires userspace to parse the headers and
"know" to allow access to the device. I suggest a udev helper program
for it.

good luck,

greg k-h

[Lars Knudsen]

Post by Lars Knudsen
I figured that made most sense :)
Still, it would be good if we could have a rule to not grab the CDC interface
part if the device includes WebUSB functionality.

What exactly do you mean by "grab"?

MM probing :)

Post by Lars Knudsen
The likelihood of a modem+WebUSB combo is so small that it must fall
in the category where potential rare exotic devices combining it must
be whitelisted and the rest be left alone.

I think you misunderstand just how crazy firmware authors can be. I'm
sure we will see those types of devices in the wild.

...But realistically how many? Bothering 99.9% to support the special case
seems less logical than just finding the 0.1% and whitelisting it (if
needed)

Post by Lars Knudsen
Also (probably more a generic udev/systemd patch) always give user (or at least
browser - if that differentiation is possible) access to WebUSB devices.

That's a bit harder as it requires userspace to parse the headers and
"know" to allow access to the device. I suggest a udev helper program
for it.

good luck,

greg k-h

[Greg KH]

Post by Lars Knudsen

Post by Lars Knudsen
I figured that made most sense :)
Still, it would be good if we could have a rule to not grab the CDC

interface

Post by Lars Knudsen
part if the device includes WebUSB functionality.

What exactly do you mean by "grab"?
MM probing :)

Probe should be fine, right? Are you really thinking that MM needs to
go "oh look, a cdc device, let's go look at all of the raw interfaces to
ensure it really isn't a webusb device as well before I touch it!"

That way lies madness...

What's wrong with touching it? The kernel already did, why would
userspace care?

Post by Lars Knudsen

Post by Lars Knudsen
The likelihood of a modem+WebUSB combo is so small that it must fall
in the category where potential rare exotic devices combining it must
be whitelisted and the rest be left alone.

I think you misunderstand just how crazy firmware authors can be.  I'm
sure we will see those types of devices in the wild.
...But realistically how many? Bothering 99.9% to support the special case
seems less logical than just finding the 0.1% and whitelisting it (if needed)

That's the joy of writing an operating system for all devices on the
planet, those 0.1% can be a lot of devices :)

Anyway, I don't think there's much to do here just yet, let's wait and
see just how bad these webusb devices end up looking like...

thanks,

greg k-h

[Dan Williams]

    > I figured that made most sense :)
    >
    > Still, it would be good if we could have a rule to not grab
the CDC
    interface
    > part if the device includes WebUSB functionality.
    What exactly do you mean by "grab"?
MM probing :)

Probe should be fine, right?  Are you really thinking that MM needs
to
go "oh look, a cdc device, let's go look at all of the raw interfaces to
ensure it really isn't a webusb device as well before I touch it!"
That way lies madness...
What's wrong with touching it?  The kernel already did, why would
userspace care?

And we're quite happy to keep blacklisting specific VID/PID combos we
know are not modems. Another possible solution is to greylist devices
that happen to have webusb descriptors, such that they won't get auto-
probed, but could be probed on-demand via D-Bus. But I'd rather that
happen via udev rules than MM trying to walk USB device attributes and
parsing webusb descriptors.

Dan

    > The likelihood of a modem+WebUSB combo is so small that it
must fall
    > in the category where potential rare exotic devices combining
it must
    > be whitelisted and the rest be left alone.
    I think you misunderstand just how crazy firmware authors can
be.  I'm
    sure we will see those types of devices in the wild.
...But realistically how many? Bothering 99.9% to support the special case
seems less logical than just finding the 0.1% and whitelisting it (if needed)

That's the joy of writing an operating system for all devices on the
planet, those 0.1% can be a lot of devices :)
Anyway, I don't think there's much to do here just yet, let's wait and
see just how bad these webusb devices end up looking like...
thanks,
greg k-h
_______________________________________________
ModemManager-devel mailing list
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

[Lars Knudsen]

Post by Dan Williams

Post by Greg KH

Post by Lars Knudsen

Post by Lars Knudsen
I figured that made most sense :)
Still, it would be good if we could have a rule to not grab

the CDC
interface

Post by Lars Knudsen
part if the device includes WebUSB functionality.

What exactly do you mean by "grab"?
MM probing :)

Probe should be fine, right? Are you really thinking that MM needs to
go "oh look, a cdc device, let's go look at all of the raw interfaces to
ensure it really isn't a webusb device as well before I touch it!"
That way lies madness...
What's wrong with touching it? The kernel already did, why would
userspace care?

And we're quite happy to keep blacklisting specific VID/PID combos we
know are not modems. Another possible solution is to greylist devices
that happen to have webusb descriptors, such that they won't get auto-
probed, but could be probed on-demand via D-Bus. But I'd rather that
happen via udev rules than MM trying to walk USB device attributes and
parsing webusb descriptors.

Actually, that sounds like a very good compromise. I remember my own
struggles 3-4 years ago when I had to get a device working properly on
ChromeOS and Ubuntu, where the firmware had to handle that the first ~16
seconds it would *sometimes* get sent strange AT commands (the probing) all
while the system thought it could already start speaking with the device
over e.g. chrome.serial. Eventually you (modemmanager) were kind enough to
get our VID/PID listed and ChromeOS was quick to pick it up (~5-6 months to
get in stable) and ubuntu so kind to upgrade to the version of modemmanager
including our blacklisting approx 2.5 years later (sigh) ;)

If greylisting prevents auto-probing, I think it would be very valuable for
devices with a WebUSB header because those will in most cases (as I see
them used) be industrial things (like my current medical company employer)
or IoT devices. And waiting ~16 seconds for a fallback to USB Serial where
WebUSB is not available (or for other reasons not chosen), can be a real
pain.

I agree that a solid udev rule would be a good way forward (I'll look into
greylisting and see if I can come up with something that covers) and maybe
this could also be the place to do the user space access (or not - I'll try
to come back with something.

thanks for all the input. Maybe Kenneth, Reilly or some working on USB
related things in Intel have something to add?

Post by Dan Williams
Dan

Post by Greg KH

Post by Lars Knudsen

Post by Lars Knudsen
The likelihood of a modem+WebUSB combo is so small that it

must fall

Post by Lars Knudsen
in the category where potential rare exotic devices combining

it must

Post by Lars Knudsen
be whitelisted and the rest be left alone.

I think you misunderstand just how crazy firmware authors can be. I'm
sure we will see those types of devices in the wild.
...But realistically how many? Bothering 99.9% to support the special case
seems less logical than just finding the 0.1% and whitelisting it (if needed)

That's the joy of writing an operating system for all devices on the
planet, those 0.1% can be a lot of devices :)
Anyway, I don't think there's much to do here just yet, let's wait and
see just how bad these webusb devices end up looking like...
thanks,
greg k-h
_______________________________________________
ModemManager-devel mailing list
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

[Oliver Neukum]

Post by Dan Williams
And we're quite happy to keep blacklisting specific VID/PID combos we
know are not modems. Another possible solution is to greylist devices
that happen to have webusb descriptors, such that they won't get auto-
probed, but could be probed on-demand via D-Bus. But I'd rather that
happen via udev rules than MM trying to walk USB device attributes and
parsing webusb descriptors.
If greylisting prevents auto-probing, I think it would be very
valuable for devices with a WebUSB header because those will in most
cases (as I see them used) be industrial things (like my current
medical company employer) or IoT devices. And waiting ~16 seconds for
a fallback to USB Serial where WebUSB is not available (or for other
reasons not chosen), can be a real pain.
I agree that a solid udev rule would be a good way forward (I'll look
into greylisting and see if I can come up with something that covers)
and maybe this could also be the place to do the user space access (or
not - I'll try to come back with something.

I am afraid this would not work. Or rather it would work once.
But as soon as the driver is already loaded, it will bind and
we have a beautiful race condition, which the kernel will almost
certainly win.
And if we happen to look at a storage device we may see an unclean
removal if you kick the kernel off a device. I am afraid if you
really want to go to triggered probing, you need a sysctl for that.

Regards
Oliver

[Dan Williams]

    And we're quite happy to keep blacklisting specific VID/PID
combos we
    know are not modems. Another possible solution is to greylist
devices
    that happen to have webusb descriptors, such that they won't
get auto-
    probed, but could be probed on-demand via D-Bus.  But I'd
rather that
    happen via udev rules than MM trying to walk USB device
attributes and
    parsing webusb descriptors.
Actually, that sounds like a very good compromise.  I remember my
own
struggles 3-4 years ago when I had to get a device working properly on
ChromeOS and Ubuntu, where the firmware had to handle that the first ~16
seconds it would *sometimes* get sent strange AT commands (the
probing)
all while the system thought it could already start speaking with
the
device over e.g. chrome.serial.  Eventually you (modemmanager) were
kind
enough to get our VID/PID listed and ChromeOS was quick to pick it
up
(~5-6 months to get in stable) and ubuntu so kind to upgrade to the
version of modemmanager including our blacklisting approx 2.5 years
later (sigh) ;)

Weird question: should modem manager really autoprobe _every_ serial
device nowdays?  99% of the devices I connect to my laptop are not
modems.  They are serial ports on development platforms, RS485
interfaces, Arduinos with a FTDI, CP210x or CH341 USB-UART bridge,
and
so on.  Modems with a physical serial port are almost nonexistent
today.
 For me it's a pain in the back to have to update the blacklist of
things modem manger shouldn't touch.

MM does already whitelist platform serial devices (eg, i8250 UART) and
already greylists USB<->serial adapters like FTDI and CP210x.

Unfortunately, you'd be surprised how many modems actually *do* get
hooked up with USB<->serial converters like FTDI and CP210x. Modem
manufacturers often build these chips into devices so the modem looks
like USB but uses a generic VID/PID and a generic driver (FTDI).

If you have updates to the blacklist, we'd happily take them.

Wouldn't it be better to whitelist known ḿodems and have modem
manager
ignore everything else?  Devices which are so new that modem manager
don't know about them can be configured manually.

I ran a list of explicit modem VID/PID pairs in kernel drivers (like
option, qmi_wwan, sierra, hso, etc) 2 years ago and there were >1000
known WWAN modems.

That >1000 does *not* count attribute-matched devices like CDC ACM
devices, CDC WDM/ether, generic serial bridge modems (FTDI/CP210x), or
USB interface class/subclass/protocol matching which many Huawei
devices now use instead. Whitelisting is simply not really an option,
unfortunately, as too many new modem devices actually do come out every
year. Thankfully, many these days are MBIM (thanks to Windows 8+) or
QMI, but the embedded world still does a lot of serially-bridged
devices.

Dan

At least to me that seems like a much more sane default.
  /Christer
_______________________________________________
ModemManager-devel mailing list
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

[Lars Knudsen]

If it can be invoked via DBus - what is the harm to only do the scan for
the greylisted (in this case webusb) modems when the user actually wants to
search for a modem (like a printer) - and leave the poor devices alone
otherwise? In headless systems, it will not be the same problem as they
will most probably be custom made anyway.

Post by Dan Williams

Post by Dan Williams
And we're quite happy to keep blacklisting specific VID/PID combos we
know are not modems. Another possible solution is to greylist devices
that happen to have webusb descriptors, such that they won't get auto-
probed, but could be probed on-demand via D-Bus. But I'd rather that
happen via udev rules than MM trying to walk USB device attributes and
parsing webusb descriptors.
Actually, that sounds like a very good compromise. I remember my own
struggles 3-4 years ago when I had to get a device working properly on
ChromeOS and Ubuntu, where the firmware had to handle that the first ~16
seconds it would *sometimes* get sent strange AT commands (the
probing)
all while the system thought it could already start speaking with
the
device over e.g. chrome.serial. Eventually you (modemmanager) were
kind
enough to get our VID/PID listed and ChromeOS was quick to pick it
up
(~5-6 months to get in stable) and ubuntu so kind to upgrade to the
version of modemmanager including our blacklisting approx 2.5 years
later (sigh) ;)

Weird question: should modem manager really autoprobe _every_ serial
device nowdays? 99% of the devices I connect to my laptop are not
modems. They are serial ports on development platforms, RS485
interfaces, Arduinos with a FTDI, CP210x or CH341 USB-UART bridge,
and
so on. Modems with a physical serial port are almost nonexistent
today.
For me it's a pain in the back to have to update the blacklist of
things modem manger shouldn't touch.

MM does already whitelist platform serial devices (eg, i8250 UART) and
already greylists USB<->serial adapters like FTDI and CP210x.
Unfortunately, you'd be surprised how many modems actually *do* get
hooked up with USB<->serial converters like FTDI and CP210x. Modem
manufacturers often build these chips into devices so the modem looks
like USB but uses a generic VID/PID and a generic driver (FTDI).
If you have updates to the blacklist, we'd happily take them.

Wouldn't it be better to whitelist known áž¿odems and have modem
manager
ignore everything else? Devices which are so new that modem manager
don't know about them can be configured manually.

I ran a list of explicit modem VID/PID pairs in kernel drivers (like
option, qmi_wwan, sierra, hso, etc) 2 years ago and there were >1000
known WWAN modems.
That >1000 does *not* count attribute-matched devices like CDC ACM
devices, CDC WDM/ether, generic serial bridge modems (FTDI/CP210x), or
USB interface class/subclass/protocol matching which many Huawei
devices now use instead. Whitelisting is simply not really an option,
unfortunately, as too many new modem devices actually do come out every
year. Thankfully, many these days are MBIM (thanks to Windows 8+) or
QMI, but the embedded world still does a lot of serially-bridged
devices.
Dan

At least to me that seems like a much more sane default.
/Christer
_______________________________________________
ModemManager-devel mailing list
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

[Oliver Neukum]

Post by Lars Knudsen
If it can be invoked via DBus - what is the harm to only do the scan
for the greylisted (in this case webusb) modems when the user
actually wants to search for a modem (like a printer) - and leave the
poor devices alone otherwise?  In headless systems, it will not be
the same problem as they will most probably be custom made anyway.

Why have a list at all? Would you want the kernel to do an unrequested
probe of a device (function) with WebUSB descriptors at all?
It seems to me that the finest granularity you might need is by
device class, e.g. probing HID devices, so you don't block
the keyboard.

Regards
Oliver

[Dan Williams]

Post by Lars Knudsen
If it can be invoked via DBus - what is the harm to only do the scan for
the greylisted (in this case webusb) modems when the user actually wants to
search for a modem (like a printer) - and leave the poor devices alone
otherwise?  In headless systems, it will not be the same problem as
they
will most probably be custom made anyway.

Yes, headless/embedded/industrial systems are fairly easy as they are
well controlled. Desktop-type use-cases expect things to just work
when plugged in, but modem (and USB device in general) OEMs are a
contrary bunch and often don't bother to identify their devices in a
way that lets them be used easily by the OS.

I'd love a magic "this is a modem!" descriptor, but we don't have one
and never will. While I don't want to get into a huge UI discussion,
unless devices are network connected, searching isn't the normal way
devices get found. They get plugged in, and they just work. And we
get to figure out all the details like this :)

Related question though; if it's a webusb modem or even a cdc-acm
device, is the issue the *time* taken by probing, or the AT/DM requests
themselves? Most devices I know of (modem or not) will disregard
communication they don't know about as a function of their protocol.
MM's probe process does not alter device state in any way, just
requests informational responses.

Dan

Post by Lars Knudsen

Post by Dan Williams

    And we're quite happy to keep blacklisting specific VID/PID
combos we
    know are not modems. Another possible solution is to greylist
devices
    that happen to have webusb descriptors, such that they won't
get auto-
    probed, but could be probed on-demand via D-Bus.  But I'd
rather that
    happen via udev rules than MM trying to walk USB device
attributes and
    parsing webusb descriptors.
Actually, that sounds like a very good compromise.  I remember my
own
struggles 3-4 years ago when I had to get a device working
properly
on
ChromeOS and Ubuntu, where the firmware had to handle that the first ~16
seconds it would *sometimes* get sent strange AT commands (the
probing)
all while the system thought it could already start speaking with
the
device over e.g. chrome.serial.  Eventually you (modemmanager) were
kind
enough to get our VID/PID listed and ChromeOS was quick to pick it
up
(~5-6 months to get in stable) and ubuntu so kind to upgrade to the
version of modemmanager including our blacklisting approx 2.5 years
later (sigh) ;)

Weird question: should modem manager really autoprobe _every_ serial
device nowdays?  99% of the devices I connect to my laptop are not
modems.  They are serial ports on development platforms, RS485
interfaces, Arduinos with a FTDI, CP210x or CH341 USB-UART
bridge,
and
so on.  Modems with a physical serial port are almost nonexistent
today.
 For me it's a pain in the back to have to update the blacklist of
things modem manger shouldn't touch.

MM does already whitelist platform serial devices (eg, i8250 UART) and
already greylists USB<->serial adapters like FTDI and CP210x.
Unfortunately, you'd be surprised how many modems actually *do* get
hooked up with USB<->serial converters like FTDI and CP210x.  Modem
manufacturers often build these chips into devices so the modem looks
like USB but uses a generic VID/PID and a generic driver (FTDI).
If you have updates to the blacklist, we'd happily take them.

Wouldn't it be better to whitelist known ḿodems and have modem
manager
ignore everything else?  Devices which are so new that modem manager
don't know about them can be configured manually.

I ran a list of explicit modem VID/PID pairs in kernel drivers (like
option, qmi_wwan, sierra, hso, etc) 2 years ago and there were

1000

known WWAN modems.
That >1000 does *not* count attribute-matched devices like CDC ACM
devices, CDC WDM/ether, generic serial bridge modems (FTDI/CP210x), or
USB interface class/subclass/protocol matching which many Huawei
devices now use instead.  Whitelisting is simply not really an
option,
unfortunately, as too many new modem devices actually do come out every
year.  Thankfully, many these days are MBIM (thanks to Windows 8+)
or
QMI, but the embedded world still does a lot of serially-bridged
devices.
Dan

At least to me that seems like a much more sane default.
  /Christer
_______________________________________________
ModemManager-devel mailing list
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

[Greg KH]

Post by Greg KH

Post by Lars Knudsen

Post by Greg KH

Web USB can only grab devices which has special Web USB headers. It can not
grab any USB device.
https://wicg.github.io/webusb/#webusb-descriptors

Ah, fun :(
So, we can add a quirk into the kernel cdc-acm driver to never bind to a
device that has the wusb platform capability descriptor,

I fail to see why a quirk should be necessary. New device classes are
expected to use new class/subclass codes distintly different from
anything handled by existing class drivers.

One would hope, but it seems like they want to piggy-back on the cdc-acm
spec. But I could be totally wrong here, does anyone have the actual
descriptor dump of a device anywhere?

We don't want to piggy-back on the CDC-ACM spec. A WebUSB device should
always have its interfaces marked vendor-specific. Below is an example of a
device which implements both a CDC-ACM interface and a WebUSB interface.

Ick, why would you want both interfaces on a device? Are you going to
allow firmware to talk to both endpoints at the same time? Why?

Why not just make it a "one interface" type of device?

thanks,

greg k-h

[Lars Knudsen]

Post by Greg KH

Post by Lars Knudsen

On Mon, Jan 09, 2017 at 09:40:59AM +0000, Kenneth Rohde

Web USB can only grab devices which has special Web USB headers. It can not
grab any USB device.
https://wicg.github.io/webusb/#webusb-descriptors

Ah, fun :(
So, we can add a quirk into the kernel cdc-acm driver to never bind to a
device that has the wusb platform capability descriptor,

I fail to see why a quirk should be necessary. New device classes are
expected to use new class/subclass codes distintly different from
anything handled by existing class drivers.

One would hope, but it seems like they want to piggy-back on the cdc-acm
spec. But I could be totally wrong here, does anyone have the actual
descriptor dump of a device anywhere?

We don't want to piggy-back on the CDC-ACM spec. A WebUSB device should
always have its interfaces marked vendor-specific. Below is an example of a
device which implements both a CDC-ACM interface and a WebUSB interface.

Ick, why would you want both interfaces on a device? Are you going to
allow firmware to talk to both endpoints at the same time? Why?

Why not just make it a "one interface" type of device?

I work for a medical company, where we are using long lived software and
hardware. Having the option of supporting both WebUSB and USB serial will
allow us to move to pure web and still support legacy platforms.

If we - in stead - were to only have WebUSB or standard CDC, we would force
an impossible break.

Having modemmanager estimating that "this WebUSB device is *probably* not a
modem" and furthermore allowing user access to that device (udev/systems)
would be a huge help in the direction of true PnP for users and
manufacturers.

Yesterday night I finally got WebUSB and MM running in parallel (so..Sorta
halfway there on Linux at least):
https://twitter.com/denladeside/status/818717316443676672


thanks,

greg k-h

[Greg KH]

Post by Greg KH

Post by Lars Knudsen

On Mon, Jan 09, 2017 at 09:40:59AM +0000, Kenneth Rohde

Web USB can only grab devices which has special Web USB headers.

It can not

Post by Greg KH

Post by Lars Knudsen

grab any USB device.
https://wicg.github.io/webusb/#webusb-descriptors

Ah, fun :(
So, we can add a quirk into the kernel cdc-acm driver to never bind

to a

Post by Greg KH

Post by Lars Knudsen

device that has the wusb platform capability descriptor,

I fail to see why a quirk should be necessary. New device classes are
expected to use new class/subclass codes distintly different from
anything handled by existing class drivers.

One would hope, but it seems like they want to piggy-back on the

cdc-acm

Post by Greg KH
spec.  But I could be totally wrong here, does anyone have the actual
descriptor dump of a device anywhere?

We don't want to piggy-back on the CDC-ACM spec. A WebUSB device should
always have its interfaces marked vendor-specific. Below is an example of

a

device which implements both a CDC-ACM interface and a WebUSB interface.

Ick, why would you want both interfaces on a device?  Are you going to
allow firmware to talk to both endpoints at the same time?  Why?
Why not just make it a "one interface" type of device?
I work for a medical company, where we are using long lived software and
hardware. Having the option of supporting both WebUSB and USB serial will allow
us to move to pure web and still support legacy platforms.
If we - in stead - were to only have WebUSB or standard CDC, we would force an
impossible break.

Ok, yes, different interfaces will work, and as long as the kernel isn't
going to bind to the interface, you should be fine. Hopefully your
firmware can handle userspace talking to both interfaces at the same
time :)

good luck!

greg k-h

[Mantas Mikulėnas]

On Mon, Jan 9, 2017 at 11:20 AM, Lars Knudsen <***@gmail.com> wrote:

Hi,

I am currently looking into how we can make using WebUSB devices less
painful for users on Linux.

The main purpose of WebUSB (as far as I can see) is to enable certain CDC
(in particular - but not limited to) devices communicate directly with
browsers visiting certain trusted sites (listed inside a binary object
store - sent on initial handshake).

The spec is here: https://wicg.github.io/webusb/ (already running fine in
chrome stable)
Examples:
http://youtu.be/Z1Nk2hH2wFE
http://youtu.be/o7wGt9RfHVA
https://twitter.com/denladeside/status/817451203076427783

I'm guessing the solution will consist of 2 parts:

1. make sure no WebUSB device is picked up by modemmanager (modemmanager
task)

2. make sure that webusb devices will be somehow accessible to be used by a
browser running with user permissions (current temp solution listed here:
adding user to plugdev, adding 0664 permissions to device:
https://developers.google.com/web/updates/2016/03/access-usb-devices-on-the-web
) (udev/systemd task).

For 2. we need to either making all webusb devices accessible or find some
other way the browsers can - in a generic way - gain access. In all cases,
it's important that no USB interfaces has been pre-claimed by the system
(e.g. by cdc_acm) or it should be possible for the browser to throw off the
claims.


I'm not sure how ModemManager could possibly avoid claiming a device based
on a website visit that will happen *sometime in the future*, if ever.

As for permissions, uaccess might work if the device types are known (see
e.g. the Yubikey udev rules), but... somehow, it sounds like webapps will
end up being more privileged than local software, a bit odd.

[Lars Knudsen]

On Jan 9, 2017 10:53, "Mantas Mikulėnas" <***@gmail.com> wrote:

On Mon, Jan 9, 2017 at 11:20 AM, Lars Knudsen <***@gmail.com> wrote:

Hi,

I am currently looking into how we can make using WebUSB devices less
painful for users on Linux.

The main purpose of WebUSB (as far as I can see) is to enable certain CDC
(in particular - but not limited to) devices communicate directly with
browsers visiting certain trusted sites (listed inside a binary object
store - sent on initial handshake).

The spec is here: https://wicg.github.io/webusb/ (already running fine in
chrome stable)
Examples:
http://youtu.be/Z1Nk2hH2wFE
http://youtu.be/o7wGt9RfHVA
https://twitter.com/denladeside/status/817451203076427783

I'm guessing the solution will consist of 2 parts:

1. make sure no WebUSB device is picked up by modemmanager (modemmanager
task)

2. make sure that webusb devices will be somehow accessible to be used by a
browser running with user permissions (current temp solution listed here:
adding user to plugdev, adding 0664 permissions to device:
https://developers.google.com/web/updates/2016/03/access-
usb-devices-on-the-web ) (udev/systemd task).

For 2. we need to either making all webusb devices accessible or find some
other way the browsers can - in a generic way - gain access. In all cases,
it's important that no USB interfaces has been pre-claimed by the system
(e.g. by cdc_acm) or it should be possible for the browser to throw off the
claims.


I'm not sure how ModemManager could possibly avoid claiming a device based
on a website visit that will happen *sometime in the future*, if ever.

It is in the USB descriptors. Should be easy to do a clean detection. It is
not likely anyone would ever make a modem with webusb descriptors.


As for permissions, uaccess might work if the device types are known (see
e.g. the Yubikey udev rules), but... somehow, it sounds like webapps will
end up being more privileged than local software, a bit odd.

[Poussa, Sakari]

+Balbi

On 1/9/17, 11:37 AM, "Kenneth Rohde Christiansen" <***@gmail.com<mailto:***@gmail.com>> wrote:

Adding Sakari and Babu, who might want to add a few people from our side.

Cheers
Kenneth
On Mon, Jan 9, 2017 at 10:20 AM Lars Knudsen <***@gmail.com<mailto:***@gmail.com>> wrote:
Hi,

I am currently looking into how we can make using WebUSB devices less painful for users on Linux.

The main purpose of WebUSB (as far as I can see) is to enable certain CDC (in particular - but not limited to) devices communicate directly with browsers visiting certain trusted sites (listed inside a binary object store - sent on initial handshake).

The spec is here: https://wicg.github.io/webusb/ (already running fine in chrome stable)
Examples:
http://youtu.be/Z1Nk2hH2wFE
http://youtu.be/o7wGt9RfHVA
https://twitter.com/denladeside/status/817451203076427783

I'm guessing the solution will consist of 2 parts:

1. make sure no WebUSB device is picked up by modemmanager (modemmanager task)

2. make sure that webusb devices will be somehow accessible to be used by a browser running with user permissions (current temp solution listed here: adding user to plugdev, adding 0664 permissions to device: https://developers.google.com/web/updates/2016/03/access-usb-devices-on-the-web ) (udev/systemd task).

For 2. we need to either making all webusb devices accessible or find some other way the browsers can - in a generic way - gain access. In all cases, it's important that no USB interfaces has been pre-claimed by the system (e.g. by cdc_acm) or it should be possible for the browser to throw off the claims.

thoughts?

br
Lars

[Felipe Balbi]

I don't think we need to change anything in the kernel. What we need is
generic udev rule that fixes up permissions for the WebUSB Interface.

IIRC, WebUSB is implemented much like CDC ACM, however bInterfaceClass
is set to Vendor Specific. That should be enough to prevent CDC-ACM
driver from binding to WebUSB Interface.

Babu once showed me on WebUSB device but I can't recall if the
descriptors were setup as I mentioned above or not. Babu, care to
confirm?

thanks

Post by Poussa, Sakari
+Balbi
Adding Sakari and Babu, who might want to add a few people from our side.
Cheers
Kenneth
Hi,
I am currently looking into how we can make using WebUSB devices less painful for users on Linux.
The main purpose of WebUSB (as far as I can see) is to enable certain CDC (in particular - but not limited to) devices communicate directly with browsers visiting certain trusted sites (listed inside a binary object store - sent on initial handshake).
The spec is here: https://wicg.github.io/webusb/ (already running fine in chrome stable)
http://youtu.be/Z1Nk2hH2wFE
http://youtu.be/o7wGt9RfHVA
https://twitter.com/denladeside/status/817451203076427783
1. make sure no WebUSB device is picked up by modemmanager (modemmanager task)
https://developers.google.com/web/updates/2016/03/access-usb-devices-on-the-web ) (udev/systemd task).
For 2. we need to either making all webusb devices accessible or find some other way the browsers can - in a generic way - gain access. In all cases, it's important that no USB interfaces has been pre-claimed by the system (e.g. by cdc_acm) or
it should be possible for the browser to throw off the claims.
thoughts?
br
Lars

[Greg KH]

Post by Felipe Balbi
I don't think we need to change anything in the kernel. What we need is
generic udev rule that fixes up permissions for the WebUSB Interface.
IIRC, WebUSB is implemented much like CDC ACM, however bInterfaceClass
is set to Vendor Specific. That should be enough to prevent CDC-ACM
driver from binding to WebUSB Interface.

Yeah, someone drug you into this thread a bit late, I already suggested
that a simple kernel patch would resolve all of this :)

Now all we do is wait for someone to make that patch...

thanks,

greg k-h

[Simon McVittie]

Post by Lars Knudsen
2. make sure that webusb devices will be somehow accessible to be used by a
adding user to plugdev, adding 0664 permissions to device: https://
developers.google.com/web/updates/2016/03/access-usb-devices-on-the-web )  
(udev/systemd task).

Since I didn't see a response to this: this sounds like a job for uaccess.
Most things that happened via the plugdev group (on Debian/derivatives)
5 or 10 years ago should happen via uaccess now.

TAG+="uaccess" in a udev rule results in an ACL being set so that
a currently-active logind session on the same seat can read and write
the device node.

S

[Lars Knudsen]

On Mon, Jan 16, 2017 at 3:23 PM, Simon McVittie <

Post by Simon McVittie

Post by Lars Knudsen
2. make sure that webusb devices will be somehow accessible to be used

by a

Post by Lars Knudsen
adding user to plugdev, adding 0664 permissions to device: https://
developers.google.com/web/updates/2016/03/access-usb-devices-on-the-web

)

Post by Lars Knudsen
(udev/systemd task).

Since I didn't see a response to this: this sounds like a job for uaccess.
Most things that happened via the plugdev group (on Debian/derivatives)
5 or 10 years ago should happen via uaccess now.
TAG+="uaccess" in a udev rule results in an ACL being set so that
a currently-active logind session on the same seat can read and write
the device node.

OK thanks!

- so if we can make a rule that consistently detects USB devices with a
WebUSB interface defined, we should get this in as a standard rule.

Is it possible to give access on an interface level - or would it always
have to be the full device?

br
Lars

Post by Simon McVittie
S
_______________________________________________
systemd-devel mailing list
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[Greg KH]

Post by Simon McVittie

Post by Lars Knudsen
2. make sure that webusb devices will be somehow accessible to be used by

a

Post by Lars Knudsen
adding user to plugdev, adding 0664 permissions to device: https://
developers.google.com/web/updates/2016/03/access-usb-devices-on-the-web )

 

Post by Lars Knudsen
(udev/systemd task).

Since I didn't see a response to this: this sounds like a job for uaccess.
Most things that happened via the plugdev group (on Debian/derivatives)
5 or 10 years ago should happen via uaccess now.
TAG+="uaccess" in a udev rule results in an ACL being set so that
a currently-active logind session on the same seat can read and write
the device node.
OK thanks!
 - so if we can make a rule that consistently detects USB devices with a WebUSB
interface defined, we should get this in as a standard rule.

Sure, feel free to write the helper binary that will do this.

Post by Simon McVittie
Is it possible to give access on an interface level - or would it always have
to be the full device?

How would you provide userspace access to only one USB interface on
Linux?

thanks,

greg k-h

[Lars Knudsen]

Post by Lars Knudsen

Post by Lars Knudsen
On Mon, Jan 16, 2017 at 3:23 PM, Simon McVittie <

Post by Lars Knudsen
2. make sure that webusb devices will be somehow accessible to be

used by

Post by Lars Knudsen
a

Post by Lars Knudsen
browser running with user permissions (current temp solution
adding user to plugdev, adding 0664 permissions to device: https://
developers.google.com/web/updates/2016/03/access-usb-

devices-on-the-web )

Post by Lars Knudsen

Post by Lars Knudsen
(udev/systemd task).

Since I didn't see a response to this: this sounds like a job for

uaccess.

Post by Lars Knudsen
Most things that happened via the plugdev group (on

Debian/derivatives)

Post by Lars Knudsen
5 or 10 years ago should happen via uaccess now.
TAG+="uaccess" in a udev rule results in an ACL being set so that
a currently-active logind session on the same seat can read and write
the device node.
OK thanks!
- so if we can make a rule that consistently detects USB devices with a

WebUSB

Post by Lars Knudsen
interface defined, we should get this in as a standard rule.

Sure, feel free to write the helper binary that will do this.

Cool, I am still wondering if we could do it with a script. Do you have an
example of a binary for udev?
(I am assuming it's a source for a plugin to be shipped with and callable
by udev?)

Post by Lars Knudsen

Post by Lars Knudsen
Is it possible to give access on an interface level - or would it always

have

Post by Lars Knudsen
to be the full device?

How would you provide userspace access to only one USB interface on
Linux?

The full device should be fine if it has a WebUSB interface (even in a
composite scenario)

br
Lars

Post by Lars Knudsen
thanks,
greg k-h

[Greg KH]

Post by Lars Knudsen

Post by Simon McVittie
 - so if we can make a rule that consistently detects USB devices with a

WebUSB

Post by Simon McVittie
interface defined, we should get this in as a standard rule.

Sure, feel free to write the helper binary that will do this.
Cool, I am still wondering if we could do it with a script.  Do you have an
example of a binary for udev?
(I am assuming it's a source for a plugin to be shipped with and callable by
udev?)

Yes, you could do it with a script, just look at the interface
information in sysfs, it all should be exported there properly. If not,
please let me know.

Post by Lars Knudsen

Post by Simon McVittie
Is it possible to give access on an interface level - or would it always

have

Post by Simon McVittie
to be the full device?

How would you provide userspace access to only one USB interface on
Linux?
The full device should be fine if it has a WebUSB interface (even in a
composite scenario)

Really? You want to allow someone "raw" access to a composite device
just because of one specific interface?

Yeah, it's a pain, and a side affect of the libusb api :(

thanks,

greg k-h

[Lars Knudsen]

Post by Lars Knudsen

Post by Lars Knudsen

Post by Lars Knudsen
- so if we can make a rule that consistently detects USB devices

with a

Post by Lars Knudsen
WebUSB

Post by Lars Knudsen
interface defined, we should get this in as a standard rule.

Sure, feel free to write the helper binary that will do this.
Cool, I am still wondering if we could do it with a script. Do you have

an

Post by Lars Knudsen
example of a binary for udev?
(I am assuming it's a source for a plugin to be shipped with and

callable by

Post by Lars Knudsen
udev?)

Yes, you could do it with a script, just look at the interface
information in sysfs, it all should be exported there properly. If not,
please let me know.

Post by Lars Knudsen

Post by Lars Knudsen
Is it possible to give access on an interface level - or would it

always

Post by Lars Knudsen
have

Post by Lars Knudsen
to be the full device?

How would you provide userspace access to only one USB interface on
Linux?
The full device should be fine if it has a WebUSB interface (even in a
composite scenario)

Really? You want to allow someone "raw" access to a composite device
just because of one specific interface?

Ideally, I would only allow the browsers running in user space and only the
WebUSB interface.
- but would that even be possible on Linux? (now/future).

We should remember that devices with a WebUSB interface included were
*made* for user access (what else would be the point?).

Also: We *do* need a 'blanket' solution for these as manufactures can't
always wait for the next time all planets align
and e.g. Ubuntu chooses to upgrade the rules. Just fyi, last time I was in
similar discussions in the smae lists, it took

Post by Lars Knudsen
Yeah, it's a pain, and a side affect of the libusb api :(
thanks,
greg k-h

[Greg KH]

Post by Lars Knudsen
The full device should be fine if it has a WebUSB interface (even in a
composite scenario)

Really?  You want to allow someone "raw" access to a composite device
just because of one specific interface?
 
Ideally, I would only allow the browsers running in user space and only the
WebUSB interface.
- but would that even be possible on Linux? (now/future).

I don't know how the browser ends up talking to the USB device in the
first place. Does it use libusb? usbfs directly? Something else?
It all depends on how it is accessing the device for what is needed to
properly set the permissions on it.

We should remember that devices with a WebUSB interface included were *made*
for user access (what else would be the point?).

I agree, but you never know what type of crazy composite device people
will create with this interface type.

Also: We *do* need a 'blanket' solution for these as manufactures can't always
wait for the next time all planets align
and e.g. Ubuntu chooses to upgrade the rules.  Just fyi, last time I was in
similar discussions in the smae lists, it took
web-enabling-legacy-devices-dc3ecb9400ed#.7l1hztlmi

Nothing I can do about crazy/stupid distros that never want to update
anything, all we can do is provide the solution and hope they wake up
and take it. Or users will end up moving to a distro that does provide
the correct continuous update model (i.e. Fedora, openSUSE, Arch, etc.)

thanks,

greg k-h

[Lars Knudsen]

Post by Greg KH

Post by Greg KH

Post by Lars Knudsen
The full device should be fine if it has a WebUSB interface (even

in a

Post by Greg KH

Post by Lars Knudsen
composite scenario)

Really? You want to allow someone "raw" access to a composite device
just because of one specific interface?
Ideally, I would only allow the browsers running in user space and only

the

Post by Greg KH
WebUSB interface.
- but would that even be possible on Linux? (now/future).

I don't know how the browser ends up talking to the USB device in the
first place. Does it use libusb? usbfs directly? Something else?
It all depends on how it is accessing the device for what is needed to
properly set the permissions on it.

Post by Greg KH
We should remember that devices with a WebUSB interface included were

*made*

Post by Greg KH
for user access (what else would be the point?).

I agree, but you never know what type of crazy composite device people
will create with this interface type.

Post by Greg KH
Also: We *do* need a 'blanket' solution for these as manufactures can't

always

Post by Greg KH
wait for the next time all planets align
and e.g. Ubuntu chooses to upgrade the rules. Just fyi, last time I was

in

Post by Greg KH
similar discussions in the smae lists, it took
web-enabling-legacy-devices-dc3ecb9400ed#.7l1hztlmi

Nothing I can do about crazy/stupid distros that never want to update
anything, all we can do is provide the solution and hope they wake up
and take it. Or users will end up moving to a distro that does provide
the correct continuous update model (i.e. Fedora, openSUSE, Arch, etc.)

Actually - there could be a way that would make the process more
'evergreen'
- you may have already considered it but it came to me in a dream last
night,
which I found quite magical (he he):

1. someone plugs in hardware with an unknown VID/PID but CDC capabilities
2. modemmanager does it's magic probing and finds "this is not a modem"
3. the VID/PID(& more if needed) + findings is sent to a cloud db ...
4. if the VID/PID(& more) gets enough votes to be modem/non-modem/other?,
it will be registered as such

every now and then, the DB is spread to e.g. CDN or the like to be picked
up by all installations...

next time someone plugs in the same hardware, it will allready be known

(this process could probably be expanded to other hardware/udev/etc)

This way, there is no 'waiting until crazy/stupid distros update' and one
could compare the process to how e.g.
the system time is updated from a time server.

thoughts?

br
Lars

Post by Greg KH
thanks,
greg k-h

[Greg KH]

Post by Lars Knudsen
1. someone plugs in hardware with an unknown VID/PID but CDC capabilities
2. modemmanager does it's magic probing and finds "this is not a modem"
3. the VID/PID(& more if needed) + findings is sent to a cloud db ...

Do you want a list of all devices you have plugged into your machine to
be sent to some random "cloud db"?

If so, great, please work on that and try to get the various distros to
pick it up :)

good luck!

greg k-h