Re: ZTE modem problems and workrounds

[Dan Williams <dcbw redhat com>]

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.

Dan