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

Jouni Malinen j
Sun Nov 25 12:16:14 PST 2012

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

More information about the Hostap mailing list