Blacklisting a broken AT port

Ben Chan benchan at chromium.org
Thu Jan 30 00:48:22 PST 2014


Dan,

Thanks for your suggestion. That solves one of the issues I encountered.
I've submitted a patch to add additional hints for a ZTE MF190 dongle.  I
may need to implement a similar solution for other modems.

Ben


On Wed, Jan 29, 2014 at 8:20 AM, Dan Williams <dcbw at redhat.com> wrote:

> On Wed, 2014-01-29 at 00:04 -0800, Ben Chan wrote:
> > Hi Aleksander,
> >
> > I notice that some dongles have broken AT ports, e.g. ttyUSB1 appears to
> be
> > AT-capable but fails to handle most AT commands, while ttyUSB3 is
> > completely functional. ModemManager may pick ttyUSB1 as primary and
> ttyUSB3
> > as secondary.
> >
> > What's the recommended way to blacklist ttyUSB1 in such case?  I guess I
> > could add a udev rule to avoid setting MM_CANDIDATE=1 on ttyUSB1.
>
> We try to avoid per-port blacklisting because it's got a lot of
> possibility for abuse for reasons kinda like this.  Not that your case
> is a problem, but that in general per-port blacklisting is a
> sledgehammer that often causes collateral damage.  I'd rather use
> affirmative hints to mark some ports as primary and others as secondary
> in these cases, instead of blacklisting.
>
> But this is actually SOP for ZTE and other devices.  Usually we have to
> scrape the windows INF files to find the modem and control ports, which
> then get encoded into the udev rules.  So if you have a device where the
> wrong port is being picked automatically, then we should certainly add
> some port hints for it.  See 77-mm-zte-port-types.rules for example.
>
> Dan
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/modemmanager-devel/attachments/20140130/4f4942f0/attachment.html>


More information about the ModemManager-devel mailing list