<div dir="ltr">Dan,<div><br></div><div>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.</div>

<div><br></div><div>Ben</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Jan 29, 2014 at 8:20 AM, Dan Williams <span dir="ltr"><<a href="mailto:dcbw@redhat.com" target="_blank">dcbw@redhat.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Wed, 2014-01-29 at 00:04 -0800, Ben Chan wrote:<br>
> Hi Aleksander,<br>
><br>
> I notice that some dongles have broken AT ports, e.g. ttyUSB1 appears to be<br>
> AT-capable but fails to handle most AT commands, while ttyUSB3 is<br>
> completely functional. ModemManager may pick ttyUSB1 as primary and ttyUSB3<br>
> as secondary.<br>
><br>
> What's the recommended way to blacklist ttyUSB1 in such case?  I guess I<br>
> could add a udev rule to avoid setting MM_CANDIDATE=1 on ttyUSB1.<br>
<br>
</div></div>We try to avoid per-port blacklisting because it's got a lot of<br>
possibility for abuse for reasons kinda like this.  Not that your case<br>
is a problem, but that in general per-port blacklisting is a<br>
sledgehammer that often causes collateral damage.  I'd rather use<br>
affirmative hints to mark some ports as primary and others as secondary<br>
in these cases, instead of blacklisting.<br>
<br>
But this is actually SOP for ZTE and other devices.  Usually we have to<br>
scrape the windows INF files to find the modem and control ports, which<br>
then get encoded into the udev rules.  So if you have a device where the<br>
wrong port is being picked automatically, then we should certainly add<br>
some port hints for it.  See 77-mm-zte-port-types.rules for example.<br>
<span class="HOEnZb"><font color="#888888"><br>
Dan<br>
<br>
</font></span></blockquote></div><br></div>