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



On 08/01/2011 05:57 PM, Dan Williams wrote:
> On Sun, 2011-07-31 at 14:41 -0400, Daniel Gnoutcheff wrote:
<snip>
>> 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.

I assume that "if the modem is still enabled" is equivalent to
"nm_device_interface_get_enabled(modem_device) returns true", correct?
If so, this sounds sensible to me as well.

> 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.

That works fine for WWAN, using autoconnect_inhibit in NMDevice.

There are scenarios, however, where where autoconnect_inhibit is not set
but we still don't want to autoconnect.  That's were we have trouble.

Scenario 1:
- User creates wwan connection with autoconnect=true
- User sets WwanEnabled == false
- User plugs in modem
Expected: NM detects the modem but doesn't enable or autoconnect it
Actual result: NM detects the modem, enables it, and autoconnects it

Scenario 2:
- User creates wwan connection with autoconnect=true
- User plugs in modem and activates connection on it
- User sets WwanEnabled == false
Expected: NM disconnects modem, disables it, and leaves it alone
Actual result: NM disconnects modem and disables it.  But after some
semi-random delay, NM re-enables and autoconnects it.

We have this problem because NMPolicy seems to expect a disabled device
to enter state UNAVAILABE.  This holds true for wifi, where we always
enter UNAVAILABE when somebody calls set_enabled(wifi_device, FALSE).
But WWAN devices are different.  Even when a modem is disabled,
NMDeviceModem still claims that it's in state DISCONNECTED, not
UNAVAILABLE.  As a result, NMPolicy thinks that it's enabled even when
it isn't.

I'm not sure I like that disabled modems stay in DISCONNECTED.  It
obscures the fact that they are disabled, and as this bug seems to
demonstrate, that can be confusing.  That's why I proposed a new STANDBY
state.

But in any case, I'll write a patch that has makes
nm_device_interface_get_enabled() == TRUE an explicit prerequisite for
autoconnect.  That would fix this.

> 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.

Nope, this matches my understanding of how things are supposed to work,
as long as we are in agreement on what "disabling the modem" means.

Have a good one,
Daniel


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]