[RFC] Locally abort associations on ASSOC_REJECT events

[Christopher Wiley]

I had a suspicion I was not doing this correctly.  Thanks!

On Sat, Nov 3, 2012 at 5:00 AM, Jouni Malinen <j at 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 at lists.shmoo.com
> http://lists.shmoo.com/mailman/listinfo/hostap
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.shmoo.com/pipermail/hostap/attachments/20121107/49aa1d2e/attachment.htm