>
> On Wed, Oct 14, 2015 at 12:26:33PM +0300, Ilan Peer wrote:
> > Some APs may send RSC octets in EAP message 3 of 4-Way Handshake or in
> > EAP message 1 of Group Key Handshake in the opposite order. Thus,
> > after a successful EAP authentication the TSC values of received
> > multicast packets, such as DHCP, don't match the RSC one and as a
> > result these packets are dropped on replay attack TSC verification. An
> > example of such AP is Sapido RB-1732.
> >
> > Workaournd this by setting RSC octets to 0 on GTK installation if the
> > AP RSC value is identified as a potentially having the byte order issue.
> > The wpa_rsc_relaxation global configuration property allows to disable
> > the GTK RSC workaround if it's not needed.
>
> Thanks, applied with some fixes and cleanup.
>
> > +static int wpa_supplicant_get_wpa_rsc_relaxation(const struct wpa_sm
> > +*sm) {
> > + if (sm->ctx->get_wpa_rsc_relaxation)
> > + return sm->ctx->get_wpa_rsc_relaxation(sm->ctx->ctx);
> > + return 0;
> > +}
>
> There is no need to add a separate function pointer and callback for this;
> there is already a mechanism for updating WPA/RSN configuration
> parameters for each connection. I replaced this callback mechanism with a
> new such configuration parameter.
>
I'll remember this in the future.
> > +static int wpa_supplicant_rsc_relaxation(const struct wpa_sm *sm,
> > + const u8 *rsc)
> > +{
> > + int rsclen;
> > +
> > + if (wpa_supplicant_get_wpa_rsc_relaxation(sm))
> > + return 0;
>
> This logic looks reversed, i.e., that needs to be "if
> (!wpa_supplicant_get_wpa_rsc_relaxation(sm))"..
>
Yep. Thanks for catching this.
Thanks,
Ilan.
_______________________________________________
Hostap mailing list
Hostap@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/hostap
