Re: NM/ofono FlightMode problem

On Wed, 2015-06-03 at 20:40 -0400, Tony Espy wrote:
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.

Per our IRC conversation, you're using the "SimManager" interface
appearing, then grabbing the SubscriberIdentity as the indicator of

So let's assume your NMOfonoModem subclass of NMModem starts in the
INITIALIZING state when the modem object is detected from Ofono.  Your
NMModem subclass would never advance beyond the INITIALIZING state until
all of these conditions are met:

1) NM has called your set_mm_enabled() hook with true (you'd have to
cache that value internally)

2) The SimManager interface has appeared

3) SimManager.SubscriberIdentity has a valid value

at all 3 points where these things may change you can have a helper
function called maybe "check_modem_initialized()" that basically does

    if (rf_enabled && sim_manager && subscriber_identity) {
        NMModemState new_state = NM_MODEM_STATE_ENABLED;

        if (SimManager.PinRequired)
            new_state = NM_MODEM_STATE_LOCKED;

        nm_modem_set_state (NM_MODEM (self), new_state, <reason>);
    } else if (nm_modem_get_state (NM_MODEM (self)) > INITIALIZING) {
        nm_modem_set_state (NM_MODEM (self), INITIALIZING, <reason>);

so basically whenever ofono wasn't ready yet (modem in flight mode or
still initializing) the NMModem would sit in INITIALIZING state.
Whenever flight mode was activated the modem would jump back to
INITIALIZING.  This should prevent the modem from becoming 'available'
before it can actually be used, and might also fix the issue of
autoconnect retries becoming exhausted when flight mode is turned on
(that we discussed on IRC).

Hopefully this seems like it'll work to you, let me know if some things
look dubious though and we can continue to iterate.


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.



networkmanager-list mailing list
networkmanager-list gnome org

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