[PATCH hostap] AP: Send Deauthentication before removing STA on (Re)Assoc Resp ack=0

[Senthil Balasubramanian]

When the driver reports via TX status that the STA did not acknowledge
the (Re)Association Response, handle_assoc_cb() calls
hostapd_drv_sta_remove() without sending any over-the-air notification
to the STA. This was a reasonable assumption when station and AP power
budgets were close to symmetric: if the AP did not see the ACK, the STA
most likely did not receive the Response either, so the STA would time
out and re-authenticate within a short window.

This assumption no longer holds on 6 GHz Low Power Indoor (LPI)
deployments. There the STA EIRP is capped 6 dB below the AP EIRP by
regulation (FCC and ETSI), and additional asymmetry comes from typical
laptop/phone antenna gain being lower than the AP's MIMO antenna gain
at the 6 GHz wavelength, and from STA PA back-off due to thermal and
battery constraints. The net result is that the AP can reliably reach
the STA while the STA's frames (including the L2 ACK following the AP's
(Re)Assoc Response) routinely fall below the AP's effective noise
floor.

In this scenario the STA decodes the (Re)Assoc Response and considers
itself associated, while hostapd silently removes the station entry.
The two sides remain out of sync until a STA-side timeout
(implementation-defined, e.g. beacon-loss or null-frame failure)
eventually fires. During that window the STA's unicast traffic is
silently dropped at the AP, since there is no association table entry
to map it to.

Address this by sending a Deauthentication frame
(WLAN_REASON_PREV_AUTH_NOT_VALID) before hostapd_drv_sta_remove() in
the !ok path of handle_assoc_cb(). The Deauthentication is transmitted
at the basic rate with the usual MAC-level retries, which gives it a
materially better chance of reaching the STA than the higher-rate
(Re)Assoc Response that just failed. If the STA never received the
(Re)Assoc Response at all, the Deauthentication is benign because it
is a Class 1 frame and does not tear down any association state on
the STA side.

Reported-by: Sudharsan Narayanan <sudharsan.narayanan at netgear.com>
Signed-off-by: Sudharsan Narayanan <sudharsan.narayanan at netgear.com>
Signed-off-by: Senthil Balasubramanian <senthil.balasubramanian at netgear.com>
---
 src/ap/ieee802_11.c | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/src/ap/ieee802_11.c b/src/ap/ieee802_11.c
index 50f7e2a35..af363cd53 100644
--- a/src/ap/ieee802_11.c
+++ b/src/ap/ieee802_11.c
@@ -8494,8 +8494,29 @@ static void handle_assoc_cb(struct hostapd_data *hapd,
                               "did not acknowledge association response");
                sta->flags &= ~WLAN_STA_ASSOC_REQ_OK;
                /* The STA is added only in case of SUCCESS */
-               if (status == WLAN_STATUS_SUCCESS)
+               if (status == WLAN_STATUS_SUCCESS) {
+                       /*
+                        * (Re)Assoc Response TX completed without an L2 ACK
+                        * from the STA. The STA may still have received and
+                        * accepted the frame. This can happen on links with
+                        * asymmetric path budget (e.g., 6 GHz where the STA
+                        * EIRP is capped well below the AP EIRP), where the
+                        * AP can reach the STA but the STA's ACK does not
+                        * reach the AP. Without explicit notification the
+                        * STA would consider itself associated while the AP
+                        * has already removed its entry, leaving the two
+                        * sides out of sync until a STA-side timeout fires.
+                        * Send a Deauthentication frame at the basic rate
+                        * before removing the STA so it can recover quickly.
+                        * If the STA never received the (Re)Assoc Response
+                        * at all, the Deauthentication is benign since it is
+                        * a Class 1 frame that does not tear down any
+                        * association state on the STA side.
+                        */
+                       hostapd_drv_sta_deauth(hapd, sta->addr,
+                                              WLAN_REASON_PREV_AUTH_NOT_VALID);
                        hostapd_drv_sta_remove(hapd, sta->addr);
+               }

                goto handle_ml;
        }
--
2.50.1 (Apple Git-155)

This e-mail, including attachments, may include confidential and/or proprietary information, and may be used only by the person or entity to which it is addressed. If the reader of this e-mail is not the intended recipient or his or her authorized agent, the reader is hereby notified that any dissemination, distribution or copying of this e-mail is prohibited. If you have received this e-mail in error, please notify the sender by replying to this message and delete this e-mail immediately.