Bug 610299
| Summary: | network is disabled after resume | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | Josh Stone <jistone> | ||||||||
| Component: | pm-utils | Assignee: | Jaroslav Škarvada <jskarvad> | ||||||||
| Status: | CLOSED CURRENTRELEASE | QA Contact: | desktop-bugs <desktop-bugs> | ||||||||
| Severity: | medium | Docs Contact: | |||||||||
| Priority: | high | ||||||||||
| Version: | 6.0 | CC: | benl, cmeadors, dcbw, dennyvatwork, james, jmccann, jskarvad, vbenes | ||||||||
| Target Milestone: | rc | Keywords: | Reopened | ||||||||
| Target Release: | --- | ||||||||||
| Hardware: | All | ||||||||||
| OS: | Linux | ||||||||||
| Whiteboard: | |||||||||||
| 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 17:20:02 UTC | Type: | --- | ||||||||
| Regression: | --- | Mount Type: | --- | ||||||||
| Documentation: | --- | CRM: | |||||||||
| Verified Versions: | Category: | --- | |||||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||||
| Embargoed: | |||||||||||
| Bug Depends On: | |||||||||||
| Bug Blocks: | 609517 | ||||||||||
| Attachments: |
|
||||||||||
|
Description
Josh Stone
2010-07-02 00:22:54 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. *** 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? 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 -> VERIFIED 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 Tore 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 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). https://bugzilla.redhat.com/show_bug.cgi?id=638640 *** 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. |