Re: [systemd-devel] WebUSB

[Greg KH]

On Wed, Jan 25, 2017 at 02:38:06PM +0100, Lars Knudsen wrote:
> 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
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] WebUSB

[Lars Knudsen]

On Fri, Jan 20, 2017 at 1:38 PM, Greg KH  wrote:

> On Fri, Jan 20, 2017 at 01:18:12PM +0100, Lars Knudsen wrote:
> > > 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
> > some years for it to land in Ubuntu:  https://medium.com/@larsgk/
> > 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



> thanks,
>
> greg k-h
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] WebUSB

[Greg KH]

On Fri, Jan 20, 2017 at 01:18:12PM +0100, Lars Knudsen wrote:
> > 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
> some years for it to land in Ubuntu:  https://medium.com/@larsgk/
> 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
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] WebUSB

[Greg KH]

On Fri, Jan 20, 2017 at 12:55:20PM +0100, Lars Knudsen wrote:
> On Fri, Jan 20, 2017 at 12:05 PM, Greg KH  wrote:
> >  - 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.
> 
> 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.

> > 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?
> 
> 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
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] WebUSB

[Lars Knudsen]

On Fri, Jan 20, 2017 at 12:05 PM, Greg KH 
wrote:

> On Fri, Jan 20, 2017 at 11:43:24AM +0100, Lars Knudsen wrote:
> >
> >
> > On Mon, Jan 16, 2017 at 3:23 PM, Simon McVittie <
> simon.mcvit...@collabora.co.uk
> > > wrote:
> >
> > On Mon, 09 Jan 2017 at 10:20:33 +0100, Lars Knudsen wrote:
> > > 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).
> >
> > 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.
>
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?)


>
> > 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?
>
The full device should be fine if it has a WebUSB interface (even in a
composite scenario)

br
Lars

>
> thanks,
>
> greg k-h
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] WebUSB

[Greg KH]

On Fri, Jan 20, 2017 at 11:43:24AM +0100, Lars Knudsen wrote:
> 
> 
> On Mon, Jan 16, 2017 at 3:23 PM, Simon McVittie 
>  > wrote:
> 
> On Mon, 09 Jan 2017 at 10:20:33 +0100, Lars Knudsen wrote:
> > 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).
> 
> 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.

> 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
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] WebUSB

[Lars Knudsen]

On Mon, Jan 16, 2017 at 3:23 PM, Simon McVittie <
simon.mcvit...@collabora.co.uk> wrote:

> On Mon, 09 Jan 2017 at 10:20:33 +0100, Lars Knudsen wrote:
> > 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).
>
> 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


> S
> ___
> 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

Re: [systemd-devel] WebUSB

[Simon McVittie]

On Mon, 09 Jan 2017 at 10:20:33 +0100, Lars Knudsen wrote:
> 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).

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
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] WebUSB

[Oliver Neukum]

Am Mittwoch, den 11.01.2017, 16:01 +0100 schrieb 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

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

Re: [systemd-devel] WebUSB

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

On Wed, Jan 11, 2017 at 3:32 PM, Dan Williams  wrote:

> On Wed, 2017-01-11 at 14:21 +0100, Christer Weinigel wrote:
> > On 2017-01-10 19:55, Lars Knudsen wrote:
> > > On Tue, Jan 10, 2017 at 7:08 PM, Dan Williams  > > > wrote:
> > > 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
> > modemmanager-de...@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] WebUSB

[Dan Williams]

On Wed, 2017-01-11 at 14:21 +0100, Christer Weinigel wrote:
> On 2017-01-10 19:55, Lars Knudsen wrote:
> > On Tue, Jan 10, 2017 at 7:08 PM, Dan Williams  > > wrote:
> > 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
> modemmanager-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] WebUSB

[Oliver Neukum]

On Tue, 2017-01-10 at 19:55 +0100, Lars Knudsen wrote



> 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


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

Re: [systemd-devel] WebUSB

[Lars Knudsen]

On Tue, Jan 10, 2017 at 7:08 PM, Dan Williams  wrote:

> On Tue, 2017-01-10 at 18:33 +0100, Greg KH wrote:
> > On Tue, Jan 10, 2017 at 06:23:13PM +0100, Lars Knudsen wrote:
> > >
> > >
> > > On Jan 10, 2017 18:19, "Greg KH"  wrote:
> > >
> > > On Tue, Jan 10, 2017 at 06:04:46PM +0100, Lars Knudsen wrote:
> > > > 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.
>

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?


