Bug 494955 - NetworkManager fails to reconnect to wireless network upon resume from suspend-to-disk or suspend-to-ram
NetworkManager fails to reconnect to wireless network upon resume from suspen...
Status: CLOSED DUPLICATE of bug 477964
Product: Fedora
Classification: Fedora
Component: NetworkManager (Show other bugs)
10
i686 Linux
low Severity high
: ---
: ---
Assigned To: Dan Williams
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-04-08 15:54 EDT by Kamil Stawirej
Modified: 2009-04-09 00:30 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-04-08 21:19:33 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Kamil Stawirej 2009-04-08 15:54:27 EDT
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-08 21:19:33 EDT
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 00:30:53 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.