wpa_supplicant: clear bssid state on deauth

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'm not 100% sure with this patch, I just tried to copy the relevant
> parts from sme_deauth(). But it definitely fixed some real world issues
> we encountered with a mac80211 based driver. With prev_bssid_set == 1,
> re-assoc packets are used in mac80211 during association.

sme_deauth() is used when the local end is forcing deauthentication, so
this may not be the ideal place to copy from.. I would assume that
setting wpa_s->sme.prev_bssid_set = 0 is the only part that is really
needed here.

> diff --git a/wpa_supplicant/events.c b/wpa_supplicant/events.c
> @@ -2246,6 +2246,18 @@ void wpa_supplicant_event(void *ctx, enum wpa_event_type event,
> +
> +#ifdef CONFIG_AP
> +			if (wpa_s->ap_iface == NULL)
> +#endif /* CONFIG_AP */
> +			{
> +#ifdef CONFIG_SME
> +				wpa_s->sme.prev_bssid_set = 0;
> +#endif /* CONFIG_SME */
> +				wpa_supplicant_set_state(wpa_s,
> +							 WPA_DISCONNECTED);
> +				os_memset(wpa_s->bssid, 0, ETH_ALEN);
> +			}
>  		}
>  #ifdef CONFIG_AP
>  		if (wpa_s->ap_iface && data && data->deauth_info.addr) {

Those added lines are used only for deauthentication case. Why would
this not be done for disassociation? What is the purpose of
set_sta(DISCONNECTED) and clearing of wpa_s->bssid here?

Something like this could be better way of achieving the main goal of
not using reassociation:




Could you please confirm that this resolves the issue you've seen?

On Sat, Jun 9, 2012 at 12:49 PM, Jouni Malinen <j@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

On Sun, Jun 10, 2012 at 10:24:26AM +0300, Arik Nemtsov wrote:
> 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.

OK, thanks!