Bug 610299 - network is disabled after resume
Summary: network is disabled after resume
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: pm-utils (Show other bugs)
(Show other bugs)
Version: 6.0
Hardware: All Linux
Target Milestone: rc
: ---
Assignee: Jaroslav Škarvada
QA Contact: desktop-bugs@redhat.com
Keywords: Reopened
: 613769 (view as bug list)
Depends On:
Blocks: 609517
TreeView+ depends on / blocked
Reported: 2010-07-02 00:22 UTC by Josh Stone
Modified: 2010-10-18 17:20 UTC (History)
8 users (show)

Fixed In Version: pm-utils-1.2.5-9.el6
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2010-10-18 17:20:02 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
just after resume.. no network available until NM service restart performed (9.50 KB, text/plain)
2010-07-13 13:23 UTC, Vladimir Benes
no flags Details
after service restart (17.83 KB, text/plain)
2010-07-13 13:24 UTC, Vladimir Benes
no flags Details
/var/log/messages from when I reproduce the problem (87.94 KB, text/plain)
2010-09-02 16:55 UTC, Tore Anderson
no flags Details

Description Josh Stone 2010-07-02 00:22:54 UTC
Description of problem:
After I suspend my laptop and then resume, my network is disabled.  If I right-click on NM's panel icon "Enable Networking" is unchecked, and attempting to check it doesn't work.

It works again if I run "sudo service NetworkManager restart"... at least until the next suspend/resume cycle...

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Suspend laptop
2. Resume laptop
3. Chech the network
Actual results:
Networking is disabled, and NM must be restarted to enable it.

Expected results:
My wireless connection should come back up.

Additional info:
This used to work fine, so I suspect a recent update.  A few days ago I updated from 0.8.1-0.3 to 0.8.1-2, so I'll try to track down the old packages to confirm the regression.

Comment 2 RHEL Product and Program Management 2010-07-02 00:43:09 UTC
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux major release.  Product Management has requested further
review of this request by Red Hat Engineering, for potential inclusion in a Red
Hat Enterprise Linux Major release.  This request is not yet committed for

Comment 3 Bill Nottingham 2010-07-12 19:29:28 UTC
*** Bug 613769 has been marked as a duplicate of this bug. ***

Comment 4 Dan Williams 2010-07-12 22:02:39 UTC
This should have been fixed as of 0.8.1-0.3 and I wouldn't expect a regression, but if you see this again, could you attach /var/log/messages after bootup for me before doing anything else?

Comment 5 Vladimir Benes 2010-07-13 13:23:56 UTC
Created attachment 431461 [details]
just after resume.. no network available until NM service restart performed

Comment 6 Vladimir Benes 2010-07-13 13:24:58 UTC
Created attachment 431462 [details]
after service restart

Comment 7 Dan Williams 2010-07-13 17:00:28 UTC
Can you add --print-reply to the dbus-send lines in /usr/lib64/pm-utils/sleep.d/55NetworkManager ?  NM doesn't appear to ever be getting the "wake up" message from that script.

Comment 8 Dan Williams 2010-07-13 17:10:04 UTC
on resume, we expect to see something like:

NetworkManager: wake requested (sleeping: yes  enabled: yes)

but there are some PolicyKit authorization checks before allowing the sleep/wake request to go through, which the --print-reply may help diagnose.  The --print-reply also makes dbus-send wait around for the reply, which worked around an older dbus bug that dropped messages from short-lived processes.  We think that dbus bug has been long-fixed, but I'm not 100% sure it really was.

Comment 9 Josh Stone 2010-07-13 21:28:33 UTC
I just confirmed that with 0.8.1-0.3, everything works reliably, but with 0.8.1-1 and 0.8.1-2 it does not.

Now testing on 0.8.1-2.  Without --print-reply, I see a "sleep requested" but no "wake requested".  With --print-reply, I see both.

