Re: problems with 3g based connections

[Dan Williams <dcbw redhat com>]

On Fri, 2010-07-16 at 12:16 +0200, van Schelve wrote:
> Am Donnerstag, den 15.07.2010, 02:00 +0200 schrieb Dan Williams
> <dcbw redhat com>:
> > On Mon, 2010-07-05 at 08:42 +0200, van Schelve wrote:
> >> >> Hi,
> >> >> 
> >> >> some days ago I have reported a curious issue with modem-manager. 
> >> >> My main Problem is that I'm sometimes not able to dialup a modem
> based
> >> 3g
> >> >> connection. The connection is not listed in nm-applet in this case
> and
> >> in
> >> >> syslog I have entries like this one: 
> >> >> 
> >> >> ... 
> >> >> May 21 10:055:28 nc0631 modem-manager: (tty/ttyUSB0): outstanding
> >> support
> >> >> task prevents export of
> /sys/devices/pci0000:00/0000:00:1d.1/usb6/6-1
> >> >> ...
> >> > 
> >> > This means that some ports of the modem are still being detected and
> >> > probed.  The modem cannot be used until all ports have completed
> >> > detection.
> >> > 
> >> >> @Dan, you asked me to bring more debug but I'm not able to reproduce
> >> this
> >> >> issue while manually starting nm / mm in debug mode. 
> >> >> Therefore: is it possible to run network-manager / modem-manager per
> >> >> default in debug mode while starting over upstart?
> >> > 
> >> > Possibly, but the debug output doesn't go to syslog, so unless it
> gets
> >> > stored somewhere by upstart it'll get lost.
> >> 
> >> We were able to capture the debug output. Without debug we run 6 of 10
> >> times into
> >> this problem. Running mm in debug mode we were able to reproduce it 3
> of
> >> 10 times.
> >> 
> >> http://pastebin.com/RS5vDxwJ
> >> http://pastebin.com/FmZbkJnc
> >> http://pastebin.com/97GPPbZW
> > 
> > This is good stuff; near the end of the log entries you'll see:
> > 
> > ** (modem-manager:1054): DEBUG: <1278077341.1209> (ttyUSB1): --> 00 78
> f0
> > 7e
> > ** (modem-manager:1054): DEBUG: <1278077342.610807> (ttyUSB1): <-- 7e 00
> > 0a 6b 24 00 00 07 00 00 00 00 00 00 00 7e
> > ** (modem-manager:1054): DEBUG: <1278077349.610774> (ttyUSB1): <-- 7e 00
> > 0a 6b 25 00 00 07 00 00 00 00 00 00 00 7e
> > ** (modem-manager:1054): DEBUG: <1278077356.610695> (ttyUSB1): <-- 7e 00
> > 0a 6b 26 00 00 07 00 00 00 00 00 00 00 7e
> > ** (modem-manager:1054): DEBUG: <1278077363.610729> (ttyUSB1): <-- 7e 00
> > 0a 6b 27 00 00 07 00 00 00 00 00 00 00 7e
> > ** (modem-manager:1054): DEBUG: <1278077370.610737> (ttyUSB1): <-- 7e 00
> > 0a 6b 28 00 00 07 00 00 00 00 00 00 00 7e
> > ** (modem-manager:1054): DEBUG: <1278077377.606758> (ttyUSB1): <-- 7e 00
> > 0a 6b 29 00 00 07 00 00 00 00 00 00 00 7e
> > 
> > so ttyUSB1 is a Sierra CnS port (their "Control and Status" protocol)
> > and MM isn't correctly failing out the QCDM probe.  What modem is this
> > again?
> > 
> Dan, you're right. It is the CnS port of the Sierra Wireless MC8775.
> And I think we found the reason for the problem. In addition to all the
> networkmanager components we have a special application, called wsm, that
> displays several informations from the modem like signal strenth, cell
> information
> active band, firmware version, hardware version.
> 
> These information are taken via CnS. We have disabled this tool and did
> some further
> tests with the result that in 50 / 50 tries everything works fine.
> 
> So we decided to remove the wsm tool from users autostart and hope that we
> will get
> the cell information in the future direct from nm-applet.
> 
> But if you are intereted in our tool, I can send it to you via pm. It's
> GPL code.

Yes, I'm quite interested.  I have CnS documentation for CDMA devices
already, but havne't gotten around to implementing it quite yet.  But
I'd love to work on it in the near future.  The idea was to create a
'libsierracns' like I already wrote 'libqcdm' and integrate that into
ModemManager and the Sierra plugin.

Dan