[RFC PATCH] PMKSA: update current cache entry on association and disassociation

[Jouni Malinen]

On Mon, Aug 13, 2012 at 05:42:15PM -0500, Dan Williams wrote:
> Ensure the current PMKSA cache entry pointer always points to the current
> BSSID's cache entry.

Thanks. Applied the disassociation part. Association part does not look
correct and I left that (i.e., most of the changes in this commit) out.
wpa_find_assoc_pmkid() is already calling pmksa_cache_set_current()
based on the used RSN element (PMKID) in (Re)Association Request frame.
Calling this function again just after that, but without the PMKID
parameter could override the sm->cur_pmksa entry. I'm not sure whether
this could happen in practice with the current PMKSA cache
implementation due to limitations on how many entries can be added for a
single BSSID (AA), but at least in theory, there could be multiple PMKSA
entries for a BSS.

In addition, this warning showed up in the logs constantly:

> @@ -2123,6 +2124,12 @@ void wpa_sm_notify_assoc(struct wpa_sm *sm, const u8 *bssid)
>  	if (os_memcmp(sm->preauth_bssid, bssid, ETH_ALEN) == 0)
>  		rsn_preauth_deinit(sm);
>  
> +	if (!pmksa_cache_set_current(sm, NULL, bssid, network_ctx, 0)) {
> +		wpa_printf(MSG_WARNING, "WPA: expected existing PMKSA cache "
> +		           "entry for " MACSTR " but none found",
> +		           MAC2STR(sm->bssid));
> +	}

Maybe that was supposed to check whether the return value was < 0 rather
than == 0? Anyway, I don't think it would be good to have this call
here. If you think the current PMKSA cache entry is not set properly,
that could be handled in wpa_supplicant_event_assoc() based on the PMKID
information from our local RSN element to avoid potentially conflicting
calls from events. and wpa.c to set the entry on association.

-- 
Jouni Malinen                                            PGP id EFC895FA