Cellular data not activated after exiting flight mode

[Alfonso Sanchez-Beato]

Cellular data is not activated in ~50% of the cases in arale after setting then unsetting flight mode.

I obtained the attached log this way:

1. Disabled wifi (to have less noise) and removed syslog (to make smaller the attached one)
2. Reboot
3. See cellular data is on: route is right, I have network access
4. Set flight mode
5. Unset flight mode
6. Data is not restored even after waiting for a few minutes. ccmni0 interface is down.

list-modems shows that the modem is data-attached
list-contexts output shows that no IP context has been activated

Doing

usr/share/ofono/scripts/activate-context 1
sudo ip route add default dev ccmni0
ping 8.8.8.8

works and I receive the ping responses.

$ system-image-cli -i
current build number: 12
device name: arale
channel: ubuntu-touch/tangxi-vivid-proposed
last update: 2015-04-16 08:06:39
version version: 12
version ubuntu: 20150416.0
version device: a17b9320788e7215ddf123544a3a2b5a4fa61f0d5add83f393866e8c7a9155b0
version custom: 20150416.0

+ NetworkManager 0.9.10.0-4ubuntu15~mtrudel1 (silo 29 atm)

[Ricardo Salveti (rsalveti)]

I could also easily reproduce that with mako/arale 173, without any custom network manager packages.

[Tony Espy (awe)]

@Ricardo

Can you let me know what version of network-manager is in your images?

