After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 667488 - Mobile Broadband must be re-enabled after every boot or resume, and after a lost connection.
Mobile Broadband must be re-enabled after every boot or resume, and after a l...
Status: RESOLVED DUPLICATE of bug 728044
Product: NetworkManager
Classification: Platform
Component: Mobile broadband
0.9.x
Other Linux
: Normal normal
: ---
Assigned To: Dan Williams
NetworkManager maintainer(s)
: 668263 (view as bug list)
Depends on:
Blocks: conn-dependency
 
 
Reported: 2012-01-08 04:15 UTC by Chris
Modified: 2014-04-23 18:00 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Patch of the wwan-fixes branch applicable to 0.9.8.0 release (14.53 KB, patch)
2013-06-09 19:45 UTC, Marius Kotsbak
none Details | Review

Description Chris 2012-01-08 04:15:38 UTC
Platform: 
i386 Ubuntu 11.10 on an EeePc 900SD with internal Huawei 3G modem (I _speculate_ that problem might be endemic to all 3G users)

Initial setup:
Mobile Broadband is set to "enabled" and a connection is set up and "connect automatically" is ticked.  3G connection works normally


Action to re-create the problem:
Turn off the computer, or enter suspend or hibernate modes.  When the system is rebooted or resumed, Mobile Broadband is no longer enabled.  Mobile Broadband must be re-enabled before a connection can be made.


Expected action:
If Mobile Broadband is enabled, then it should stay enabled until the user chooses to disable it.


Additional information:
If Connection with the 3G home network is lost (eg passing through a black spot) then the connection is closed and Mobile Broadband reverts to the disabled state.  I think this is the basis for Bug 663650  however it's much easier and simpler to re-create the problem with a reboot or resume however it is this behaviour that is the most frustrating when using a computer on the move.


Basis for expected action:
On previous versions (eg 0.8.X on Ubuntu 10.04 LTS) if Mobile Broadband had been enabled, and the connection set to connect automatically then a 3G connection was indeed established as soon as the computer was booted or resumed from a suspend or hibernation.
_______________________________________

Severity was selected as "Normal" because "Annoying" didn't seem to be a valid option.  ;-)


Chris
Comment 1 Chris 2012-01-08 04:39:24 UTC
Initially reported by me as a bug on Launchpad on 2011.10.22
https://bugs.launchpad.net/bugs/880084

Chris
Comment 2 Fernando 2012-03-27 12:13:10 UTC
Using Lubuntu 11.10 this also happens: one has to enable manually the broadband connection at the GUI or issue a command: nmcli nm wwan on
Comment 3 Chris 2012-05-06 21:04:57 UTC
This bug is still confirmed for NetworkManager 0.9.4.0 under Ubuntu 12.04

Chris
Comment 4 Fernando 2012-05-07 21:07:00 UTC
Linux WattOS R5  began to use at this R5 version NetworkManager, a good move cause now it handles 3G connections and very low profile hardware, however since it is a Ubuntu/Lubuntu based, it also has this bug issue. In this case it does not allow dedicate remote computer boxes for data log to use 3G cause after losing its signal, its gone, and no one near in hundred Km to operate it. It also can not be set to start with 3G set but that can me my limitation using dbus scripts.
Comment 5 Axel 2012-07-08 09:30:57 UTC
To me, this appears to be the result of confusion about the meaning of "Enable" in the design of NetworkManager: It could mean (a) "establish connection now" or (b) "establish connection when this is the best available option". Older versions of NetworkManager simply always connected through the best available option, so there was no need to turn (b) on or off. Not sure if there was an option to switch (a) on or off.  

It would make sense to have switches for (b) in the drop-down menu, but in fact NM seems to interpret the switches rather in the sense of (a).  So, if there is no way to connect things are automatically disabled.

