Re: NM connects to a mobile network even if "Mobile network" in tray icon's context menu is unchecked

[Dan Williams <dcbw redhat com>]

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
> networkmanager-list gnome org
> http://mail.gnome.org/mailman/listinfo/networkmanager-list