In ACS, SAP phymode is updated as per the ACS request, but actual
phymode is calculated during start bss, which check the IEs etc.
In pe session the ht/vht/he/eht capability flags are not updated
as per the new phymode/dot11mode and thus even if phymode is
11ac, he flag is set and send he caps to firmware.
So once SAP is started, don't allow phymode update from ACS.
Also update the ht/vht/he/eht capability as per the new dot11mode
so that there is no mismatch in dot11mode and
ht/vht/he/eht capability flag.
CRs-Fixed: 3696205
Change-Id: I73e5f8ed0fbdc17b423bcba6fd3cbf2acc221fc2
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
Currently, if power constraint is advertised by AP then local
max tx power is calculated as per the rule defined in 9.4.2.13
(Power Constraint element) i.e regulatory power - local constraint
advertised by AP. As per the rule defined in 11.7.6
(Transmit power selection) transmit power for STA should be less
than or equal to the minimum of the local maximum transmit power
level and regulatory client maximum power.
Fix is instead of populating max_tx_power as diff of regulatory power
and derived local max tx power, populate max_tx_power to the MIN
of regulatory power and local max tx power to align with IEEE
standard.
Change-Id: I65fe4c9c6a4c7dd80540530c25b7ac2b1952633c
CRs-Fixed: 3740468
AP sends "Operating Mode Notification" IE having max supported
channel width (say ap operating bw) via beacon/probe response/
association/re-association response frame.
When datapath detect leaky AP, to enable/disable, userspace
sends ch_width update to host.
Step 1. If STA founds OMN IE present in above frame, host
sends update channel width (say new AP operating BW is
80 MHz) ind via WMI_PEER_SET_PARAM_CMDID with param id 4
(WMI_HOST_PEER_CHWIDTH).
Step 2: After ch_width update to 80 MHz in FW at step 1,
if host receives a update ch_width (to 160 MHz) request
from userspace on leaky AP detection disable. Host updates
its internal channel info structure with new BW and sends
update indication to FW via WMI_VDEV_SET_PARAM_CMDID
with param id WMI_VDEV_PARAM_CHWIDTH_WITH_NOTIFY.
In case, if host allows ch_width update greater than ch_width
present in OMN IE (ap operating bw), FW only disable leaky
detection but did not update Rx/Tx BW as per new ch_width as
ap operating bw is still 80 MHz (configured at step 1).
This leads to out of sync for value of ch_width in host and
FW and IOT issues.
To keep host and FW in sync with current AP's operating BW,
add a sanity check and reject request before updating internal
channel info structure in host if new ch_width (coming from
user space) is greater than ap operating bw present OMN IE.
Change-Id: Iedc1706e32b9e08512ca6c9b98162902cd32f976
CRs-Fixed: 3732557
With Change-Id: Iad3704d391058675e7d4ff6ffc419f74efa0c658,
wlan_reg_set_channel_params_for_pwrmode is removed for mlo get_channel,
2 GHz link CCFS may not filled correctly in ht/vht/he OP, wrong CCFS
is passed to kernel, regulatory check failed, disconnect will happen.
To fix it, add back wlan_reg_set_channel_params_for_pwrmode to
calculate CCFS0/CCFS1 correctly by primary freq and channel width.
Change-Id: Ie2467bccaa2998646428dd4e03173911dcc312cd
CRs-Fixed: 3734198
When enable irq failure is encountered trigger recovery with reason
code ENABLE_IRQ_FAILURE, this helps to recover the system in error
scenario.
Change-Id: I003f43fc9e3473cc939729700a03c8a8c790d34f
CRs-Fixed: 3724860
In the api extract_roam_frame_info_tlv(), the status code
for the MGMT tx packet is filled with tx_status value instead
of correct value.
Modify the api extract_roam_frame_info_tlv() to populate the
proper value of status code for MGMT TX packet.
Change-Id: Ia07b34ccc74f47bfac56bb1831e4ad1bce237d63
CRs-Fixed: 3741911
Force single link on 2 GHz:
mlo_support_link_num=1, mlo_support_link_band=1
Force single link on 5 GHz:
mlo_support_link_num=1, mlo_support_link_band=2
Force single link on 6 GHz:
mlo_support_link_num=1, mlo_support_link_band=4
Force 2 links on 2+5 GHz, force assoc link 2 GHz:
mlo_support_link_num=2, mlo_support_link_band=0x13
Force 2 links on 2+5 GHz, force assoc link 5 GHz:
mlo_support_link_num=2, mlo_support_link_band=0x23
Force 2 links on 5+6 GHz, force assoc link 6 GHz:
mlo_support_link_num=2, mlo_support_link_band=0x46
Change-Id: Id6f56421528a42aa7059693845fe71a206bded93
CRs-Fixed: 3722009
Currently host is updating CSA failure to fw for both
valid and invalid case.
To address this issue, don't send CSA failure for
valid CSA scenario.
CRs-Fixed: 3719460
Change-Id: I55a5afcde76acf306d027f29e3e6f92a28a8b050
With this change - I5e376cfaf798a228b4c1db45770fc0108d54052a
function call to send CSA status failure if CSA is not
required was removed.
Bring back this function call to send CSA status failure
and also send CSA status failure if any error is seen while
handling CSA param.
CRs-Fixed: 3659013
Change-Id: I4ca0bf9aa3be71659b8af9306a939a355d28d46b
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
For secondary (partner) VDEV, upon receiving peer delete request
from host, FW will immediately send peer delete response even
before the peer delete handshake with HW is completed.
This approach is brought in for two link association teardown
where starting a peer delete timer on partner link VDEV down may
result in timeout, if the assoc link peer delete is not received
before the timer expires.
To avoid this case, FW will only start peer delete timer during
primary (assoc) VDEV down and sends the peer delete response once
it is actually deleted in the system.
Now with three link support, if there is link switch on partner VDEV,
FW is sending peer delete response immediately (even if the delete is
still ongoing) to host and host is proceeding with MAC address update
and new peer create (with new link id) causing FW to assert as peer
delete on that VDEV is in progress.
Add new flag to indicate whether link switch in progress during
current peer delete WMI cmd. If this flag is set, FW will not send
peer delete response immediately but wait for the delete handshake
to complete with HW.
Change-Id: I81b2e15421fc59f54f6b1a33ef66a0cfdb908430
CRs-Fixed: 3663345
Currently if connection is in 5 GHz connection channel and 160 MHz
channel width, host always fills center frequency as 0 in response
of "get channel" request. This results disconnection triggered
by kernel.
Fix is to use proper center frequency present in vdev mlme
structure (vdev->vdev_mlme.des_chan->ch_cfreq2).
Change-Id: Ied59288b2047d9fd0e86d829a21890f4f031b320
CRs-Fixed: 3731341
Issue: In case of connection with MBSSID MLO AP,
host fails to update channel information in response
to “get_channel" request for standby link which leads
to disconnection triggered from kernel.
Fix is to update AP channel info for standby link in
case of association with MBSSID AP, while generating
probe resp from association response for standby link.
Change-Id: I1b3eba22a34bd4b83f2f66c9ca847c926a921f42
CRs-Fixed: 3726019
Correct parameter of policy_mgr_allow_concurrency_csa in API
lim_is_csa_channel_allowed.
Change-Id: I7bd4992c36dad9a07e8f6cee071e74fb4d22f58c
CRs-Fixed: 3717381
After NAN PASN pairing, followup action frames are exchanged between
the paired peers and are forwarded to userspace.
Currently, when target sends the action frames on NAN VDEV, driver
drops the frame due to following reasons:
1. driver is not able to find the adapter by destination for the
NAN opmode.
2. For "ACTION_CATEGORY_PROTECTED_DUAL_OF_PUBLIC_ACTION", WEP bit
is set, so these action frames have additional bytes for CCMP
header after mac header. Thus, when kernel tries to compare the
action category, then it drops the frame.
So, to fix this, exempt the adapter check and strip the CCMP header
while sending the frame to userspace.
Change-Id: I9a79b7a6dee6a5c3df86d28424673f8e5776e147
CRs-Fixed: 3694362
Currently, host driver receives the keys from the userspace and
caches it in the VDEV object and then sends it to the target. But
during SSR, driver destroys VDEV and hence keys are deleted.
After SSR, driver need to send the keys again to the target as
keys are destroyed from the target as well. But currently, keys
are not available in the driver because keys are destroyed with
VDEV deletion.
So, to fix this, send crypto keys to target for SAP after SSR
and clear the keys on SAP down.
Change-Id: Icdfc93876ab79304b9dc96f9fce16553582a0d18
CRs-Fixed: 3663712
Currently, host driver sets beacon protection flag in the vdev
during SAP bring up and send it to the target with beacon template.
But while SSR, driver destroys vdev and hence beacon protection
flag is reset and after SSR, driver does not set the beacon
protection flag. Thus, target does not enable beacon protection
and does not send MIC IE in the beacon frame.
So, to fix this, set the beacon protection flag in the vdev while
restarting the SAP.
Change-Id: I14f64463ed0d2e66a305160dcc7c810012dde2fb
CRs-Fixed: 3636385
Currently, if power_constraint_abs is 0 and tpe_ie is
not advertsied by AP or skip_tpe_consideration is false
then diff of regulatory power and local_constraint is
updated to FW as Tx power which may cause issue in case both
powers are same.
Fix is set regulatory tx power in case regulatory tx power
and local constarint is same.
Change-Id: If897684d33f163ae7c879122f1c7be90a58412cd
CRs-Fixed: 3726862
Currently there is no support to check 6 GHz channel
information in the device console.
To address this issue add an API to fetch 6 GHz channel
information for given power type.
CRs-Fixed: 3723735
Change-Id: Ie999e0b2ebfa45ca33269d64b30bfc162cc283d6
Currently as part of the linkdown detection in the RTPM resume sequence
host cleans up below:
a. Intimating the kernel for the pending scan complete
b. Setting the wmi flag to make sure there is no CE access
to send the wmi commands.
c. Notifying the IPA to disable the IPA pipes.
Performing operation c) involves accessing ipa doorbell register
by doing soc force wake resulting in internally again calling
runtime_resume leading to deadlock.
Initiate ipa cleanup as part of the shutdown sequence rather than
early cleanup.
Change-Id: I1edb44fbdefad3c21bd60a42baa285705a7ed4a9
CRs-Fixed: 3719988
Currently, Host driver is enabling CTS2SELF for most of the qcom
AP (8CFDF0) and It will try to send the data in all the cases by
not waiting for RTS-CTS and in some cases if it does not win the
medium, it will take around 4x time than normal RTS-CTS(in case
of failure) leading to throughput issue.
This change is to disable CTS2SELF for OUI : 8CFDF0
Change-Id: I4becf0d1c093f458868634a9636d2e14d60a9f37
CRs-Fixed: 3689771
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
