[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 <dcbw at redhat.com> 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 <dcbw at redhat.com
> > > <mailto:dcbw at redhat.com>> 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-devel at lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20170111/7bff42ef/attachment.html>