Re: ZTE modem problems and workrounds



On Tue, 2009-06-30 at 21:46 +0100, Rick Jones wrote:
> I've had quite a bit of trouble getting a ZTE 627 3G modem to work
> reliably with NM. I've spent a lot of time testing, poking, and
> prodding, and there are problems in several areas. Not all of this is
> NM directly, but it all impinges.
> 
> I've posted everything I've found on the Ubuntu forums, specifically
> this post:
> <http://ubuntuforums.org/showthread.php?p=7539275#post7539275>, please
> refer to this (and some earlier posts in that thread) rather than me
> re-post everything here. 

> This is why you sometimes get two connections listed in
> NetworkManager, when it thinks there are two modems, but if you try
> to use the one that's on ttyUSB1, chances are it won't connect.

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.

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

Some logging output of NM would also be helpful when you plug the modem
in.

NM 0.8 + ModemManager will actually fix this for good, but we'll keep
trying to make NM 0.7.x work too.

> I don't know how the system decides to use the "option" driver for a
> given port. I think this is handled by HAL, but I don't really
> understand HAL or how its config files work. When I originally got
> this device working on Hardy I had to add a .fdi file to get NM to see
> the device. I'm now on Jaunty, with a 2.6.29 kernel, and it turns out
> the .fdi file is no longer needed, but I can't find where the device
> is defined in the standard files.

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.

Dan

Attachment: 01-deprecated-keys.fdi
Description: application/xml



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]