Wifi-2382. Fix for STA Assoc rejection with reason code 17

If a previously associated-and-authorized STA comes for a new
connection (Assoc Request), AP rejects the Assoc with code 17.
Solution is to delete the STA entry at AP before re-adding the
STA entry. This clears out the state-machine at the AP and
accepts the new connection from the STA.

Signed-off-by: ravi vaishnav <ravi.vaishnav@netexperience.com>
This commit is contained in:
ravi vaishnav
2021-05-17 11:44:22 -04:00
committed by Rick Sommerville
parent d40e1f9d13
commit d3695266fc
2 changed files with 56 additions and 0 deletions

View File

@@ -0,0 +1,28 @@
Index: hostapd-2020-06-08-5a8b3662/src/ap/ieee802_11.c
===================================================================
--- hostapd-2020-06-08-5a8b3662.orig/src/ap/ieee802_11.c
+++ hostapd-2020-06-08-5a8b3662/src/ap/ieee802_11.c
@@ -3675,6 +3675,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)",
@@ -3688,7 +3695,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;

View File

@@ -0,0 +1,28 @@
Index: hostapd-2020-06-08-5a8b3662/src/ap/ieee802_11.c
===================================================================
--- hostapd-2020-06-08-5a8b3662.orig/src/ap/ieee802_11.c
+++ hostapd-2020-06-08-5a8b3662/src/ap/ieee802_11.c
@@ -3675,6 +3675,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)",
@@ -3688,7 +3695,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;