Bug 444192 - wireless doesn't work right after resume from hibernate
wireless doesn't work right after resume from hibernate
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: NetworkManager (Show other bugs)
rawhide
i386 Linux
low Severity medium
: ---
: ---
Assigned To: Dan Williams
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-04-25 15:05 EDT by Andrew Duggan
Modified: 2008-09-07 14:55 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-05-02 11:58:38 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 Andrew Duggan 2008-04-25 15:05:58 EDT
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):

NetworkManager-0.7.0-0.9.2.svn3590.fc9.i386
wpa_supplicant-0.6.3-5.fc9.i386
dhclient-4.0.0-14.fc9.i386

How reproducible:

Always

Steps to Reproduce:
1. Hibernate then resume
2. 
3.
  
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
kernel-2.6.25-1.fc9.i686

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

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
hibernate/resume.

There are no selinux avc's reported.

Even with this bug NM is still seriously great!
Comment 1 Andrew Duggan 2008-04-26 22:28:59 EDT
I can also get it to reconnect by 
# ifdown wlan0
# dbus-send --system \
 --dest=org.freedesktop.NetworkManager \
 /org/freedesktop/NetworkManager \
 org.freedesktop.NetworkManager.sleep
# dbus-send --system \
 --dest=org.freedesktop.NetworkManager \
 /org/freedesktop/NetworkManager \
 org.freedesktop.NetworkManager.wake

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 \
 objpath:/org/freedesktop/NetworkManagerSettings/0

returns this:

Error org.freedesktop.NetworkManager.ConnectionNotActive: The connection was not
active.
Comment 2 Andrew Duggan 2008-04-28 20:11:36 EDT
Updated to svn3614

Now NM crashes on resume

Apr 28 20:03:49 apd-dell1 NetworkManager: <info>  (eth0): exported as
/org/freedesktop/Hal/devices/net_00_15_c5_ac_3a_a1
Apr 28 20:03:49 apd-dell1 NetworkManager: Failed to register GObject with
DBusConnection
Comment 3 Andrew Duggan 2008-04-30 10:56:31 EDT
Updated to svn3619

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

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 13:01:25 EDT
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 06:45:52 EDT
This specific crash has been fixed in the latest koji builds that will hit F9 today:

http://koji.fedoraproject.org/koji/buildinfo?buildID=47742
Comment 6 Andrew Duggan 2008-05-01 13:46:22 EDT
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.

Thanks.
Comment 7 Andrew Duggan 2008-05-01 22:15:51 EDT
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 11:58:38 EDT
I consider this fixed with 

NetworkManager-0.7.0-0.9.3.svn3623
and
NetworkManager-vpnc-0.7.0-0.7.7.svn3627

Excellent - thanks!
Comment 9 Debarshi Ray 2008-09-07 14:55:23 EDT
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.

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