If so, fixing this bug might require rethinking the design of NetworkManager, and perhaps go back to the old behaviour...
Comment 6 Marius Kotsbak 2012-07-20 12:37:08 UTC
Duplicate of bug #659228?
Comment 7 Axel 2012-07-20 13:20:09 UTC
(In reply to comment #6)
> Duplicate of bug #659228?

Could be. The description of bug #659228 is not very detailed.
Comment 8 Chris 2012-07-21 22:52:24 UTC
(In reply to comment #7)
> (In reply to comment #6)
> > Duplicate of bug #659228?
> 
> Could be. The description of bug #659228 is not very detailed.

I agree it _could_ be.  The problem appears to be one of logic, rather than any serious problem with the code.  For me the problem occurred when Ubuntu adopted NM 0.9x in release 11.04 beta, and has been there ever since - well over a year.

I've tried looking at the code myself but it's all Greek to me.  I was a serious 'C' programmer decades ago, but just don't have the time to figure out how it all hangs together.  I got as far as finding the definitions for the relevant flags (MOBILE_BROADBAND_ENABLED or similar) but can't figure out which is the entrant code for setting NM to the current settings or defaults.  I was hoping that the problem was a simple error in logic that could be fixed easily - and still am hoping...

Oh, and what do we have to do to get this moved from status "unconfirmed" to "confirmed".  It's easily re-creatable and appears to be affecting many people.  If everyone is busy dealing with "confirmed" bugs and are not looking at ones like this, I'd certainly like to the status of this upgraded so that it can at least get put on the list of things to do.

Chris
Comment 9 Marius Kotsbak 2012-07-22 07:44:18 UTC
Please test the patch referred to in the other bug report.
Comment 10 Pavel Simerda 2012-07-27 00:23:23 UTC
Bug 554538 is related but not the same.
Comment 11 Pavel Simerda 2012-07-27 00:23:44 UTC
*** Bug 668263 has been marked as a duplicate of this bug. ***
Comment 12 Pavel Simerda 2012-07-27 13:19:28 UTC
Replying to https://bugzilla.gnome.org/show_bug.cgi?id=633465#c6:

> The problem here is what should happen. Some people might prefer that the
> network connection is set up automatically when the phone is connected, if you
> always connect the phone to use it as a modem.

Automatic connection is configurable. When this is fixed, you can configure it
to your best linking.

> Other people connect the phone to the PC to charge it, transfer files, photos
> etc. and never use it as a modem.
> 
> Maybe we also need to list the devices in the NM config and let each of them
> have an autoconnection flag, or let you specify which devices should
> autoconnect in the list of mobile broadband connections.
> 
> The most user friendly would probably to ask the user when a new device (or
> device type?) is connected if it should be used for internet connection.

So the only concern is about what is the default and when does the UI let the user configure it.
Comment 13 Marius Kotsbak 2012-07-27 13:59:06 UTC
> Automatic connection is configurable. When this is fixed, you can configure it
> to your best linking.

No, it is not. I want autoconnection using the internal laptop modem, but not autoconnection when I connect my phone to charge it or access its files.

Now there is only one option to autoconnect or not for each mobile network connections, but not any option to restrict it to just some devices (like you can for the ethernet connections).
Comment 14 Pavel Simerda 2012-07-27 15:24:36 UTC
Marius,

if you have one configured connection for every device, you can configure their
autoconnection, right?

If yes, the only thing that must be done is to make autoconnect actually work.
Comment 15 Marius Kotsbak 2012-07-27 15:57:38 UTC
Unfortunately no, since the entries we have now for mobile broandband refer to subscriptions/APNs and is not associated with devices. An entry marked for auto is reused for all devices, which might not be correct (e.g. if they contain SIM card from different operators, or if you want autoconnect on external, but not internal modem). We could treat that as a separate issue though.
Comment 16 Pavel Simerda 2012-07-27 16:35:17 UTC
> An entry marked for auto
> is reused for all devices, which might not be correct (e.g. if they contain SIM
> card from different operators, or if you want autoconnect on external, but not
> internal modem). We could treat that as a separate issue though.

Now I see your point.
Comment 17 Marius Kotsbak 2012-07-30 10:35:22 UTC
See also the proposed patch and discussion in NM-list thread "PATCH: Auto-Enable WWAN after PIN entry": https://mail.gnome.org/archives/networkmanager-list/2012-July/msg00103.html
Comment 18 Marius Kotsbak 2012-08-24 18:11:17 UTC
Some scripts were linked here as workaround:

https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/848164/comments/16
Comment 19 Chris 2012-08-24 20:14:25 UTC
I tried using the patch tool to apply the patch mentioned in comment 9.  I negotiated the minefield of dependencies but it didn't appear to apply the patch correctly - there is no change.
Comment 20 Marius Kotsbak 2012-10-19 17:31:17 UTC
A sufficient solution to this could be to just preserve the state of the mobile broadband enable switch over reboots/sleeps etc, so that if it was enabled at shutdown, it would trigger a connection at boot.
Comment 21 Chris 2012-10-19 19:28:25 UTC
@Marius Kotsbak : Yes, that's all that we need or really want.  The mobile broadband is being switched to the disabled state for some reason.
Comment 22 Marius Kotsbak 2013-01-29 00:45:47 UTC
It seems like this patch to Network Manager is a quickfix:

diff --git a/src/nm-manager.c b/src/nm-manager.c
index fbc9d23..51ada11 100644
--- a/src/nm-manager.c
+++ b/src/nm-manager.c
@@ -1373,8 +1373,8 @@ radio_enabled_for_rstate (RadioState *rstate, gboolean check_changeable)
        enabled = rstate->user_enabled && rstate->hw_enabled;
        if (check_changeable) {
                enabled &= rstate->sw_enabled;
-               if (rstate->daemon_enabled_func)
-                       enabled &= rstate->daemon_enabled;
+               //              if (rstate->daemon_enabled_func)
+               //                      enabled &= rstate->daemon_enabled;
        }
        return enabled;
 }

It removes the requirement that the daemon must be enabled (which it is not, i.e. modem enabled) for NM to obey user wwan enable switch.
Comment 23 Marius Kotsbak 2013-02-03 20:09:14 UTC
For me, the above fix did solve the autoconnect at startup, but not after sleep. I guess making reconnect work would make that work too, bug #554538.
Comment 24 Dan Winship 2013-05-02 16:08:14 UTC
NM bugzilla reorganization... sorry for the bug spam.
Comment 25 Dan Williams 2013-05-31 21:41:59 UTC
Please try the code in dcbw/wwan-fixes.  This unties the ModemManager enabled/disabled state from rfkill.  With this branch, if airplane mode/rfkill is not on, NM will set any WWAN modem Enabled, and will attempt to connect any WWAN connection marked autoconnect=true.

Some problems with any approach like this, which could be solved with more code:

1) NM doesn't wait for the modem to be registered before starting autoconnect, partly this is historical, and partly because a number of modems take a really, really long time to register with the network, and some just don't seem to ever auto-register without a lot of kicking, which only happens as part of the connect process in ModemManager.  So basically, if you have any autoconnect WWAN connection, it'll always be started regardless of whether the modem has a signal or not.

2) NM doesn't check for problems before trying to autoconnect; eg if the SIM is PUK locked, or the modem is in the "failed" state (indicating it cannot be enabled without further user action) then NM will keep trying to autoconnect it.

So I think this branch is a start, if not where we finally want to be.  At least it fixes the rfkill/enabled issues that were a problem before.
Comment 26 Ladislav Nesnera 2013-06-01 13:22:13 UTC
(In reply to comment #25)
> Please try the code in dcbw/wwan-fixes..

What do you mean by this? Which code? Thanks
Comment 28 Marius Kotsbak 2013-06-09 16:53:56 UTC
With this code change, maybe it makes more sense to apply the "make sure we prioritize WiFi over 3G when WiFi is available" from Ubuntu: 

http://bazaar.launchpad.net/~network-manager/network-manager/ubuntu/revision/733
Comment 29 Marius Kotsbak 2013-06-09 19:45:49 UTC
Created attachment 246366 [details] [review]
Patch of the wwan-fixes branch applicable to 0.9.8.0 release
Comment 30 Dan Williams 2014-04-22 14:49:20 UTC
dcbw/wwan-fixes is up for review in bug 728432.
Comment 31 Dan Winship 2014-04-23 18:00:14 UTC
This will be fixed by dcbw/wwan-fixes (in 728044; dcbw linked to wrong bug above)

*** This bug has been marked as a duplicate of bug 728044 ***