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