GNOME Bugzilla – Bug 730131
Implicitly enable/disable modem
Last modified: 2014-10-15 09:24:08 UTC
I talked with Aleksander about modem enabling/disabling during GNOME devx hackfest in Berlin. Currently geoclue has to enable the modem itself for using it but since it doesn't know if the modem is in use by another application, it doesn't disable it after using it. This results in waste of battery power. I suggested to Aleksander that the best thing would be for ModemManager to take care of that as it knows if modem is in use or not. The alternative would be some kind of explicit UI but throwing this decision on user would be a terrible thing to do.
Also MM doing this would make it MM's responsibility to ensure that modem is never enabled if 'RF Kill' or 'offline mode' is enabled, rather than each MM using app to have to do that separately.
Been thinking more about this; and I'm not sure how to really handle this properly. If we try to keep track of who explicitly enabled the modem in ModemManager, the best we can do is to store the bus names of each of the DBus clients performing the Enable() calls... but what happens then with "mmcli" (command line) users? Those are 1-request DBus clients, and consecutive mmcli calls via DBus to ModemManager will have different bus names. I see no way to do this without increasing the DBus API. Another thing, then, is that multiple apps may want to get the modem enabled (e.g. geoclue for location, a SMS reader/writer for messaging, NetworkManager for connection...), but also the user needs to be able to explicitly make sure the modem gets disabled (e.g. going to airplane mode). IIRC, NM does this now, so it now controls whether the modem is enabled/disabled and whether the radio is actually off or on when the modem is disabled. I'm tempted to say that modem enabling/disabling needs to be managed in a single place, and that logically would be NetworkManager. If geoclue wants to enable location support in a given modem, the modem first would need to be enabled via NetworkManager. If a SMS reader/writer wants to use a given modem, the modem first would need to be enabled via NetworkManager. I think this really makes sense... what do you think? Geoclue would need to fallback to never try to enable a modem. If this makes sense, what we do need is a way in the UI to enable one modem (via NetworkManager) WITHOUT launching a connection. Currently the shell/system-settings don't seem to allow this (as they used to!). This would be equivalent to the "WiFi On" setting, but with WWAN. With Wifi you can On/Off it, and then assign a connection to it. The same should be ideally available with WWAN, i.e. On/Off it (enabling/disabling modems), and then assign a connection to it only when a connection needs to be launched.
(In reply to comment #2) > Been thinking more about this; and I'm not sure how to really handle this > properly. > > If we try to keep track of who explicitly enabled the modem in ModemManager, > the best we can do is to store the bus names of each of the DBus clients > performing the Enable() calls... No, what I'm saying is that clients should usually not need to make that call and enable/disable is implicit. > but what happens then with "mmcli" (command > line) users? Those are 1-request DBus clients, and consecutive mmcli calls via > DBus to ModemManager will have different bus names. I see no way to do this > without increasing the DBus API. We could treat some clients differently. Read below. > but also the user needs to be able to explicitly make sure > the modem gets disabled (e.g. going to airplane mode). That should either be handle directly by ModemManager or MM should allow access to explicit enable/disable to some particular client, e.g NetworkManager, mmcli. In that case, MM should simply enable/disable as asked, ignoring the number of clients etc. > Another thing, then, is that multiple apps may want to get the modem enabled > (e.g. geoclue for location, a SMS reader/writer for messaging, NetworkManager > for connection...), Why would multiple clients wanting to use the modem be an issue? You enable modem on first request and disable it when last client vanishes. > I'm tempted to say that modem enabling/disabling needs to be managed in a > single place, and that logically would be NetworkManager. If geoclue wants to > enable location support in a given modem, the modem first would need to be > enabled via NetworkManager. If a SMS reader/writer wants to use a given modem, > the modem first would need to be enabled via NetworkManager. I think this > really makes sense... what do you think? Geoclue would need to fallback to > never try to enable a modem. Don't quite like it. We can't really have a nice UI for user I imagine. > If this makes sense, what we do need is a way in the UI to enable one modem > (via NetworkManager) WITHOUT launching a connection. Yes and that would be really weird. Why should user have to bother with that when all they want is to find their location or send an SMS? This sounds like we are throwing the problem at user.
I see your point, but I also see a lot of issues with an implementation like that. E.g. you assume that clients may want to enable the modem to do their stuff (like geoclue wanting to enable modem to get location); but what happens if we're in airplane mode (as requested by system settings to NetworkManager)?. NM did really make sure we went into modem disabled+radio off; so, then geoclue can just re-request modem enabled to ModemManager? The logical step, if the user asked for Airplane Mode would be to have the user leave Airplane Mode (re-enabling the modems at that step via NM). In order to handle this we would need not only to track clients, but also decide 'client types', so that some are allowed to disable the modem even if other clients had it enabled, and so that some are not allowed to enable the modem if some other clients requested it to be disabled... complex! :) Also, enabling a modem means powering-on the modem radio among other things (so greater power consumption, your device emitting radio waves...); I'm not sure we should be doing that blindly whenever an app wants to use modem features... I think there should be some explicit setting to do that. Still think that "WWAN Off/On" is not a big issue for the user...
(In reply to comment #4) > I see your point, but I also see a lot of issues with an implementation like > that. E.g. you assume that clients may want to enable the modem to do their > stuff (like geoclue wanting to enable modem to get location); but what happens > if we're in airplane mode (as requested by system settings to NetworkManager)?. I don't see that as an issue at all. Since geoclue is not doing any enabling, it doesn't have to care about aeroplane mode. MM doesn't enable the modem if airplane mode is enabled and when its turned off, it enables the modem if there is any clients that need the modem. Also aeroplane mode applies to all modems so I'd treat it more like disabling/enabling of MM rather than the modem. > NM did really make sure we went into modem disabled+radio off; so, then geoclue > can just re-request modem enabled to ModemManager? No, as I said before geoclue (or any client except for special ones) doesn't need to enable it. Geoclue does Setup on Location intereface and enabling/disabling modem is implicit in that operation. MM decides whether or not to enable/disable modem. > The logical step, if the > user asked for Airplane Mode would be to have the user leave Airplane Mode > (re-enabling the modems at that step via NM). In order to handle this we would > need not only to track clients, but also decide 'client types', so that some > are allowed to disable the modem even if other clients had it enabled, and so > that some are not allowed to enable the modem if some other clients requested > it to be disabled... complex! :) Its complicated yes but still very much possible to implement. :) You just have to have the separate concept of explicit and implicit enable/disable I think.
In any case, it just seems plain wrong to leave enabling/disabling of modems to client and it leads to all kinds of race conditions. Also throwing the problem to user isn't something we should even consider if MM can handle this on its own (even if its very hard to implement).
Moving bugreport to the new ModemManager bugzilla in fd.o; summarized the issue there as well. Please subscribe to the new bugreport to get new updates. https://bugs.freedesktop.org/show_bug.cgi?id=85040 Closing this report as NOTGNOME.