Patchwork [RFC] Locally abort associations on ASSOC_REJECT events

login
register
mail settings
Submitter Jouni Malinen
Date Nov. 3, 2012, noon
Message ID <20121103120031.GA8411@w1.fi>
Download mbox | patch
Permalink /patch/196829/
State Accepted
Headers show

Comments

Jouni Malinen - Nov. 3, 2012, noon
On Wed, Oct 10, 2012 at 02:51:03PM -0700, Christopher Wiley wrote:
> Respond to AP triggered association failures by locally aborting the
> association process.  For instance, certain enterprise AP's return
> status code 17 (too many STAs) and reject association requests when a
> particular AP has too many associated devices.  Locally aborting the
> association process lets wpa_supplicant begin roaming immediately rather
> than waiting for the authentication timeout to fire.

This is actually based on Authentication frame getting rejected instead
of association getting rejected.. I was trying to reproduce this by
making the AP reject the Association Request frame and that was actually
handled already since cfg80211 deauthenticates and indicates a
deauthentication event to user space in such a case. For rejected
Authentication frame, no such event happen and that is the not covered
case even though the internal event in wpa_supplicant is called
EVENT_ASSOC_REJECT.

> This change duplicates similar behavior that occurs when the driver
> supports SME.

> diff --git a/wpa_supplicant/events.c b/wpa_supplicant/events.c
>  		if (wpa_s->drv_flags & WPA_DRIVER_FLAGS_SME)
>  			sme_event_assoc_reject(wpa_s, data);
> +		else
> +			/* We could wait for the auth timer to fire, but it is
> +			 * much faster to abort locally sooner rather than
> +			 * later.
> +			 */
> +			wpa_supplicant_event_disassoc_finish(wpa_s,
> +				data->assoc_reject.status_code, 1);

This function is supposed to be used in the case where association has
already happened successfully. It does quite a bit of steps that are not
needed or desired for the case where we did not get associated. I
handled this with a bit different change that uses the common connection
failure routine:
Christopher Wiley - Nov. 7, 2012, 8:12 p.m.
I had a suspicion I was not doing this correctly.  Thanks!

On Sat, Nov 3, 2012 at 5:00 AM, Jouni Malinen <j@w1.fi> wrote:

> On Wed, Oct 10, 2012 at 02:51:03PM -0700, Christopher Wiley wrote:
> > Respond to AP triggered association failures by locally aborting the
> > association process.  For instance, certain enterprise AP's return
> > status code 17 (too many STAs) and reject association requests when a
> > particular AP has too many associated devices.  Locally aborting the
> > association process lets wpa_supplicant begin roaming immediately rather
> > than waiting for the authentication timeout to fire.
>
> This is actually based on Authentication frame getting rejected instead
> of association getting rejected.. I was trying to reproduce this by
> making the AP reject the Association Request frame and that was actually
> handled already since cfg80211 deauthenticates and indicates a
> deauthentication event to user space in such a case. For rejected
> Authentication frame, no such event happen and that is the not covered
> case even though the internal event in wpa_supplicant is called
> EVENT_ASSOC_REJECT.
>
> > This change duplicates similar behavior that occurs when the driver
> > supports SME.
>
> > diff --git a/wpa_supplicant/events.c b/wpa_supplicant/events.c
> >               if (wpa_s->drv_flags & WPA_DRIVER_FLAGS_SME)
> >                       sme_event_assoc_reject(wpa_s, data);
> > +             else
> > +                     /* We could wait for the auth timer to fire, but
> it is
> > +                      * much faster to abort locally sooner rather than
> > +                      * later.
> > +                      */
> > +                     wpa_supplicant_event_disassoc_finish(wpa_s,
> > +                             data->assoc_reject.status_code, 1);
>
> This function is supposed to be used in the case where association has
> already happened successfully. It does quite a bit of steps that are not
> needed or desired for the case where we did not get associated. I
> handled this with a bit different change that uses the common connection
> failure routine:
>
>
> diff --git a/wpa_supplicant/events.c b/wpa_supplicant/events.c
> index 53b8338..1aa9c21 100644
> --- a/wpa_supplicant/events.c
> +++ b/wpa_supplicant/events.c
> @@ -2524,6 +2524,13 @@ void wpa_supplicant_event(void *ctx, enum
> wpa_event_type event,
>                                 data->assoc_reject.status_code);
>                 if (wpa_s->drv_flags & WPA_DRIVER_FLAGS_SME)
>                         sme_event_assoc_reject(wpa_s, data);
> +               else {
> +                       const u8 *bssid = data->assoc_reject.bssid;
> +                       if (bssid == NULL || is_zero_ether_addr(bssid))
> +                               bssid = wpa_s->pending_bssid;
> +                       wpas_connection_failed(wpa_s, bssid);
> +                       wpa_supplicant_mark_disassoc(wpa_s);
> +               }
>                 break;
>         case EVENT_AUTH_TIMED_OUT:
>                 if (wpa_s->drv_flags & WPA_DRIVER_FLAGS_SME)
>
> --
> Jouni Malinen                                            PGP id EFC895FA
> _______________________________________________
> HostAP mailing list
> HostAP@lists.shmoo.com
> http://lists.shmoo.com/mailman/listinfo/hostap
>

Patch

diff --git a/wpa_supplicant/events.c b/wpa_supplicant/events.c
index 53b8338..1aa9c21 100644
--- a/wpa_supplicant/events.c
+++ b/wpa_supplicant/events.c
@@ -2524,6 +2524,13 @@  void wpa_supplicant_event(void *ctx, enum wpa_event_type event,
 				data->assoc_reject.status_code);
 		if (wpa_s->drv_flags & WPA_DRIVER_FLAGS_SME)
 			sme_event_assoc_reject(wpa_s, data);
+		else {
+			const u8 *bssid = data->assoc_reject.bssid;
+			if (bssid == NULL || is_zero_ether_addr(bssid))
+				bssid = wpa_s->pending_bssid;
+			wpas_connection_failed(wpa_s, bssid);
+			wpa_supplicant_mark_disassoc(wpa_s);
+		}
 		break;
 	case EVENT_AUTH_TIMED_OUT:
 		if (wpa_s->drv_flags & WPA_DRIVER_FLAGS_SME)