Re: [MM] [PATCH] iface-modem-3gpp: handle non-deferrable registration state updates

[Aleksander Morgado <aleksander lanedo com>]

On 06/05/13 19:46, Dan Williams wrote:
> > > > > > > > > Would a transition from 'registered' to 'idle'/'searching' considered a
> > > > > > > > > 'service' loss from the connection manager's perspective (e.g. the service
> > > > > > > > > disappears and then reappears in connection manager)?  In practice,  a
> > > > > > > > > +CEREG change may not necessarily mean that the service disappears. But I
> > > > > > > > > guess such a glitch can be smoothed out in the connection manager layer
> > > > > > > > > instead of the modem manager layer. I'm happy to update the logic as
> > > > > > > > > suggested if that's the expected behavior.
> > > > > > >
> > > > > > > Idle might be, searching probably wouldn't be.  For Searching I think we
> > > > > > > wanted to do the 15 or 30 second timer thing and only terminate if the
> > > > > > > modem didn't reacquire the network within that window?  If the device is
> > > > > > > 'idle' though, I'm pretty sure you're hosed and we should shut the
> > > > > > > packet data connection down.  If the device is 'idle', then it's not
> > > > > > > looking for a network, and it's not registered, so you have nothing.
> > > > >
> > > > >
> > > > > I'm fine with the 15s timeout when we are connected; but when not
> > > > > connected, a change from registered to either idle or searching should
> > > > > probably get notified in the DBus interface, that's the change I'm
> > > > > suggesting.
> > >
> > > Thinking it twice, what I think we should have is the following:
> > >
> > >  *  3GPP registration changes are notified always *right away* (no
> > > timeout) in the 3GPP DBus interface ("RegistrationState" property),
> > > regardless of whether we are connected or not.
> > >  *  Same for 3GPP2: CDMA1x and EV-DO registration changes are notified
> > > always *right away* (no timeout) in the CDMA DBus interface
> > > ("Cdma1xRegistrationState" and "EvdoRegistrationState" properties),
> > > regardless of whether we are connected or not.
> > >  * The 15s timeout to report unregistered should be set up only when the
> > > modem is connected; and the logic should be applied in the Modem
> > > interface, and only for the "State" property (so applicable to both 3GPP
> > > and 3GPP2).
> > >
> > >
> > > Some example cases:
> > >  1) If the modem *is not* connected and we get a 3GPP registration
> > > update from MM_MODEM_3GPP_REGISTRATION_STATE_HOME to
> > > MM_MODEM_3GPP_REGISTRATION_STATE_SEARCHING, "RegistrationState" in the
> > > 3GPP interface is updated right away, and the "State" property in the
> > > Modem interface is also updated (Registered->Searching) right away.
> > >
> > >  2) If the modem *is* connected and we get a 3GPP registration update
> > > from MM_MODEM_3GPP_REGISTRATION_STATE_HOME to
> > > MM_MODEM_3GPP_REGISTRATION_STATE_SEARCHING, "RegistrationState" in the
> > > 3GPP interface is updated right away, _but_ for the "State" property in
> > > the Modem interface we wait up to 15s before updating it
> > > (Connected->Disconnecting->Searching), in case we get a new registration
> > > state update back to HOME.
> Yeah, this seems like more correct behavior to me.  I think it's useful
> for clients to know the actual state of the registration, which
> obviously is a separate property to the overall modem state, and only
> one input into it.

Tracking the change here:

https://bugzilla.gnome.org/show_bug.cgi?id=699803

-- 
Aleksander