Currently wlan_hdd_mgmt_tx path is still using legacy API to convert
channel frequency to number, it is not applicable for 6 GHz channel if
convert it back from number to frequency.
Fix it by replace all places where using legacy API to convert channel
and use channel frequency from supplicant directly. It can fix mgmt tx
from supplicant on 6 GHz channel.
Change-Id: I60fe37d7d716eeaceaa00f3fb59c77b629ebacac
CRs-Fixed: 3024898
Currently in the wma_stats_ext_event_handler(), the buf_ptr
is not pointing correctly to the event data received from FW.
This is leading to an OOB memory access during qdf_mem_copy().
So, to avoid this issue correctly point the buf_ptr to the event
data sent by the FW in the TLV.
Change-Id: Iffa3e96a6a36eff5899a7a9a7febe0ebb9d7878f
CRs-Fixed: 4011656
Currently, host doesn't recalculate TX power post CSA if
no change in power constraint or TPE IE, this can cause
issue if local regulatory power is different for new CSA
frequency.
To address this issue, add support to recalculate TX power
for first beacon received post CSA.
Change-Id: I91f4609c552d579c24e781d382e647b6617e9315
CRs-Fixed: 3809724
Currently for WAPI connection auth mode is updated only
in key management, but on connect request for validating
auth mode, it compared with original key management and
failing to connect because of mismatch in auth and cipher suits.
To fix this, update auth mode in original key management as well
in crypto for WAPI connection.
CRs-Fixed: 3901275
Change-Id: I942fbbc68c18d7c8137053b5fc9cb0260109fdcd
According to spec the TSinfo size should be 4 bytes.
To fix this issue,TSInfo size is increased to 4bytes aligning with the
current standard.
CRs-Fixed: 3910625
Change-Id: I7979fa84af0295d21d4afe1b876af494a5b8fed8
The tx completion handler for the frame frees the buffer.
Therefore, usage of frame after tx completion causes undesired
effect.
Remove the dereference of tx frame buffer contents in
lim_tx_mgmt_frame() after the tx completion.
Change-Id: I32211e1bce4f96ba920a2212ef65aa39831666ab
CRs-Fixed: 3772014
Fix the possible OOB write in unpacking the country IE due to
the IE length check against integer division.
CRs-Fixed: 3910626
Change-Id: I800290ab7285fb46ed43a46ce38967046b4881fa
(cherry picked from commit 0002f9ddc9a6be3e34fe15e55f286b5794b29f08)
Some third-party APs are not able to handle more than 1 octet
in the RSNXE, even though RSNXE support is present.
Therefore, to prevent this interop issue, send only 1 octet of
RSNXE if the AP broadcasts only 1 octet.
RSNXE handling logic summary:
1. Don't modify userspace RSNXE when caps other than
SAE_H2E, SAE_PK, SECURE_LTF, SECURE_RTT,
PROT_RANGE_NEGOTIOATION are set.
2. AP doesn't send RSNXE
For WPA2 - Strip the RSNXE completely.
For WPA3 - Retain only SAE capabilities such as H2E and PK.
3. AP supports RSNXE with length 1
For WPA2 & WPA3 - Retain only the first octet in RSNXE.
4. AP supports RSNXE with multiple octet
For WPA2 & WPA3 - Use the userspace assoc ie RSNXE as it is.
Change-Id: I56d1d5711b067fe5e0ff19117f6a600219cb86a0
CRs-Fixed: 3490369
Currently when sar safety unsolited timer expires, driver schedules
a work to send sar safety unsolited events to user space. When driver
receives sar set command from user space it tries to stop this work
with delayed work stop sync. This delayed work stop sync API waits for
work to get complete and then it stops the work, because of this,
work runs the complete for loop and sends extra sar safety unsolicited
events even after receiving sar set command.
To addrerss above issue, set the sar safety request response event
before delayed work stop sync to complete the work.
Change-Id: I3485e4b1ea600393ff2d9512a055de92d0a3d612
CRs-Fixed: 3213334
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
