Bug 598765 - Add "Enable networking" button to knetworkmanager
Add "Enable networking" button to knetworkmanager
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: knetworkmanager (Show other bugs)
13
All Linux
low Severity medium
: ---
: ---
Assigned To: Rex Dieter
Fedora Extras Quality Assurance
: FutureFeature, Patch, Triaged
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-06-01 21:25 EDT by Jerry Amundson
Modified: 2010-06-29 11:34 EDT (History)
12 users (show)

See Also:
Fixed In Version: kde-plasma-networkmanagement-0.9-0.20.20100603.fc13
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: 589108
Environment:
Last Closed: 2010-06-25 17:50:52 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
KDE Software Compilation 238325 None None None Never

  None (edit)
Description Jerry Amundson 2010-06-01 21:25:49 EDT
+++ This bug was initially created as a clone of Bug #589108 +++

Description of problem:
Networking is disabled by state file after power loss drained laptop battery

Version-Release number of selected component (if applicable):
NetworkManager-0.8.0-7.git20100422.fc13.i686

How reproducible:
always

Steps to Reproduce:
1.login to KDE on laptop
2.disconnect power, and let battery die
3.plugin power and boot - no network.
  
Actual results:
no network management

Expected results:
network management

Additional info:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=571331

Note in step 3. above there are actually two boots as the resume from power mgmt suspend never works for me - I force power off and restart.

--- Additional comment from oded@geek.co.il on 2010-05-10 09:11:17 EDT ---

I have the same problem after trying to recover from a failed suspend.

Removing the state file at /var/lib/NetworkManager and restarting NetworkManager solved the problem for me.

--- Additional comment from eqisow@gmail.com on 2010-05-10 23:00:39 EDT ---

Same issue here on a Dell Studio 1558, 03:00.0 Network controller: Intel Corporation Centrino Advanced-N 6200 (rev 35), NetworkManager-0.8.0-13.git20100509.fc13

--- Additional comment from joel_rees@sannet.ne.jp on 2010-05-16 07:22:23 EDT ---

Additional evidence:

I had this happen to me, apparently when my daughter accidentally hit the sleep button on the keyboard or selected hibernate instead of shutdown from the shutdown menu.

The file mentioned above, 

/var/lib/NetworkManager/NetworkManager.state

shows the wired network disabled and the wireless enabled.

The box is a desktop, by the way, not a laptop. No battery. No wireless hardware of any sort. 32 bit, single CPU Sempron. (Should I attach a dmesg?) 

Oh, and it's running Fedora 12.

Editing the file instead of deleting it also seems to unclog the networking stuff.

--- Additional comment from dcbw@redhat.com on 2010-05-17 19:55:41 EDT ---

*** Bug 592505 has been marked as a duplicate of this bug. ***

--- Additional comment from dcbw@redhat.com on 2010-05-17 20:10:11 EDT ---

*** Bug 552233 has been marked as a duplicate of this bug. ***

--- Additional comment from rbh00@netcom.com on 2010-05-19 17:46:39 EDT ---

When this symptom has happened to me, the following command instantly fixes it:
    nmcli nm wakeup

The circumstances seem to be that NM sets NetworkingEnabled to false in the /var/lib/NetworkManager/NetworkManager.state file but the situation can arise where NM cannot reset it.

My guess is that this flag is set at suspend time (and of course at 'nmcli nm sleep' time as well).  Further, I guess that NM expects a 'suspend' to be followed by a 'resume', which should reset this flag to be NetworkingEnabled=true.  But if the latter fails, as it stands manual intervention is reqired.

The failure can occur in at least these two ways:  the hardware's suspend function is broken and a power-on reboot is required, and the battery discharges and a power-on reboot is required.  The NetworkingEnabled=false flag remains set in these cases, and manual intervention is required.  But a naïve user is at a complete loss what to do.  Even sophisticated users, e.g., helpers on the #fedora channel of freenode, are at a loss, as I've seen.  NM should perhaps set the flag to true when freshly started?

