Bug 494955

Summary: NetworkManager fails to reconnect to wireless network upon resume from suspend-to-disk or suspend-to-ram
Product: [Fedora] Fedora Reporter: Kamil Stawirej <17083525>
Component: NetworkManagerAssignee: Dan Williams <dcbw>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: low    
Version: 10CC: dcbw
Target Milestone: ---   
Target Release: ---   
Hardware: i686   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-04-09 01:19:33 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:

Description Kamil Stawirej 2009-04-08 19:54:27 UTC 
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).
Comment 1 Dan Williams 2009-04-09 01:19:33 UTC 
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 ***
Comment 2 Kamil Stawirej 2009-04-09 04:30:53 UTC 
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.