Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 610299 - network is disabled after resume
network is disabled after resume
Status: CLOSED CURRENTRELEASE
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: pm-utils (Show other bugs)
6.0
All Linux
high Severity medium
: rc
: ---
Assigned To: Jaroslav Škarvada
desktop-bugs@redhat.com
: Reopened
: 613769 (view as bug list)
Depends On:
Blocks: 609517
  Show dependency treegraph
 
Reported: 2010-07-01 20:22 EDT by Josh Stone
Modified: 2010-10-18 13:20 EDT (History)
8 users (show)

See Also:
Fixed In Version: pm-utils-1.2.5-9.el6
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-10-18 13:20:02 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)
just after resume.. no network available until NM service restart performed (9.50 KB, text/plain)
2010-07-13 09:23 EDT, Vladimir Benes
no flags Details
after service restart (17.83 KB, text/plain)
2010-07-13 09:24 EDT, Vladimir Benes
no flags Details
/var/log/messages from when I reproduce the problem (87.94 KB, text/plain)
2010-09-02 12:55 EDT, Tore Anderson
no flags Details

  None (edit)
Description Josh Stone 2010-07-01 20:22:54 EDT
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 Product and Program Management 2010-07-01 20:43:09 EDT
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 15:29:28 EDT
*** Bug 613769 has been marked as a duplicate of this bug. ***
Comment 4 Dan Williams 2010-07-12 18:02:39 EDT
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 09:23:56 EDT
Created attachment 431461 [details]
just after resume.. no network available until NM service restart performed
Comment 6 Vladimir Benes 2010-07-13 09:24:58 EDT
Created attachment 431462 [details]
after service restart
Comment 7 Dan Williams 2010-07-13 13:00:28 EDT
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 13:10:04 EDT
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 17:28:33 EDT
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 19:50:23 EDT
Just to 100% confirm, with --print-reply, you do *not* experience the bug, correct?
Comment 11 Josh Stone 2010-07-13 19:59:05 EDT
(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 09:47:01 EDT
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 09:53:28 EDT
I can take care of adding the --print-reply to pm-utils...
Comment 14 Vladimir Benes 2010-07-14 10:40:24 EDT
ok, network resumes and reconnects now
-> VERIFIED
Comment 15 James Ettle 2010-08-29 03:54:49 EDT
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 12:55:50 EDT
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 10:53:29 EDT
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 18:29:57 EDT
Still have problem also with Fedora 14 with the default setup (without --print-reply workaround).
Comment 19 Dan Williams 2010-10-18 13:18:22 EDT
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 13:19:13 EDT
Ugh, this should not be duped, reopening.
Comment 21 Dan Williams 2010-10-18 13:20:02 EDT
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.