Re: NM/ofono FlightMode problem

[Dan Williams <dcbw redhat com>]

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

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

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
this:

    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.

Dan

> 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
> _______________________________________________
> networkmanager-list mailing list
> networkmanager-list gnome org
> https://mail.gnome.org/mailman/listinfo/networkmanager-list