Bug 85040

Summary:	core: track clients and implicitly enable/disable modem
Product:	ModemManager	Reporter:	Aleksander Morgado <aleksander>
Component:	general	Assignee:	ModemManager bug user <modemmanager>
Status:	RESOLVED MOVED	QA Contact:
Severity:	normal
Priority:	medium	CC:	zeenix
Version:	unspecified
Hardware:	Other
OS:	All
Whiteboard:
i915 platform:		i915 features:

Description Aleksander Morgado 2014-10-15 09:23:37 UTC

Originally reported at:
https://bugzilla.gnome.org/show_bug.cgi?id=730131
Please refer to the original bug report if more details are needed.

Currently ModemManager has a single method to request Enabling/Disabling a modem. This method applies directly to the state of the modem, so if a process asks to Enable a modem, the modem will be enabled; and if a process asks to Disable a modem, the modem will be disabled. The current approach has always been developed assuming that the User shell/settings would allow to Enable/Disable modems either one by one or all together (e.g. WWAN OFF/ON).

Now, the issue is that while it makes sense to have that configuration as a network setting (as done for e.g. WiFi), the configuration gets a bit more complex when there are other apps wanting to access the modem but not for connection purposes. One such case is e.g. geoclue which wants location information (like GPS) retrieved from the modem, but which shouldn't care whether WWAN was set to OFF for connection purposes. Other use cases could be a messaging application (for SMS) or a contacts management application (for managing SIM contacts).

In order to handle this, a new "soft-enabling/disabling" method could be added, which would allow clients to say "I'd like the modem enabled", and "I'd like the modem disabled", BUT which would then let ModemManager decide whether the request is accepted or not. See e.g. these sequences:

* Initially the modem starts in a soft-disabled state.
* Process A soft-enables the modem. MM transitions modem to Enabled state.
* Process B soft-enables the modem. MM keeps the modem in Enabled state.
* Process A soft-disables the modem. MM keeps the modem in Enabled state.
* Process B soft-disables the modem. MM transitions modem to Disabled state.

* Initially the modem starts in a soft-disabled state.
* Process A soft-enables the modem. MM transitions modem to Enabled state.
* Process B soft-enables the modem. MM keeps the modem in Enabled state.
* Process A exits, disappears from the bus. MM keeps the modem in Enabled state.
* Process B soft-disables the modem. MM transitions modem to Disabled state.

The modem will be Enabled as soon as ONE process asks soft-enable. And the modem will be Disabled when ALL processes ask soft-disable or when ALL disappear from the bus.

Processes asking soft-enable/disable would be e.g. both geoclue and NetworkManager. The WWAN ON/OFF setting in NetworkManager would apply to this new logic.

Now, the new soft-enabling method would be working along with the original (hard-) Enable(). The 'hard' original method would take always precedence over the soft ones. E.g. these sequences:

* Initially the modem starts in a soft-disabled state.
* Process A (e.g. mmcli) HARD-enables the modem. MM transitions modem to Enabled state.
* Process B soft-enables the modem. MM keeps the modem in Enabled state.
* Process A exits. MM keeps the modem in Enabled state.
* Process B soft-disables the modem. MM keeps the modem in Enabled state.

* Initially the modem starts in a soft-disabled state.
* Process A soft-enables the modem. MM transitions modem to Enabled state.
* Process B soft-enables the modem. MM keeps the modem in Enabled state.
* Process C (e.g. airplane mode=ON) HARD-disables the modem. MM transitions modem to Disabled state.

Plus, an additional e.g. "reset-enable" method would also be needed, to let processes which asked hard enable/disable actions to remove their request and let the soft ones apply again. E.g. this sequence which extends the previous one:
* Initially the modem starts in a soft-disabled state.
* Process A soft-enables the modem. MM transitions modem to Enabled state.
* Process B soft-enables the modem. MM keeps the modem in Enabled state.
* Process C (e.g. airplane mode=ON) HARD-disables the modem. MM transitions modem to Disabled state.
* Process D soft-enables the modem. MM keeps the modem in Disabled state.
* Process C (e.g. airplane mode=OFF) RESET-enables the modem. MM transitions modem to Enabled state (because there are processes with soft-enables).

And another one:
* Initially the modem starts in a soft-disabled state.
* Process C (e.g. airplane mode=ON) HARD-disables the modem. MM keeps the modem in Disabled state.
* Process C (e.g. airplane mode=OFF) RESET-enables the modem. MM keeps the modem in Disabled state (because there are NO processes with soft-enables).

Comment 1 Dan Williams 2015-04-02 18:17:18 UTC

Zeeshan mentioned on IRC that GeoClue doesn't actually want to enable a modem that doesn't have Location capabilities, but of course we cannot reliably detect whether a modem has Location capabilities until the modem is unlocked because the AT parser is in restricted mode until the PIN is entered.

I think we want some kind of mechanism in ModemManager itself, like NetworkManager's agent system or Bluez' agent system, where agents can register to handle PIN/PUK/etc requests for the modem.  It does get a bit complicated because you typically want to request secrets from the same user's agent as is making a D-Bus request.

Then apps like GeoClue that don't actually care about PINs or whatever could call some new kind of method that would ask ModemManager to put the modem into Disabled state, maybe even allow calling Enable(false) when the modem is <= DISABLED, which would ask the agents for the PIN code and advance to DISABLED state.  That way GeoClue could get the PIN code entered and be able to detect Location capabilities, without having to enable the modem.

Comment 2 GitLab Migration User 2018-06-10 09:04:02 UTC

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mobile-broadband/ModemManager/issues/46.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.