Re: ZTE modem problems and workrounds

[Dan Williams <dcbw redhat com>]

On Wed, 2009-07-01 at 10:24 +0100, Rick Jones wrote:
> --On Tuesday, June 30, 2009 17:10:43 -0400 Dan Williams
> <dcbw redhat com> wrote:
> > 
> > You may get two connections listed in NetworkManager for older
> versions
> > of NetworkManager.  NM 0.7.1 has patches to correct that, which ask
> HAL
> > for the 'parent' device of each port, and only creates one modem
> device
> > for each parent device it finds.  The logic to do that is somewhat
> > complex, but I'm fairly confident that 0.7.1 has the correct fixes
> here.
> > However, the output of 'lshal' would be helpful here to determine
> how
> > exactly the modem presents itself.
> 
> Output from lshal for everything relating to the device (19d2:0031)
> attached.
> 
> > Note that you'll also want at least one additional patch to NM, *or*
> you
> > can install the file attached that will fix a problem where NM was
> using
> > obsolete HAL keys for a few things.  Put the attached file
> >
> at /usr/share/hal/fdi/information/10freedesktop/01-deprecated-keys.fdi
> 
> Ah - that explains some things. I've added your .fdi file and it now
> only detects one modem. However there is a problem in that it is
> random as to whether it picks ttyUSB1 or ttyUSB2. Although ttyUSB1
> (interface 1) does respond to some AT commands, it won't actually

Ok, we need to figure out what commands it actually responds to, and see
if there's some way to distinguish the specific ports.  Are you able to
get a program like minicom or screen running on the ports so we can try
out some commands.  If you can do that, try the following commands on
all the ports the modem exposes, and let me know what they return
(including what port you entered it on):

ATI
AT+CGMM
AT+CGAP?

Second, do any of the non-usable ports spontaneously emit messages?
Huawei devices emit a variety of AT^BOOT, AT^RSSI, etc on the secondary
port that can't be used for PPP, and that's something we can detect.

>  function as a modem. It seems to be there purely for monitoring
> state, and receiving UMs when the modem is connected. If NM chooses
> this port then it will never connect. Sometimes it will not
> initialise, sometimes it gets as far as sending the ATDT string, but
> there is never a connection. You have to use ttyUSB2 (interface 3) as
> the real modem - I don't know how NM can be told to do this.

We probably can't figure this out reliably, because we're only sure
about your device.  If you re-plug it, does it *always* only work on
ttyUSB3/usbif3?  The problem is that this can change with firmware
version, cycle of the moon, etc, depending on a number of factors.  We
can't simply assume it's always going to be the same, which makes it
really fragile to hardcode somewhere.

Some devices actually have defined USB interfaces for different things,
some have special commands to look up the port types (hso), others have
special AT responses that indicate different ports (sierra).

Dan

> > What driver binds to which device is entirely a kernel thing.  The
> > drivers themselves specify which devices they can control, and the
> > kernel will bind that driver to the device when it shows up.
> 
> Thanks - after a quick dig in the code of option.c I see how that
> works now.
> 
> I'm also trying to get more details of the problem with the state 7->8
> transition with ppp. I'll send some log output later in a separate
> message.
> 
> Rick