Bug 444192

Summary: wireless doesn't work right after resume from hibernate
Product: [Fedora] Fedora Reporter: Andrew Duggan <lists>
Component: NetworkManagerAssignee: Dan Williams <dcbw>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: rawhideCC: dcbw, debarshir, wtogami
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-05-02 15:58:38 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Description Andrew Duggan 2008-04-25 19:05:58 UTC
Description of problem:

After a resume from hibernate, NetworkManager does not (re)connect to the
wireless network. 
Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1. Hibernate then resume
Actual results:

NetworkManager nm-applet presents a disconnected icon

Expected results:

NetworkManager (re) connects to the wireless network 

Additional info:

Broadcom 4311 using the b43 driver and the recommended firmware

even while disconnected, a iwlist wlan0 scanning will return the correct scan

I have to 
service NetworkManager stop ; \
killall -9 wpa_supplicant dhclient ; \
sleep 10; service NetworkManager start 

to get it to reconnect.  The killall might be overkill, even a service
NetworkManager restart does not fix the problem.  I've also sometimes also had
to do a ifdown wlan0, which leads me to think that NM or maybe wpa_supplicant
thinks the interface is still up from before NetworkManager was put to sleep by
the pm-utils /usr/lib/pm-utils/sleep.d/10NetworkManager.

Also even after I get it to reconnect, sometimes the nm-applet continues to list
the visible networks from home when I hibernated at home  and resumed at work. 
The driver is not presenting those as an iwlist wlan0 scanning returns the
correct list always.

Even hitting the kill switch waiting about 30 seconds and hitting it again does
not make it reconnect.  

If the LAN (wired) has a link NM will connect to that just fine after

There are no selinux avc's reported.

Even with this bug NM is still seriously great!

Comment 1 Andrew Duggan 2008-04-27 02:28:59 UTC
I can also get it to reconnect by 
# ifdown wlan0
# dbus-send --system \
 --dest=org.freedesktop.NetworkManager \
 /org/freedesktop/NetworkManager \
# dbus-send --system \
 --dest=org.freedesktop.NetworkManager \
 /org/freedesktop/NetworkManager \

after resume

Plus if I do a 

dbus-send  --system --type=method_call --print-reply \
 --dest=org.freedesktop.NetworkManager \
 /org/freedesktop/NetworkManager/ActiveConnection/1 \
 org.freedesktop.DBus.Properties.Get \
  string:org.freedesktop.NetworkManager.Connection.Active string:Connection

I get this back

method return sender=:1.6 -> dest=:1.156 reply_serial=2
   variant       object path "/org/freedesktop/NetworkManagerSettings/0"

I can't find that object path in in org.freedesktop.NetworkManager using d-feet.
So I am not surprised that this

dbus-send --system --type=method_call --print-reply \
 --dest=org.freedesktop.NetworkManager \
 /org/freedesktop/NetworkManager \
 org.freedesktop.NetworkManager.DeactivateConnection \

returns this:

Error org.freedesktop.NetworkManager.ConnectionNotActive: The connection was not

Comment 2 Andrew Duggan 2008-04-29 00:11:36 UTC
Updated to svn3614

Now NM crashes on resume

Apr 28 20:03:49 apd-dell1 NetworkManager: <info>  (eth0): exported as
Apr 28 20:03:49 apd-dell1 NetworkManager: Failed to register GObject with

Comment 3 Andrew Duggan 2008-04-30 14:56:31 UTC
Updated to svn3619

Get the following avc when in permissive mode, and it crashes on resume if in

On the Upsdide though in permissive mode it actually did reconnect to the
wireless network (svn3619) on resume from hibernate.

FWIW time timestamp is from when the hibernate was initiated  08:46:18 

Source Context:  system_u:system_r:dhcpc_t:SystemLow-SystemHigh
Target Context:  system_u:system_r:syslogd_t
Target Objects:  ./stat [ file ]
Source:  psSource 
Path:  /bin/ps
Port:  <Unknown>
Host:  localhost
Source RPM Packages:  procps-3.2.7-20.fc9
Target RPM Packages:  
Policy RPM:  selinux-policy-3.3.1-42.fc9
Selinux Enabled:  
TruePolicy Type:  targeted
MLS Enabled:  True
Enforcing Mode:  Permissive
Plugin Name:  catchall_fileHost 
Name:  localhost
Platform:  Linux localhost 2.6.25-8.fc9.i686 #1 SMP Wed Apr 23 03:56:19 EDT 2008
i686 i686
Alert Count:  1
First Seen:  Wed 30 Apr 2008 08:46:20 AM EDT
Last Seen:  Wed 30 Apr 2008 08:46:20 AM EDT

Comment 4 Andrew Duggan 2008-04-30 17:01:25 UTC
Spoke too soon, I hibernate/resumed again and this time although NM didn't crash
it did not reattach to the wireless network.  Same sort of avc's still  happen.
Needed to .sleep, ifdown wlan0 and then .wake to make it reconnect.

Comment 5 Dan Williams 2008-05-01 10:45:52 UTC
This specific crash has been fixed in the latest koji builds that will hit F9 today:


Comment 6 Andrew Duggan 2008-05-01 17:46:22 UTC
Yes with svn3623 the crashing is gone!  The original problem remains. 

Plus I've noticed that trying to a vpn after the hibernate/resume fails
consistently with a notification that says that the vpn dameon died
unexpectedly.  If I run nm-vpnc-service from a shell, this is way is produced.  

** (process:9062): WARNING **: VPN property 'name' failed validation.

Then it exits after a about a minute or two.

running vpnc directly works, so it's not an issue with vpnc or the remote vpn
gateway.  Plus it worked until I did the first hibernate/resume cycle after
installing svn3623.   For good measure I rebooted after that to make sure there
was nothing wrong with my normal process after an NM update.


Comment 7 Andrew Duggan 2008-05-02 02:15:51 UTC
svn3623.  Wireless is reconnecting on resume from hibernate.  It takes about 90
seconds, (it used to be faster, but 90 seconds is not unacceptable from my POV).
 I've done about 10 hibernate/resume cycles and it's pretty consistently working
at ~90 seconds so I would say the original issue is fixed). Thanks. There does
seem to be now an issue with the VPN  

Comment 8 Andrew Duggan 2008-05-02 15:58:38 UTC
I consider this fixed with 


Excellent - thanks!

Comment 9 Debarshi Ray 2008-09-07 18:55:23 UTC
I am encountering the same problem. On resuming from hibernation NetworkManager repeatedly asks for the WPA2 password but can not connect.

I am using NetworkManager-0.7.0-0.9.4.svn3675.fc9.x86_64 on a WPA2 Personal protected 802.11b/g network. I am using the SVN snapshot from Madwifi to get my Atheros AR5418 card to work on Fedora 9, and my access point is a Linksys WRT54G2.

Rebooting the system solves the problem.