6-STABLE, ath, wpa_supplicant/dhcp and suspend/resume problem.

[Sam Leffler]

George Hartzell wrote:
> [In addition to responding to some of Brooks' info, there's a bit of
> new information at the end of the message.]
> 
> Brooks Davis writes:
>  > On Sat, Dec 10, 2005 at 10:33:23AM -0800, Sam Leffler wrote:
>  > > George Hartzell wrote:
>  > > >I have an IBM T42p (2379-DYU) with an atheros based mini-pci card,
>  > > >running 6-STABLE cvsup'ed yesterday morning.
>  > > >
>  > > >I have wpa_supplicant configured for my WEP based 11g network, and
>  > > >have this line in my /etc/rc.conf:
>  > > >
>  > > >  ifconfig_ath0="DHCP WPA NOAUTO"
>  > > >
>  > > >I start the interface via /etc/rc./netif start ath0 when I want to use
>  > > >it.
>  > > >
>  > > >When I suspend the laptop, the wireless link doesn't work on resume.
>  > > >The little icon in my gnome panel has a red disk/white line across the
>  > > >transmit/receive graphics, but the signal strength indicators are a
>  > > >3-high pile of diamonds (same as when it's working).  I'm not sure
>  > > >where the panel-thingy is getting its information.
>  > > >
>  > > >I can resurrect the interface w/ /etc/rc.d/netif restart ath0.
>  > > >
>  > > >When I run wpa_supplicant by hand with some debugging flags, I see the
>  > > >following:
>  > > >
>  > > >   (satchel)[8:59am]~>>sudo /usr/sbin/wpa_supplicant -d -d -K -q -i ath0 
>  > > >   -c /etc/wpa_supplicant.conf
>  > > >   Initializing interface 'ath0' conf '/etc/wpa_supplicant.conf' driver 
>  > > >   'default'
>  > > >   Configuration file '/etc/wpa_supplicant.conf' -> 
>  > > >   '/etc/wpa_supplicant.conf'
>  > > >   Reading configuration file '/etc/wpa_supplicant.conf'
>  > > >   ctrl_interface='/var/run/wpa_supplicant'
>  > > >   ctrl_interface_group=0
>  > > >   eapol_version=1
>  > > >   ap_scan=1
>  > > >   fast_reauth=1
>  > > >   Priority group 5
>  > > >      id=0 ssid='air-palomarin'
>  > > >   Initializing interface (2) 'ath0'
>  > > >   Own MAC address: 00:05:4e:4a:70:e3
>  > > >   wpa_driver_bsd_set_wpa: enabled=1
>  > > >   wpa_driver_bsd_set_wpa_internal: wpa=3 privacy=1
>  > > >   wpa_driver_bsd_del_key: keyidx=0
>  > > >   wpa_driver_bsd_del_key: keyidx=1
>  > > >   wpa_driver_bsd_del_key: keyidx=2
>  > > >   wpa_driver_bsd_del_key: keyidx=3
>  > > >   wpa_driver_bsd_set_countermeasures: enabled=0
>  > > >   wpa_driver_bsd_set_drop_unencrypted: enabled=1
>  > > >   Setting scan request: 0 sec 100000 usec
>  > > >   Starting AP scan (broadcast SSID)
>  > > >   Received 0 bytes of scan results (1 BSSes)
>  > > >   Scan results: 1
>  > > >   Selecting BSS from priority group 5
>  > > >   0: 00:13:10:9f:28:3a ssid='air-palomarin' wpa_ie_len=0 rsn_ie_len=0
>  > > >      skip - no WPA/RSN IE
>  > > >      selected non-WPA AP 00:13:10:9f:28:3a ssid='air-palomarin'
>  > > >   Trying to associate with 00:13:10:9f:28:3a (SSID='air-palomarin' 
>  > > >   freq=2452 MHz)
>  > > >   Cancelling scan request
>  > > >   Automatic auth_alg selection: 0x1
>  > > >   No keys have been configured - skip key clearing
>  > > >   wpa_driver_bsd_set_key: alg=WEP addr=ff:ff:ff:ff:ff:ff key_idx=0 
>  > > >   set_tx=1 seq_len=0 key_len=5
>  > > >   wpa_driver_bsd_set_key: alg=WEP addr=ff:ff:ff:ff:ff:ff key_idx=1 
>  > > >   set_tx=0 seq_len=0 key_len=5
>  > > >   wpa_driver_bsd_set_key: alg=WEP addr=ff:ff:ff:ff:ff:ff key_idx=2 
>  > > >   set_tx=0 seq_len=0 key_len=13
>  > > >   wpa_driver_bsd_set_drop_unencrypted: enabled=1
>  > > >   wpa_driver_bsd_associate: ssid 'air-palomarin' wpa ie len 0 pairwise 1 
>  > > >   group 1 key mgmt 2
>  > > >   wpa_driver_bsd_associate: set PRIVACY 1
>  > > >   Setting authentication timeout: 5 sec 0 usec
>  > > >   Association event - clear replay counter
>  > > >   Associated to a new BSS: BSSID=00:13:10:9f:28:3a
>  > > >   Associated with 00:13:10:9f:28:3a
>  > > >   Cancelling authentication timeout
>  > > >***SUSPENDED/RESUMED HERE***   
>  > > >   Setting scan request: 0 sec 100000 usec
>  > > >   Added BSSID 00:13:10:9f:28:3a into blacklist
>  > > >   Disconnect event - remove keys
>  > > >   Starting AP scan (broadcast SSID)
>  > > >
>  > > >And the interface isn't working.  Killing and restarting
>  > > >wpa_supplicant brings it back.
>  > > >
>  > > >I also have an older apm based sony Z505 w/ an ath0 pc-card that
>  > > >suspends and resumes w/out any manual intervention.
>  > > >
>  > > >What can I do to make the IBM work w/out manual intervention?
>  > > 
>  > > I have a t42 and atheros card and it works fine w/o the NOAUTO setting 
>  > > and WPA (not WEP).   If removing NOAUTO fixes things then maybe some 
>  > > fixup is required in the rc.resume script.  I'd have expected devd to be 
>  > > notified on resume to bring the interface back up but since you've got 
>  > > NOAUTO set perhaps that's disabling it from happening.
>  > 
>  > I think there are two things going one.  First, NOAUTO means that on
>  > resume the card doesn't come up because the system can't tell resume
>  > from anything else.  
> 
> Removing NOAUTO from the ifconfig_ath0 line does not fix my problem.
> 
>  > Second, wpa_supplicant doesn't get killed like it
>  > should during suspend (probably due to races) and it doesn't in my
>  > experience deal well with card state changing underneath it.
> 
> So, on suspend wpa_supplicant should be killed, and then on resume it
> should restart from scratch (as long as I'm not using NOAUTO...)?

Actually I don't think so (on reflection).  On suspend the driver will 
stop the device and mark the 802.11 state to "INIT".  This causes 
wpa_supplicant to be notified the association was dropped but since the 
interface is still present (and marked UP) it will stick around and try 
to reconnect.  It would be better if wpa_supplicant recognized a suspend 
was happening and not try to immediately revise the interface but that's 
a separate issue.

> 
> Is wpa_supplicant responsible for running dhclient or is that started
> separately via /etc/rc.d/netif?  I've noticed that if I'm running
> wpa_supplicant in the foreground and kill it, dhclient dies too.  Or
> is that just because it loses link?

dhclient is launched by devd when the link up even is dispatched.  If 
you terminate wpa_supplicant I believe it marks the interface down 
(actually restoring state to what it found on startup) which would then 
cause dhclient to terminate.

> 
>  > I suspect
>  > the eventual answer is that we'll need to and suspend and resume code
>  > to /etc/rc.d/netif so we can record the state of interfaces at suspend
>  > and restore them at resume.  That's a fairly tricky problem to solve
>  > completely because users can do silly things like spending, swaping
>  > cards, and resuming.
> 
> Who/what would run the netif script at suspend time?
> /etc/rc.{suspend,resume} only seem to run if I suspend via acpiconf,
> not if I suspend via closing the lid w/ hw.acpi.lid_switch_state: S3.
> 
> Would the problem be easier to solve if we punted on the swapping out
> cards while suspended problem?  Would it also cover ethernet
> interfaces (em0 in my case) that are also NOAUTO?

NOAUTO in this case is irrelevant.  If you ifconfig ath0 down on suspend 
and mark it up on resume then you can get the behaviour Brooks was 
suggesting (or use rc.d/netif).  But in my experience you can just leave 
wpa_supplicant running on suspend and when resume comes it'll just 
wakeup and resurrect state so there's little to gain by stopping it.  If 
this is a cardbus card and it's removed while suspended wpa_supplicant 
should recognize this and terminate.  Likewise if you swap cards though 
I'm not 100% sure the right thing will happen if you swap cards s.t. the 
same interface is created on resume (e.g. pull one ath card and replace 
it with a different one).


> 
> <NEW_INFO>
> I have a bit of new data that may or may not be useful.  Here's the
> tail end of my dmesg output.  Sometimes there seems to be a message
> about being unable to reset ath0.  Is that a red herring?
> 
>    can't re-use a leaf (squelch_level)!
>    ath0: link state changed to UP
>    ath0: link state changed to DOWN
>    ath0: unable to reset hardware; hal status 3
>    wakeup from sleeping state (slept 00:51:26)
>    can't re-use a leaf (directional_scrolls)!
>    can't re-use a leaf (low_speed_threshold)!
>    can't re-use a leaf (min_movement)!
>    can't re-use a leaf (squelch_level)!
>    ath0: link state changed to UP
>    ath0: link state changed to DOWN
>    wakeup from sleeping state (slept 00:00:06)
>    ath0: link state changed to UP
>    can't re-use a leaf (directional_scrolls)!
>    can't re-use a leaf (low_speed_threshold)!
>    can't re-use a leaf (min_movement)!
>    can't re-use a leaf (squelch_level)!
>    ath0: link state changed to DOWN
>    wakeup from sleeping state (slept 00:00:09)
>    ath0: link state changed to UP
>    ath0: link state changed to DOWN
>    wakeup from sleeping state (slept 00:00:06)
>    can't re-use a leaf (directional_scrolls)!
>    can't re-use a leaf (low_speed_threshold)!
>    can't re-use a leaf (min_movement)!
>    can't re-use a leaf (squelch_level)!
>    ath0: link state changed to UP
>    ath0: link state changed to DOWN
>    ath0: unable to reset hardware; hal status 3
>    wakeup from sleeping state (slept 01:10:08)
>    can't re-use a leaf (directional_scrolls)!
>    can't re-use a leaf (low_speed_threshold)!
>    can't re-use a leaf (min_movement)!
>    can't re-use a leaf (squelch_level)!

Please send me your wpa_supplicant.conf file offline and I'll see if I 
can recreate what's going on.  It may be something specific to WEP 
though I can't imagine why.

	Sam