Hi Antony, On Thursday 11 September 2008 22:03:11 Antony Gelberg wrote: > Package: wpasupplicant > Version: 0.6.4~git20080716.93ef879-1 > Severity: normal > > Hi, > > I have to say that this is a difficult problem to replicate, or should I say > the workaround is not always the same. I find that after suspending or > hibernating my laptop, the wlan0 interface doesn't come back up properly. It > doesn't seem to matter whether or not I resume in the same SSID that I > suspended in.
My hunch is it is very likely to be a problem related to the kernel wifi driver/networking stack. Also check your dmesg buffer for interesting messages from the kernel. > > Here follows some output, taken a couple of minutes after resume, with my > comments prefixed with ***. > > Every 2.0s: ifconfig wlan0 > Sat Sep 6 11:57:11 2008 > > wlan0 Link encap:Ethernet HWaddr 00:1f:3c:4b:70:1f > UP BROADCAST MULTICAST MTU:1500 Metric:1 > RX packets:675729 errors:0 dropped:0 overruns:0 frame:0 > TX packets:269129 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:1000 > RX bytes:880049567 (839.2 MiB) TX bytes:65980602 (62.9 MiB) > > *** No IP address assigned. > > very 2.0s: iwconfig wlan0 > wlan0 IEEE 802.11 ESSID:"haslemere" > Mode:Managed Frequency:2.462 GHz Access Point: Not-Associated > Tx-Power=15 dBm > Retry min limit:7 RTS thr:off Fragment thr=2352 B > Encryption key: ***munged [2] > Link Quality:0 Signal level:0 Noise level:0 > Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 > Tx excessive retries:0 Invalid misc:0 Missed beacon:0 > > *** No MAC address. > > labrie:/home/antony# tail -f /var/log/wpa_supplicant.wlan0.log > Failed to initiate AP scan. > Failed to initiate AP scan. > Failed to initiate AP scan. > Failed to initiate AP scan. > Failed to initiate AP scan. > Failed to initiate AP scan. > Failed to initiate AP scan. > Failed to initiate AP scan. > Failed to initiate AP scan. > Failed to initiate AP scan. > > *** Self-explanatory. > > Every 2.0s: ps ax |grep wlan0 > Sat Sep 6 11:59:47 2008 > > 28074 ? Ss 0:00 /sbin/wpa_supplicant -W -B -P > /var/run/wpa_supplicant.wlan0.pid -i wlan0 -D wext -q -f > /var/log/wpa_supplicant.w > 28125 ? Ss 0:00 /sbin/wpa_cli -B -P /var/run/wpa_action.wlan0.pid > -i wlan0 -p /var/run/wpa_supplicant -a /sbin/wpa_action > 32259 pts/8 S+ 0:00 watch ifconfig wlan0 > 32267 ? Ss 0:00 avahi-autoipd: [wlan0] bound 169.254.3.212 > 32268 ? Ss 0:00 avahi-autoipd: [wlan0] callout dispatcher > 32277 pts/10 S+ 0:00 watch iwconfig wlan0 > 32280 ? Ss 0:00 dhclient3 -pf /var/run/dhclient.wlan0.pid -lf > /var/lib/dhcp3/dhclient.wlan0.leases wlan0 > 32392 pts/9 S+ 0:00 tail -f /var/log/wpa_supplicant.wlan0.log > 32593 pts/14 S+ 0:00 watch ps ax |grep wlan0 > 32629 pts/14 S+ 0:00 sh -c ps ax |grep wlan0 > 32631 pts/14 S+ 0:00 grep wlan0 > > *** wpa_supplicant and dhclient are running. > > I tried reassociate in wpa_cli, and it associated with the AP, but still > didn't receive an IP address via DHCP. I then tried ifdown wlan0 && ifup > wlan0, and I got: > <2>Trying to associate with 00:14:bf:3d:a7:8e (SSID='haslemere' freq=2462 MHz) > <2>CTRL-EVENT-SCAN-RESULTS > <2>Authentication with 00:14:bf:3d:a7:8e timed out. > > Eventually things work, after ifdown wlan0, then waiting a minute or two, then > ifup wlan0. I wish I could be more specific about the recovery but it doesn't > seem consistent - I'm not even 100% sure it's related to my ifdown and ifup > commands. Please let me know if you need any more information, I'll happily > assist debugging if you give me a clue. > > Lastly: > # cat /etc/network/interfaces > # This file describes the network interfaces available on your system > # and how to activate them. For more information, see interfaces(5). > > # The loopback network interface > auto lo > iface lo inet loopback > > # The primary network interface > allow-hotplug eth0 > iface eth0 inet dhcp > > auto wlan0 > iface wlan0 inet manual > wpa-driver wext > wpa-roam /etc/wpa_supplicant/wpa_supplicant.conf > > iface default inet dhcp Workarounds: I have found it very reliable to have the network disconnected entering suspend, and reconnected upon resuming. Otherwise, for me, the iwl* driver seemed to resume still associated network but without meaningful network connectivity. The execution of such a hook depends on what power management software you are using. On Debian the popular ones seem to be acpi-support or pm-utils. I understand pm-utils pretty well, and have integrated a suspend/resume hook in a package in personal archive: http://sidux.net/kelmo/debian/pool/main/w/wpasupplicant/ (Disclaimer: be careful with packages not coming directly from Debian archive) It installs a script to: /etc/wpa_supplicant/action_wpa.sh With symlink to script in pm-utils hook area: /etc/pm/sleep.d/action_wpa As long as you keep the default wpa_supplicant configuration option for ctrl_interface (/var/run/wpa_supplicant/) this hook should be able to disconnect all wpa-roam'ing interfaces as machine goes into sleep, and reconnect on resume. For acpi-support see: http://bugs.debian.org/390884 , I do not use or understand acpi-support very well. Thanks, Kel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
