ASR_BASE
Change-Id: Icf3719cc0afe3eeb3edc7fa80a2eb5199ca9dda1
diff --git a/package/network/services/hostapd/patches/021-fix-sta-add-after-previous-connection.patch b/package/network/services/hostapd/patches/021-fix-sta-add-after-previous-connection.patch
new file mode 100644
index 0000000..b5551f5
--- /dev/null
+++ b/package/network/services/hostapd/patches/021-fix-sta-add-after-previous-connection.patch
@@ -0,0 +1,30 @@
+From: Felix Fietkau <nbd@nbd.name>
+Date: Tue, 25 May 2021 10:50:16 +0200
+Subject: [PATCH] fix adding back stations after a missed deauth/disassoc
+
+--- a/src/ap/ieee802_11.c
++++ b/src/ap/ieee802_11.c
+@@ -4784,6 +4784,13 @@ static int add_associated_sta(struct hos
+ * drivers to accept the STA parameter configuration. Since this is
+ * after a new FT-over-DS exchange, a new TK has been derived, so key
+ * reinstallation is not a concern for this case.
++ *
++ * If the STA was associated and authorized earlier, but came for a new
++ * connection (!added_unassoc + !reassoc), remove the existing STA entry
++ * so that it can be re-added. This case is rarely seen when the AP could
++ * not receive the deauth/disassoc frame from the STA. And the STA comes
++ * back with new connection within a short period or before the inactive
++ * STA entry is removed from the list.
+ */
+ wpa_printf(MSG_DEBUG, "Add associated STA " MACSTR
+ " (added_unassoc=%d auth_alg=%u ft_over_ds=%u reassoc=%d authorized=%d ft_tk=%d fils_tk=%d)",
+@@ -4797,7 +4804,8 @@ static int add_associated_sta(struct hos
+ (!(sta->flags & WLAN_STA_AUTHORIZED) ||
+ (reassoc && sta->ft_over_ds && sta->auth_alg == WLAN_AUTH_FT) ||
+ (!wpa_auth_sta_ft_tk_already_set(sta->wpa_sm) &&
+- !wpa_auth_sta_fils_tk_already_set(sta->wpa_sm)))) {
++ !wpa_auth_sta_fils_tk_already_set(sta->wpa_sm)) ||
++ (!reassoc && (sta->flags & WLAN_STA_AUTHORIZED)))) {
+ hostapd_drv_sta_remove(hapd, sta->addr);
+ wpa_auth_sm_event(sta->wpa_sm, WPA_DRV_STA_REMOVED);
+ set = 0;