[PATCH] wpa_supplicant: clear bssid state on deauth

[Arik Nemtsov]

On Sat, Jun 9, 2012 at 12:49 PM, Jouni Malinen <j at w1.fi> wrote:
> On Wed, May 30, 2012 at 09:32:48AM +0300, Arik Nemtsov wrote:
>> When de-authenticated by an AP, the state of wpa_s should be cleared,
>> especially the previous bssid. Otherwise, we will use re-assoc packets
>> when associating to the same AP. This is not according to spec, and some
>> APs refuse to association.
>
> Would you be able to identify such an AP that rejects the reassociation
> in this type of case?

I believe we had problems with some Broadcom APs. I can ask for
specific models if you're interested.

> diff --git a/wpa_supplicant/events.c b/wpa_supplicant/events.c
> index d09be6c..e7dfa4e 100644
> --- a/wpa_supplicant/events.c
> +++ b/wpa_supplicant/events.c
> @@ -121,6 +121,9 @@ void wpa_supplicant_mark_disassoc(struct wpa_supplicant *wpa_s)
> ? ? ? ?bssid_changed = !is_zero_ether_addr(wpa_s->bssid);
> ? ? ? ?os_memset(wpa_s->bssid, 0, ETH_ALEN);
> ? ? ? ?os_memset(wpa_s->pending_bssid, 0, ETH_ALEN);
> +#ifdef CONFIG_SME
> + ? ? ? wpa_s->sme.prev_bssid_set = 0;
> +#endif /* CONFIG_SME */
> ?#ifdef CONFIG_P2P
> ? ? ? ?os_memset(wpa_s->go_dev_addr, 0, ETH_ALEN);
> ?#endif /* CONFIG_P2P */
>
>
> Could you please confirm that this resolves the issue you've seen?

This would indeed resolve the issue (and was the initial variant we
tested). I added the set_state to WPA_DISCONNECTED since I failed to
see the wpa_supplicant_event_disassoc() further down in the code,
which eventually causes the same thing to happen.

Your patch should do the work just fine.

Thanks,
Arik