Bug 588578 - Wireless network does not reconnect on resume after suspend to RAM
Summary: Wireless network does not reconnect on resume after suspend to RAM
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: NetworkManager
Version: 13
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Dan Williams
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-05-04 00:18 UTC by Uno Engborg
Modified: 2010-05-05 20:25 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2010-05-05 20:25:02 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
/var/log/messages displaying log entries from the suspend/resume activities (17.26 KB, text/plain)
2010-05-04 00:21 UTC, Uno Engborg
no flags Details

Description Uno Engborg 2010-05-04 00:18:02 UTC
Description of problem:

This error occured afer upgrading from:
   NetworkManager-vpnc-0.8.0-1.git20100411.fc13.i686
to:
   NetworkManager-0.8.0-9.git20100429.fc13.i686

Wireless network does not reconnect automatically on resume after suspend to RAM

kernel: kernel-2.6.33.3-72.fc13.i686
Network controller: Intel Corporation PRO/Wireless 2200BG [Calexico2] Network Connection (rev 05)



Version-Release number of selected component (if applicable):
0.8.0-9.git20100429.fc13


How reproducible: Always


Steps to Reproduce:
1. run pm-suspend, or close the lid on the laptop to initiate a suspend to RAM
2. open the lid
3. Watch the computer wake up, everything is fine exept it is no longer connected to the network. However, the NetworkManager signal strenth icon is shown instead of the "double computer icon" that normally is shown when no network is selected.
  
Actual results:
The wireless network is disconnected

Expected results:
The wireless network should reconnect automatically if it was connected when the suspend took place.


Additional info:
Manually selecting a network, after resuming restores the network connection.

Comment 1 Uno Engborg 2010-05-04 00:21:32 UTC
Created attachment 411161 [details]
/var/log/messages displaying log entries from the suspend/resume activities

Comment 2 Dan Williams 2010-05-05 03:34:39 UTC
It looks like you've got a shared network connection defined for wifi that allows other users to connect to your computer and use its internet connection.  And it looks like that connection has "Connect automatically" checked. Try right-clicking on the applet icon and deleting that network in the connection editor.

May  4 01:40:50 humlan NetworkManager: <info> Activation (eth0/wireless): connection 'WEBWORKS' has security, and secrets exist.  No new secrets needed.
May  4 01:40:50 humlan NetworkManager: <info> Config: added 'ssid' value 'WEBWORKS'
May  4 01:40:50 humlan NetworkManager: <info> Config: added 'mode' value '1'
May  4 01:40:50 humlan NetworkManager: <info> Config: added 'frequency' value '2412'

(the 'mode 1' is the part that says its adhoc/shared).

If you see the WEBWORKS network in the editor, does teh "Wireless" page say "Mode: adhoc" on it?

Comment 3 Uno Engborg 2010-05-05 08:32:42 UTC
First of all, after the latest "yum update" the network now actually comes up again on resume, So as far as I'm concerned this bug could be closed, unless my log info indicates some other type of error that could be problematic to somebody else.

If I try to edit the network connections I see two connections in the edit dialog:

WEBWORKS        used 1 day ago
Auto WEBWORKS   used 8 days ago

If I do mouseover on the signal strength icon, the mouseover pop up indicates that it is the "Auto WEBWORKS" connection that is used.


- The "WEBWORKS" connection is indeed of type Adhoc, but it is not shared.

- The "Auto WEBWORKS" connection is of type "infrastructure" (Or whatever it might be called in English, my Swedish system calls it "infrastruktur"). This connection is shared.

I removed the "WEBWORKS" line and it still works fine.

Comment 4 Dan Williams 2010-05-05 20:25:02 UTC
ok, thanks for the update.  You were hitting bug 588814 which was fixed by the latest bits from this morning.


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