| developer | 29c4d2d | 2022-12-26 19:41:22 +0800 | [diff] [blame] | 1 | --- a/src/ap/ieee802_11.c |
| 2 | +++ b/src/ap/ieee802_11.c |
| developer | e35b8e4 | 2023-10-16 11:04:00 +0800 | [diff] [blame] | 3 | @@ -4621,6 +4621,13 @@ static int add_associated_sta(struct hos |
| developer | 29c4d2d | 2022-12-26 19:41:22 +0800 | [diff] [blame] | 4 | * drivers to accept the STA parameter configuration. Since this is |
| 5 | * after a new FT-over-DS exchange, a new TK has been derived, so key |
| 6 | * reinstallation is not a concern for this case. |
| 7 | + * |
| 8 | + * If the STA was associated and authorized earlier, but came for a new |
| 9 | + * connection (!added_unassoc + !reassoc), remove the existing STA entry |
| 10 | + * so that it can be re-added. This case is rarely seen when the AP could |
| 11 | + * not receive the deauth/disassoc frame from the STA. And the STA comes |
| 12 | + * back with new connection within a short period or before the inactive |
| 13 | + * STA entry is removed from the list. |
| 14 | */ |
| 15 | wpa_printf(MSG_DEBUG, "Add associated STA " MACSTR |
| 16 | " (added_unassoc=%d auth_alg=%u ft_over_ds=%u reassoc=%d authorized=%d ft_tk=%d fils_tk=%d)", |
| developer | e35b8e4 | 2023-10-16 11:04:00 +0800 | [diff] [blame] | 17 | @@ -4634,7 +4641,8 @@ static int add_associated_sta(struct hos |
| developer | 29c4d2d | 2022-12-26 19:41:22 +0800 | [diff] [blame] | 18 | (!(sta->flags & WLAN_STA_AUTHORIZED) || |
| 19 | (reassoc && sta->ft_over_ds && sta->auth_alg == WLAN_AUTH_FT) || |
| 20 | (!wpa_auth_sta_ft_tk_already_set(sta->wpa_sm) && |
| 21 | - !wpa_auth_sta_fils_tk_already_set(sta->wpa_sm)))) { |
| 22 | + !wpa_auth_sta_fils_tk_already_set(sta->wpa_sm)) || |
| 23 | + (!reassoc && (sta->flags & WLAN_STA_AUTHORIZED)))) { |
| 24 | hostapd_drv_sta_remove(hapd, sta->addr); |
| 25 | wpa_auth_sm_event(sta->wpa_sm, WPA_DRV_STA_REMOVED); |
| 26 | set = 0; |