Comment 10 Dan Williams 2010-07-13 23:50:23 UTC
Just to 100% confirm, with --print-reply, you do *not* experience the bug, correct?

Comment 11 Josh Stone 2010-07-13 23:59:05 UTC
(In reply to comment #10)
> Just to 100% confirm, with --print-reply, you do *not* experience the bug,
> correct?    

Correct.  Sorry, I forgot to say that.

Comment 12 Dan Williams 2010-07-14 13:47:01 UTC
Diagnosis: NetworkManager checks the identity of the caller so that it can (optionally) perform authentication on the request.  That includes asking DBus for the caller's UID.  Unfortunately, by the time NM gets the dbus message, dbus-send may have already exited (if --print-reply isn't used) and thus when NM tries to get the UID, dbus-send isn't running anymore and that request fails, which fails the sleep/wake.

For the time being, we'll need to add --print-reply to the pm-utils script and dump the output to /dev/null so that dbus-send sticks around long enough to be authenticated.

Comment 13 Dan Williams 2010-07-14 13:53:28 UTC
I can take care of adding the --print-reply to pm-utils...

Comment 14 Vladimir Benes 2010-07-14 14:40:24 UTC
ok, network resumes and reconnects now

Comment 15 James Ettle 2010-08-29 07:54:49 UTC
I also see this with NetworkManager-0.8.1-4.git20100817.fc13.x86_64 on Fedora 13. (I though this was a dbus bug that was squashed ages ago?)

Comment 16 Tore Anderson 2010-09-02 16:55:50 UTC
Created attachment 442675 [details]
/var/log/messages from when I reproduce the problem

I have this problem, too.  It doesn't always occur, but frequently enough.  The hardware is an Asus Eee 1001PX with an Atheros wireless chipset.

When the bug occurs, NM doesn't reconnect to the network after resume.  The NM systray icon shows two diagonally adjacent monitors with a little «X» in the lower right corner.  When left-clicking it it just says «Networking disabled» (greyed out), when right-clicking I see «[ ] Enable Networking» at the top, also greyed out.  Restarting the NetworkManager service instantly restores connectivity.  The version in use is 0.8.1-4.git20100817.fc13.i686

I'm attaching a log where I reproduce the problem.  Timeline:

18:25:50  NetworkManager --log-level=debug is started, connects instantly to the wireless network
18:26:05  I suspend the laptop
18:26:15  I wake the laptop back up - it fails to reconnect
18:28:56  I restart NetworkManager, and it instantly connects

Smolt profile:  http://smolts.org/show?uuid=pub_963ae6fe-4056-4140-a90b-39b010b493a5


Comment 17 Daniele Viganò 2010-10-04 14:53:29 UTC
Same problem in Fedora 13 and KDE.

NetworkManager.x86_64             1:0.8.1-6.git20100831.fc13
NetworkManager-glib.x86_64        1:0.8.1-6.git20100831.fc13
NetworkManager-gnome.x86_64       1:0.8.1-6.git20100831.fc13        
knetworkmanager.x86_64            1:0.9-0.20.20100603.fc13 @updates             
knetworkmanager-libs.x86_64       1:0.9-0.20.20100603.fc13 @updates  

Profile (no up-to-date):

Seems to be solved adding --print-reply to /usr/lib64/pm-utils/sleep.d/55NetworkManager


Comment 18 Daniele Viganò 2010-10-17 22:29:57 UTC
Still have problem also with Fedora 14 with the default setup (without --print-reply workaround).

Comment 19 Dan Williams 2010-10-18 17:18:22 UTC
This bug is about RHEL6.  I've pushed builds to Fedora 12, 13, and 14 that have fixed this (though the actual bug is still in pm-utils).


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

Comment 20 Dan Williams 2010-10-18 17:19:13 UTC
Ugh, this should not be duped, reopening.

Comment 21 Dan Williams 2010-10-18 17:20:02 UTC
Hmm, can't seem move back to VERIFIED, so closing.

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