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 690094 - Expose basic modem status information directly in the NMDeviceModem
Expose basic modem status information directly in the NMDeviceModem
Status: RESOLVED OBSOLETE
Product: NetworkManager
Classification: Platform
Component: API
0.9.x
Other Linux
: Normal normal
: ---
Assigned To: NetworkManager maintainer(s)
NetworkManager maintainer(s)
Depends on:
Blocks: 687853
 
 
Reported: 2012-12-12 12:39 UTC by Aleksander Morgado
Modified: 2020-11-12 14:28 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Aleksander Morgado 2012-12-12 12:39:25 UTC
Applications using NetworkManager/ModemManager would be greatly simplified if NetworkManager exposed already some common status information directly in the NMDeviceModem, so that they do not need to gather that information from the ModemManager interfaces.

The main problem I see here is which is the minimum set of status information that we may want to expose duplicated. Given the gnome-shell and nm-applet requirements, for example, this would be the minimum subset:
 * Operator Name and MCC/MNC
 * CDMA SID
 * Signal strength
 * Modem status
 * Registration status (unregistered/home/roaming)
 * Current access technology (hspa, umts...) or mode (2G, 3G...)

I'm not sure about this; as we definitely don't want to duplicate all the status info. And also, what if any other common user (not just gnome-shell or nm-applet) wanted more info here?
Comment 1 Dan Williams 2012-12-13 20:37:48 UTC
I think we can skip Modem Status, since the status doesn't matter much to clients; it's the *NM* DeviceModem state that matters here.  Enable/disable, PIN entry, etc will be handled by NMDeviceModem either already or in the near future.

The question is, what information is useful to show in a basic client?  I think the rest of it is likely useful to expose, though for the access tech I'd got with specific technology, eg UMTS/EVDOrA/etc instead of generic 2G/3G/4G.

We should be able to retrieve all of this by watching the MM simple status, or periodically querying the simple status if we haven't received an update in a while, and if the modem is enabled.  We'll only do this in >= NM_DEVICE_STATE_DISCONNECTED.

I think that for now, we only need to expose minimal *status* information, read-only.  I can't see a pressing use-case for exposing actual method calls that just call through to MM, like "SendPin" or "Register(310-260)" etc.  For anything more than basic status, the client can just talk to MM.

If MM doesn't expose all this info in the simple-status call, then perhaps we should update MM to put it there.  I'm pretty sure it's well-covered by git master, but we may need to update 0.6 in a few places.
Comment 2 Giovanni Campagna 2012-12-27 17:58:47 UTC
I think we should also expose modem status, or at least the registration state. That way, we can show the 3G icon in the shell when the modem is unabled/registered but not connected.
Comment 3 Aleksander Morgado 2012-12-28 05:35:28 UTC
Registration state (both 3GPP and CDMA) are needed in order for the UI to show if we're roaming or not. Modem state, as Dan suggests, is not really needed.

And then, we also have PIN/PUK retry counts, which the UI also should show in the PIN/PUK unlock dialog...
Comment 4 Giovanni Campagna 2012-12-28 12:42:59 UTC
(In reply to comment #3)
> Registration state (both 3GPP and CDMA) are needed in order for the UI to show
> if we're roaming or not. Modem state, as Dan suggests, is not really needed.
> 
> And then, we also have PIN/PUK retry counts, which the UI also should show in
> the PIN/PUK unlock dialog...

I expect the latter to be exposed through SecretAgent interface (as a hint or unsaved connection property), not NMDeviceModem. Or at least, it would simplify a lot the implementation.
Comment 5 Aleksander Morgado 2012-12-28 13:08:16 UTC
> > And then, we also have PIN/PUK retry counts, which the UI also should show in
> > the PIN/PUK unlock dialog...
> 
> I expect the latter to be exposed through SecretAgent interface (as a hint or
> unsaved connection property), not NMDeviceModem. Or at least, it would simplify
> a lot the implementation.

Yeah, true.
Comment 6 André Klapper 2020-11-12 14:28:43 UTC
bugzilla.gnome.org is being shut down in favor of a GitLab instance. 
We are closing all old bug reports and feature requests in GNOME Bugzilla which have not seen updates for a long time.

If you still use NetworkManager and if you still see this bug / want this feature in a recent and supported version of NetworkManager, then please feel free to report it at https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/

Thank you for creating this report and we are sorry it could not be implemented (workforce and time is unfortunately limited).