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):
Steps to Reproduce:
1. Suspend laptop
2. Resume laptop
3. Chech the network
Networking is disabled, and NM must be restarted to enable it.
My wireless connection should come back up.
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.
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
*** Bug 613769 has been marked as a duplicate of this bug. ***
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?
Created attachment 431461 [details]
just after resume.. no network available until NM service restart performed
Created attachment 431462 [details]
after service restart
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.
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.
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.
Just to 100% confirm, with --print-reply, you do *not* experience the bug, correct?
(In reply to comment #10)
> Just to 100% confirm, with --print-reply, you do *not* experience the bug,
Correct. Sorry, I forgot to say that.
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.
I can take care of adding the --print-reply to pm-utils...
ok, network resumes and reconnects now
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?)
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
Same problem in Fedora 13 and KDE.
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
Still have problem also with Fedora 14 with the default setup (without --print-reply workaround).
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 ***
Ugh, this should not be duped, reopening.
Hmm, can't seem move back to VERIFIED, so closing.