After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 699803 - [MM 0.8] Notify registration changes right away
[MM 0.8] Notify registration changes right away
Status: RESOLVED FIXED
Product: NetworkManager
Classification: Platform
Component: ModemManager
git master
Other Linux
: Normal normal
: ---
Assigned To: NetworkManager maintainer(s)
NetworkManager maintainer(s)
Depends on:
Blocks:
 
 
Reported: 2013-05-07 07:51 UTC by Aleksander Morgado
Modified: 2013-05-20 07:13 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Aleksander Morgado 2013-05-07 07:51:49 UTC
*  3GPP registration changes should be 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 should be 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.
Comment 1 Aleksander Morgado 2013-05-07 13:08:09 UTC
The 'aleksander/registration-updates' branch removes the deferred registration update from the 3GPP interface; and just allows going back to SEARCHING without stopping the connection.

I wonder if this is enough, and fully avoid the deferred registration updates... Ben, Dan, any comment on this?
Comment 2 Ben Chan 2013-05-07 18:07:33 UTC
In practice, we observed that some modems report +CEREG status 2 (searching) followed by +CEREG status 1 (registered) within a second or two. That seems to happen when the modem is on the border of two cells. The modem usually recovers from the registration state change very quickly without interrupting the IP connectivity. So the original motivation of deferring the registration state updates was to smooth out these kinds of glitches, which from the user's perspective, should be transparent.

There are two aspects to consider with the new implementation:

1. The existing connection shouldn't be dropped if the registration state is recovered within 15s

2. From the connection manager's perspective, a registration state loss may cause the associated service to drop as the operator info is associated with the registration. e.g. the user may see the associated mobile network disappears and reappears as the registration goes away and comes back. That may be ok if the modem is not connected. But it seems quite confusing when the modem is still connected.

Aspect (1) seems to remain unchanged in the new implementation. I'm more concerned about aspect (2) regarding the immediate registration state update while the modem is still connected.
Comment 3 Aleksander Morgado 2013-05-07 20:38:58 UTC
(In reply to comment #2)
> In practice, we observed that some modems report +CEREG status 2 (searching)
> followed by +CEREG status 1 (registered) within a second or two. That seems to
> happen when the modem is on the border of two cells. The modem usually recovers
> from the registration state change very quickly without interrupting the IP
> connectivity. So the original motivation of deferring the registration state
> updates was to smooth out these kinds of glitches, which from the user's
> perspective, should be transparent.
> 
> There are two aspects to consider with the new implementation:
> 
> 1. The existing connection shouldn't be dropped if the registration state is
> recovered within 15s
> 
> 2. From the connection manager's perspective, a registration state loss may
> cause the associated service to drop as the operator info is associated with
> the registration. e.g. the user may see the associated mobile network
> disappears and reappears as the registration goes away and comes back. That may
> be ok if the modem is not connected. But it seems quite confusing when the
> modem is still connected.
> 
> Aspect (1) seems to remain unchanged in the new implementation. I'm more
> concerned about aspect (2) regarding the immediate registration state update
> while the modem is still connected.

Regarding (1), the latest implementation I have in the branch doesn't follow the logic I described above. I removed the 15s deferred update completely; instead we allow the modem to go to SEARCHING state without stopping the connection explicitly. This logic should be enough according to the issues you describe, and AFAIK is also what Dan suggested.

Regarding (2), I guess it's a task for the connection manager or UI to handle this. ModemManager should expose the state as reported by the modem, if the modem reports SEARCHING, we should report it in the 3GPP interface, even if the modem reports CONNECTED in the Modem interface. I understand that it may be a nice thing to have this logic directly in MM, but I also understand that not all connection managers may want it that way.

Are you able to check whether the logic in the 'aleksander/registration-updates' branch is enough for your use cases?
Comment 4 Dan Williams 2013-05-09 15:34:42 UTC
Branch looks good to me, though I haven't live-tested the behavior.  If Ben's able to do that in a controlled environment with some nice fading of the base station simulator, that would be awesome :)
Comment 5 Aleksander Morgado 2013-05-20 07:13:53 UTC
Branch merged after successful tests done by Ben.

This problem has been fixed in the development version. The fix will be available in the next major software release. Thank you for your bug report.