NM/ofono FlightMode problem

[Tony Espy <espy canonical com>]

Dan --

I'd like to hear your opinion about the following problem I'm trying to 
solve, and your take on an idea I have of how to fix it.

This occurs with the current version of NetworkManager we're using for 
Ubuntu on phones, 0.9.10.0-4ubuntu15.1.1 ( see [1] for bzr packaging 
branch ).

One  of the patches ( ignore_rfkill_if_urfkill_is_present.patch ) we're 
carrying allows NM to integrate with urfkill, a daemon that we use for 
implementing FlightMode, and managing the desired state across reboots 
of FlightMode and any other system radio killswitches.  There's a long 
story about why this daemon needed to be used, but I'll keep that out of 
the discussion for now.

Please note, I'm pretty sure the following description is correct, 
however it's possible that I missed something...

When the urfkill Killswitch DBus signal is received that indicates that 
a radio killswitch for WWAN has been is disabled ( ie. setting the modem 
online ), a callback in NM_MANAGER gets invoked. This callback then 
invokes nm_manager_update_radio_enabled, which in turn iterates over all 
the MANAGER's devices looking for a matching rf_type, and when found 
calls nm_device_set_enabled for the device.

This eventually bubbles down to our NM_MODEM_OFONO subclass, which 
actually doesn't do anything other than log the set_enabled call ( note, 
urfkill is responsible for onlining/offlining the modem via ofono ).

As part of this chain of calls, NM_MODEM sets the modem_state to 
ENABLING, which in turn triggers NM_DEVICE_MODEM to set the device_state 
to DISCONNECTED, as the device has now become *available* ( thanks to 
NM_DEVICE_MODEM->set_enabled setting the rf_enabled flag to TRUE ).

The problem is, this last device state change, triggers NM_DEVICE to 
refresh the available connections, however doing so calls back into the 
NM_MODEM_OFONO sub-class to check that connections are compatible.  When 
this happens, there's a chance that the ofono hasn't finished initizing 
the modem after being set online by urfkill.  If this happens, our modem 
connection is effectively stalled, as nothing other than another 
FlightMode toggle, or a reboot will re-kick the device to refresh it's 
available connections again.

I think the correct way to go about fixing this is to introduce the 
usage of the modem states DISABLED and ENABLED, as currently NM_MODEM 
only seems to use DISABLING and ENABLING.

Doing this would allow NM_MODEM_OFONO and NM_MODEM_BROADBAND to only 
signal the transition to DISABLED/ENABLED based on state and/or return 
values from ofono and modem-manager respectively.

Thoughts?

Regards,
/tony

[1] 
https://code.launchpad.net/~phablet-team/network-manager/vivid-phone-overlay