No data connection switching from 2G only to 3G

After waiting ~10 minutes, connection was up again. May be a duplicate of bug https://bugs.launchpad.net/canonical-devices-system-image/+bug/1418077

I used Movistar and Yoigo SIM cards.

Output of 'list-modems' and 'list-contexts': http://paste.ubuntu.com/11545969/

@Victor

Could you please reproduce and attach the system directly ( ie. not via past.ubuntu.com )?

Victor's list-modems output shows the modem registered to Yoigo ( mcc/mnc: 214/04 ), and the RadioSettings TechnologyPreference property set to "umts" ( 3g ). None of the contexts are active, which means NetworkManager has probably disabled the connection due to the autoconnect_retry limit being hit. I can't be sure till I see the syslog though...

Thanks for the log @Victor.

So the smoking gun is:

Jun 4 14:26:41 ubuntu-phablet NetworkManager[1408]: <info> Disabling autoconnect for connection '/214040113340577/context2'.

There's only one of these in the log. When this happens, NetworkManager has seen a disconnect for the modem, but hasn't yet seen the signal that the GPRS has de-tached ( which is what should happen when you change radio technology ). In this case, NM retries the modem rapidly, and burns through the autoconnect_retry_count for the connection. When this count reaches zero, NM sets a 5m timer to reset the retry_count and try again.

This is indeed similar to the bug #1418077 ( FixReleased ) and bug #1445080 ( InProgress). I have a partial fix for the latter bug which may resolve your specific scenario.

One question, do you wait for the network-indicator to show the mobile connection is active before switching the radio technology from 3g to 2g, and back again? I see the connection coming up in the syslog, but it looks like the technology gets toggled again before it's completely finished.

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

Tony: From 3G to 2G, the data connection is up in a short time. I wait until 2G data is up, and then switch from 2G to 3G. That forces to wait ~10 minutes.

We will poke in a fix for this

I've split out some of the code I was working on for bug #1445080 ( Cellular connection isn't restored after FlightMode disabled ) and created a proposed fix..

I've pushed a test version to my PPA for testing before I go ahead and create a silo ( I'd like the merge proposal reviewed as well ). You can just grab the network-manager and libnm-util2 packages from the PPA and install directly ( install libnm-util2 *before* the network-manager packages ):

https://launchpad.net/~awe/+archive/ubuntu/ppa/+packages

A couple of minor comments were addressed in the merge proposal, and a new version with an official version number has been pushed to the telephony PPA, this package will be binary sync'd to a silo for landing in the overlay PPA. I will post silo details when they become available.

For anyone else wanted to test, this fix has landed in silo-031:

https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-031

This bug was fixed in the package network-manager 0.9.10.0-4ubuntu15.1.2 in https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/stable-phone-overlay

---------------

network-manager (0.9.10.0-4ubuntu15.1.2) vivid; urgency=medium

  * debian/patches/lp1461593-add-modem-reconnect-delay.patch: add
    a 5s delay to NM_POLICY's activation logic triggered when a
    device is disconnected. This allows the modem time to settle
    and NM to process the resulting DBus state changes (LP: #1461593).

 -- Tony Espy <email address hidden> Mon, 08 Jun 2015 15:49:56 -0400

This bug was fixed in the package network-manager - 0.9.10.0-4ubuntu19

---------------
network-manager (0.9.10.0-4ubuntu19) wily; urgency=medium

  [ Tony Espy ]
  * debian/patches/add_ofono_settings_support.patch: remove code
    that added APN, USERNAME and PASSWORD to NM_SETTING_GSM object.
    NM doesn't actually need access to these settings, and USERNAME/
    PASSWORD can cause issues with NM's secrets needed logic.
  * debian/patches/0001-wwan-add-support-for-using-oFono-as-a-modem-manager.patch,
    debian/patches/lp1461593-add-nm-settings-connection-reset-retries-methods.patch,
    debian/patches/add_ofono_settings_support.patch,
    debian/patches/lp1461593-add-modem-reconnect-delay-to-policy.patch: More changes
    to NMModemOfono's modem_state handling. Added get/set_reset_retries_timeout
    methods to NMSettingsConnection, and use the set method to lower the timeout for
    ofono connections to 30s. Finally added a 5s delay to NM_POLICY's activation
    logic triggered when a modem device is disconnected. This allows modem time to
    settle and NM to process the resulting DBus state changes. (LP: #1461593)
  * debian/patches/0001-wwan-add-support-for-using-oFono-as-a-modem-manager.patch,
    debian/patches/lp1445080-modify-device-modem-avail.patch,
    debian/patches/lp1445080-nm-modem-check-for-set-mm-enabled-func.patch,
    debian/patches/lp1461593-add-modem-reconnect-delay-to-policy.patch: These
    changes collectively fix flight-mode on arale ( and other devices ), due to
    some fundemental race conditions in the ofono logic. (LP: #1445080, #1440917)
  * debian/patches/0001-wwan-add-support-for-using-oFono-as-a-modem-manager.patch,
    debian/patches/add_ofono_settings_support.patch: Add support for the ofono
    gprs-context 'Preferred' property. (LP: #1361864)

  [ Mathieu Trudel-Lapierre ]
  * d/p/0002-wifi-cull-the-scan-list-before-signalling-ScanDone-b.patch:
    Re-add schedule_scan() call after we get the ScanDone signal from the
    supplicant. Otherwise we'd do one scan on startup and never scan again.
    (LP: #1445134)

 -- Mathieu Trudel-Lapierre <email address hidden> Wed, 05 Aug 2015 12:17:28 -0400