diff options
Diffstat (limited to 'package/network/services/hostapd/patches/021-fix-sta-add-after-previous-connection.patch')
| -rw-r--r-- | package/network/services/hostapd/patches/021-fix-sta-add-after-previous-connection.patch | 26 |
1 files changed, 26 insertions, 0 deletions
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 0000000000..124fd8bdf1 --- /dev/null +++ b/package/network/services/hostapd/patches/021-fix-sta-add-after-previous-connection.patch @@ -0,0 +1,26 @@ +--- a/src/ap/ieee802_11.c ++++ b/src/ap/ieee802_11.c +@@ -4942,6 +4942,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)", +@@ -4955,7 +4962,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; |