>
> 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
> > modemmanager-de...@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] WebUSB

[Dan Williams]

On Tue, 2017-01-10 at 18:33 +0100, Greg KH wrote:
> On Tue, Jan 10, 2017 at 06:23:13PM +0100, Lars Knudsen wrote:
> > 
> > 
> > On Jan 10, 2017 18:19, "Greg KH"  wrote:
> > 
> > On Tue, Jan 10, 2017 at 06:04:46PM +0100, Lars Knudsen wrote:
> > > 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
> modemmanager-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] WebUSB

[Lars Knudsen]

On Jan 10, 2017 18:19, "Greg KH"  wrote:

On Tue, Jan 10, 2017 at 06:04:46PM +0100, Lars Knudsen wrote:
> 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 :)


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


> 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
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] WebUSB

[Greg KH]

On Tue, Jan 10, 2017 at 06:23:13PM +0100, Lars Knudsen wrote:
> 
> 
> On Jan 10, 2017 18:19, "Greg KH"  wrote:
> 
> On Tue, Jan 10, 2017 at 06:04:46PM +0100, Lars Knudsen wrote:
> > 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?

> > 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
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] WebUSB

[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

On Jan 10, 2017 17:34, "Dan Williams"  wrote:

On Tue, 2017-01-10 at 01:01 +0100, Lars Knudsen wrote:
> On Tue, Jan 10, 2017 at 12:47 AM, Lars Knudsen 
> 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 
> > 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:
> > >   bLength18
> > >   bDescriptorType 1
> > >   bcdUSB   2.10
> > >   bDeviceClass0 (Defined at Interface level)
> > >   bDeviceSubClass 0
> > >   bDeviceProtocol 0
> > >   bMaxPacketSize064
> > >   idVendor   0x1209 InterBiometrics
> > >   idProduct  0xd010
> > >   bcdDevice0.01
> > >   iManufacturer   1 empriKit
> > >   iProduct2 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
> > >   bInterfaceNumber0
> > >   bAlternateSetting   0
> > >   bNumEndpoints   1
> > >   bInterfaceClass 2 Communications
> > >   bInterfaceSubClass  2 Abstract (modem)
> > >   

Re: [systemd-devel] WebUSB

[Dan Williams]

On Tue, 2017-01-10 at 01:01 +0100, Lars Knudsen wrote:
> On Tue, Jan 10, 2017 at 12:47 AM, Lars Knudsen 
> 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 
> > 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:
> > >   bLength18
> > >   bDescriptorType 1
> > >   bcdUSB   2.10
> > >   bDeviceClass0 (Defined at Interface level)
> > >   bDeviceSubClass 0
> > >   bDeviceProtocol 0
> > >   bMaxPacketSize064
> > >   idVendor   0x1209 InterBiometrics
> > >   idProduct  0xd010
> > >   bcdDevice0.01
> > >   iManufacturer   1 empriKit
> > >   iProduct2 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
> > >   bInterfaceNumber0
> > >   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:
> > > bMasterInterface0
> > > bSlaveInterface 1
> > >   Endpoint Descriptor:
> > > bLength 7
> > > bDescriptorType 5
> > > bEndpointAddress 

Re: [systemd-devel] WebUSB

[Greg KH]

On Tue, Jan 10, 2017 at 08:39:28AM +0100, Lars Knudsen wrote:
> 
> 
> On Jan 10, 2017 07:51, "Greg KH"  wrote:
> 
> On Mon, Jan 09, 2017 at 01:32:40PM -0800, Reilly Grant 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  writes:
> > > > > On Mon, Jan 09, 2017 at 09:40:59AM +, 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.
> 
> 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
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] WebUSB

[Lars Knudsen]

On Jan 10, 2017 07:51, "Greg KH"  wrote:

On Mon, Jan 09, 2017 at 01:32:40PM -0800, Reilly Grant 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  writes:
> > > > On Mon, Jan 09, 2017 at 09:40:59AM +, 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.

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
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] WebUSB

[Greg KH]

On Mon, Jan 09, 2017 at 01:32:40PM -0800, Reilly Grant 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  writes:
> > > > On Mon, Jan 09, 2017 at 09:40:59AM +, 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.

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
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] WebUSB

[Lars Knudsen]

