On Mon, 2017-01-09 at 20:05 +0100, Lars Knudsen wrote: > 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? > 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 > On Jan 9, 2017 19:40, "Dan Williams" <d...@redhat.com> wrote: > > > On Mon, 2017-01-09 at 19:22 +0100, Lars Knudsen wrote: > > > On Jan 9, 2017 18:56, "Bjørn Mork" <bj...@mork.no> wrote: > > > > > > > Lars Knudsen <lar...@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@lists.freedesktop.org > > > https://lists.freedesktop.org/mailman/listinfo/systemd-devel _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
