[systemd-devel] WebUSB
Lars Knudsen
larsgk at gmail.com
Tue Jan 10 17:04:46 UTC 2017
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
On Jan 10, 2017 17:34, "Dan Williams" <dcbw at redhat.com> wrote:
On Tue, 2017-01-10 at 01:01 +0100, Lars Knudsen wrote:
> On Tue, Jan 10, 2017 at 12:47 AM, Lars Knudsen <larsgk at gmail.com>
> wrote:
>
> > 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
> >
> > On Tue, Jan 10, 2017 at 12:11 AM, Lars Knudsen <larsgk at gmail.com>
> > wrote:
> >
> > > 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
> > >
> > >
> > > On Mon, Jan 9, 2017 at 10:32 PM, Reilly Grant <me at reilly.io>
> > > wrote:
> > >
> > > > On 2017-01-09 9:55 am, Greg KH wrote:
> > > >
> > > > > On Mon, Jan 09, 2017 at 06:13:04PM +0100, Bjørn Mork wrote:
> > > > >
> > > > > > Greg KH <greg at kroah.com> writes:
> > > > > > > On Mon, Jan 09, 2017 at 09:40:59AM +0000, Kenneth Rohde
> > > > > > > Christiansen
> > > > > >
> > > > > > wrote:
> > > > > > > > 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
> > > > Device Descriptor:
> > > > 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
> > > > Configuration Descriptor:
> > > > bLength 9
> > > > bDescriptorType 2
> > > > wTotalLength 98
> > > > bNumInterfaces 3
> > > > bConfigurationValue 1
> > > > iConfiguration 0
> > > > bmAttributes 0xa0
> > > > (Bus Powered)
> > > > Remote Wakeup
> > > > MaxPower 500mA
> > > > Interface Association:
> > > > bLength 8
> > > > bDescriptorType 11
> > > > bFirstInterface 0
> > > > bInterfaceCount 2
> > > > bFunctionClass 2 Communications
> > > > bFunctionSubClass 2 Abstract (modem)
> > > > bFunctionProtocol 1 AT-commands (v.25ter)
> > > > iFunction 0
> > > > Interface Descriptor:
> > > > bLength 9
> > > > bDescriptorType 4
> > > > bInterfaceNumber 0
> > > > bAlternateSetting 0
> > > > bNumEndpoints 1
> > > > bInterfaceClass 2 Communications
> > > > bInterfaceSubClass 2 Abstract (modem)
> > > > bInterfaceProtocol 0 None
> > > > iInterface 0
> > > > CDC Header:
> > > > bcdCDC 1.10
> > > > CDC Call Management:
> > > > bmCapabilities 0x01
> > > > call management
> > > > bDataInterface 1
> > > > CDC ACM:
> > > > bmCapabilities 0x06
> > > > sends break
> > > > 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 64
> > > > 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 0x02 EP 2 OUT
> > > > 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 0x83 EP 3 IN
> > > > 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 0x04 EP 4 OUT
> > > > 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 0x85 EP 5 IN
> > > > 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 57
> > > > bNumDeviceCaps 2
> > > > FIXME: alloc bigger buffer for device capability descriptors
> > > > Device Status: 0x0000
> > > > (Bus Powered)
> > > >
> > > >
>
> _______________________________________________
> 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/20170110/076d5bcb/attachment-0001.html>
More information about the systemd-devel
mailing list