Regression in suspend/resume after "nl80211: Drop frame events that are for foreign address"

Jouni Malinen j at w1.fi
Mon May 13 04:57:22 EDT 2013


On Sun, May 12, 2013 at 07:30:12PM +0000, Peer, Ilan wrote:
> Using the latest hostap 2.0 we are seeing connectivity problems after a suspend/resume cycle, where the wpa_supplicant assumes that it is still connected to the AP although the station was disconnected from the AP during the suspend flow. We tried bisecting this, and the results point to the change  introduced in "nl80211: Drop frame events that are for foreign address". The logs after the resume show that event 39 (DEAUTH) is ignored due to an address mismatch (where A1 is the BSSID of the AP that we have just disconnected from). After the patch was reverted the connection after suspend/resume was successful.

Could you please send wpa_supplicant debug log with timestamps (-t on
command line) and logs from "ip monitor" and "iw event -t"?

> wpa_supplicant[10881]: RTM_NEWLINK: operstate=1 ifi_flags=0x1003 ([UP])
> wpa_supplicant[10881]: RTM_NEWLINK, IFLA_IFNAME: Interface 'wlan0' added
> wpa_supplicant[10881]: nl80211: if_removed already cleared - ignore event
> wpa_supplicant[10881]: nl80211: Ignore event for foreign ifindex 2
> wpa_supplicant[10881]: nl80211: Ignore event for foreign ifindex 2
> wpa_supplicant[10881]: nl80211: Event message available
> wpa_supplicant[10881]: nl80211: Delete station 00:23:5d:8e:6e:a0
> wpa_supplicant[10881]: nl80211: Event message available
> wpa_supplicant[10881]: nl80211: MLME event 39 on wlan0(00:15:00:bf:47:8a) A1=00:23:5d:8e:6e:a0
> wpa_supplicant[10881]: nl80211: wlan0: Ignore MLME frame event for foreign address

There is not enough context in this to figure out what exactly happened
during suspend. I think something else than wpa_supplicant is requesting
disconnection here and that would explain why git bisect points at the
specific commit..

wpa_supplicant should know on its own when it requests disconnection
which is why this does not show up in other cases, but I guess we need
to accept the events for frames that the local device sent for cases
where something else in the system ended up generating the
deauthentication or disassociation frame. This commit does that:
http://w1.fi/gitweb/gitweb.cgi?p=hostap.git;a=commitdiff;h=455299fb40d79bcbeaedcfbc04d00ac8330bbbdd

I would assume it addresses the issue you are seeing. At least it fixes
a case where "iw wlan0 disconnect" command issued while wpa_supplicant
was running and in connected state ended up wpa_supplicant ignoring the
deauthentication event.

-- 
Jouni Malinen                                            PGP id EFC895FA


More information about the HostAP mailing list