Bug 297711 - Mobile broadband devices are not automatically activated
Summary: Mobile broadband devices are not automatically activated
Status: RESOLVED UPSTREAM
Alias: None
Product: Network Management
Classification: Miscellaneous
Component: Mobile Broadband (show other bugs)
Version: 0.9
Platform: Fedora RPMs Linux
: NOR normal
Target Milestone: ---
Assignee: Lamarque V. Souza
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-04-08 10:33 UTC by Björn Ruberg
Modified: 2012-04-14 21:27 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Björn Ruberg 2012-04-08 10:33:06 UTC
When my UMTS stick is unlocked and available, I have to manually activate it by clicking a broadband connection or the "mobile broadband"-checkbox in the plasma network popup.

That's something like a paper cut - but uncomfortable. (My stick often reinitalizes often when failing to create a connection. I have to reenter the PIN code and do an additional click afterwards. Uncomfortable if you are currently not sitting on a table)

Because the UMTS-device is not activated, the "connect automatically"-checkbox I checked for my specific broadband connection.

In case of a wireless device the behaviour is correct. When a wifi device is activated, the networkmanager automatically to a wireless-network, if there is one found that is configured with "connect automatically".

(I may be able to patch the problem myself, if someone hints me where to look and I do not have to setup a whole kde-development environment)
Comment 1 Lamarque V. Souza 2012-04-08 14:42:27 UTC
(In reply to comment #0)
> When my UMTS stick is unlocked and available, I have to manually activate it
> by clicking a broadband connection or the "mobile broadband"-checkbox in the
> plasma network popup.

That's because NetworkManager disables mobile broadband by default. There is nothing I can do about this.
 
> That's something like a paper cut - but uncomfortable. (My stick often
> reinitalizes often when failing to create a connection. I have to reenter
> the PIN code and do an additional click afterwards. Uncomfortable if you are
> currently not sitting on a table)

I add an option to Plasma NM 0.9.0.1 (not released yet, I am just waiting for the tar.bz2 to reach KDE's ftp server to announce it) to only ask for the PIN when activating the connection. That should help with this problem but I know it will not solve it. The problem is that the PIN belongs to the sim-card not the modem, so I cannot store the PIN for a modem. That is also an upstream problem (in ModemManager). ModemManager developers are working on solutions for that but I do not know the current status about this problem.
 
> Because the UMTS-device is not activated, the "connect
> automatically"-checkbox I checked for my specific broadband connection.

If mobile broadband is disabled (again, by NetworkManager, not by us) the auto-connect feature simply does not work.
 
> In case of a wireless device the behaviour is correct. When a wifi device is
> activated, the networkmanager automatically to a wireless-network, if there
> is one found that is configured with "connect automatically".

If wifi had been disabled the auto-connect feature also does not work for it, that is the same thing for mobile broadband. The only difference is that NetworkManager allow us to set wifi always enable or always disable but for mobile broadband it always disables it when the modem is attached to the computer so save battery power (some modems are internal and cannot be removed like USB modems to prevent them from draining power).
 
> (I may be able to patch the problem myself, if someone hints me where to
> look and I do not have to setup a whole kde-development environment)

This is an upstream problem. I already tried to add a hack to always enable mobile broadband but it caused more troubles than good, so I removed it. You should contact NetworkManager/ModemManager developers about this issue.
Comment 2 Björn Ruberg 2012-04-10 17:21:48 UTC
Thanks for the explanation!