GNOME Bugzilla – Bug 667488
Mobile Broadband must be re-enabled after every boot or resume, and after a lost connection.
Last modified: 2014-04-23 18:00:14 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
Initially reported by me as a bug on Launchpad on 2011.10.22 https://bugs.launchpad.net/bugs/880084 Chris
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
This bug is still confirmed for NetworkManager 0.9.4.0 under Ubuntu 12.04 Chris
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.
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...
Duplicate of bug #659228?
(In reply to comment #6) > Duplicate of bug #659228? Could be. The description of bug #659228 is not very detailed.
(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
Please test the patch referred to in the other bug report.
Bug 554538 is related but not the same.
*** Bug 668263 has been marked as a duplicate of this bug. ***
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.
> 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).
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.
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.
> 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.
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
Some scripts were linked here as workaround: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/848164/comments/16
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.
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.
@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.
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.
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.
NM bugzilla reorganization... sorry for the bug spam.
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.
(In reply to comment #25) > Please try the code in dcbw/wwan-fixes.. What do you mean by this? Which code? Thanks
Branch http://cgit.freedesktop.org/NetworkManager/NetworkManager/log/?h=dcbw/wwan-fixes
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
Created attachment 246366 [details] [review] Patch of the wwan-fixes branch applicable to 0.9.8.0 release
dcbw/wwan-fixes is up for review in bug 728432.
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 ***