Host semd wmi as following order after CSA received/vdev restart and
before vdev up, old puncture bitmap mismatched with new phy mode lead to
F/W assert.
1. WMI PEER PHY MODE
2. WMI PEER BW
To fix it, swap order as following
1. WMI PEER BW
2. WMI PEER PHY MODE
Change-Id: I1ae3e5093cb45520be0f50ffb31fa7386201340b
CRs-Fixed: 3650797
AP sends "Operating Mode Notification" IE contains max supported
channel width indication (ap operating channel bandwidth) via
beacon/probe response/association/re-association response frame.
After sending OMN IE to DUT, AP expects DUT should do Tx/Rx of
data packet on ap operating channel bandwidth.
Due a recent change in FW (via CR/3701633), FW combined BW and
PHYMODE update requests into single message to avoid race condition
and assert in FW. It means whenever host updates ch_width to FW,
should also update corresponding phymode immediately via same
command WMI_PEER_SET_PARAM_CMDID with param id WMI_HOST_PEER_PHYMODE.
Currently on detecting OMN IE in any of above frame,
host sends WMI_PEER_SET_PARAM_CMDID command only once with
param id WMI_HOST_PEER_CHWIDTH to update ch_width only with
expectation “FW should use same ch_width for further Tx/Rx
of data packet”. But FW ignoring only ch_width updates (without
followed by phymode update), this results DUT fails to do Tx/Rx
of data packet on ch_width present in OMN IE.
Fix is to make sure on detection of OMN IE (contains valid ch_width)
in above frame(s), host should send WMI_PEER_SET_PARAM_CMDID command
two times to FW to update ch_width and corresponding phymode.
Change-Id: Ic23205bb6c164b1bcb9c183d0f7818b082b84583
CRs-Fixed: 3734683
Firmware sends the roam scan info tlv to driver during roaming.
Currently, in this tlv, firmware fills scan type as (0-3) and
driver log this as "PARTIAL", "FULL", "NO SCAN" and "Higher Band"
But with new requirement, idle roaming shall only roam to higher band
(2.4 GHz < 5 GHz < 6 GHz) than current band.
1. If current band is 2.4 GHz, it cannot roam to 2.4 GHz.
It can roam to 5 GHz and 6 GHz.
2. If current band is 5 GHz, it cannot roam to 2.4 GHz and 5 GHz.
It can roam to 6 GHz.
So, to add this requirement, firmware introduces new scan type 4 for
which driver need to log.
Change-Id: I80d1c47a434da5009aed4cab08c6eae91bda5b0e
CRs-Fixed: 3379468
is disabled
Issue Scenario:
1) INI gEnableDFSMasterCap is set to 0
2) User tries to force start SAP on 160 MHz.
3) SAP starts on 160 MHz which contains DFS channels.
This is a violation since the DUT does not support DFS
master capability.
To fix this, stop the SAP bringup if atleast one of the
bonded channels is DFS.
CRs-Fixed: 4516874
Change-Id: Iaeb77d52059505bafb8a0d38386cb1790432b498
Ensure the "WIPHY_FLAG_DFS_OFFLOAD" flag is always set in
wiphy flag, regardless of DFS master capability ini.
This changes eliminates the need for supplicant to check
DFS flags for the SAP channel, as the DFS logic is
consistently offloaded to the driver.
CRs-Fixed: 3716167
Change-Id: I571f1cf15d268b85ad4de4d2f2a93d39f59b1231
Add A_INT64 as a signed 64-bit integer type in uapi/linux/a_types.h.
This complements the existing A_UINT64 definition and provides a
consistent signed 64-bit typedef for consumers of this UAPI header.
CRs-Fixed: 4492650
Change-Id: Ie7f5fb55ba291273ecf35920a217fc65dfa3f661
Currently, the driver overwrites the supplicant
configured connect request AKMs with that of the
candidate's AKM. Due to this, the STA attempts
connection via an AKM which is not present in the
original connect request.
To fix this, use the intersection of original AKM
list and the candidate supported AKMs to derive the
connection AKM.
Change-Id: I700630fda91b4b3ff73e50a38e3c0386ede85e42
CRs-Fixed: 4490428
SPMK global cache in the vdev private is persistent
across connections. Therefore, in cross-ssid roaming
cases with different AKMs, SPMK in the global cache
will always be sent to the firmware in RSO start, even
for non-SAE connections. This causes roam failure.
Reset the spmk global cache for every new connection.
Change-Id: I03deefe16242ef79d0985a8c05881914e6f7af01
CRs-Fixed: 3310182
currently self rsn cap intersect with AP rsn cap IE
which is filed in bss desc, but while reading rsn cap
IE from bss desc is getting all Zero's, due to which
self cap also become Zero's.
Fix is read AP rsn cap from negotiated rsn cap of bss
desc which is populate properly and self rsn cap is
filled correctly.
Change-Id: Ia1d9c27e1f3a7528636ab78ebe973090a9ae6f1d
CRs-Fixed: 4423830
Scenario:
1) FW sends roam start to the host, and host disables the netif
queues. Therefore, the ping from the stack does not reach the
driver.
3) The driver goes into runtime suspend, and the firmware aborts
roaming due to pmf assoc retry.
4) After assoc comeback timeout, the firmware successfully roams.
However, both roam abort and roam sync are not wakeable events.
5) Therefore, the host stays in runtime suspend until the timeout
as part of the serialization command queued during roam start.
6) Netif queues are enabled back after roam start timeout and ping
resumes.
This results in a data loss for a longer time, eventhough the
firmware has aborted the roaming. Currently, the host driver prevents
runtime suspend only from roam sync event until roam sync completion.
To fix this issue, prevent the runtime suspend from the roam start
until roam sync completion/roam abort/roam ho-failure.
Change-Id: I9d63dd6af09d17e90d7d2d6a63a8aaa59297a047
CRs-Fixed: 4413987
Acquire the runtime pm lock when roam sync event is received
and release after roam sync complete is sent.
Change-Id: Ic56d353dd343f5fcbc228a8d7251e047177b9a9b
CRs-Fixed: 3238723
The wma_fill_rx_stats function accesses wmi_rx array using index
wmi_rx[i * WLAN_MAX_AC + k] without validating that wmi_rx buffer
has sufficient elements. This can lead to buffer overflow when
num_peer_ac_rx_stats * WLAN_MAX_AC exceeds the available num_rx_stats.
Add validation check to ensure wmi_rx does not reach out of bound
before accessing the array.
CRs-Fixed: 4315163
Change-Id: I91cf41d8f931aef7d5666b2744fc5d8a167d43f3
When aggregation of a flow is in progress, there can be case
when the HW flow table entry match may fail for few packets.
Such packets, even though belong to a flow already present in
flow table, are routed independently to any RX ring.
When software checks this rx ring ID, from the independently routed
packet and compares the ring ID against the one which is assigned
for the flow, there will be a mismatch leading to unwanted behaviour.
Hence, always validate the fse_metadata before taking any
action on the basis of rx ring ID mismatch. The non-matching
packets, with invalid fse metadata can be submitted to network
stack independently.
Change-Id: Ia95f20ef1050bc981b2d22571b612fd2af6f6a65
CRs-Fixed: 3272353
Currently host overwrites crypto AKM with candidate AP’s AKM.
To choose the most secure AKM, host do sort of AKMs properly
based on security to use for association and can choose the
AKM which station do not advertise and results in Assoc failure.
To fix this, consider intersection of crypto and candidate AP’s
AKM for association instead of AKMs directly from AP config.
CRs-Fixed: 4320132
Change-Id: Id1813fc9f7fe76ff5ae9daf4da051067bddfdce1
The MBSSID cap in the extended capability IE is
populated properly in the Probe and Assoc request
of the initial connection. But, this cap is missing
in the reassoc request during roaming.
Host driver fills this cap based on the service cap
of MBSSID support only during the probe/assoc req
generation. This cap is not passed to the firmware
via SET IE or via assoc IEs in the RSO START.
Since the service cap would not change in runtime,
override the MBSSID cap in the assoc IEs received
from the userspace itself. This sets the cap in both
SET IE as well as RSO START.
Change-Id: I69476e503a369df6533de9c215efc4c39d9e251c
CRs-Fixed: 4117861
A validation check has been added to ensure
beacon length is not less than
(bcn->noa_sub_ie_len + sizeof(struct p2p_ie)),
preventing underflow issues.
Change-Id: I924a3ebf4a0749d5a4c56b36878765fcf46440a4
CRs-Fixed: 4166530
When both EIRP and PSD TPE IEs are advertised by 6 GHz AP, we need
to use PSD power. We need to keep the psd_power true if psd_set
is true (means PSD TPE IE present) when driver processes the EIRP
TPE IE.
If reg rules don't support psd power, ignore PSD TPE IE.
Change-Id: I96cf8f08ffd0aa143f0f0f453eed3c8b8e5d2382
CRs-Fixed: 3693350
Add TPE IE EIRP power parsing support for 6 GHz channels.
1) Currently, is_psd_power flag is derived from current
channel list chan flag which returns true if corresponding
channel supports PSD power. Normally, all 6 GHz channels
support PSD, so this flag is usually set to 1. But, AP
can transmit EIRP power in TPE IE for 6 GHz channels,
thus derive this flag based on tx_power interpretation
field in TPE IE for accurate value.
2) The calculated center freq is passed as argument to
retrieve regulatory power from reg channel list
but this logic works only for PSD. E.g. In case of EIRP,
center freq can be 6125 MHz for oper freq 6115 and BW
40 MHz, and causing reg APIs to return reg power as 0.
Thus, pass operating freq as argument in case of EIRP.
Change-Id: If1ad3870a866592d970adad218e507c9c756f615
CRs-Fixed: 3266393
Currently host driver does not validate bw in lim calculate
tpc api before is it gets next higher bw, there is a possiblity
that this bw becomes invalid and driver ends up with out of bound
access for get higher bw array.
In current scenario when host driver tries to start vdev on
frequency 2472 for country IN and executes this API for frequency
2472, at the same time country is changed to US and this frequency
becomes invalid. so in the execution of this API host driver gets
invalid bw from reg set param and ends up with out of bound access
for get higher bw array.
TO address above issue, add a check to validate bw before driver
acceses get higher bw array.
Change-Id: Ibd6a2ff44a7928bb2fd461e6c49d4e306e4de7f7
CRs-Fixed: 3186084
Currently, the WOW wakeup event handler lacks validation for the
WMA handle and the PSOC pointer within the WMA handle. This omission
can lead to null pointer dereferences in the host.
To address this issue, null pointer checks for both the WMA handle
and the PSOC pointer have been added.
CRs-Fixed: 4107000
Change-Id: Iaf22d5adc14b65b778b0e1d78108eded0cccb8c9
Introduce a new ini parameter, to apply an RSSI penalty
to non-6 GHz candidate APs during roaming from 6 GHz AP.
This ensures roaming to non-6 GHz AP occurs only if it
offers significantly better signal quality.
Change-Id: I02482c37c56c44d3d1804282abd09deaefb8eed3
CRs-Fixed: 4141300
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
We have fixed using channel number as internal parameter instead of
chan frequency with change I60fe37d7d716eeaceaa00f3fb59c77b629ebacac,
but variables name are still chan which might cause confused to reader.
Rename all places where "chan" to "chan_freq", which actually channel
frequency used. And alter miss APIs which still expect channel number.
Change-Id: I948cbad133a17093f49384b563966d2c53b51707
CRs-Fixed: 3033951
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
(cherry picked from commit 685e5c9a53)
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)
(cherry picked from commit f33a4f5a7d)
