Mobile data doesn't automatically connect after leaving wifi

Bug #1533508 reported by Dubstar_04
96
This bug affects 21 people
Affects Status Importance Assigned to Milestone
Canonical System Image
Fix Released
Critical
Unassigned
network-manager (Ubuntu)
Invalid
Undecided
Unassigned
ofono (Ubuntu)
Fix Released
Undecided
Alfonso Sanchez-Beato

Bug Description

The mobile data doesn't automatically connect when leaving wifi.

Expected Behavior:
- Leave wifi
- Mobile data connects automatically

Observed Behavior:
- Leave wifi
- Mobile data is available but user interaction is required to connect. The device requires a reboot or airplane mode to be cycled before a connection is made.

Tags: connectivity

Related branches

Revision history for this message
Dubstar_04 (dubstar-04) wrote :
description: updated
Dubstar_04 (dubstar-04)
description: updated
Revision history for this message
Jean-Baptiste Lallement (jibel) wrote :

I confirm this behaviour the device frequently doesn't switch to cellular data automatically.

Observed on
current build number: 217
device name: arale
channel: ubuntu-touch/rc-proposed/meizu.en

and previous builds.

Changed in canonical-devices-system-image:
status: New → Confirmed
importance: Undecided → High
assignee: nobody → John McAleely (john.mcaleely)
milestone: none → ww02-2016
Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in network-manager (Ubuntu):
status: New → Confirmed
Changed in canonical-devices-system-image:
milestone: ww02-2016 → ww08-2016
Revision history for this message
Tony Espy (awe) wrote :

@Jean-Baptiste

Do you end up with the same network-menu as shown in screenshot included with comment #1?

The network icon shown on the menu indicates that WiFi is off, and no mobile data connection.

If you can reproduce again, can you please include the output of these commands:

% /usr/share/ofono/scripts/list-modems -p

% nmcli d

Also can you please attach the syslog too?

Changed in network-manager (Ubuntu):
status: Confirmed → Incomplete
Revision history for this message
Tony Espy (awe) wrote :

@Dubstar_04

Can you please let us know what device you're using? Also, in addition to the information requested in comment #4, could you please include details about what software you're running on the device? Please either grab a screenshot of Settings::About This Phone::OS, or the output from the command 'system-image-cli -i'.

Revision history for this message
Jean-Baptiste Lallement (jibel) wrote :

Yes, exactly same screenshot than comment 1. Here is syslog from when I reproduced, I forgot to save list-modems and nmcli. I'll do next time I've this problem.

Revision history for this message
Dubstar_04 (dubstar-04) wrote :

@awe

I am currently using an MX4 on OTA8.5. Next time i experience the issue I will try to capture the required logs.

Revision history for this message
Dubstar_04 (dubstar-04) wrote :

Logs Attached.

Revision history for this message
Dubstar_04 (dubstar-04) wrote :
Revision history for this message
Dubstar_04 (dubstar-04) wrote :
Revision history for this message
Dubstar_04 (dubstar-04) wrote :
Revision history for this message
Dubstar_04 (dubstar-04) wrote :
Revision history for this message
Dubstar_04 (dubstar-04) wrote :
Revision history for this message
Dubstar_04 (dubstar-04) wrote :

I created 2 sets of logs.

- one with wifi on.
- one with wifi off.

Hopefully these will help. if there is anything else I can do to help debug please let me know.

Thanks,

Dan

Revision history for this message
Jean-Baptiste Lallement (jibel) wrote :

syslog, list-modems -p and nmcli d when the device didn't reconnect to cellular data and no wifi connection was available.

description: updated
description: updated
Revision history for this message
Timo Jyrinki (timo-jyrinki) wrote :

This happened to me on Bq E4.5 for the first time now after I upgraded from OTA-8.5 to OTA-9.

tags: added: connectivity
Changed in canonical-devices-system-image:
importance: High → Critical
Revision history for this message
Timo Jyrinki (timo-jyrinki) wrote :

Silo 032 has long pending networking fixes that now have seen more recent work and the silo might be in shape for landing.

As an interested party in this networking related bug (among many), could you please give 032 a whirl on vivid-overlay (xenial also available) and test your networking in general in addition to this particular bug? If we see no regressions - and we do see fixes - we could try landing the silo.

Upgrade with 'citrain device-upgrade 32 0000'.

Revision history for this message
Andrea Bernabei (faenil) wrote :

I hit the same bug :)
Krillin, rc-proposed, r245

here's list-modems output http://pastebin.ubuntu.com/14866296/

and nmcli d reports
DEVICE TYPE STATE CONNECTION
ril_0 gsm unavailable --
ril_1 gsm unavailable --
ifb0 ifb unmanaged --
ifb1 ifb unmanaged --
lo loopback unmanaged --
ip6tnl0 unknown unmanaged --
sit0 unknown unmanaged --
tunl0 unknown unmanaged --

