[systemd-devel] WebUSB

[Dan Williams]

On Mon, 2017-01-09 at 19:22 +0100, Lars Knudsen wrote:
> On Jan 9, 2017 18:56, "Bjørn Mork" <bjorn at mork.no> wrote:
> 
> > Lars Knudsen <larsgk at gmail.com> writes:
> > 
> > > 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?
> > 
> > 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)

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?

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

> 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

> > 
> > 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
> systemd-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel