NM/ofono FlightMode problem

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, ( 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.



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

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]