Re: missing RX_FLAG_DECRIPTED in ieee80211_rx_status after first reassociation in 802.11R

[Johannes Berg <johannes@sipsolutions.net>]

Hi Cédric,

> 	I attached the trace file since it is quite long (about 1400 lines).
> 	Here are some pointers : 
> 		Original AP = 90:A4:DE:AA:42:94, channel : 132, ssid : acksyscdtest
> 		Second AP = 90:A4:DE:AA:41:ED, channel : 132, ssid : acksyscdtest
> 
> 		When wpa_supplicant is launched, it associates directly with
> 90:A4:DE:AA:42:94.
> 		The roaming order is given by the wpa_cli roam command (roam
> 90:A4:DE:AA:41:ED). You can find it at line 1042 of the traces.
> 		I used the -T option of wpa_supplicant.
> 
> 	In order to get cfg80211 traces I had to switch to compat wireless
> version 2012-12-06 (previous was 2012-09-07). Nevertheless, the
> behavior seems to remain the same (same exit in
> ieee80211_key_enable_hw_accel at the first roam).

Thanks for the trace! That allowed me to understand the bug very easily,
I didn't realize you had used FT.

It looks like this bug was introduced by my

commit 66e67e418908442389d3a9e6509985f01cbaf9b0
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Fri Jan 20 13:55:27 2012 +0100

    mac80211: redesign auth/assoc

This changed the way mac80211 allocates stations when it connects to an
AP, to allocate it before associating. wpa_supplicant can deal with key
setting being rejected before association and will set the key again
after association, which is the code path that was used before this code
change in mac80211, but now mac80211 would accept the key even before
that.

I think the patch below might work to restore the old behaviour:

diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c
index 7d290bc..48a03b0 100644
--- a/net/mac80211/cfg.c
+++ b/net/mac80211/cfg.c
@@ -164,7 +164,7 @@ static int ieee80211_add_key(struct wiphy *wiphy, struct net_device *dev,
 			sta = sta_info_get(sdata, mac_addr);
 		else
 			sta = sta_info_get_bss(sdata, mac_addr);
-		if (!sta) {
+		if (!sta || !test_sta_flag(sta, WLAN_STA_ASSOC)) {
 			ieee80211_key_free(sdata->local, key);
 			err = -ENOENT;
 			goto out_unlock;


That would probably be a reasonable patch for stable. I think the other
way we could handle this is accept the key, and only upload it to the
hardware after the station has been marked associated.

johannes