[systemd-devel] WebUSB

Mon Jan 9 19:05:05 UTC 2017

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

On Jan 9, 2017 19:40, "Dan Williams" <dcbw at redhat.com> wrote:

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20170109/ca3b60ff/attachment-0001.html>