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
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1445080
Title:
Cellular data not activated after exiting flight mode
To manage notifications about this bug go to:
https://bugs.launchpad.net/canonical-devices-system-image/+bug/1445080/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
