Re: ZTE modem problems and workrounds

[Rick Jones <rick activeservice co uk>]

Thanks - I sympathise re. ZTE.

Is this likely to come through as an update to 0.7.1, or will we have to wait until NM .8 with MM?

The last time I tried to compile NM from source myself was a total disaster :(

Cheers
Rick

--On Thursday, July 02, 2009 16:28:55 -0400 Dan Williams <dcbw redhat com> wrote:

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