I just tried to reproduce this with mako ( vivid-proposed #178 ) and it works just fine. The version of the NM in this image is 0.9.10.0-4ubuntu15. This version contains my most recent re-connect fix, which might be what your hitting. See bug #1418077 for details.

[Tony Espy (awe)]

Also when debugging issues with NM connections, please add the output of 'nmcli d' to the bug reports, as this will show NM's view of the connections.

[Tony Espy (awe)]

I did managed to reproduce this on arale ( vivid-proposed #165 ) with the recent version of NM which fixes bug #1418077.

'nmcli d' shows the modem as disconnected. list-modems shows the ConnectionManager interface both powered and attached per Alfonso's original description. The modem is registered to a carrier using UMTS, and list-contexts shows no active contexts.

[Tony Espy (awe)]

@Ricardo

Can you also confirm that the modem is online too when you try to reproduce? Just want to ensure you're not hitting the urfkill saved state problem. Also does a reboot restore a working connection?

[Ricardo Salveti (rsalveti)]

Yup, modem is online just fine, the side effect is the same described by Alfonso (and you at comment #5).

Modem is online, powered and attached, without any active context.

current build number: 179
device name: m75
channel: ubuntu-touch/vivid-proposed
last update: 2010-01-01 01:29:38
version version: 179

[Tony Espy (awe)]

@Ricardo

What about mako? I have a hunch this is arale-specific as I couldn't reproduce on mako.

[Ricardo Salveti (rsalveti)]

Just tested again and was again able to reproduce on mako:

phablet@ubuntu-phablet:/usr/share/ofono/scripts$ ./list-modems
[ /ril_0 ]
    Revision = M9615A-CEFWMAZM-2.0.1700.98
    Serial = 353918052313257
    Online = 1
    Type = hardware
    Features = ussd net gprs sms rat sim
    Emergency = 0
    Model = Fake Modem Model
    Lockdown = 0
    Powered = 1
    Interfaces = org.ofono.CallBarring org.ofono.CallSettings org.ofono.SupplementaryServices org.ofono.NetworkRegistration org.ofono.ConnectionManager org.ofono.Phonebook org.ofono.CallForwarding org.ofono.SmartMessaging org.ofono.PushNotification org.ofono.MessageManager org.ofono.NetworkTime org.ofono.MessageWaiting org.ofono.RadioSettings org.ofono.SimManager org.ofono.CallVolume org.ofono.VoiceCallManager
    Manufacturer = Fake Manufacturer
    [ org.ofono.CallBarring ]
        VoiceIncoming = disabled
        VoiceOutgoing = disabled
    [ org.ofono.CallSettings ]
        CallingLineRestriction = off
        CalledLinePresentation = disabled
        CallingLinePresentation = enabled
        HideCallerId = default
        ConnectedLineRestriction = unknown
        ConnectedLinePresentation = unknown
        VoiceCallWaiting = enabled
        CallingNamePresentation = unknown
    [ org.ofono.SupplementaryServices ]
        State = idle
    [ org.ofono.NetworkRegistration ]
        CellId = 3198203
        Technology = umts
        MobileCountryCode = 724
        LocationAreaCode = 40248
        Status = registered
        MobileNetworkCode = 06
        Mode = auto
        Name = VIVO
        Strength = 45
    [ org.ofono.ConnectionManager ]
        Attached = 1
        Powered = 1
        RoamingAllowed = 0
        Bearer = hspa
        Suspended = 0
    [ org.ofono.Phonebook ]
    [ org.ofono.CallForwarding ]
        ForwardingFlagOnSim = 0
        VoiceNoReplyTimeout = 30
        VoiceNoReply = [phone]
        VoiceUnconditional =
        VoiceBusy = [phone]
        VoiceNotReachable = [phone]
    [ org.ofono.SmartMessaging ]
    [ org.ofono.PushNotification ]
    [ org.ofono.MessageManager ]
        ServiceCenterAddress = [phone]
        Alphabet = default
        Bearer = cs-preferred
        UseDeliveryReports = 0
    [ org.ofono.NetworkTime ]
    [ org.ofono.MessageWaiting ]
        VoicemailMailboxNumber = *555
        VoicemailMessageCount = 0
        VoicemailWaiting = 1
    [ org.ofono.RadioSettings ]
        TechnologyPreference = umts
        FastDormancy = 0
        ModemTechnologies = gsm umts
    [ org.ofono.SimManager ]
        BarredDialing = 0
        CardIdentifier = 89551090318161348308
        FixedDialing = 0
        MobileNetworkCode = 06
        Retries =
        LockedPins =
        SubscriberIdentity = 724064900113482
        PinRequired = none
        MobileCountryCode = 724
        ServiceNumbers = [Policia] = '190' [Defesa Civil] = '199' [Bombeiros] = '193' [Vivo no Mundo] = '[phone]' [Vivo] = '*8486' [Ambulancia] = '192'
        SubscriberNumbers = [phone]
        Present = 1
        PreferredLanguages = pt es en
    [ org.ofono.CallVolume ]
        SpeakerVolume = 0
        MicrophoneVolume = 0
   ...

[Ricardo Salveti (rsalveti)]

And works fine after a reboot (still with wifi disabled).

[Ricardo Salveti (rsalveti)]

It seems NM was trying to connect, but that never actually succeeded:
Apr 21 21:47:01 ubuntu-phablet NetworkManager[1518]: <debug> [1429652821.190832] [nm-modem-manager.c:205] poke_modem_cb(): Requesting to (re)launch modem-manager...
Apr 21 21:49:01 ubuntu-phablet NetworkManager[1518]: <debug> [1429652941.287746] [nm-modem-manager.c:205] poke_modem_cb(): Requesting to (re)launch modem-manager...
Apr 21 21:51:01 ubuntu-phablet NetworkManager[1518]: <debug> [1429653061.188103] [nm-modem-manager.c:205] poke_modem_cb(): Requesting to (re)launch modem-manager...
Apr 21 21:53:01 ubuntu-phablet NetworkManager[1518]: <debug> [1429653181.282422] [nm-modem-manager.c:205] poke_modem_cb(): Requesting to (re)launch modem-manager...

[Jonathan Cave (jocave)]

Version: ubuntu-touch/devel-proposed/krillin.en r59 krillin

Slightly different scenario with similar symptoms:

 * Tesco Mobile SIM in slot 1 (O2 MVNO)
 * On booting the phone registers on network and cellular data is enabled
 * Can browse internet etc
 * After some time it appears the network drops (bars empty)
 * It reconnects quickly but the data connection does not come back up

[Jonathan Cave (jocave)]

list-contexts when data is working

[Jonathan Cave (jocave)]

list-contexts when data down

[Tony Espy (awe)]

@Jonathan

That's a very different scenario as Flight-Mode is not involved, please add your comments to bug #1424791 instead.

[Tony Espy (awe)]

I've just tried on krillin ( vivid-proposed / #193 ); conformed NM version is: 0.9.10.0-4ubuntu15. I had a single AT&T SIM in the first slot.

WiFi disabled, I toggled FM on/off ten times. Sometimes I'd tap the toggle as soon as it became active, sometimes I waited up to 1-2m before toggling. Although there's lag to search and find a network, once signal bars appear, the 2g icon appears shortly ( <30s ) thereafter.

[Will Quincay (mini-lee)]

On Aquaris BQ e4.5, Ubuntu 14.10 (r22), image part 20150528.

After reboot in flight mode, SIM card is recognized, but impossible to enter PIN code, the Unlock button is invalid.

You can reproduce it like that :
-set flight mode
-turn off the device
-turn on the device
-unset flight mode
-> the Unlock button is out of order...
a reboot with flight mode unset is needed to be able to enter PIN code.

Do not know if it could be linked with above messages...
Thanks

[Tony Espy (awe)]

@Will

Thanks for your comment. I was just able to reproduce this using a devel image from two weeks ago ( ubuntu-touch/rc-proposed/ubuntu #171 ). I'm pretty sure this is an unrelated problem. Could you please file a new bug against ofono? Also please add if you had one or two SIMs installed?

[Tony Espy (awe)]

@Will

It appears that this may be related to an enhancement/fix which auto-unlocks the phone when FlightMode was toggled and a PIN-locked SIM was inserted. This works well ( at least with one PIN-locked SIM installed... I didn't try two ).

[Tony Espy (awe)]

So regarding the original bug, there are two scenarios that can happen when FlightMode is enabled on arale. These same scenarios could also occur on other platforms as well, which would explain why @Ricardo was able to reproduce on mako.

1. When FlightMode is enabled, often the first event NM sees is the ofono gprs context's 'Settings' property change to {} ( ie. the connection has been closed, so no IP settings exist anymore ). This failure of an active connection causes the connection_retry count ( currently at 4 ) to drop by 1.

When this happens, NM immediately schedules an activation check ( on the idle queue ), but as not much else is happening, the activation attempt occurs almost immediately. The attempt fails, as ofono is in the middle of bringing down the modem. NM actually manages to try three times in a row, and then disables the connection because the retry_count of the connection has hit zero. This causes a 5m timer to be set, which will reset the retry count and re-trigger auto-activation.

When the timer fires, the reset fails to auto-activate the connection. The cause of why it fails to auto-activate when the timer goes off is still being investigated, but it believed to be related to the following scenario.

2. Other times when FlightMode is enabled, it's possible for the NM_MODEM_OFONO instance to detect that the modem has gone offline and/or detached from GPRS *before* the active connection drops. This is good, because there's code that recognizes this, and disables auto-connect for the connection ( so the whole retry / 5m timer logic doesn't trigger ). There's also code that re-enables auto-connect when it seems the modem re-attach to GPRS and go Online.

At some point during the modem online process, the device state goes from UNAVAILABLE to DISCONNECTED, which triggers NM_DEVICE to refresh it's available connections. This eventually bubbles down to a function in the NM_MODEM_OFONO class called check_compatible_connection(). This function attempts to read ofono's SimManager 'SubscriberIdentity' property from DBus synchronously, and doesn't check for an empty value. It then uses this value for comparison against the connection ID ( which is the SubscriberIdentity/context name ) and the check fails, so the connection isn't added to the the device's list of available connections, which in turn prevents the connection from being activated...

This

[Alfonso Sanchez-Beato (alfonsosanchezbeato)]

@Will, @Tony:

The behaviour you see is probably related to indicator-network, so if you open a bug please include that package too. I think the behaviour has improved after latest landings for that package which fixed some problems for PUK-blocked SIMs, although issues still remain.

I do not really think that the auto-unlocking change is related, as that would not trigger after a reboot.

[Łukasz Zemczak (sil2100)]

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

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

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

  * debian/patches/lp1445080-fix-modem-flight-mode.patch: re-work
    NMModemOfono's modem state logic to get rid of a race condition
    that can cause flight-mode to fail and leave the modem stuck
    with no active connections (LP: #1445080).

 -- Tony Espy <email address hidden> Sat, 27 Jun 2015 16:08:26 -0400

[Launchpad Janitor (janitor)]

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