Re: ZTE modem problems and workrounds

[Dan Williams <dcbw redhat com>]

On Thu, 2009-07-02 at 11:33 -0400, Dan Williams wrote:
> On Thu, 2009-07-02 at 15:59 +0100, Rick Jones wrote:
> > 
> > --On Thursday, July 02, 2009 10:19:24 -0400 Dan Williams
> > <dcbw redhat com> wrote:
> > 
> > > > > > To start with there is always +ZUSIMR:2 every 2 secs., this
> > can be
> > > > > > stopped by giving any version of AT+CPMS on either port (stops
> > the
> > > > > > messages on both ports). The only other UMs I see are +ZDONR
> > and
> > > > > > +ZPASR.
> > > > > 
> > > > > Ugh.  That sucks.  That means hardcoding stuff on a per-modem
> > basis,
> > > > > potentially using AT+CGMM responses instead of USB IDs, because
> > some
> > > > > vendors (Huawei) use the same USB ID for vastly different
> > devices to
> > > > > work around stupid Windows bugs.
> > > > 
> > > > I've found some ZTE windows inf drivers that appear to confirm
> > that
> > > > we'll need to hardcode ports.  Teh suck.
> > > 
> > > Rick, could I ask you to run 'lsusb -vv' for me while the modem is
> > > plugged in *and* has been put into modem mode?
> > 
> > I agree, sucks big-time. And from contributions to forums I've come
> > across there are other versions of this device with the same IDs but
> > with the modem on a different IF number (Australian version I
> > think) :(
> 
> Hmm, the ZTE windows .inf files seem to hardcode it on a USB VID/PID
> basis, so I hope we don't run into that.
> 
> > Is there no way to use HAL to define either the valid or the invalid
> > interface? With NM 0.7.0 it was necessary to add a .fdi which
> > specified the interface, but it doesn't seem to need that any more. Or
> > are you trying to get away from HAL?
> 
> Yes, HAL is dead, and already on the 'master' git branch only udev is
> used.
> 
> > Output from lsusb attached. It's the same regardless of whether the
> > modem is connected or not. One thing I noticed is that the transfer
> > type for one of the input EPs in IF3 is Interrupt - that's the only
> > one, all the others are Bulk.
> 
> Yeah, that could be a good clue.  We'd need to verify that for a few
> other ZTE devices though before running with it.

FWIW I've attempted to handle this issue in the following commits to

NM:
7406e3a0e8147e23ad3c5b775b3ce940c93ada2a

and ModemManager:
52da9990eef279bbc349685a7558d26cf4b7893b
869c69e223208564302ba3be074dafbdf1b02cc2

and ZTE is now on my hate-list.  Option did this nicely by implementing
a firmware call that returns the port type, which is really the right
thing to do.  But it boggles my mind that *every ZTE device is
different* according to the .INF files.  What a maintenance nightmare.

Dan