What are the exact and complete semantics of this NetworkingEnabled=false flag?

Is there a valid case where a freshly started NetworkManager service can expect NetworkingEnabled=false to be the proper setting?  If there is, could a freshly started NM pop up a graphic window asking the user if enabling was okay?

--- Additional comment from jklimes@redhat.com on 2010-05-20 08:27:31 EDT ---

(In reply to comment #6)
> When this symptom has happened to me, the following command instantly fixes it:
>     nmcli nm wakeup

Yeah, this pokes NM to wake up via D-BUS.
The same effect can be reached by:
1. right clicking nm-applet and checking "Enable Networking"
2. directly via D-Bus call, e.g. with dbus-send:
dbus-send --system --dest=org.freedesktop.NetworkManager /org/freedesktop/NetworkManager org.freedesktop.NetworkManager.Sleep boolean:false

> 
> The circumstances seem to be that NM sets NetworkingEnabled to false in the
> /var/lib/NetworkManager/NetworkManager.state file but the situation can arise
> where NM cannot reset it.
> 
> My guess is that this flag is set at suspend time (and of course at 'nmcli nm
> sleep' time as well).  Further, I guess that NM expects a 'suspend' to be
> followed by a 'resume', which should reset this flag to be
> NetworkingEnabled=true.  But if the latter fails, as it stands manual
> intervention is reqired.
>
The flag is set by 
/usr/lib64/pm-utils/sleep.d/55NetworkManager script when suspending. The same script is responsible for waking NM up on resume. But when resume fails, of course, the flag is not set to true again.
The whole problem is that suspend/resume should not reuse NetworkingEnabled flag, but it does at present. It's planned to change that in the future, though (see the duped bugs and some others on the issue).

> The failure can occur in at least these two ways:  the hardware's suspend
> function is broken and a power-on reboot is required, and the battery
> discharges and a power-on reboot is required.  The NetworkingEnabled=false flag
> remains set in these cases, and manual intervention is required.  But a naïve
> user is at a complete loss what to do.  Even sophisticated users, e.g., helpers
> on the #fedora channel of freenode, are at a loss, as I've seen.  NM should
> perhaps set the flag to true when freshly started?
> 
> What are the exact and complete semantics of this NetworkingEnabled=false flag?
> 
The state file was introduced to retain setting during restarts. So that you can set the flags and see the same stuff over reboots.

> Is there a valid case where a freshly started NetworkManager service can expect
> NetworkingEnabled=false to be the proper setting?  If there is, could a freshly
> started NM pop up a graphic window asking the user if enabling was okay?    

There are valid cases.
You may manually disable wireless or whole networking (e.g via right-clicking nm-applet). And you want to have the same state after reboot, of course.
I am sure about a pop-up. I think that disabled state is already indicated via nm-applet icon. See attachment.

--- Additional comment from jklimes@redhat.com on 2010-05-20 08:29:18 EDT ---

Created an attachment (id=415400)
nm-applet: NetworkManager in sleep state

--- Additional comment from oded@geek.co.il on 2010-05-20 09:28:41 EDT ---

The main problem with using nm-applet for waking up NetworkManager, is that if you use KDE then you don't have nm-applet, you have knetworkmanager which doesn't have that features.

When NetworkManager is sleeping, knetworkmanager shows a disabled menu entry saying "networking is disabled" and there is no way to enable it.

--- Additional comment from jklimes@redhat.com on 2010-05-20 13:45:00 EDT ---

This is actually a deficiency of knetworkmanager.
I've submitted a patch for knetworkmanager to fix that:
https://bugs.kde.org/show_bug.cgi?id=238325

Btw, you can use nm-applet in KDE without any problem (I do that myself).

--- Additional comment from jklimes@redhat.com on 2010-05-20 13:57:07 EDT ---

Created an attachment (id=415484)
knetworkmanager with added "Enable networking" checkbox

knetworkmanager with enable check boxes when NetworkManager is sleeping.

--- Additional comment from dcbw@redhat.com on 2010-05-22 13:04:39 EDT ---

Upstream NetworkManager commits that fix this bug:

ee3ece9dac985034c5c1f81a6769b40fd7856579 (0.8.1)
fa70542c618665cf203a2b71fa0e504f759f7902 (master)

still need to hook the applet's Enable checkbox up to the new bits in a separate commit.

--- Additional comment from dcbw@redhat.com on 2010-05-22 13:57:51 EDT ---

5ca1a9d546be81b54e57d525b54ff92597de6115 (0.7.x)

--- Additional comment from jamundso@gmail.com on 2010-05-24 20:28:25 EDT ---

(In reply to comment #12)
> Upstream NetworkManager commits that fix this bug:
> 
> ee3ece9dac985034c5c1f81a6769b40fd7856579 (0.8.1)
> fa70542c618665cf203a2b71fa0e504f759f7902 (master)

This is in my list of bugs to "Retest", but I see no way to do so. Please update accordingly. Thanks!
Comment 1 Steven M. Parrish 2010-06-04 22:33:24 EDT
This bug has been triaged



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 2 Rex Dieter 2010-06-08 16:04:42 EDT
ok, patches applied to
kdebase-workspace-4_4_85-2_fc14
kde-plasma-networkmanagement-0_9-0_20_20100603_fc14

in rawhide.

Will work to backport these to kde-4.4.4
Comment 3 Rex Dieter 2010-06-09 12:45:24 EDT
Jerry, I'm testing out backporting patches for kde-4.4.4, but found some badness.  

In knetworkmanager, upon deselecting 'enable networking' the app disappears from my systray, and won't come back.

Did I possibly botch something?

See,
http://cvs.fedoraproject.org/viewvc/devel/kde-plasma-networkmanagement/networkmanagement-kdebug238325.patch

http://cvs.fedoraproject.org/viewvc/devel/kdebase-workspace/kdebase-workspace-4.4.85-kdebug238325.patch
Comment 4 Rex Dieter 2010-06-09 12:46:54 EDT
fwiw, kdebase-workspace-4.4.85-kdebug238325.patch  (seems to) appy cleanly against 4.4.4 too.
Comment 5 Rex Dieter 2010-06-11 11:47:06 EDT
Nevermind my comment #3 about the app disappearing.  The interesting part I missed is that the systray icon gets hidden when 'enable networking' is not enabled.

I'd say we have a winner.
Comment 6 Fedora Update System 2010-06-17 10:11:53 EDT
kde-plasma-networkmanagement-0.9-0.20.20100603.fc13 has been submitted as an update for Fedora 13.
http://admin.fedoraproject.org/updates/kde-plasma-networkmanagement-0.9-0.20.20100603.fc13
Comment 7 Fedora Update System 2010-06-21 09:01:45 EDT
kde-plasma-networkmanagement-0.9-0.20.20100603.fc13, kdebase-workspace-4.4.4-2.fc13 has been pushed to the Fedora 13 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update kde-plasma-networkmanagement kdebase-workspace'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/kdebase-workspace-4.4.4-2.fc13,kde-plasma-networkmanagement-0.9-0.20.20100603.fc13
Comment 8 Jirka Klimes 2010-06-21 15:35:17 EDT
I've tested the packages and they work as expected.
Thanks.
Comment 9 Fedora Update System 2010-06-29 11:34:45 EDT
kde-plasma-networkmanagement-0.9-0.20.20100603.fc13, kdebase-workspace-4.4.4-2.fc13 has been pushed to the Fedora 13 stable repository.  If problems still persist, please make note of it in this bug report.

Note You need to log in before you can comment on or make changes to this bug.