On Sun, 2011-07-31 at 14:41 -0400, Daniel Gnoutcheff wrote: > On 07/30/2011 06:58 PM, Dan Williams wrote: > > Yeah, I think your analysis is correct. It would seem really odd to me > > to auto-activate a mobile broadband connection if the MB is not enabled. > > If MB is not enabled, only a user action should enable it. Thanks fro > > checking this out. > > No problem. :) > > So, when the user disables wifi, we transition the wifi devices to > NM_DEVICE_STATE_UNAVAILABLE. This is what prevents nm-policy from > trying to autoconnect them. It also means that ActivateConnection calls > will fail (unnecessarily perhaps) for those devices, but for wifi we can > live with that. > > But we can't live with that for modems. This means we've been leaving > "disabled" modems at NM_DEVICE_STATE_DISCONNECTED, so nm-policy happily > autoconnects them.
Hmm, though if the modem is still "enabled" then I suppose it's fair game for autoconnecting, if the connection is set for that. That's a nuance I hadn't thought of but makes some amount of sense, given that users must explicitly enable the modem in the first place. We've given "disconnect" special meaning though, which is that if the user explicitly chooses disconnect from the menu (which translates to NM's Disconnect() call) then the device is not supposed to be reconnected automatically until either the user does so, or the machine is put to sleep. If we're not respecting that for WWAN then we should be. So basically, we need to harmonize the way things are treated. If a device is not available (disabled, rfkill, whatever) then we shouldn't autoconnect it. If the device is available, then we should autoconnect it as long as a autoconnect connection is defined. If the user has explicitly disconnected the device, then the device should stay disconnected until the user performs some action (or the machine wakes up from sleep). The way to stop the WWAN device (and wired, and wifi) from doing anything automatic is to disable it or disconnect it explicitly, or set your connections to autoconnect=no. We can't make this too complicated otherwise the ruleset that people have to memorize becomes too complex and you're left wondering about what it's actually supposed to be doing. I feel like the paragraph above is the most reasonable course of action for a device, feel free to argue if you disagree though. Of course we can also default WWAN connections to autoconnect=false in the editor/applet or even in the AddAndActivate() call. We aren't doing this now, because of the way the GObject based NMSetting classes work, where during the call to AddAndActivate() you cannot tell whether a boolean property was present or not; if it's missing GObject assigns the default value (in this case TRUE) so we can't distinguish between whether the caller passed TRUE for autoconnect because they wanted it that way, or whether the caller didn't pass anything there at all. So in that case it's left up to the applet/editor to set the right value there, which appears to be the case (the applet sets FALSE for autoconnect). So I guess my vote would be to ensure our behavior is harmonized for Disconnect() and leave it to applets to set autoconnect? Dan > Lots of ways I can think of to fix this, I'm currently torn between > these two: > > 1) Have nm-policy:schedule_activate_check explicitly check radio states > as appropriate. > > 2) Add a new device state, say NM_DEVICE_STATE_STANDBY = 25 (between > UNAVAILABLE and DISCONNECTED), indicating that we can use the device but > we have decided not to. Devices in NM_DEVICE_STATE_STANDBY won't be > autoconnected, but a manual activation request is expected to work. > > Thoughts? Thanks! > > Later, > Daniel > > P.S. when we have an ActivateConnection on a disabled modem, we'll also > want to mark the wwan radios as enabled and ensure that the caller has > the polkit permission to enable wwan radios. We don't seem to do that. > _______________________________________________ > networkmanager-list mailing list > [email protected] > http://mail.gnome.org/mailman/listinfo/networkmanager-list _______________________________________________ networkmanager-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/networkmanager-list