Revision history for this message
Alfonso Sanchez-Beato (alfonsosanchezbeato) wrote :

In all cases list-modems show something similar to:

[ org.ofono.ConnectionManager ]
        RoamingAllowed = 0
        Powered = 1
        Bearer = hspa
        Attached = 0

The modem is not attached, so no connection is possible. But, we are able to detect a bearer, which is suspicious. It might be ofono wrongly reporting a detached state, when connection to cellular might be actually possible.

Revision history for this message
Timo Jyrinki (timo-jyrinki) wrote :

If there is a Qt side to this bug, the silo 32 has a certain probability of fixing it.

Revision history for this message
Timo Jyrinki (timo-jyrinki) wrote :

Hmm, nope, I've occasionally seen this both with and without silo 32 on my daily phone.

no longer affects: qtbase-opensource-src (Ubuntu)
no longer affects: qtbase-opensource-src (Ubuntu RTM)
Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in ofono (Ubuntu):
status: New → Confirmed
Changed in canonical-devices-system-image:
assignee: John McAleely (john.mcaleely) → Alfonso Sanchez-Beato (alfonsosanchezbeato)
Revision history for this message
Alfonso Sanchez-Beato (alfonsosanchezbeato) wrote :

If anybody is able to reproduce this and does not mind making the system image writable, please try downloading and installing

http://people.canonical.com/~abeato/debug/ofono_1.17-debug-attachment.deb

AND modify /etc/init/ofono.override changing line

exec ofonod -P provision,udev*,dun*,smart*,hfp_bluez5,stktest,sap

to

exec ofonod -d -P provision,udev*,dun*,smart*,hfp_bluez5,stktest,sap

Changed in ofono (Ubuntu):
status: Confirmed → Incomplete
Changed in canonical-devices-system-image:
status: Confirmed → Incomplete
assignee: Alfonso Sanchez-Beato (alfonsosanchezbeato) → John McAleely (john.mcaleely)
milestone: ww08-2016 → 11
Revision history for this message
Alfonso Sanchez-Beato (alfonsosanchezbeato) wrote :

Finally I was able to reproduce this issue with traces. syslog attached.

Revision history for this message
Alfonso Sanchez-Beato (alfonsosanchezbeato) wrote :

If anybody else is able to reproduce this, it would be great to have the output of

/usr/share/ofono/scripts/list-contexts

additionally to list-modems and nmcli output.

Revision history for this message
Alfonso Sanchez-Beato (alfonsosanchezbeato) wrote :

This is how the bug is apparently produced:

1. NM asks ofono to activate a context
2. Network is gone just a moment after that and modem detaches
3. Attached property is set to FALSE by ofono, then it tries to deactivate activated contexts, but there are none (no response yet from the request sent in step 1)
4. A few seconds later, the context is activated. Obviously the modem has registered again, but no event has triggered for that yet.
5. Modem says it is registered, right AFTER it has activated the context (which is maybe not the most correct sequence of events). Ofono detects that there are active context and it assumes it asked these context to close when it set Attached to FALSE. But that is not true as there were no active context when we did that. We do not change Attached property because ofono waits for old contexts to close before setting Attached to TRUE.
6. We stall until the active context is finally closed by some external event, which might happen hours later. While we are in this situation there is an active context, but probably it is not used by NM as it does nothing with ofono until Attached is TRUE. This last thing needs confirmation.

Changed in ofono (Ubuntu):
status: Incomplete → Confirmed
Changed in canonical-devices-system-image:
status: Incomplete → Confirmed
Changed in canonical-devices-system-image:
assignee: John McAleely (john.mcaleely) → Alfonso Sanchez-Beato (alfonsosanchezbeato)
Changed in ofono (Ubuntu):
assignee: nobody → Alfonso Sanchez-Beato (alfonsosanchezbeato)
Changed in canonical-devices-system-image:
assignee: Alfonso Sanchez-Beato (alfonsosanchezbeato) → nobody
Revision history for this message
Alfonso Sanchez-Beato (alfonsosanchezbeato) wrote :

Fix for this in:

https://github.com/rilmodem/ofono/pull/238

Note: it is possible to still having some issues with connections. see bug #1565717 .

Changed in canonical-devices-system-image:
status: Confirmed → Fix Committed
Changed in ofono (Ubuntu):
status: Confirmed → Fix Released
Changed in network-manager (Ubuntu):
status: Incomplete → Invalid
Changed in canonical-devices-system-image:
status: Fix Committed → Fix Released
Revision history for this message
Dubstar_04 (dubstar-04) wrote :

This is still happening for me.

Revision history for this message
Alessandro Roncador (roncador-ale) wrote :

Issue affect data connection if switching from one mobile operator to another. When connected to host network data connection is disabled by setting (to avoid extra charge) but is not reconnected when own network is available. Device Aquaris E5, OTA-11

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.