Commit d673cb6f authored by Christian 'Ansuel' Marangi's avatar Christian 'Ansuel' Marangi Committed by Kalle Valo

wifi: ath11k: fix peer addition/deletion error on sta band migration

This patch try to fix the following error.

Wed Jun  1 22:19:30 2022 kern.warn kernel: [  119.561227] ath11k c000000.wifi: peer already added vdev id 0 req, vdev id 1 present
Wed Jun  1 22:19:30 2022 kern.warn kernel: [  119.561282] ath11k c000000.wifi: Failed to add peer: 28:c2:1f:xx:xx:xx for VDEV: 0
Wed Jun  1 22:19:30 2022 kern.warn kernel: [  119.568053] ath11k c000000.wifi: Failed to add station: 28:c2:1f:xx:xx:xx for VDEV: 0
Wed Jun  1 22:19:31 2022 daemon.notice hostapd: wlan2: STA 28:c2:1f:xx:xx:xx IEEE 802.11: Could not add STA to kernel driver
Wed Jun  1 22:19:31 2022 daemon.notice hostapd: wlan2: STA 28:c2:1f:xx:xx:xx IEEE 802.11: did not acknowledge authentication response
Wed Jun  1 22:19:31 2022 daemon.notice hostapd: wlan1: AP-STA-DISCONNECTED 28:c2:1f:xx:xx:xx
Wed Jun  1 22:19:31 2022 daemon.info hostapd: wlan1: STA 28:c2:1f:xx:xx:xx IEEE 802.11: disassociated due to inactivity
Wed Jun  1 22:19:32 2022 daemon.info hostapd: wlan1: STA 28:c2:1f:xx:xx:xx IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)

To repro this:
- Have 2 Wifi with the same bssid and pass on different band (2.4 and
5GHz)
- Enable 802.11r Fast Transaction with same mobility domain
- FT Protocol: FT over the Air
From a openwrt system issue the command (with the correct mac)
ubus call hostapd.wlan1 wnm_disassoc_imminent '{"addr":"28:C2:1F:xx:xx:xx"}'
Notice the log printing the errors.

The cause of this error has been investigated and we found that this is
related to the WiFi Fast Transaction feature. We observed that this is
triggered when the router tells the device to change band. In this case
the device first auth to the other band and then the disconnect path
from the prev band is triggered.
This is problematic with the current rhash implementation since the
addrs is used as key and the logic of "adding first, delete later"
conflicts with the rhash logic.
In fact peer addition will fail since the peer is already added and with
that fixed a peer deletion will cause unitended effect by removing the
peer just added.

Current solution to this is to add additional logic to the peer delete,
make sure we are deleting the correct peer taken from the rhash
table (and fallback to the peer list) and for the peer add logic delete
the peer entry for the rhash list before adding the new one (counting as
an error only when a peer with the same vlan_id is asked to be added).

With this change, a sta can correctly transition from 2.4GHz and 5GHZ
with no drop and no error are printed.

Tested-on: IPQ8074 hw2.0 AHB WLAN.HK.2.5.0.1-01208-QCAHKSWPL_SILICONZ-1

Fixes: 7b0c70d9 ("ath11k: Add peer rhash table support")
Signed-off-by: default avatarChristian 'Ansuel' Marangi <ansuelsmth@gmail.com>
Signed-off-by: default avatarKalle Valo <quic_kvalo@quicinc.com>
Link: https://lore.kernel.org/r/20220603164559.27769-1-ansuelsmth@gmail.com
parent 55b5ee33
...@@ -302,6 +302,21 @@ static int __ath11k_peer_delete(struct ath11k *ar, u32 vdev_id, const u8 *addr) ...@@ -302,6 +302,21 @@ static int __ath11k_peer_delete(struct ath11k *ar, u32 vdev_id, const u8 *addr)
spin_lock_bh(&ab->base_lock); spin_lock_bh(&ab->base_lock);
peer = ath11k_peer_find_by_addr(ab, addr); peer = ath11k_peer_find_by_addr(ab, addr);
/* Check if the found peer is what we want to remove.
* While the sta is transitioning to another band we may
* have 2 peer with the same addr assigned to different
* vdev_id. Make sure we are deleting the correct peer.
*/
if (peer && peer->vdev_id == vdev_id)
ath11k_peer_rhash_delete(ab, peer);
/* Fallback to peer list search if the correct peer can't be found.
* Skip the deletion of the peer from the rhash since it has already
* been deleted in peer add.
*/
if (!peer)
peer = ath11k_peer_find(ab, vdev_id, addr);
if (!peer) { if (!peer) {
spin_unlock_bh(&ab->base_lock); spin_unlock_bh(&ab->base_lock);
mutex_unlock(&ab->tbl_mtx_lock); mutex_unlock(&ab->tbl_mtx_lock);
...@@ -312,8 +327,6 @@ static int __ath11k_peer_delete(struct ath11k *ar, u32 vdev_id, const u8 *addr) ...@@ -312,8 +327,6 @@ static int __ath11k_peer_delete(struct ath11k *ar, u32 vdev_id, const u8 *addr)
return -EINVAL; return -EINVAL;
} }
ath11k_peer_rhash_delete(ab, peer);
spin_unlock_bh(&ab->base_lock); spin_unlock_bh(&ab->base_lock);
mutex_unlock(&ab->tbl_mtx_lock); mutex_unlock(&ab->tbl_mtx_lock);
...@@ -372,9 +385,18 @@ int ath11k_peer_create(struct ath11k *ar, struct ath11k_vif *arvif, ...@@ -372,9 +385,18 @@ int ath11k_peer_create(struct ath11k *ar, struct ath11k_vif *arvif,
spin_lock_bh(&ar->ab->base_lock); spin_lock_bh(&ar->ab->base_lock);
peer = ath11k_peer_find_by_addr(ar->ab, param->peer_addr); peer = ath11k_peer_find_by_addr(ar->ab, param->peer_addr);
if (peer) { if (peer) {
if (peer->vdev_id == param->vdev_id) {
spin_unlock_bh(&ar->ab->base_lock); spin_unlock_bh(&ar->ab->base_lock);
return -EINVAL; return -EINVAL;
} }
/* Assume sta is transitioning to another band.
* Remove here the peer from rhash.
*/
mutex_lock(&ar->ab->tbl_mtx_lock);
ath11k_peer_rhash_delete(ar->ab, peer);
mutex_unlock(&ar->ab->tbl_mtx_lock);
}
spin_unlock_bh(&ar->ab->base_lock); spin_unlock_bh(&ar->ab->base_lock);
ret = ath11k_wmi_send_peer_create_cmd(ar, param); ret = ath11k_wmi_send_peer_create_cmd(ar, param);
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment