Comment 21 for bug 1445080

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