Update the connect request crypto parameters based
on the new kernel changes to increase the size of the
akm_suites array in connect request
Change-Id: I36eb265d3dafe9d822879fdbed340ba0c6bb7225
CRs-Fixed: 3806556
Current code supports CFG80211_MULTI_AKM_CONNECT_SUPPORT only for
v5.15 kernel.
Enable this feature support from kernelv6.0 by default.
Change-Id: I6fbf83df54fd898abde0546f526b193a6d8dc620
CRs-Fixed: 3806550
Update wiphy->max_num_akms_connect to wiphy->max_num_akm_suites,
based on the upstream kernel change.
Change-Id: I54455b1d3fc162ddea5a0f9380f66a4a06236076
CRs-Fixed: 3214543
When the AP is configured with multiple AKMs for eg. SuiteB
and FT-SuiteB then Supplicant selects the FT-SuiteB based
on its precedence order but driver was selecting SuiteB due
to its incorrect AKM precedence. Due to this the RSN IE in
assoc-request was filled with SuiteB AKM but all other IEs
were used of FT-SuiteB as sent by the Supplicant. And this
is resulting in association failure.
Fix the AKM precedence in the order of more secure AKM.
Change-Id: I96ff786924778d336507e3bca4a38de4d7c07ffc
CRs-Fixed: 3861554
(cherry picked from commit 97b3d04265)
Update the connect request crypto parameters based
on the new kernel changes to increase the size of the
akm_suites array in connect request
Change-Id: I36eb265d3dafe9d822879fdbed340ba0c6bb7225
CRs-Fixed: 3806556
Current code supports CFG80211_MULTI_AKM_CONNECT_SUPPORT only for
v5.15 kernel.
Enable this feature support from kernelv6.0 by default.
Change-Id: I6fbf83df54fd898abde0546f526b193a6d8dc620
CRs-Fixed: 3806550
Update wiphy->max_num_akms_connect to wiphy->max_num_akm_suites,
based on the upstream kernel change.
Change-Id: I54455b1d3fc162ddea5a0f9380f66a4a06236076
CRs-Fixed: 3214543
When the AP is configured with multiple AKMs for eg. SuiteB
and FT-SuiteB then Supplicant selects the FT-SuiteB based
on its precedence order but driver was selecting SuiteB due
to its incorrect AKM precedence. Due to this the RSN IE in
assoc-request was filled with SuiteB AKM but all other IEs
were used of FT-SuiteB as sent by the Supplicant. And this
is resulting in association failure.
Fix the AKM precedence in the order of more secure AKM.
Change-Id: I96ff786924778d336507e3bca4a38de4d7c07ffc
CRs-Fixed: 3861554
When MSDU fails for checksum validation, do not aggregate those
packets and make sure current flow is flushed. Since checksum
failure packet data is not trust worthy it is not advisable to
build aggregated skb on top of checksum failure packets.
Change-Id: I09d8c4aeb656e6b0b5d268a60d72147534f2a2ab
CRs-Fixed: 3805053
Target may use association request frame to roam to AP in offload
roaming. Current API pe_set_rmf_caps only supports
reassociation frame parsing.
Add association request frame RSN IE extraction support in
pe_set_rmf_caps.
Change-Id: Ic8bc427a9d7a37dd3531cdfda243bce398eb7400
CRs-Fixed: 3264727
Currently the user configured MFP state that comes from the
userspace in connect request is not handled or processed.
Instead the RSN caps from assoc IE of connect request is inter-
sected with AP RSN caps and sent to Firmware using RSO command.
This RSN caps is used in FW in selecting a roam candidate, which
was causing the cross AKM (eg:SAE -> PSK) roam fail.
Hence, use the user configured MFP value in sending the RSN caps
to Firmware.
Change-Id: Ibf2d7bfba6cd17a98b9e4b1c8c468046ab2e7e62
CRs-Fixed: 3604149
Add support to update key management with higher security
after BSS create response.
Also, Currently if there are multiple AKM and ucast cipher.
Host overwrites AKM and ucast cipher value with the new one.
Instead of overwrite, add support to do ORing to keep all values.
Change-Id: I7a489c7d90a609c28be69a9fe9deb0b9b9c328af
CRs-Fixed: 3751018
Currently, host supports max 2 AKMs based on
NL80211_MAX_NR_AKM_SUITES.
Add support for max 5 number of AKMs in connect req.
Change-Id: I65d54cc0c09d07ae1ac4b8669a64543d332b75e6
CRs-Fixed: 3782253
Currently, STA doesn't support roam between WPA2 to WPA3
security or vice versa. To support this feature, host sends
list of allowed_authmode. So that Firmware will check and
roam on those authmode.
Fix, add support for allowed_authmode list in ap_profile.
Change-Id: I438a133a434ea12ec34680997ace358fd4910028
CRs-Fixed: 3782230
Add support for security score. On the basis of score,
host will select AP for initial connection and roaming.
Change-Id: I041a1b0c1456d7f01dd07e9b282996c56755655e
CRs-Fixed: 3782215
Host completes scan, however due to memory allocation
failure, driver cannot send the scan completed event to
the userspace. After timeout, supplicant sends vendor
scan abort to the driver. However, driver doesn't send
the failure status(because driver doesn't have any active
scan to abort). Since, the status code is sent as 0,
supplicant keeps waiting for the scan completed status
event from host.
Send the vendor abort failure reason to the userspace, so that
the supplicant can clear out scan-in-progress flag.
Change-Id: I771b7d3d76c7d7aea58ac3d02665bd43da00e222
CRs-Fixed: 3707469
Currently roaming_in_progress is set during ROAM_START event from
firmware and reset after ROAM_SYNC_COMPLETE or ROAM_ABORT or
ROAM_HO_FAIL event. But in suspend mode there can be scenario
that firmware sends the ROAM_HO_FAIL first being a wakable event,
followed by ROAM_START event which is non-wakable. Here the
roaming_in_progress bit gets reset and then set. But due to
HO_FAIL the host triggers the disconnection. And during this
currently the roaming_in_progress is reset during VDEV down in
all the cases except HO_FAIL. Hence reset the roaming_in_progress
during VDEV down in all cases irrespective of the VDEV stop type.
Change-Id: I53428b8a43769ed891bdc3e93b11207fe47a1939
CRs-Fixed: 3745192
Currently in the function hdd_send_roam_scan_channel_freq_list_to_sme,
the num_chan variable is declared as uint8_t and is incremented
for each nested attribute PARAM_SCAN_FREQ_LIST.
If the number of attributes sent by userspace is more than max value
of uint8_t, then an integer overflow occurs.
To avoid this issue, add a sanity check to see if num_chan has reached
SIR_MAX_SUPPORTED_CHANNEL_LIST before incrementing variable.
Change-Id: I601a73a118eb65ebb8575f6ed5ed1f29d915f59e
CRs-Fixed: 3568577
qdf_conc_list_lock from policy manager is destroyed as part of
idle shutdown, later when FW down indication comes it is trying
to acquire as part of ucfg_dp_bus_bw_compute_timer_stop.
So call ucfg_dp_bus_bw_compute_timer_stop function in
hdd_soc_recovery_cleanup after checking driver status.
Change-Id: I27164a4b11467aee6c925225fe33d4fdbe0b4082
CRs-Fixed: 3689606
Currently host doesn't check if power type is supported
for connection channel while calculating best 6 GHz
power type for connection. This results in calculation
of incorrect power for connection values if 6 GHz power
type is not supported for that particular channel.
To address this issue configure power type for connection
only if that power type is supported for connection
channel.
Change-Id: I7e4ccdb962974cc8c415e8d174b2da0bf311f1a5
CRs-Fixed: 3697212
Find the best 6 GHz power type for connection
according to following regulatory policy:
1) SP power type is selected only if AP advertises
SP and client supports SP.
2) LPI power type is selected only if AP advertises
LPI and client supports LPI.
3) VLP power type is selected for the below cases,
a) AP advertises VLP and client supports VLP
b) AP advertises SP but client doesn't support
SP but supports VLP.
c) AP advertises LPI but client doesn't support
LPI but supports VLP.
Change-Id: I582fb582e1e11b731a1c6cda01f4fc366f166143
CRs-Fixed: 3456192
Currently the roam scan high RSSI delta is configured via INI.
Define an attribute to allow user configure high RSSI roam
trigger threshold. STA is expected to trigger roam if the current
connected AP's RSSI gets above this high RSSI threshold. STA's
roam attempt on high RSSI threshold aims to find candidates from
other better Wi-Fi bands.
This attribute value is given priority over the INI.
Use a new service bit WMI_SERVICE_5GHZ_HI_RSSI_ROAM_SUPPORT to
enable high RSSI roam trigger in 5 GHz as well.
Change-Id: Ide48ad2261b603de36bd1b31114b91c3a9d6606f
CRs-Fixed: 3586170
In present scenario, STA disconnects with AP if it receives
invalid channel in CSA IE. In this case STA shouldn't
disconnect with AP as this request may come from a spoof AP.
Ignore this CSA request as it might be from spoof AP and
if it is from genuine AP heart beat failure happens and
results in disconnection. After disconnection DUT may
reconnect to same or other APs.
Change-Id: I840508dd27d8c313a3e8f74c4e1f5aa64eecf6f9
CRs-Fixed: 3390251
Currently as STA, when populating channel width set, only max BW
advertised by target are considered. However issue is that due to
regulatory limitations, the max BW advertised may not be the real
operating BW used by our device. Under such conditions, there'll
be conflicts between AP's view of our capablities and the real
ones host configured to target.
Therefore when populating supported channel width set for VHT and HE
capabilities, take current session's channel width into account so
so that capabilities advertised could correctly reflect current
running configurations.
Change-Id: Ib072c3e4d36d5c3fbd5504d94a936175d1a92db0
CRs-Fixed: 3047338
Higher Bandwidth support 80/80+80/160 is enabled on 2.4 GHz Band.
Modififed the population of peer capability logic to disable
80+80/160 based on the band.
Change-Id: I8319ef3fcd93676bca1115a088a926a772545d24
CRs-Fixed: 3030837
