[PATCH 1/1] hostapd: Avoid EAPOL trigger in reassoc path for AP, in case of 4way HS offload

[Vinayak Yadawad]

Hi Jouni,

I have addressed the comments as part of "[PATCH v2 1/1] hostapd:
Avoid EAPOL trigger in reassoc path for AP, in case of 4way HS
offload".
With this change a common approach is used for both assoc/reassoc
paths to avoid authentication in case of 4way HS offload.
Without this change, if a sta connects back without a disassoc/deauth
in between, the reassoc path gets triggered followed by EAPOL HS (M1).
With the current change, the EAPOL HS is avoided from the reassoc path as well.

Regards,
Vinayak

Regards,
Vinayak

On Fri, Aug 16, 2024 at 3:28 PM Vinayak Yadawad
<vinayak.yadawad at broadcom.com> wrote:
>
> Hi Jouni,
>
> >Do you really mean association path and reassociation path here? The
> >current implementation in hostapd_new_assoc_sta() should be used both
> >when processing an Association Request frame and when processing a
> >Reassociation Request frame.
> The fix is meant for a case where assoc event is received by the AP
> from an already associated STA (without deauth in between).
> wpa_auth_sta_associated handles both reassoc and assoc case
> differently and the 4way HS offload case is getting skipped for
> reassoc case. This change should have been in common path. Let me
> check whether I can handle the same in  SM_STATE(WPA_PTK, PTKSTART).
>
> Regards,
> Vinayak
>
>
> On Sat, Aug 10, 2024 at 1:29 PM Jouni Malinen <j at w1.fi> wrote:
> >
> > On Fri, May 24, 2024 at 12:00:27PM +0530, Vinayak Yadawad wrote:
> > > Currently avoiding of EAPOL exchange for AP with 4way HS offload is
> > > handled only in new STA assoc path. Current change avoids complete
> > > authentication trigger in case of AP reassoc path as well.
> >
> > Do you really mean association path and reassociation path here? The
> > current implementation in hostapd_new_assoc_sta() should be used both
> > when processing an Association Request frame and when processing a
> > Reassociation Request frame.
> >
> > > diff --git a/src/ap/wpa_auth.c b/src/ap/wpa_auth.c
> > > @@ -2708,8 +2717,20 @@ SM_STATE(WPA_PTK, PTKSTART)
> > >       SM_ENTRY_MA(WPA_PTK, PTKSTART, wpa_ptk);
> > > +
> > > +     wpa_auth_get_drv_flags(sm->wpa_auth, &drv_flags, &drv_flags2);
> > > +     ap_4way_hs_offload = !!(drv_flags2 & WPA_DRIVER_FLAGS2_4WAY_HANDSHAKE_AP_PSK);
> > > +     if (ap_4way_hs_offload) {
> > > +             /* 4way HS offloaded to driver no need of EAPOL */
> > > +             wpa_printf(MSG_INFO, "Avoid EAPOL in case of 4way HS offload");
> > > +             return;
> > > +     }
> >
> > This on the other hand would address other reasons to start 4-way
> > handshake than association or reassociation. For example, rekeying of
> > the PTK would be such a case. This might be a reasonable thing to do,
> > but that commit message makes the intent of this change quite unclear.
> >
> > --
> > Jouni Malinen                                            PGP id EFC895FA