Cellular data connection stops after a while

@Jean-Baptiste

I'm pretty sure this is a duplicate of bug #1426122.

When your network fails, can you grab the output of the command 'nmcli d'?

The problem we've seen on arale & krillin with network-manager 0.9.10 is that the patch that makes network-manager ignore devices owned by rild, wasn't updated for arale & krillin, and the NM 0.9.10's behavior changed slightly such that it now will try and manage the rild devices when they become active.

Note, I see you attached the output of 'nmcli d' ( nmcli-dev.txt ), but what's important is the output after the problem occurs. The file you attached shows the initial state when things are working.

I rebooted the device, it established a data connection (H symbol in the indicator) then after less than 5 minutes it disconnected

$ nmcli d
DEVICE TYPE STATE CONNECTION
ril_0 gsm disconnected --
ril_1 gsm unavailable --
ifb0 ifb unmanaged --
ifb1 ifb unmanaged --
lo loopback unmanaged --
ip6tnl0 unknown unmanaged --
sit0 unknown unmanaged --
tunl0 unknown unmanaged --
ccmni0 wifi unmanaged --
ccmni1 wifi unmanaged --
ccmni2 wifi unmanaged --

@Jean-Baptiste

Hmmm, this looks different than bug #1426122.

How are you determining that it disconnected? Did the icon change or are you running a ping, or some other application attempting to use the network that starts failing?

Also can you:

1. attach the syslog from the device

2. attach the output of /usr/share/ofono/scripts/list-contexts

3. attach the output of /usr/share/ofono/scripts/list-modems

Moved back to Incomplete until we better understand the bug.

@Jean-Baptiste

Can you reproduce this reliably?

Also, it sounds like your steps are:

1. Boot the phone w/WiFi enabled, and in range of a remembered access point
2. Disable WiFi
3. Verify the mobile data connection comes up
4. After several minutes, the data connection will drop; sometimes it's re-established, sometimes not.

How is your cell reception? Do you a see strong cellular signal on the top-panel?

Finally, one thing that might help diagnose would be to install and run Sergio's network-test-session tool:

https://github.com/sergiusens/network-test-session

I tried to 1. boot with Wifi enabled, then disable it. 2. Boot with Wifi disabled
The result is the same, there is a cellular data connection, which drops after several minutes.

The signal is usually 2 or 3 bars, never less, never more.

I'll try Sergio's tool.

Here is the log of a test session when I reproduced this morning.

I booted the phone with Wifi, disabled Wifi, the device switched to 3G. At 10:10, it lost the connection and it came back at 10:15. The connection was stable for the rest of the test.
The indicator showed 3 bars then 2 bars.

OK, I'll take a dive into the network-test-session logs later today.

From your description in comment #9, it sounds like this is the same issue as bug #1418077, where something causes the mobile data connection to drop and NM takes ~5m to restore the connection. If the logs concur with my theory, I will dup this bug and update the other bug to include the scenario where the connection drops on its own ( ie. not triggered by a radio technology change ).

So it looks you indeed have hit #1418077.

This is pretty obvious by looking in the attached nmlog file, and search for connection '/208150102671184/context1'. You'll see it get disabled at 18:41:24 after a bunch of failed attempts ( modem-no-carrier ). It gets successfully auto-activated again in +5m.

That said, I also see something else that concerns me.

If you look at the netlog, after '/208150102671184/context1' is disabled, you'll see NM try a 'context3', 'context5', and 'context1' again. The odd thing is that the related IMSI is not '208150102671184' it's '208103698221268'. Looking at network-test-session.log ( also attached ), you'll see that '208150102671184' is the IMSI for ril_0, and that ril_1 is PIN-locked. It appears to me that NM may be trying contexts from other SIM directories it finds in /var/lib/ofono/.

I need some confirmation from Mathieu before I change this bug to Confirmed and re-title it...

I created bug #1431471 to track the wrong SIM problem mentioned in comment #11.