How to debug 3G USB modem problems?

[Uwe Geuder <networkmanagerList-ugeuder snkmail com>]

I understand that this a upstream list and most readers are interested
in the bleeding edge. However, I have to support some systems for
"naive" users and I prefer to use a plain vanilla distribution as long
as possible. So please bear with my question regarding versions
straight from the museum...

On Ubuntu 10.04 (long time support) they have nm version 0.8-0ubuntu3

The USB modem in use is a Nokia CS-17. (I know that if you search for
trouble, you select a 3G USB modem. Unfortunately this variant is
really by orders of magnitude cheaper in this case than anything more
reliable.)

The good news is that the CS-17 works even with that old software.

The bad news is that it's completely unreliable. Some 30%-50% of the
connection attempts just fail. Unfortunately the failures seem to come
in waves. If it fails the first time, it will also fail the 2nd, 3rd
etc. Removing the modem does not help. But 1 or 2 hours later it might
just work again. Alternatively if I want to repeat the problem, I can
make 15 connections in a row without any failure. 

The other problem is that while the connection typically stays open
for hours during normal web browsing, it will disconnect with quite
high probability when downloading bigger files. Today I needed 4 attempts
to download a 20 MB file.

I would exclude network-side problems or weak signal, because I use 3G
data on the same network nearly all day long on my smartphone without
such problems. Additionlly, when the USB modem fails to connect I can use
my phone as the modem using the data cable and everything works. 

So how could I debug this? Is it a Linux-side problem or a firmware problem
in the CS-17? (Haven't had a chance to test it with M$ yet)

>From searching in the mailing list archives I found 2 debugging hints:

1. starting nm from command line as

# NM_SERIAL_DEBUG=1 NM_PPP_DEBUG=1 NetworkManager --no-daemon | tee log.txt

That works nicely. When the connection attempt fails I see how PPP
negotiation starts, but it doesn't seem to get any reply. 

sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x5c8b3860> <pcomp> <accomp>]

After 5 repetitions pppd seems to give up and nm complains that the
connection failed.

(Not sure whether NM_SERIAL_DEBUG has any effect, I don't think I see that
variable in the source code of my version)

The problem is that using the command line (and root) is OK for me on
my test machine, but not for the user in question on the real target
machine. So I'd like to configure the "real" service such that logging is
always on.

I tried to do so by adding the 2 environment variables to
/etc/init/network-manager.conf (Ubuntu uses upstart)

env NM_PPP_DEBUG=1
env NM_SERIAL_DEBUG=1
exec NetworkManager

Unfortunately that seems to have no effect to the pppd logging. The
pppd stuff that I can see when running with --no-daemon does just not
appear in syslog, neither in successful nor in failing cases. (I have
checked from /proc/nnn/environ that the environment variables really
end up in the network-manager process)

Also the debug parameter appears on the pppd command line as shown in syslog.

How can I get pppd logging when running as a daemon?

2. The other hint I found in the mailing archive was a config file entry

[logging]
level=WARN

I changed that to level=DEBUG, but I don't think it made a
difference. Could not find such parameter in my source code. Has it
possibly been added only in a later version?


Yesterday I read in some forum that killing modem-manager after a
failed connection attempt helps. Today I had only very few failed
attempts in my testing and killing modem-manager helped each time. Not
yet sure whether this is really a reliable work-around. If yes, I
could of course script it.

Does the problem description ring any bells? If you remember specific fixes
that solve these issues, I might try to backport them to my
version. Or just install a newer version manually.

Regards,

Uwe


P.S. Yes, I am aware of the modeswitching. I left that out from the
description above, I'm sure that the modem was always in the right
mode.