Certain APs available to end users may allow EHT/MLO config
in non-WPA3 security modes (like WPA2). Current implementation
will not allow connection to such APs in EHT/MLO and instead
downgrades to 11ax mode.
OEMs may want to control this driver behavior via INI based
on the requirement. To allow connecting to such APs in EHT/MLO
a new INI is introduced as a bitmap. The default value of this
INI will not allow connection to any of those APs in EHT/MLO.
Change-Id: I3e657f3f4ba1f5efc9263cb90bcd1773233975ac
CRs-Fixed: 3693813
Each link in MLO can have different RSN capabilities with
different AKMs, PMF capability, UC/MC cipher suites and so on.
For any choice of links for MLO connection, the AKMs of the
links should have one common AKM.
Eliminate partner links without overlapping AKMs from MLO
connection.
Modify partner link AKM to match assoc link AKM, so that
only overlapping AKM is chosen even though an AKM with
higher security exists for partner link.
Change-Id: I9573e938789a4b95ae824872845d31008861f6f2
CRs-Fixed: 3693814
For non-TxMBSSID ML AP ML probe req may not receive any response
from MBSSID AP and later partner link may fail to connect as
scan entry is not present.
Introduce new flag to suggest whether the partner link scan entry
is present or not in the scan DB. If flag is set to true, generate
scan entry for such links.
Introduce new APIs which will generate ML probe resp using
the per-STA profile of partner link from assoc resp frame.
Introduce API to get the current candidate scan entry from
connect request.
Change-Id: I1c33956b01eb468afa26be5b0bfba634ee3a0aee
CRs-Fixed: 3675830
On set country code, host updates EHT cap IE to FW via
WMI_VDEV_SET_IE_CMDID command. 320 MHz BW capability in
EHT cap IE should be as per new country code.
Change-Id: I3b80dbeee6f35dacc41f15612373ea7f8efc5803
CRs-Fixed: 3670311
Excessive logging in wlan_mgmt_txrx_desc_get if descritor is
not found.
Rate limit excessive logging in error log.
Change-Id: I929c5cca5dea94db4b618f0390d76a6ca83159a9
CRs-Fixed: 3696162
RSO is stopped upon receiving link switch request to avoid the
race between link switch and roaming. RSO is enabled again once
link switch operation is successfully completed, i.e. upon connect
complete of the new link.
But link switch may fail due to multiple reasons (e.g. scan
result/partner info is not available for link switch) and the
connection is retained with single link as the other link is
already cleaned up as part of link switch request processing.
RSO is not enabled in such failure cases and thus firmware
doesn't roam even it finds a better candidate.
Restore RSO state to ENABLED upon link switch failure.
Also, cleanup the failed link bit in wlan_connected_links upon
link switch failure.
Change-Id: Ieefd7bf9615c80e7ab6ecdbee5c99d6e52857cc6
CRs-Fixed: 3681892
Wireless environment may have APs with same BSSID but different
MLD address and if any APs BSSID is similar to the current
candidates affiliated partner link BSSID, then receiving beacon
or probe resp from such APs will override the affiliated link's
scan entry and the MLD address may be different or NULL if the
AP is non-ML.
If link VDEV connection starts and during candidate selection
it may find the scan entry of this other AP and attempt to drive
connection will lead to creating ML link VDEV's peer with
different MLD address than assoc VDEV's peer.
Enhance scan filter to match MLD address for link VDEV to avoid
such scan entry override.
Change-Id: I11c9b4efdf2d60e92482b296d731d613a200bf0e
CRs-Fixed: 3668326
For the NO Candidate scenario, the connecting event is
not logged resulting in breaking the connectivity logging
mechanism sanity.
Add support to log CONNECTING connectivity log during
NO CANDIDATE found scenario in order to maintain the
logging mechanism sanity.
Change-Id: I534307802d28365ffea330e85b710074ab863c09
CRs-Fixed: 3678114
Currently if the TBTT length is more than max supported length
driver doesn't the mld information from the RNR IE. This leads
to SLO rather than MLO.
Add the fix to restrict the max length to current supported max
length which helps to parse the ML information further
results in ML association.
CRs-Fixed: 3679296
Change-Id: Id8c58044be162f638ed5e74e0fd04aa0b77780f5
In order to identify certain vendor APs, it generated
AP beacon from MBSSID nonTx profile shall include these
Vendor Specific IEs (VSIEs).
If any matching VSIE of interest is present, copy the
IE to generated frame.
Change-Id: Ic3566ad0123c7353d7ace1b0077d6a3730d10dc8
CRs-Fixed: 3682937
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: I379c03138b70580f44c2b96489ada030ec6fc20e
CRs-Fixed: 3686660
If MLO link VDEV flag is set but MLO VDEV flag is not set
the APIs only checking for MLO link VDEV will assume VDEV
as ML but the APIs checking MLO VDEV will assume VDEV as
non-ML, this is not valid.
As per definition of MLO VDEV and MLO link VDEV:
-If any VDEV is MLO link VDEV then it has to be MLO VDEV.
-If any VDEV is not MLO VDEV then it shall not be MLO link VDEV.
Change contains following:
-On clearing MLO VDEV flag, clear MLO link VDEV flag.
-On setting MLO link VDEV flag, set MLO VDEV flag if not
already set.
Change-Id: I8efeaa1cb75b37e5f7f2cc5c16067df677000c45
CRs-Fixed: 3657212
Add PID name where SM events and transition
happened to help debug issues where the info
about which task started a certain event to
happen are crucial to rootcause the problem.
Change-Id: I208b46c6d0ec725ab0d9713bf2dd562c40719a24
CRs-Fixed: 3624811
Successful link switch connect implies that the VDEV-Link mapping
changed in driver and FW expects success notification in link switch
confirmation after which FW updates internal fields to reflect this
VDEV-Link mapping same as in driver.
If driver receives SB disconnect while link switch is in progress,
it defers the SB disconnect and moves link switch to abort state.
As current state is in abort, host will forcefully sends failure
status to FW in link switch confirmation and immediately starts SB
disconnect and sends VDEV_STOP to FW. As link switch status is
failure, VDEV-Link mapping is not updated in FW and FW might send
another link switch request with params corresponding to previous
VDEV-Link mapping and leads to Host-FW out of sync issue.
If the status of link switch connect is success, then force link
switch confirmation status to success so that FW can update new
VDEV-Link mapping.
Change-Id: Iaa9836f9089a2f8fcbf4d49e3c598f9a01aa8d06
CRs-Fixed: 3665211
Cancel scan when P2P scan with BSSID and found BSSID.
Send flag to fw by WMI_SCAN_FLAG_EXT_P2P_REDUCE_TIME_SCAN.
Change the scan flag value align with fw change of:
I4760f4515c07f575df523d7e387c07113b277a6b
Change-Id: I6af3c5ae1027af36e0494f1eaceb7cb5aebec494
CRs-Fixed: 3659688
Add an API to support sending multiple COEX config in one WMI command.
This is to optimize and save target host to firmware WMI command
communication time.
Change-Id: Ie510ee3ebfca67a2b748c403ec52a8d7b597f676
CRs-Fixed: 3651226
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: 3669552
Increase priority for the 6 GHz + 2 GHz combination,
even when 5 GHz + 6 GHz MLSR is enabled.
This modification aims to emphasize frequency prioritization for
frequency not on same mac.
Change-Id: I159c673b8f1d772e2f557df9e9811292a65a4bb6
CRs-Fixed: 3672983
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: Ia0bce7b50436e4e2b52d2c4948c7aa8a3a7a0a97
CRs-Fixed: 3654159
Currently, firmware doesn't send CSA event to host when there is
a link_switch request is given to host. Similarly, it doesn't
send link_switch if CSA is in progress.
Host driver can also initiate channel switch operation when
it detects a change in the Operation IEs(HT_INFO/VHT_OP/HE_OP/
EHT_OP, etc..) from beacon/probe rsp. When link switch is
started by firmware and if host also triggers VDEV_RESTART
due to a change in the beacon at the same time, VDEV_RESTART
timeout happens as vdev lock is held by link switch module
in firmware.
So, host driver can't allow link switch when such VDEV_RESTART
is in progress.
Add an MLD level check when CSA/chan_switch is started and reject
link switch request if it's set.
Change-Id: If5b7fbcbf214684c28d0129546376220a147bce9
CRs-Fixed: 3655049
Issue 1:
With this change - I1bdfd71245552a51fd5123931a7a6dcc16f2a942
host is setting AP power type before beofre saving reg
rules in pdev.
To address this issue, set AP power type after saving
reg rules in pdev.
Issue 2:
In reg_append_mas_chan_list_for_6g host is checking
the pdev_priv_obj->reg_cur_6g_ap_pwr_type before filling
6 GHz pdev current channel list. If some country supports
only LPI, and gindoor_channel_support is disabled,
the AP power type will be REG_CURRENT_MAX_AP_TYPE and host
won't fill supported 6 GHz channels in the pdev
current channel list.
To address this issue, remove the check of
reg_cur_6g_ap_pwr_type in reg_append_mas_chan_list_for_6g.
CRs-Fixed: 3663908
Change-Id: I1bdb5f24c1d7bfb3fe9755b145207a219662fc9d
Currently, Host driver assigns the maximum score for a valid BSSID hint.
However, when there are multiple candidates with same assoc link,
there is no distinction. To maintain priority, host driver host driver
needs to increment the ETP score in such cases.
Change-Id: Id4b854f77b473870121fc9ec56276a0fc0b0439e
CRs-Fixed: 3663364
For peer-to-peer T2LM negotiation vdev pointer is passed as NULL to
wlan_mlo_add_t2lm_info_ie(). This function calls
wlan_vdev_mlme_get_cmpt_obj() to get vdev_mlme pointer. Hence, 'vdev is
NULL' print is seen on the console. This print is misleading even though it
is not a failure. Hence, call wlan_vdev_mlme_get_cmpt_obj() only for
Advertised T2LM feature.
Change-Id: Iea4e97ae25beede76d0e61efa2cb111bbdf63b13
CRs-Fixed: 3658029
Pine and Spruce supports 80P80 mode of operation in 5 GHz band
and hence opclass 130 is sent to the user application in
MESH_MAP_OPCLASS_FOR_CUR_HWMODE NL80211 command.
However, these chips support 80P80 mode of operation
only on CFI 138 and 155, but to the application all the 80 MHz
channels in the 5 GHz band are advertised as supported.
This causes the application's channel selection algorithm to fail.
The existing API reg_is_chan_supported() can determine if the input
frequency is 80P80 capable only if cfreq2 of the 80P80 channel is
provided and in reg_get_cfis_from_opclassmap_for_non6g() API, it is not
possible to determine all combinations of cfreq2 for the given primary
frequency. Hence, a call to is_freq_80p80_supported() is made to
determine if any 80P80 combination is possible for the given input
frequency.
Also, 6 GHz channels do not support 80P80 mode of operation.
reg_is_cfi_supported() does a lot of computation to find out that
80P80 is not supported. Hence, if the opclass entry
is 6 GHz 80P80, set 80p80_supported as false.
Hence, send only the supported 80P80 CFIs in the
supported channel list array in MESH_MAP_OPCLASS_FOR_CUR_HWMODE command.
CRs-Fixed: 3627501
Change-Id: Ib5d3e872b34b8df81b8466e877b10f2fd4e68e40
Modify return values in wlan_crypto_setkey to
reflect the exact error condition.
Change-Id: I21729bf999a6561d6282bb456451e1e1a0748609
CRs-Fixed: 3629285
Currently for any assoc failure the number of links part of the
association is reduced and retried with less number of partner links.
If the failure is due to PMKID retry to the same with the same number
of partner links instead of downgrading the links.
Change-Id: I65320d92b4b77d2ccfb20a05fbab2aa8377bb6fa
CRs-Fixed: 3653834
Host driver moves VDEV SM to IDLE_DUE_TO_LINK_SWITCH any link
switch failure to handle events such as DISCONNECT_REQ which
gets dropped if the VDEV is in INIT state.
Disconnect request on any ML VDEV initiates disconnect on partner
VDEVs as well if they are either in connected or connecting state
but not if in IDLE_DUE_TO_LINK_SWITCH state. This leaves the VDEV
in this new IDLE_DUE_TO_LINK_SWITCH state instead of in INIT state.
Include VDEVs which are in IDLE_DUE_TO_LINK_SWITCH during partner
VDEV disconnect so that VDEV SM moves to INIT.
Change-Id: I6e715c0bb94562be866e902009b3bfd7d2c60e8a
CRs-Fixed: 3659110
Currently 'reg_compute_pdev_current_chan_list' is called
twice as shown below, when 'wmi_reg_chan_list_cc_ext_event'
from FW is handled.
LIST_CC_EXT event:
reg_compute_pdev_current_chan_list() [ 1st call]
reg_send_scheduler_msg_nb()/reg_send_scheduler_msg_sb()
wlan_reg_decide_6g_ap_pwr_type()
reg_decide_6g_ap_pwr_type()
reg_set_ap_pwr_and_update_chan_list()
reg_compute_pdev_current_chan_list() [2nd call]
To solve this, do not call 'wlan_reg_decide_6g_ap_pwr_type'
from north bound or south bound callbacks.
However, the above fix creates another problem because the function
'reg_decide_6g_ap_pwr_type', in addition to calling
'reg_compute_pdev_current_chan_list', also sets the current 6 GHz
power type for the pdev. A proper place to set the 6 GHz
power type is in function 'reg_set_ap_pwr_type',
which currently does not set 6 GHz power type correctly.
Hence remove 'wlan_reg_decide_6g_ap_pwr_type' and
'reg_decide_6g_ap_pwr_type' functions and modify
'reg_set_ap_pwr_type' to set the best 6 GHz power type
based on the 6 GHz regulatory rules.
CRs-Fixed: 3609342
Change-Id: I1bdfd71245552a51fd5123931a7a6dcc16f2a942
Issue happens during following scenario:
1. Connecting to ML AP1 (with SSID1) and disconnect.
2. Connecting to ML AP2 (with SSID2), as part of that vdev
is destroyed and created but stored keys for AP1 are not reset.
3. Disconnect for ML AP2.
4. Connect to ML AP1.
Now host driver sends stored keys FW instead of the newly
generated keys sent by supplicant.
To fix this during ML dev initialization
clear the stored keys.
CRs-Fixed: 3649214
Change-Id: Ibffeb8b3108bf353e9140cbc901f99f08d9b0449
Provide support for bangradar with Frequency hopping radar type
as one of the parameters.
Add the parameter as part of the packed structure to be sent to FW.
Change-Id: I1c366c8f1c2033527bbd74f0ae6219225cafc4ed
CRs-Fixed: 3641574
If "override_ht20_40_24g" ini is set, the host driver disables
the HT40/HE40 caps for 2.4 GHz after connection via SET IE. The
firmware uses this for roam. However, if reassoc comes from userspace
with the HT40 cap different from the initial connect, then host
does not update the IEs based on new cap. This leads to mismatch
between user configuration and firmware roam.
To fix this, modify and send the HE40/HT40 caps via SET IE for
every connect request. Reset it after disconnection to the default
self cap.
Change-Id: I3de73d2ff2e5ebbbda530c29371edc0295ec608f
CRs-Fixed: 3655893
For MCC, dp_vdev_detach_wifi3->dp_vdev_id_map_tbl_remove
will happen before mlo dev ctxt detach from vdev destroy,
which will cause it access dp vdev with null pointer issue
(use-after-free).
So move the mlo dev context detach out from the function
wlan_objmgr_vdev_obj_destroy(), and will detach the mlo
dev context from hdd_vdev_destroy_event_wait for MCC and
meanwhile not impact win logic.
Change-Id: Id07db64a27cd7032ea45fb4661b54edb662010c7
CRs-Fixed: 3621883
Since sta don't send probe req to MBSSID AP, channel info in
link_info not update.
But station receive beacon and update info into scan_entry,
so when connect done, we can update link channel info from
scan_entry by bssid and freq.
Change-Id: Ie7058cf055847b709823a7ade89e074f718f03d6
CRs-Fixed: 3625825
Add initialization value for bss_mld_addr in function
cm_check_and_prepare_roam_req().
Change-Id: Ic9ac9fd6f94343ff1bab8b45bac81e889a9dfe1f
CRs-Fixed: 3643137
Currently host is directly acting on the link_id for which link switch
is requested, if the link is already active on the other vdev if the
link switch is not sanitized resulting in firmware ending up
in bad state.
Reject the link switch if the link is already active on different vdev.
CRs-Fixed: 3635416
Change-Id: Idf445dcc487540c4faac7cf98abf7c214512d750
In case of outdoor NULL response, currently the api
'reg_set_ap_pwr_and_update_chan_list' bypasses setting power
type when ap_pwr_type is REG_CURRENT_MAX_AP_TYPE
in order to update the current channel list to the upper layers.
Due to this, selecting best power mode
algorithm fails during the invalid case scenario (allowing
to operate in channel which is not in Outdoor SP channel list).
To fix this problem, remove check which bypasses setting power type in
the api reg_set_ap_pwr_and_update_chan_list.
This removal needs an additional change which will handle the updating of
current channel list, which is done in another change. Refer to
change Change-Id: I176a432a031af0170e8bc7dec9b417828595fd14
for more details.
Change-Id: I80e3a0d12afa175d30fa945fb83aa8b247bf3889
CRs-Fixed: 3641754
Currently, mlo_get_assoc_rsp provides assoc rsp pointer
every time even in case of reassociation where assoc rsp
is not valid which can cause issue in link_switch as assoc
rsp provided might be invalid.
Fix is to provide reassoc rsp if present in case assoc
rsp is not present.
Change-Id: I91715a39f77159b68eee5cc97dc291a09e21a897
CRs-Fixed: 3622768
New API, reg_get_next_higher_bandwidth added to
get next higher bandwdith for the given channel width.
Add boundary check for channel width in
API get_next_lower_bandwith.
Change-Id: Icd250d0c518eda9749b25778427b1bffac66ad56
CRs-Fixed: 3636188
Currently the ini "enable_responder_11az_support" is a boolean value
and applicable for enabling all the RSTA operations- 11az TB and NTB
ranging. Change the usage of existing ini "enable_responder_11az_support"
into a bitmap as below:
BIT 0 - 11az NTB
BIT 1 - 11az TB
Set the wiphy ext caps based on the bitmap values
this change to enable TB/NTB ranging as per user config
Change-Id: I97034677e6ed6840d8d9403b32b823c318a17634
CRs-Fixed: 3640571
In case of 2 link AP, partner link will be 1 instead of
2. As of now, driver set is_valid_link as false in
case of 2 partner link.
Fix is, set is_valid_link as false if partner link is 1.
CRs-Fixed: 3645066
Change-Id: Ib91baff1915b9b38a8144ad3f9c8cb113c450205
Add null check for RNR node in the scan API
scm_filter_rnr_flag_pno before accessing its parameters.
CRs-Fixed: 3645688
Change-Id: I8c18c75214128496d159425c923db1be1525e298
