Description of problem: When the computer is resumed from suspend-to-ram or suspend-to-disk, NetworkManager fails to resume the previously active wlan connection. The NM tray icon is in the 'no connection' state, and when it is right-clicked and the 'Networking' option is unchecked and re-checked, NM starts to initialise the connection, but never actually succeeds. Instead, it starts to indefinitely ask for the wireless lan password, regardless of whether or not it is given correctly. Also, after resuming from suspend-to-disk, a window pops up asking for the default keyring password. Version-Release number of selected component (if applicable): 0.7.0.99 How reproducible: always Steps to Reproduce: 1. suspend or hibernate your machine 2. wake it up 3. (optionally) uncheck and re-check 'networking' in the NM right-click menu. Actual results: NM keeps asking for wireless secrets. Also, after resuming from suspend-to-disk a window pops up with a demand for the default keyring password. Expected results: After resuming from suspend-to-disk or suspend-to-ram, NM should reconnect to the previously used wireless network (provided the network is still available, of course). Additional info: I use a hp pavillion dv6000 laptop computer with a 4311 broadcom wireless adapter (and hence the b43 kernel module).
The networking enabled thing is known and filed; the reconnection issue is likely due to driver/supplicant bugs that are also in the process of being fixed. Is your AP hidden? *** This bug has been marked as a duplicate of bug 477964 ***
MY AP point is not hidden. SSID broadcasting is on. With the previous kernel (2.6.27.19-170.2.35) I would issue the following commands: rmmod b43 service NetworkManager restart modprobe b43 service NetworkManager restart and NM then was able to establish my wireless connection. With the current kernel (2.6.27.21-170.2.56), the procedure above does not work any more. I have to log out, log in as a different user (who immediately has the wireless connection started), then log out again, and log in as myself. The connection is immediately available. The funny thing about this is that I never had this sort of a problem when I used fedora 8, and even when I first installed f10. The problem started to occur later, and it gradually increased with each kernel(?) update, to the point where the wireless connection is never re-established after suspension/hibernation.