| Message ID | f520dc126c3c95146a0b93d4c3da03a2261b310d.1715940979.git.vinayak.yadawad@broadcom.com |
|---|---|
| State | Changes Requested |
| Headers | show |
| Series | [1/1] hostapd: Avoid EAPOL trigger in reassoc path for AP, in case of 4way HS offload | expand |
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.
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@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
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@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@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
diff --git a/src/ap/wpa_auth.c b/src/ap/wpa_auth.c index 8304c6047..c3e0398ea 100644 --- a/src/ap/wpa_auth.c +++ b/src/ap/wpa_auth.c @@ -367,6 +367,15 @@ static inline int wpa_auth_start_ampe(struct wpa_authenticator *wpa_auth, #endif /* CONFIG_MESH */ +static inline int wpa_auth_get_drv_flags(struct wpa_authenticator *wpa_auth, + u64 *drv_flags, u64 *drv_flags2) +{ + if(!wpa_auth->cb->get_drv_flags) + return -1; + return wpa_auth->cb->get_drv_flags(wpa_auth->cb_ctx, drv_flags, + drv_flags2); +} + int wpa_auth_for_each_sta(struct wpa_authenticator *wpa_auth, int (*cb)(struct wpa_state_machine *sm, void *ctx), void *cb_ctx) @@ -2708,8 +2717,20 @@ SM_STATE(WPA_PTK, PTKSTART) #ifdef CONFIG_TESTING_OPTIONS struct wpa_auth_config *conf = &sm->wpa_auth->conf; #endif /* CONFIG_TESTING_OPTIONS */ + u64 drv_flags = 0; + u64 drv_flags2 = 0; + bool ap_4way_hs_offload = false; 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; + } + sm->PTKRequest = false; sm->TimeoutEvt = false; sm->alt_snonce_valid = false;
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. Signed-off-by: Vinayak Yadawad <vinayak.yadawad@broadcom.com> --- src/ap/wpa_auth.c | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+)