RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 610299 - network is disabled after resume
Summary: network is disabled after resume
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: pm-utils
Version: 6.0
Hardware: All
OS: Linux
high
medium
Target Milestone: rc
: ---
Assignee: Jaroslav Škarvada
QA Contact: desktop-bugs@redhat.com
URL:
Whiteboard:
: 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:
Clone Of:
Environment:
Last Closed: 2010-10-18 17:20:02 UTC
Target Upstream Version:
Embargoed:

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
View All

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):
NetworkManager-0.8.1-2.el6.i686

How reproducible:
100%

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 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
inclusion.
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
-> VERIFIED
Comment 15 James 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

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

Packages:
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):
http://smolt.fedoraproject.org/client/show/pub_baa15265-3aaa-4b3c-8376-14889eddabe9

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

Daniele
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).

https://bugzilla.redhat.com/show_bug.cgi?id=638640

*** 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.