Description of problem: For some days now, network manager does not automatically reconnect the wireless connection after resuming from suspend. It did that before. Version-Release number of selected component (if applicable): Name : NetworkManager Arch : x86_64 Epoch : 1 Version : 0.8.1 Release : 6.git20100831.fc13 Size : 5.1 M How reproducible: Always Steps to Reproduce: 1. Start nm-applet 2. Suspend 3. Resume Additional info: I'm using nm-applet in KDE environment. For a long time already nm-applet does not start anymore automatically with the session. The problem reported in this bug is much newer.
Same problem with Gnome and x86. Additionally, won't connect automatically during boot/login, wants to create a new configuration instead of using existing one, have to manually get networking restored after suspend. Backdating to 1:NetworkManager-0.8.1-0.1.git20100510.fc13.i686 works fine.
I have the effects described by mr Laxström above. Kde with fedora 12 and 13 have been varyingly unable to restore wlan connection after suspend and resume, both in my laptop with iwlagn with f13 and in my wife's f12 with broadcom wl (from rpmfusion), both using kde. The networkmanager versions from atleast August up to 20100831 restored connections occasionally on both laptops and now the 20100831 seems to need a restart everytime on my f13. On my laptop it's sufficient to tap the hardware wlan button on and off, but my wife's hp mini requires a NetworkManager restart to get things going again. On my wife's f12 the resume works occasionally however. On both of these machines things work fine after a boot, so I think mr Guerdat above is describing a different issue. The only NetworkManager comment I see in /var/log/messages is that my BT device was removed. Nothing about the wlan. I can provide more accurate hw and version information, logs and try out things, just tell me what you need.
Correction, it does resume sometimes with my laptop, too, just not every time.
I've been using the 0.8.1-0.1.git20100510.fc13 ever since and no problems. I'll just stick to that and give the next version a go and downgrade back if the problem persists.
Exactly what I've been doing. A new version gets released, I try it and downgrade when it shows the same symptoms. Guess I'd better manually download the git20100510 version in case it disappears for downgrading. It'd be better if this got fixed instead.
Good point, but the 20100510 was the f13 release version making it a little less likely to disappear than updates.
I'll try to sum up suspend/resume problem as it vary on NM versions, desktop environment, tool calling suspend, etc. There is a problem with short-lived processes calling D-Bus methods, causing that messages can be lost sometimes. Thus wake-up request may not be received by NM. Adding --print-reply to /usr/lib[64]/pm-utils/sleep.d/55NetworkManager should help, see https://bugzilla.redhat.com/show_bug.cgi?id=552506#c4 NM versions after 20100510 started to authenticate requests, which probably provoked the bug. NM 20100831 starts to listen to UPower's Sleeping/Resuming D-Bus signals, which helps not to rely on pm-utils (or something) to poke NetworkManager. Gnome: gnome-power-manager uses UPower for power management including suspending. Thus everything should work, because Sleeping/Resuming signals are issued by UPower and listened to by NM. KDE: PowerDevil (KDE power manager) doesn't have UPower backend yet, it still relies on HAL. As a result, in KDE, NM is still resumed via pm-utils (55NetworkManager hook). So the bug and its workaround described above are valid. So when reporting the problem, please: 1. include /var/log/messages 2. provide info about NM version, your desktop environment, suspending method (closing lid, clicking a suspend button, calling pm-suspend, ...) (In reply to comment #2) > The only NetworkManager comment I see in /var/log/messages is that my BT device > was removed. Nothing about the wlan. There are NetworkManager logs in /var/log/messages in Fedora. When suspend is requested, it logs: NetworkManager[1278]: <info> sleep requested (sleeping: no enabled: yes) NetworkManager[1278]: <info> sleeping or disabling... When resuming: NetworkManager[1278]: <info> wake requested (sleeping: yes enabled: yes) NetworkManager[1278]: <info> waking up and re-enabling...
I am bothered by the same problem on F14 with NetworkManager-0.8.1-6.git20100831.fc14.i686. The follow issues seem related or duplicated: https://bugzilla.redhat.com/show_bug.cgi?id=633874 https://bugzilla.redhat.com/show_bug.cgi?id=635055 https://bugzilla.redhat.com/show_bug.cgi?id=638640 I will post the message log at next time I face this problem.
I updated to the latest NM and found: 1) NM wouldn't connect using my old configuration. Created a new config and connected. 2) Rebooted and no connection on login. 3) Restarted NM (sudo /etc/init.d/NetworkManager restart) and connected. 4) Suspended to RAM via lid close. 5) Came out of suspend with no connection. Restarting NM gave connection. Making the config available to all users doesn't help. F13 with all updates, user interface Gnome. NM is NetworkManager-0.8.1-6.git20100831.fc13.i686. Backdating to NetworkManager-0.8.1-0.1.git20100510.fc13.i686 and using old config works fine. Attaching 2 /var/log/snippets, one for boot issue, one for suspend.
Created attachment 451915 [details] log during boot and login when NM fails to connect.
Created attachment 451916 [details] log after suspend and resume when NM fails.
Jeff, please note you're using the ralink vendor drivers which are known to have problems when run with wpa_supplicant in a more automatic mode. When this happens, run 'nm-tool' and please report how many access points are shown in the scan list for ra0. If it's none, then the drivers have failed to successfully scan, and NM will request another scan in about 20 seconds or so. You can also force a new scan by running "iwlist ra0 scan" from a terminal, and if that causes NM to start connecting, then the drivers certainly are at fault. There's not a lot NM can do about buggy drivers. The reason it works when you restart NM is that the card has had time to get its act together and then responds correctly to the scan request that NM fires off when it starts. You can debug NM further by: service NetworkManager stop /usr/sbin/NetworkManager --log-level=debug --log-domains=HW,DEVICE,WIFI,WIFI_SCAN which will split out a lot more info about scans and when they fail.
With the new drivers (anything newer than the F13-delivered ones dated 5/10/2010), I get passphrase requests even with a working, newly-generated config. At this point, nm-tool reports my router as available as does the iwlist command. Restarting NM will generate another passphrase request but allows me to cancel and will then connect. Entering a passphrase just creates yet another new config instead of using an existing one. nm-tool: - Device: ra0 ------------------------------------------------------------------ Type: 802.11 WiFi Driver: rt2860 State: disconnected Default: no HW Address: 00:00:00:00:00:00 Capabilities: Wireless Properties WEP Encryption: yes WPA Encryption: yes WPA2 Encryption: yes Wireless Access Points mine: Infra, 30:46:9A:67:6A:92, Freq 2412 MHz, Rate 44 Mb/s, Strength 86 WPA2 iwlist ra0 scan: ra0 Scan completed : Cell 01 - Address: 30:46:9A:67:6A:92 Protocol:802.11b/g/n ESSID:"mine" Mode:Managed Frequency:2.412 GHz (Channel 1) Quality:96/100 Signal level:-52 dBm Noise level:-92 dBm Encryption key:on Bit Rates:300 Mb/s IE: IEEE 802.11i/WPA2 Version 1 Group Cipher : CCMP Pairwise Ciphers (1) : CCMP Authentication Suites (1) : PSK So, it doesn't appear to be a driver issue and that's backed up with the fact that the older (git20100510) NM doesn't have a problem.
Created attachment 452526 [details] Yet another piece of log
Jeff, when the problems occur, do you see any messages relating to "wlan0" or "ra0" in the output of the 'dmesg' command?
As noted in the second /var/log/messages snippet above, there are several references to ra0 (but not wlan0) when resuming. A dmesg grep shows only: RtmpOSNetDevDetach(): RtmpOSNetDeviceDetach(), dev->name=ra0! which is the first line in the above snippet after my notation of resuming. FWIW, a quick test of booting from the F14 Beta live CD shows suspending to work properly.
Jeff, to debug this further we'll need to get info out of NM. You can debug it further by: service NetworkManager stop /usr/sbin/NetworkManager --log-level=debug --log-domains=HW,DEVICE,WIFI,WIFI_SCAN which will split out a lot more info about scans and when they fail. Then try a suspend/resume cycle and copy & paste the NM output into a text file, then attach it to this bug report if you could. It would help quite a bit in figuring out where the driver and NM aren't communicating.
Created attachment 454694 [details] NM log with debug enabled
Attached the requested log. Had to kill the debug NM process and restart before it connected after suspend.
Jeff, it looks like in your logs that NM is waiting for the applet to return the wireless passphrase/key. Do you get any popups asking you for one? Also, can you check ~/.xsession-errors right after this happens and paste in any recent messages?
As noted above (comments 1, 9 and 13), I constantly get prompts for the passphrase. If I enter them, I get a new configuration rather than using the existing one that works. So, I cancel the 2 prompts that occur immediately, restart NM and cancel the prompt when NM starts up. The connection is then made using the existing configuration. Since there are no timestamps in .xsession-errors, here are the last several lines. As you can see, there are several cancellations. I have no idea why the current configuration doesn't work at first but then works fine after cancelling all prompts, not to mention why I have to restart NM to make it work (simply cancelling the first prompts and then trying to manually connect to the router doesn't work). ** Message: <info> No keyring secrets found for Auto mine/802-11-wireless-security; asking user. ** Message: <info> New secrets for Auto mine/802-11-wireless-security requested; ask the user ** (nm-applet:1904): WARNING **: applet-device-wifi.c.1648 (get_secrets_dialog_response_cb): canceled ** (nm-applet:1904): WARNING **: _nm_object_get_property: Error getting 'State' for /org/freedesktop/NetworkManager/ActiveConnection/3: (19) Method "Get" with signature "ss" on interface "org.freedesktop.DBus.Properties" doesn't exist ** (nm-applet:1904): WARNING **: _nm_object_get_property: Error getting 'State' for /org/freedesktop/NetworkManager/ActiveConnection/3: (19) Method "Get" with signature "ss" on interface "org.freedesktop.DBus.Properties" doesn't exist ** (nm-applet:1904): WARNING **: _nm_object_get_property: Error getting 'State' for /org/freedesktop/NetworkManager/ActiveConnection/3: (19) Method "Get" with signature "ss" on interface "org.freedesktop.DBus.Properties" doesn't exist ** (nm-applet:1904): WARNING **: applet-device-wifi.c.1648 (get_secrets_dialog_response_cb): canceled ** Message: NM disappeared ** Message: applet now removed from the notification area ** Message: applet now embedded in the notification area ** Message: <info> No keyring secrets found for Auto mine/802-11-wireless-security; asking user. ** Message: NM appeared ** (nm-applet:1904): WARNING **: applet-device-wifi.c.1648 (get_secrets_dialog_response_cb): canceled
Are you using KDE or XFCE? The message about "no keyring secrets found" indicates that nm-applet is not able to save the passphrase in the gnome-keyring.
Gnome.
Fresh install of F14. Installed update today of NetworkManager-0.8.1-10.git20100831.fc14.i686 and still have same problems (no wireless on ra0 during boot/login nor after suspend). I've gotten around it temporarily by adding: /etc/pm/sleep.d/02NetworkManager #!/bin/bash case $1 in hibernate) echo "Hibernate - NM!" ;; suspend) echo "Suspend - NM!" ;; thaw) /sbin/service NetworkManager restart ;; resume) /sbin/service NetworkManager restart ;; *) echo "somebody is calling me totally wrong." ;; esac to solve the resume issue and this to /etc/rc.d/rc.local for the boot issue: /sbin/service NetworkManager restart It works but shouldn't be needed.
It really looks like there is a problem storing/getting secrets from keyring. I'd suggest you checked proper installation of gnome-keyring. You can also verify that your correct password is stored in gnome-keying using seahorse GUI.
It's the stock install and can be verified with a new user. The secret is read properly, just not at the time it's called. Maybe a race condition that my kludge "fixes"?
I have the exact same issue with gnome-keyring after returning from suspend with nm-applet. It's not an installation issue with gnome-keyring, and it's not exclusive to F13. I'm seeing this in RHEL 6.0: NetworkManager-0.8.1-5.el6_0.1.x86_64 gnome-keyring-2.28.2-6.el6.x86_64
This message is a reminder that Fedora 13 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 13. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '13'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 13's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 13 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 13 changed to end-of-life (EOL) status on 2011-06-25. Fedora 13 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.