If CSR roam synch callback fails then the status is not updated
with error status code and this causes the caller to consider
roam synch indication is successful and RSO stop is not sent
to firmware leading to roam synch completion timeout at firmware
Send correct status to the caller of the api:
cm_roam_sync_event_handler_cb() if CSR roam synch processing
fails
CRs-Fixed: 3800617
Change-Id: I29214c04976498fd81cb5266738e341928af3af7
When roaming happens with full SAE for FT-SAE AKMs host doesn't
update the PMK received from firmware into its global cache.
This causes stale PMK to be sent to firmware when full SAE
happens when roaming to below AKM's:
WLAN_CRYPTO_KEY_MGMT_FT_SAE
WLAN_CRYPTO_KEY_MGMT_FT_SAE_EXT_KEY
So update the PMK sent from firmware for above AKM's when
auth status is connected (full SAE happens at host).
CRs-Fixed: 3807689
Change-Id: I25d1a253de37481952c41f54697521285a0ccf92
If host founds below all conditions are true:
1. Connected AP sends CCX IE in beacon/probe response
2. single PMK feature enabled via ini
"sae_single_pmk_feature_enabled"
3. And current connection is SAE with AKM type
WLAN_CRYPTO_KEY_MGMT_SAE_EXT_KEY or
WLAN_CRYPTO_KEY_MGMT_SAE
Then host should mark connected AP supports
"single PMK feature" and update same to FW via RSO
command.
Change-Id: I831cfefb60271b03e5c5cbdfde0bd5277ee116e0
CRs-Fixed: 3795133
After roaming to 11BE 320 MHz EHT AP, the channel width is wrongly
updated as 40 MHz in newly created pe_session. This causes wrong
channel info to be sent to kernel in the get sta channel request
and could result in disconnection. In lim_fill_ft_session(),
the chan_width is updated from VHT OP or Vendor VHT OP IE only
currently. But in 6 GHz EHT 320 mode, the VHT OP IE will not be
present and default 40 MHz is assigned.
So extract the channel info from EHT OP IE and use that to fill
the ft pe session created after roaming
Change-Id: I81b52391e69dfe87b103ca1ee90dd9658f02273a
CRs-Fixed: 3746276
Currently, ROAM_SYNC is aborted on the corresponding vdev when
the vdev is not in CONNECTED state. This abort operation sends
an RSO_STOP to fw but the status is not notified to the caller.
This results in a race condition in the below scenario,
1. Firmware roamed to a 2-link ML AP and sent Roam sync ind
to host
2. Host posted ROAM_SYNC on vdev-0 in scheduler thread context
as the vdev-0 state is CONNECTED
3. Got a DISCONNECT request from userspace in user thread and
the states moved to DISCONNECTING.
4. Host tried to post ROAM_SYNC to vdev-1 but aborted as the
state is not CONNECTED and tries to send RSO_STOP to fw.
This RSO_STOP won’t be sent as it’s a link vdev and the
RSO_STOP should go from assoc vdev later.
But this status is not indicated to the caller which
proceeds with vdev-0 ROAM_SYNC.
5. As vdev-0 ROAM_SYNC doesn't check for the connection state
once processing is started, ROAM_SYNC would be completed
on vdev-0.
6. This causes out of sync and vdev-1 doesn't get cleaned-up.
7. As part of the disconnect, host tries to cleanup the old
peer on vdev-1. But firmware ignores this as that peer is
already cleaned up in fw.
This results in peer map-unmap issue later as the new Roamed
peer on vdev-1 will never get cleaned-up in host but the same
got cleaned up in fw. FW is free to use that peer_id to
another peer mac later and when it does, host DP complains.
So, indicate ROAM_SYNC abort status to the caller to abort
the complete Roaming.
Change-Id: Ic65149ddf28f01ca5d7a0f6d3137a38e64e6c6ae
CRs-Fixed: 3786671
Host driver doesn't disable RSO before restarting the vdev
for fw-initiated as well host-initiated CSA or BW change for
link vdev. Therefore, if the FW is in middle of roam(for host
initiated CSA) cases, this restart leads to race condition in FW.
Add a new reason code for VDEV restarts triggered due to CSA,
enable/disable the RSO SM based on this new reason code for
assoc as well as partner links.
Change-Id: I48925d76df62bb1c60f212048b95c434af18042f
CRs-Fixed: 3770973
Firmware timestamp values are not printed for BTM_QUERY &
BTM_REQ events and wrong value for BTM_RSP. This is because
the timestamp values is read from wrong structures.
Read the firmware timestamp values from correct wmi structure
to fill the connectivity diag event
Change-Id: I568e87ee3e4bb66d3f73d353df794ced92b418c1
CRs-Fixed: 3788350
In cm_is_peer_preset_on_other_sta, wma_context is
fetched from gp_cds_context and used without any
validation checks. This may lead in NULL pointer
dereference.
To address this issue add null check before
accessing.
Change-Id: I78656303855efb2369afcf47d1aabe3b916498c4
CRs-Fixed: 3712317
Currently, the driver doesn't consider the force 20 MHz in
2.4 GHz configuration while calculating the channel width
for the session during roam. Therefore, fw and host will be
out-of-sync wrt the channel width of the connection.
Consider the force override 20 MHz in 2.4 GHz config which is
based on the ht40 cap of connect request for the channel width
computation.
Change-Id: Id616dd1ceefd5b2c2130be1b88067a92121e0fa1
CRs-Fixed: 3768406
When roaming happens from 3 Link AP to Legacy or 1 link AP after
a link switch, and the assoc vdev when connected to 3 Link AP is
disconnected during roaming, it causes the DP default link mapping
not to be updated. This resutls in data stall and ultimately
NUD failure is triggered resulting in disconnection.
After roaming to Multilink AP, then update the DP with
the new deflink as the assoc vdev.
CRs-Fixed: 3681911
Change-Id: I114a9858c3cbe58ef59743ad251a2b3af2543d3d
The vdev id in bs_req cannot exceed the WLAN_UMAC_PSOC_MAX_VDEVS
count.
Add the sanity check before accessing the ref_count array.
Change-Id: I31743b4be75944bb8947eac7537172d56614637d
CRs-Fixed: 3759720
Host has to issue RSO_STOP to firmware before performing any
vdev operations(start/stop/down/up,..). Otherwise firmware may
face memory corruptions if it tries to access the same
vdev while host is modifying it.
Currently, RSO_STOP is sent to firmware only if all vdevs are
UP. But in OWE/EAPOL offloaded roaming cases, assoc vdev
would be UP and partner vdev would be down till EAPOL is
done and keys are received from userspace. Connect is started
on partner vdev once the keys are received. Host driver is going
to do a vdev start as part of this connect. So, RSO_STOP is
supposed to be sent to firmware before performing any connect
operations on partner vdev.
So, send RSO_STOP to firmware right after sending
ROAM_SYNC_COMPLETE even if the link vdev is no UP.
Change-Id: Idaa15c7b0cedff5fd6f276626047f349c500a5b8
CRs-Fixed: 3769038
If the scan entries for a non-tx profile MBSSID partner links
are not present at the time of candidate selection, then
host driver generates the scan entry for the missing partner
link from the assoc response.
The assoc response from the AP has PMKID in the RSN(some APs
do not include RSN IE in assoc resp).In this case, the RSN
along with PMKID gets inherited into the scan cache of the
missing partner and this leads to mismatch between M3 and
scan entry RSN causing disconnection.
To fix this, mark all the MBSSID partners without scan entries
as invalid links at the time of candidate shortlisting. Score
and connect to only non-tx candidates with valid scan entries.
Remove the probe response generation from assoc response logic.
Change-Id: I3b90ca1f1d81f2de7cc629576714c72975b11ae9
CRs-Fixed: 3738606
Add new APIs to save number of links to which FW roamed
and add new API to retrieve this saved info.
Change-Id: Idfd8727855bd5da97a3808c78e89a505ef06c249
CRs-Fixed: 3755754
Currently, firmware-reported unsafe channels are ignored
and userspace configured channels are honored when
coex_unsafe_chan_nb_user_prefer ini is set. This is supported for
SAP mode only.
But some platforms may want driver to ignore the firmware-
reported coex channels for P2P-GO also.
Enhance the ini to allow user to configure mode specific
bit as mentioned below,
BIT 0: Don't honor fw coex/unsafe channel info for SAP mode
BIT 1: Don't honor fw coex/unsafe channel info for P2P-GO mode
Change-Id: I91a2c6b2da9aba411d081f6ae3b23d374fe53159
CRs-Fixed: 3766393
HW is non-DBS. SAP is UP in 6 GHz. Now, when a STA connection is
attempted, the pcl for the second connection would have SAP SCC
channel with highest priority, all the 5 GHz channels with 2nd
highest priority and the 6 GHz channels with least priority.
Therefore, even if there is a strong 6 GHz candidate for STA, the
5 GHz candidate would be chosen and the SAP moves to SCC in 5 GHz.
To fix this, ignore the pcl scoring for the non-DBS concurrency
cases as the SAP can move to the channel of the best STA interface.
If the SAP is in legacy band, and if still a 6 GHz STA is chosen,
then the legacy SAP would be torn down. So, give STA the best
possible in non-DBS case.
Change-Id: If268b61c61e77db96b499437cdbc95188240fba8
CRs-Fixed: 3749399
As per new requirement, If DUT associates with an AP does
not support BTM then when host receives BTM req frame
from FW. Instead of forwarding the BTM req frame to
supplicant, host should drop it.
Change-Id: Ie6b6c27c01b072fac19dc039327cb9a86370b535
CRs-Fixed: 3746758
User/wpa_supplicant disable roaming flag is only effective for current
connection, it will be cleared during new connection.
APP/wpa_supplicant can uses QCA_NL80211_VENDOR_SUBCMD_ROAMING to change
roaming behavior for current connection.
Change-Id: If9f439f51e25e3d67f5db5557c0d8f468b071596
CRs-Fixed: 3737996
On receiving QCA_WLAN_VENDOR_ATTR_CONFIG_BTM_SUPPORT vendor
command, do below action in host:
1. Disable btm_offload_config in FW via RSO command.
2. If btm_offload_config disabled in FW at step #1,
FW forwards BTM frame to Host, Host needs to drop frame.
3. Disable btm ext capability (p_ext_cap->bss_transition)
bit in assoc request and unicast probe request to AP.
4. On disconnection, restore BTM configuration.
Change-Id: I228bafe243c43bc055f19d472c2f2d986225f577
CRs-Fixed: 3742276
Add support to process newly added vendor command
QCA_WLAN_VENDOR_ATTR_CONFIG_BTM_SUPPORT.
User space use this vendor command to disable/enable
BTM roaming for STA interface.
If host receives this vendor command in connected
state, host should return failure to user space.
Change-Id: Iafadc2fab2ee30a0eb2e8e7ebb7178c1d36fe1c9
CRs-Fixed: 3715920
In mlo_roam_copy_reassoc_rsp(), assoc_rsp is a pointer inside
copied_reassoc_rsp incase of memory allocation for assoc_rsp,
copied_reassoc_rsp is getting freed but in the same error leg
"connect_ies->assoc_rsp.len" is getting set to 0 resulting in
use-after-free
Remove the code in the error handling to avoid use-after-free.
Change-Id: I5a7b3bbef42db4e8bedba0c7c3eaf961e4d7e83a
CRs-Fixed: 3728493
Currently, In the MLO t2lm API, wlan_mlo_parse_bcn_prbresp_t2lm_ie
is missing frame boundary checks which may lead to out-of-bound
reads if the lengths are not checked by the caller.
Fix is, while parsing t2lm ie pass the frame length and add
check for frame boundary.
CRs-Fixed: 3707241
Change-Id: Ic83638eff2250a704df8dfa8bd233238fcc7a25b
Add support to send roam cancel diag event in instances with
below reasons:
IDLE ROAM scan cancelled due to screen ON
scan cancelled due to other high priority roam scan
Add new diag structure & reason code enum for this diag
event
CRs-Fixed: 3708863
Change-Id: I1f7a819d766735f7d89eda3945e7ed92d22919ae
Some solutions may not have HS-2.0 certification and there is
no need to forward the BTM frame to wpa_supplicant in such
solutions. Let firmware handle the frame in such cases by
enabling btm_offload so that it doesn't wakeup the host.
Firmware may roam to another AP upon BTM reception.
To enable/disable BTM offload add hs20_btm_offload_disable INI.
If this INI is enable BTM offload will be disable and if INI
is disable BTM offload will be enabled.
Change-Id: Id6e18404cc3a12a23b213c0f858c943715285932
CRs-Fixed: 3718776
MLD address is mandatory for link VDEV connect request or
else the partner link will fail during candidate fetch from
scan DB because of MLD address mismatch.
For MLO OWE roaming, link VDEV connection starts after
completion of EAPOL-HS, and here MLD address is not filled
leading to link VDEV connect failure.
Use connect response to fill MLD address in link VDEV
connect for MLO OWE roaming
Change-Id: I9eae3b7ba3619a9ce62603efd0590aabce9c70f3
CRs-Fixed: 3715021
Currently, HS_20_AP param of cm_ext_obj->rso_config is set
to true when STA connects to a HS-2.0 AP. This is to disable
btm_offload as per HS-2.0 cert requirements.
But this flag is not cleared even when STA disconnects from
that AP and this disables btm_offload for next connections
as well even for non-HS-2.0 APs.
So, reset the flag as part of connect start to avoid this.
Change-Id: I3763544ecca0e4628b0c78633364fe70fd9b3094
CRs-Fixed: 3712758
Host tried to associate to AP, 6 GHz link is selected as
the assoc link and in the RNR there are two partner links 5 GHz, 2.4 GHz.
Only 6 GHz/2.4 GHz are beaconing and 5 GHz is not beaconing.
STA sent the ML-Probe request on 6 GHz link requesting the full profile
for the 5 GHz and 2.4 GHz links but AP responded with only one partner
link 2.4 GHz, from this we generated 2.4 GHz and added to scan cache,
AP didn't respond with 5 GHz link in per-sta.
STA sent the assoc request over 3-links and AP accepted the assoc,
and association is successful over 3-link and the same is intimated
to the firmware that 3link association is successful.
But while sending the connection information to the kernel 5 GHz link
is not found resulting in HDD/Kernel not being aware of the 5 GHz link.
Fix :- Use assoc response from the ML AP to generate ML probe resp
for the partner links to add to scan DB so that partner link
VDEV will have candidate to start connection.
Change-Id: I30176e58d9b02e7ed275b1c926cd1e119b66f8f3
CRs-Fixed: 3686809
Currently on HO failure host posts disconnect with priority
set in serialization queue before dequeuing the dummy roam
command from serialization, as a result for 2 link ML STA
case when HO failure is received, assoc VDEV disconnect gets
priority over partner link VDEV in the serialization
queue. When assoc VDEV disconnect is complete, host updates this
info to userspace and userspace issues dynamic mac address
update command. While processing this command the DP assoc VDEV
is first detached then re attached. There is possibility of
race where link VDEV disconnect starts in parallel, as DP link
VDEV has the reference of DP assoc VDEV, in order to release the
reference it looks up for the DP assoc VDEV , but as part of mac
address update if DP assoc VDEV is detached and reattachment is
pending then the DP link VDEV doesn't get the DP assoc VDEV and
reference release fails.
To address this issue don't prioritize disconnect for
HO Fail case.
Change-Id: I74c7bce851423226d3aac2750fddd5e6c7e34fd1
CRs-Fixed: 3697528
Add more validation for vendor command force active link bitmap:
1.If force inactive num is present due to MCC link(DBS RD) or
concurrency with legacy intf, don't allow force active if
left inactive link number doesn't meet concurrency requirement.
2.If force inactive bitmap is present due to link removal or
concurrency with legacy intf, don't allow force active if
it is conflict with existing concurrency requirement.
Change-Id: Ic7507c1797189c079f0032a39819e15467bd6bf3
CRs-Fixed: 3701323
Few non-TxMBSSID APs may not respond to ML probe req and driver
can't add latest scan entry for the partner links from ML probe
resp and if beacons from partner links are not received for a
duration enough to flush out the scan entry of that link then
connection of partner VDEV will fail with no candidates found.
Use assoc response from the MBSSID AP to generate ML probe resp
for the partner links to add to scan DB so that partner link
VDEV will have candidate to start connection.
Following are the conditions for this logic:
- Candidate is a non-TxBSSID in an MBSSID set
- Connection is for more than single link (MLSR/MLMR)
- Scan entry for partner link is not found in scan DB
Change-Id: If97475878d61d986988a6e97e693b194518dc192
CRs-Fixed: 3679519
Currently, driver drops BTM frames in unsupported cases,
e.g. connected to MBO AP without PMF capability, concurrent P2P
session present which doesn't allow STA roaming.
Add connectivity log support and indicate the reason for BTM
drop/block.
Define interface for userspace as below,
New subtype: WLAN_CONN_DIAG_BTM_BLOCK_EVENT
New enum to fill sub_reason for BTM_BLOCK_EVENT type
Change-Id: I87115da57d275a94c5ae69252ec09bcad698e47c
CRs-Fixed: 3699042
Firmware sends WMI_ROAM_SYNCH_KEY_EVENTID after roaming
to 3 Link ML AP. Host allocates memory for every crypto
keys and populates data from the fw event.
This memory is not freed if the addition to crypto
module fails and results in memleak.
Fix is to free the crypto key entry when addition fails.
CRs-Fixed: 3678765
Change-Id: Ife70261b697ec016f50d4e0730c3fa4fc0ec06ab
T2LM Req/Resp Connectivity logging is not supported if
the T2LM request is initiated from STA.
Add support for T2LM Request/Response connectivity logging
when T2LM request is initiated from the STA.
Change-Id: If61b5ba7c7eb9ec5687d271afc300737df8fdf8d
CRs-Fixed: 3689209
Bss peer reference is taken without updating the ref count.
This is causing a crash if the peer is freed and the pointer
is still maintained resulting in the dangling pointer. Use
correct api to take BSS peer reference.
Change-Id: I732c10cf6339342a1f9716a5c8057085f9b91f68
CRs-Fixed: 3669170
Link switch uses cached partner links info in mlo_sta_ctx,
currently during roaming as partner links info is not filled
then link switch fails during connect.
Copy partner links info to sta context in mlo dev ctx on
roaming.
Change-Id: Ie513173f0ccdc39f46be5cf4af11021abe5950aa
CRs-Fixed: 3695386
In the api cm_roam_btm_req_event(), BTM request and
BTM Candidate Connectivity logs are printed for both
partial and full scan when disassoc_imminent is set for BTM
roam trigger. But actually, over the air frame was received
only once on the device.
So to avoid BTM frame logs duplication,
ignore the BTM request frame TLV & btm candidate TLV received from
firmware after BTM roam trigger with disassoc imminent set.
Change-Id: I7d8cf4a4f0c7e2ee7958ae3fc309f14890c2fd33
CRs-Fixed: 3675909
After roaming to 2+5 MLO AP, MLD high RSSI roaming trigger is
getting disabled if assoc link is on 5 GHz.
To fix it, if self MLD roaming is supported, then don't enable
high rssi roaming trigger for 2.4 GHz link and disable it for 5
GHz link after roaming is competed.
Change-Id: I4c02cb2c946d97884fbc0d6cc513c585c21b9548
CRs-Fixed: 3670241
In api cm_roam_scan_info_event(), band_mask is updated
for ROAM_STATS_SCAN_TYPE_HIGHER_BAND_6GHZ and
ROAM_STATS_SCAN_TYPE_HIGHER_BAND_5GHZ_6GHZ. But
the band mask is truncated for ROAM_STATS_SCAN_TYPE_FULL.
add check in api cm_roam_scan_info_event() to update
band mask only for scan type
ROAM_STATS_SCAN_TYPE_HIGHER_BAND_6GHZ and
ROAM_STATS_SCAN_TYPE_HIGHER_BAND_5GHZ_6GHZ in order
to prevent the band mask from truncating for
ROAM_STATS_SCAN_TYPE_FULL.
Change-Id: I3e85c87e3e304d0c4d4ae311c7be1939e73d05df
CRs-Fixed: 3666578
Currently, host disables btm_offload feature if the connected AP
supports MBO/OCE but not PMF. Firmware doesn't process the btm
requests received from AP in such cases and forwards the same
to host. Host forwards them to userspace. But userspace may not
expect these frames as roaming is offloaded to firmware.
Drop the BTM request frames in driver for LFR3 cases when the
connected AP supports MBO without PMF.
Change-Id: I35800ff31f8a48d12eb57cdd36856fdef2b53b8e
CRs-Fixed: 3687371
Currently for STA + STA case, consider the below scenario:
1. Roam start received on vdev 2 & vdev 0. Vdev 2 roam
serialization command becomes active and vdev 0 roam
command is on the pending queue.
2. HO failure with AP0 received on vdev 2. This dequeues
the vdev2 roam serialization command. Vdev0 roam command
becomes active.
3. Roam synch indication received on vdev0 with peer AP as
AP0 (which is the peer on vdev 2). So duplicate detection
logic prevents same peer creation, so roam synch fails but
its not indicated properly to firmware. This leads to
disconnection of both the STAs.
To address the issue, first enqueue disconnect with high
priority set before removing roam command from serialization
so disconnect gets activated if roam was active for the
vdev.
Also while processing roam synch indication, check if peer is
found on different STA and send roam stop to fw so fw also
cleans up and initiates HO failure.
Change-Id: Iddeddcde782b936dc2ea4b8f32fd0be3c0ced591
CRs-Fixed: 3686114
Currently, RSO_STOP is sent to firmware if ROAM_SYNC is aborted
due to some reason. Host doesn't check for the current state of
RSO state machine and may send the RSO_STOP twice. Firmware
responds with SUCCESS for the second request and driver
continue to cleanup peer/vdev assuming that it's a normal
RSO_STOP response. This results inconsistency in firmware
as it might be in the middle of peer/vdev cleanup and
leads to ASSERTION.
Check for the RSO state machine status and avoid sending
RSO_STOP twice.
Change-Id: I87cdb4a682095772070a839bbb86e56a9450b299
CRs-Fixed: 3677172
Link beacon in roam sync frame event may be not for actual link when
roamed to 2+ link AP, then get right link beacon from scan cache, but
beacon size may be larger, if malloc buffer with link beacon size in roam
sync frame event to save beacon IE got from scan cache, OOB will happen.
To fix it, when malloc buf to save beacon IE during roaming, use max
mgmt mpdu size.
Change-Id: I08fc52ce26edc1f02365837a1ed7a632ed7c6706
CRs-Fixed: 3667410
Implement a locking mechanism for retrieving and
storing crypto keys. Currently, due to race condition,
Host driver is fetching information in one thread while
simultaneously writing key information in another thread,
resulting in synchronization issues.
This change is to add lock mechanism while reading and writing
crypto keys.
Change-Id: I156b619cf7c3c052ad3122a6f808d732fb5e4f51
CRs-Fixed: 3672330
Add new data structure to save the external/internal set link
request. The different source of request has different priority.
In some situations, a certain request may not be honored if
it conflicts with higher priority request.
Change-Id: Ib95d0c688f92dcfc294702e7deb2e3b7da13f76c
CRs-Fixed: 3650630
After 3-link association is complete, Host sends force
inactive num command between 5 GHz and 6 GHz links to
firmware. Later, if user wants to force enable 1 or 2
links, the current checks prevent it from taking effect
as a previous force active num is in place and a NO
FORCE command cannot be sent as it is a DBS RD.
So add new API in policy manager to check if the new
force active num command is valid and process accordingly.
All new force active num commands except for 5 GHz +
6 GHz links should be allowed while honoring the prior
force inactive bitmap as well.
CRs-Fixed: 3656412
Change-Id: Iecfca57d9b47acd31d191cca2632a6d1baf62174