On Tue, Jan 10, 2017 at 12:47 AM, Lars Knudsen  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

>
> On Tue, Jan 10, 2017 at 12:11 AM, Lars Knudsen  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:
>>   bLength18
>>   bDescriptorType 1
>>   bcdUSB   2.10
>>   bDeviceClass0 (Defined at Interface level)
>>   bDeviceSubClass 0
>>   bDeviceProtocol 0
>>   bMaxPacketSize064
>>   idVendor   0x1209 InterBiometrics
>>   idProduct  0xd010
>>   bcdDevice0.01
>>   iManufacturer   1 empriKit
>>   iProduct2 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
>>   bInterfaceNumber0
>>   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:
>> bMasterInterface0
>> bSlaveInterface 1
>>   Endpoint Descriptor:
>> bLength 7
>> bDescriptorType 5
>> bEndpointAddress 0x81  EP 1 IN
>> bmAttributes3
>>   Transfer TypeInterrupt
>>   Synch Type   None
>>   Usage Type   Data
>> wMaxPacketSize 0x0010  1x 16 bytes
>> bInterval  16
>> Interface Descriptor:
>>   bLength 9
>>   bDescriptorType 4
>>   bInterfaceNumber1
>>   bAlternateSetting   0
>>   bNumEndpoints   2
>>   bInterfaceClass10 CDC Data
>>   bInterfaceSubClass  0 Unused
>>   bInterfaceProtocol  0
>>   iInterface  0
>>   Endpoint Descriptor:
>> bLength 7
>> bDescriptorType 5
>> bEndpointAddress 0x82  EP 2 IN
>> bmAttributes2
>>   Transfer TypeBulk
>>  

Re: [systemd-devel] WebUSB

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

On Tue, Jan 10, 2017 at 12:11 AM, Lars Knudsen  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:
>   bLength18
>   bDescriptorType 1
>   bcdUSB   2.10
>   bDeviceClass0 (Defined at Interface level)
>   bDeviceSubClass 0
>   bDeviceProtocol 0
>   bMaxPacketSize064
>   idVendor   0x1209 InterBiometrics
>   idProduct  0xd010
>   bcdDevice0.01
>   iManufacturer   1 empriKit
>   iProduct2 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
>   bInterfaceNumber0
>   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:
> bMasterInterface0
> bSlaveInterface 1
>   Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x81  EP 1 IN
> bmAttributes3
>   Transfer TypeInterrupt
>   Synch Type   None
>   Usage Type   Data
> wMaxPacketSize 0x0010  1x 16 bytes
> bInterval  16
> Interface Descriptor:
>   bLength 9
>   bDescriptorType 4
>   bInterfaceNumber1
>   bAlternateSetting   0
>   bNumEndpoints   2
>   bInterfaceClass10 CDC Data
>   bInterfaceSubClass  0 Unused
>   bInterfaceProtocol  0
>   iInterface  0
>   Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x82  EP 2 IN
> bmAttributes2
>   Transfer TypeBulk
>   Synch Type   None
>   Usage Type   Data
> wMaxPacketSize 0x0040  1x 64 bytes
> bInterval   0
>   Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x02  

Re: [systemd-devel] WebUSB

[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:
  bLength18
  bDescriptorType 1
  bcdUSB   2.10
  bDeviceClass0 (Defined at Interface level)
  bDeviceSubClass 0
  bDeviceProtocol 0
  bMaxPacketSize064
  idVendor   0x1209 InterBiometrics
  idProduct  0xd010
  bcdDevice0.01
  iManufacturer   1 empriKit
  iProduct2 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
  bInterfaceNumber0
  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:
bMasterInterface0
bSlaveInterface 1
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81  EP 1 IN
bmAttributes3
  Transfer TypeInterrupt
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0010  1x 16 bytes
bInterval  16
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber1
  bAlternateSetting   0
  bNumEndpoints   2
  bInterfaceClass10 CDC Data
  bInterfaceSubClass  0 Unused
  bInterfaceProtocol  0
  iInterface  0
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x82  EP 2 IN
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0040  1x 64 bytes
bInterval   0
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02  EP 2 OUT
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0040  1x 64 bytes
bInterval   0
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber2
  bAlternateSetting   0
  bNumEndpoints   2
  bInterfaceClass   255 Vendor Specific Class
  bInterfaceSubClass  0
  bInterfaceProtocol  0
  iInterface  0
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress

Re: [systemd-devel] WebUSB

[Dan Williams]

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"  wrote:
> 
> > On Mon, 2017-01-09 at 19:22 +0100, Lars Knudsen wrote:
> > > On Jan 9, 2017 18:56, "Bjørn Mork"  wrote:
> > > 
> > > > Lars Knudsen  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 - 

Re: [systemd-devel] WebUSB

[Lars Knudsen]

On Mon, Jan 9, 2017 at 7:43 PM, Bjørn Mork  wrote:

> Lars Knudsen  writes:
>
> > 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?
>
> 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?)

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


>
> Bjørn
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] WebUSB

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

On Jan 9, 2017 19:40, "Dan Williams"  wrote:

> On Mon, 2017-01-09 at 19:22 +0100, Lars Knudsen wrote:
> > On Jan 9, 2017 18:56, "Bjørn Mork"  wrote:
> >
> > > Lars Knudsen  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 

Re: [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"  wrote:
> 
> > Lars Knudsen  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 

Re: [systemd-devel] WebUSB

[Lars Knudsen]

On Jan 9, 2017 18:56, "Bjørn Mork"  wrote:

> Lars Knudsen  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)

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
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] WebUSB

[Greg KH]

On Mon, Jan 09, 2017 at 06:13:04PM +0100, Bjørn Mork wrote:
> Greg KH  writes:
> > On Mon, Jan 09, 2017 at 09:40:59AM +, 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?

thanks,

greg k-h
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] WebUSB

[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

On Jan 9, 2017 18:13, "Bjørn Mork"  wrote:

Greg KH  writes:
> On Mon, Jan 09, 2017 at 09:40:59AM +, 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.


Bjørn
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] WebUSB

[Greg KH]

On Mon, Jan 09, 2017 at 01:12:11PM +0200, Felipe Balbi wrote:
> 
> 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
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] WebUSB

[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

"Poussa, Sakari"  writes:
> +Balbi
>
> On 1/9/17, 11:37 AM, "Kenneth Rohde Christiansen" 
>  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  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:
>
>  https://www.youtube.com/watch?v=Z1Nk2hH2wFE
>
>  https://www.youtube.com/watch?v=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
>

-- 
balbi


signature.asc
Description: PGP signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] WebUSB

[Lars Knudsen]

On Mon, Jan 9, 2017 at 11:39 AM, Greg KH  wrote:

> On Mon, Jan 09, 2017 at 11:29:24AM +0100, Aleksander Morgado wrote:
> > On Mon, Jan 9, 2017 at 11:07 AM, Greg KH  wrote:
> > > On Mon, Jan 09, 2017 at 09:40:59AM +, 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, 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
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] WebUSB

[Poussa, Sakari]

+Balbi

On 1/9/17, 11:37 AM, "Kenneth Rohde Christiansen" 
> 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 
> 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:
https://www.youtube.com/watch?v=Z1Nk2hH2wFE
https://www.youtube.com/watch?v=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


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

Re: [systemd-devel] WebUSB

[Greg KH]

On Mon, Jan 09, 2017 at 11:29:24AM +0100, Aleksander Morgado wrote:
> On Mon, Jan 9, 2017 at 11:07 AM, Greg KH  wrote:
> > On Mon, Jan 09, 2017 at 09:40:59AM +, 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, 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
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] WebUSB

[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 <
aleksan...@aleksander.es> wrote:

> On Mon, Jan 9, 2017 at 11:07 AM, Greg KH  wrote:
> > On Mon, Jan 09, 2017 at 09:40:59AM +, 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, 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
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] WebUSB

[Mantas Mikulėnas]

On Mon, Jan 9, 2017 at 11:20 AM, Lars Knudsen  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:
https://www.youtube.com/watch?v=Z1Nk2hH2wFE
https://www.youtube.com/watch?v=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.

-- 
Mantas Mikulėnas 
-- 

Mantas Mikulėnas 
Sent from my phone
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] WebUSB

[Lars Knudsen]

On Jan 9, 2017 10:53, "Mantas Mikulėnas"  wrote:

On Mon, Jan 9, 2017 at 11:20 AM, Lars Knudsen  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:
https://www.youtube.com/watch?v=Z1Nk2hH2wFE
https://www.youtube.com/watch?v=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.

-- 
Mantas Mikulėnas 
-- 

Mantas Mikulėnas 
Sent from my phone
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel