Add NULL check for twt_psoc_obj pointer to avoid NULL pointer
deference in function wlan_twt_get_pmo_allowed().
Change-Id: I1e5c24b843845c89e8779c5e69433c41c2311829
CRs-Fixed: 3626932
SAP restart happens when a concurrent STA comes up in the
same band. Currently, the new bw is calculated based on channel
supported max bw. If SAP moves from one 6 GHz channel to another
6 GHz channel, the new bw would be calculated as 320 MHz even if
the current SAP operating bw is 160 MHz. But SAP bw should be
limited to current operating bw as it might have got downgraded
to 160 MHz as part of sap_bw_update algo.
Considered current operating bw when SAP restart happens as part
of sap_bw_update.
Change-Id: If310b0ad9f914b438ae3c1968ca8f1ee26d57589
CRs-Fixed: 3637263
Disable puncture in US LPI mode per FCC request.
If bad FCC AP is detected, send WMI_VDEV_PARAM_CHWIDTH_WITH_NOTIFY with
reduced bw after setkey is done.
Also add the same bad FCC AP detection logic in HDD where bw increase req
from SS framework is handled.
When handle beacon update, also FCC AP detection logic to avoid wrong
channel switch.
If the AP removes or reduces puncturing pattern in new beacon, send
WMI_VDEV_PARAM_CHWIDTH_WITH_NOTIFY with increased bw.
For roaming case, after roaming, host will receive new beacon with new
bpcc, same as beacon update, use the same bad FCC AP detection logic and
send WMI_VDEV_PARAM_CHWIDTH_WITH_NOTIFY with updted bw right away or after
setkey is done (in case of hybrid roaming like OWE).
Change-Id: I6e85de879575d5c0a1960527f9018b4b33bf18d6
CRs-Fixed: 3631634
If WLAN_SUPPORT_TWT or WLAN_TWT_CONV_SUPPORTED not defined, FEATURE_SET
is defined, function wlan_twt_get_feature_info() will be called by
wma_set_feature_set_info(). However wlan_twt_get_feature_info() is not
declaration.
Change-Id: I31b1e5c6520adf4dc495356d45fc89f481c9962e
CRs-Fixed: 3637229
Customer framework may set active num 2 to driver for ML STA.
If the two enabled links are MCC, don't not force active 2
links.
If current enabled links are < 2 and there are concurrent
connections present, force active 2 links, which may be
conflict with concurrent rules, reject it.
Change-Id: Ifd37b7a3fb66e77954b26dad13f3f4244d114dea
CRs-Fixed: 3644404
Currently, if standalone SAP is operating in 6 GHz
and SET_FCC_CHANNEL 0/2 command is issued, as a result
complete 6 GHz band gets disabled and host triggers
SAP CSA to a new 2.4 GHz frequency.
In this path CSA is getting triggered for the second
time and as SAP is operating in a 2.4 GHz frequency
host does CSA to a new 5 GHz channel.
To address the issues,
1) Add logic to do SAP CSA to best valid channel if current
channel is disabled.
2) Invoke wlan_reg_recompute_current_chan_list from
policy_mgr_update_connection_info only for STA
and P2P client.
Change-Id: I3dd2b4075d8cd9e73735317ac3a5f7fb08635548
CRs-Fixed: 3603739
As per spec if Wide Bandwidth Channel Switch (id 163) and Bandwidth
Indication (id 164) sub element present in channel load request,
Host should send same sub element ids with same values as in request
in channel load response.
Change-Id: If419c1e2ac694ee5d2da301e404085bb3fc68674
CRs-Fixed: 3629125
AP can send channel width and related information via below OPIE:
1. Wide Bandwidth Channel Switch (Subelement ID 163)
2. Bandwidth Indication (Subelement ID 164)
Trigger wide band scan as per values present for above IEs present
in channel load request.
Change-Id: I013389972f0f72395488a2405e4b0dcbff39dd42
CRs-Fixed: 3629109
LL_LT_SAP supports MCC with sta interface and does not
support SCC with any interface. Add a logic to force
MCC if any STA comes up in SCC with the LL_LT_SAP interface.
This change adds below logic to force MCC on LL_LT_SAP:
1. If STA is present and LL_LT_SAP comes up, select MCC
channel in ACS and make sure to bring LL_LT_SAP on MCC channel.
2. If LL_LT_SAP starts without ACS in SCC channel, then
overwrite this SCC channel with MCC channel.
3. If LL_LT_SAP is present and STA comes up in SCC with
LL_LT_SAP, move LL_LT_SAP to an MCC channel or on different
MAC channel.
4. If LL_LT_SAP and STA are present in MCC and STA receives
CSA on LL_LT_SAP frequency resulting in SCC then move
LL_LT_SAP to MCC frequency.
5. If LL_LT_SAP and STA are present in MCC and STA roams
to LL_LT_SAP frequency resulting in SCC then move
LL_LT_SAP to MCC frequency.
Preference to lower 5 GHz will be given followed by
standalone MAC frequency then MCC frequency.
Change-Id: I7f4380ed7d726112bbc2aa94a50ffbb5d8b6036d
CRs-Fixed: 3640669
Currently, host driver only validate the first vendor IE with a matching
OUI was considered, leading to potential oversight. Now the updated
logic thoroughly checks and validate each vendor IE with its
corresponding OUI data.
Change-Id: I3c5444373e355425adbf6e802591b68b74de598f
CRs-Fixed: 3640771
Enable CTS2SELF for specified APs that has below OUI:
Currently, STA initiates an RTS before sending a data packet and expects
AP to send CTS. The data packet would be sent out only if CTS is
received. But some APs may not respond for the RTS and station would
retry RTS frames continuously till max retry threshold is reached. It's
observed that few commercial APs have this behavior and there is no use
of sending RTS to such APs.
Identify the vendor OUI of such APs, send a self-CTS and send the
data packets. This can avoid RTS spamming also.
Default OUIs: (All values in Hex)
OUI 1: 000C43
OUI data Len: 04
OUI Data : 07000000
OUI data Mask: F0 - 11110000
Info Mask : 21 - 0010 0001 Check for OUI and Band
Capabilities: C0 - 1100 0000 Band == 2 GHz || Band == 5 GHz
OUI 2 : 000C43
OUI data Len : 04
OUI Data : 03000000
OUI data Mask: F0 - 11110000
Info Mask : 21 - 0010 0001 Check for OUI and Band
Capabilities: C0 - 1100 0000 Band == 2 GHz || Band == 5 GHz
OUI 3 : 8CFDF0
OUI data Len : 05
OUI Data : 0101020100
OUI data Mask: F8 - 11111000
Info Mask : 21 - 0010 0001 Check for OUI and Band
Capabilities: C0 - 1100 0000 Band == 2 GHz || Band == 5 GHz
OUI 4 : 8CFDF0
OUI data Len : 05
OUI Data : 0109020300
OUI data Mask: F8 - 11111000
Info Mask : 21 - 0010 0001 Check for OUI and Band
Capabilities: C0 - 1100 0000 Band == 2 GHz || Band == 5 GHz
Change-Id: I98706d997587b712f6e830a43143645ec2e1b1c5
CRs-Fixed: 3637059
For Roam result connectivity logging, bssid is not
printed for No ROAM case when connected to a MLO AP.
Expected Log when connected to MLO AP:
[Kernel Timestamp][ROAM] RESULT NO_ROAM
bssid=??:??:??:??:??:?? [Vendor Extra data]
Observed log when connected to a MLO AP:
[Kernel Timestamp][ROAM] RESULT NO_ROAM [Vendor Extra data]
Add "is_mlo" parameter to be sent in order indicate
userspace the whether the log belongs to MLO AP.
Modify BSSID to bss peer mac of assoc link to be
printed as part Roam Result No roam log when
connected to a MLO AP
Change-Id: Ia9acc1cf7c5377b595771f2718edd9dbf8f45367
CRs-Fixed: 3638160
Get weight of selected frequencies list of LL_LT_SAP. This will
be used by caller api to select the best frequency for LL_LT_SAP.
Change-Id: I066aea0591f8e65a61c53586d68aa753b081e3db
CRs-Fixed: 3640864
Currently in dp_get_transmit_mac_addr(), VDEV objmgr is referred without
incrementing the VDEV reference count, because of this there could be a
potential kernel NPE when VDEV deletion and dp_start_xmit() are in race.
Since taking VDEV references is discouraged in the per packet path due
to locking, a simple VDEV NULL check should solve the problem considering
the fact that DP VDEV object is already protected by
dp_intf::num_active_task.
Change-Id: I52229dc589feada1b1ffb261468915df88d1e486
CRs-Fixed: 3625809
In advance logging the total freq is shown as NUM_CHANNELS(102)
for scan type ROAM_STATS_SCAN_TYPE_HIGHER_BAND_5GHZ_6GHZ or
ROAM_STATS_SCAN_TYPE_HIGHER_BAND_6GHZ.
Fix is to send max NUM_CHANNELS number of channel only if
scan type is ROAM_STATS_SCAN_TYPE_FULL.
CRs-Fixed: 3637662
Change-Id: I2abb01d54d7ac2a38879d05d5070960df4b4e75a
For mcc to scc switch config QDF_MCC_TO_SCC_SWITCH_WITH_FAVORITE_CHANNEL,
if GO is on 5/6 GHz, SAP is not allowed to active on 5/6 GHz, SAP should
move to 2.4 GHz, If GO is not present on 5/6 GHz, SAP needs to move to
5/6 GHz user configured frequency.
Change-Id: I4ba99460fe5656440c6010afcb0ebbc9c0f4de76
CRs-Fixed: 3624311
For MLO connectivity log, T2LM status logs shows
tid_ul and tid_dl as NONE for default TID mapping instead of
ALL. T2LM status logs is also displays the T2LM status
for link that is not associated with the MLO connection
with status '1'
Expected log for default TID mapping:
[Kernel Timestamp][MLD] T2LM STATUS band=? tid_dl=ALL
tid_ul=ALL [Vendor Extra data]
Observed log for default TID mapping:
[Kernel Timestamp][MLD] T2LM STATUS band=? tid_dl=NONE
tid_ul=NONE [Vendor Extra data]
Modify the api wlan_populate_tid_link_id_bitmap() to
check for default mapping. If a given T2LM has default
mapping, tid_ul and tid_dl is populated with default value
in order to be printed as ALL in userspace.
Change-Id: Id23052da6b6fd0a3a4bec3a9f9d3d4979bab3296
CRs-Fixed: 3636383
For MLO setup connectivity logging, the Band info is
not included for the standby links, resulting in logging
in an inappropriate format.
Expected Log format:
[Kernel Timestamp][MLD] SETUP band=? status=? bssid=?
link_id=? [Vendor Extra data]
Observed Log for standby link:
[kernel Timestamp][MLD] SETUP status=1 [vendor extra data]
Modify the MLO setup connectivity logging to log for
the links associated with the connection.
Change-Id: I2a8857ed123faf3c69c2a406eec506c6ed8c454b
CRs-Fixed: 3636343
Rename policy_mgr_get_lt_ll_sap_freq to
policy_mgr_get_ll_lt_sap_freq and policy_mgr_get_ht_ll_sap_freq()
to policy_mgr_get_ll_ht_sap_freq()
Change-Id: I740d6dfc75008b36861c8e90d6e365ebc6d8a054
CRs-Fixed: 3637126
At present, the tdls_handle_link_unforce may be invoked multiple
times even though the link is unforced previously. That causes
sending set link command unnecessarily.
Fix by checking the current link force state to avoid setting link
again.
Change-Id: I1e75fb713b17e6efd8143ebbc5ce59aed0409061
CRs-Fixed: 3640207
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
Add callback mlme_vdev_reconfig_notify_standby to cld code to
handle standby link removal.
For standby link, it is going to be removed by AP, so don't
start link removal timer for it. Force inactive it to avoid
link switch to it.
Change-Id: Ib28e6b043f582e0fff2f4702e32ff222fc3428d3
CRs-Fixed: 3629633
Offload TX data packets such as ARP response, EAPOL during roaming are
sent by firmware through HTT msg if packet capture mode is enabled.
Whenever any such packet is received via HTT msg, host inspects the
ether type of the packet and matches with the TX filter set by user
via vendor command. If the ether type matches with the TX filter set
by user, then host forwards that packet to packet capture mode interface
otherwise, drops it.
To inspect the ether type of any packet, host uses generic API which
expects packet to be in SKB format. Currently, whenever any offload
TX data packet is received in HTT msg, host wrongly passes the buffer
received in HTT msg instead of SKB to APIs expecting SKB buffer.
This leads to undefined behavior.
So, to fix above issue, whenever any offload TX data packet received,
first allocate the SKB, copy the payload buf of HTT msg which is TX
packet to SKB data and then pass that SKB to the generic APIs to get
the ether type.
Additionally, this change fixes the minor logging error.
Change-Id: If09d49d8a1dcc04ca81454fc262bb5789a0f56be
CRs-Fixed: 3613594
User can set following combination of configs in vendor command for
packet capture mode:
1. PKT_CAPTURE_MGMT_CONNECT_NO_BEACON: to receive all mgmt frames but
no beacons
2. PKT_CAPTURE_MGMT_CONNECT_NO_BEACON + PKT_CAPTURE_MGMT_CONNECT_BEACON +
connected_beacon_interval : to receive all other mgmt frames and only
connected SSID beacons at particular intervals
3. PKT_CAPTURE_MGMT_CONNECT_NO_BEACON +
PKT_CAPTURE_MGMT_CONNECT_SCAN_BEACON: to receive all other mgmt
frames and beacons only during scan.
But with current condition connected SSID or scan beacons config will
not be sent to FW as host checks for PKT_CAPTURE_MGMT_CONNECT_NO_BEACON
config only. Also, on reception of any beacon, host checks for only
PKT_CAPTURE_MGMT_CONNECT_NO_BEACON and if it is set, host drops the
beacon which is wrong.
So, enhance the conditions to send config to FW as well as
remove the condition on reception of any beacon so that connected SSID or
scan beacons are forwarded to packet capture interface when connected
beacon interval config or PKT_CAPTURE_MGMT_CONNECT_BEACON or
PKT_CAPTURE_MGMT_CONNECT_SCAN_BEACON is set by user in vendor command
along with PKT_CAPTURE_MGMT_CONNECT_NO_BEACON config.
Change-Id: I246b175f1c88ed45214527880ba14cdc17bf8206
CRs-Fixed: 3604708
Currently, host driver takes vdev reference while sending coex
logging config to the target. If user issues logging config
command before creating vdev, then vdev will be null and
dereferencing it causes crash in driver.
To fix this, add null check for vdev just after taking reference.
Change-Id: I91d7834ecdc506a7b7a20b38a7c8150bd22adb72
CRs-Fixed: 3637112
When scan is complete, tdls notifier tries to update the
tdls_current_mode for all available TDLS & P2P vdev. This causes
the TDLS current mode to enabled wrongly and further add peer gets
honored for P2P Client vdev in STA + P2P client concurrency.
So avoid changing current mode for P2P cli when STA vdev is
present.
Also add check for P2P CLI mode in tdls_check_is_tdls_allowed()
to avoid tdls commands going on P2P client vdev.
Change-Id: I681de9781a4892e307681da5699ca7b30f8f9651
CRs-Fixed: 3626695
If LL_LT_SAP is already present and if STA tries to
come up on same mac, then it may result in data loss
on LL_LT_SAP as STA will need ROC on the connection
channel for some time, to avoid these data loss during
STA connection, add logic to switch the bearer for LL_LT_SAP
data to non-wlan and once connection completes, switch back
the bearer to wlan.
Change-Id: I7ace6c6f4f41548ec112882dc81be6c6b5a4eae0
CRs-Fixed: 3627656
MLD is applicable for infrasture modes(STA/SAP) and is mandatory to
operate in 11BE for these modes. NAN/NDI(NDP) may want to use EHT
rates and it's not mandatory to support MLO.
Currently, host driver sets vdev dot11mode as 11AX when MLD address
is zero. But this is applicable for STA/SAP only. So, exempt NAN/NDI
modes from this dot11mode downgrade operation to allow these to use
EHT rates.
Change-Id: Ie43811eb7bd12dbf286617cebe194ced8c28c3f0
CRs-Fixed: 3635961
Userspace can dynamically modify association BW and as part of
disconnect need to reset the BW to original value, if not the
next connection will might happen with downgraded BW.
Currently the restore is happening on deflink VDEV instead of
actual disconnecting VDEV.
Fix this by changing function argument to accept link info
pointer in HDD adapter of that corresponding VDEV.
Additionally, the driver capability for 6 GHz-320 MHz is not
properly restored and further connections to 320 MHz are
happening on 160 MHz.
To fix the 160 MHz downgrade, use original EHT capabilities in
global MAC context instead of using modified EHT cap where
320 MHz support got reset on userspace dynamic BW update.
Change-Id: If2badb0a234f45d57dc186729bc529137d7a5131
CRs-Fixed: 3628940
Band is not printed for the neighbor report request/response logs.
Fill band info for neighbor report request/response frame
logging event from the wmi_neighbor_rpt_info TLV
wmi_roam_neighbor_report_info->neighbor_report_detail[Bits 26:24]
for both the single TLV and multi TLV case.
This band info indicates the band of the link over which the
frame was transmitted/received.
Change-Id: I2c6671ffc600cba571c666f01fa07fb3d89eb6a8
CRs-Fixed: 3626819
In api wma_roam_update_vdev(), peer frequency is set before
peer setup which results in band info to be missing in
Datapath connectivity logs after roaming.
Modify api wma_roam_update_vdev() to set peer frequency
after peer setup in order to print band info for
datapath connectivity logs after roaming.
Change-Id: Idc2d6c1cda072f576c26964a0fc0c418760608f4
CRs-Fixed: 3629093
Based on new requirement, add changes to send the vendor event
send audio transport switch request and also add changes to process
the response received as a vendor command.
Change-Id: I4b8804c9021ea8807ca785f81f3df431690029fb
CRs-Fixed: 3626954
Based on the new requirement, host driver needs to send the audio
transport switch request from host driver to user space, to
support this requirement, register os_if callback function with
bearer switch state machine
Change-Id: Ib94ff4d9876e79d984401262253602c975b0fb1e
CRs-Fixed: 3626952
If "override_ht20_40_24g" ini is set, then both
connection and roaming should not happen to the
2.4 GHz BSS in 40 MHz.
Based on this ini, update the channel widthset
capability for the 40 MHz in the HT/HE/EHT cap
IEs after connection. Similarly, after disconnect
reset the capabilities back to default self cap.
Change-Id: I6f7e019f4a8f194a703b503741a57f22509a5d3d
CRs-Fixed: 3623042
Currently, SAP+STA and STA+SAP concurrencies are considered for
320 MHz SAP bandwidth downgrade to 160 MHz/upgrade to 320 MHz
from 160 MHz.
But during MLO link switch, a link gets disconnected and a new
link connection is started. The new link might be of 6 GHz, which
makes the sap_bw_update algo thinks that new connection/candidate
is 6 GHz and it can coexist with 320 MHz with SAP. This drives the
sap_bw_update algo to upgrade to 320 MHz, which starts policy mgr
opportunistic timer. This blocks the link switch(new link
connect operation). But this is not correct as a link is already
present and new link gets added.
Add a condition to check current bandwidth of the SAP and go for
downgrade only if the current bw is 320 MHz.
Also, cleanup the code which restarts policy mgr opportunistic
timer explicitly as timer is anyway started post
connect/disconnect completion. Introduce a new reason
POLICY_MGR_UPDATE_REASON_TIMER_START for this purpose.
Change-Id: Id49632b385cd3554b67be11e02e4e45ce094f0b4
CRs-Fixed: 3632270
Add changes to init bmiss timeout values with
half of CFG_LFR_BEACONLOSS_TIMEOUT_ON_WAKEUP
and CFG_LFR_BEACONLOSS_TIMEOUT_ON_SLEEP
if CONNECTION_ROAMING_CFG is set.
CRs-Fixed: 3633348
Change-Id: If2d4a3975c86e3aa50ee98117795ce7c77b0460c
Add changes to handle audio transport switch events in different
states of the bearer switch state machine.
Change-Id: I07568b3c3ccc5877d1e6f46ae5bf12afd3af3ec2
CRs-Fixed: 3626950
When connected 320 MHz AP, use SET_MAX_BANDWIDTH set to 160 MHz,
then GET_CU_SUB_CBW20, driver should report all 320 MHz channel
CU info, so we need record center freq2 for 320 MHz at the time
of initial connection.
Change-Id: I8b8ed049926caa31bfac3c702434b68e5f5a26ae
CRs-Fixed: 3629227
Add check's in following cases if STA does
not support T2LM negotiation.
1. Do not send T2LM wmi when T2LM IE is present in
beacon or probe response or assoc response.
2. Skip T2LM candidate validation during connection.
3. Drop T2LM action request frame.
CRs-Fixed: 3610173
Change-Id: I9d45bd005675250f6739ce897ab5b482f27f1417
Add ucfg wrapper API over the existing MLD ID get/set APIs
that will be invoked in HDD/OSIF.
Change-Id: I07d2e661c7e8129e54a0449f958749648c25e4ac
CRs-Fixed: 3621169
Current SAP is unable to bringup 2 vdevs and connect 2-link MLO.
To unblock validation we simulate 2link connection on SAP.
Changes are as Follows:
- Add MLD caps to Beacon Frame
- Add RNR IE to Beacon/Probe Rsp Frame
- Add Per-Sta Profile to Probe Rsp Frame
- Add Per-Sta Profile to Assoc Rsp Frame
Change-Id: Ice2d3557e00426ead044ec6b4b507746db4148d4
CRs-Fixed: 3591637
Currently for rx packet delivery whether it is from monitor mode or
local packet capture path, is handled in NAPI softirq context and
netif_receive_skb() is called without disabling local bh.
In case of local packet capture, for tx packets after the tx_mon tlvs are
parsed, ppdu queue is handled in workqueue context and nbuf is passed
up the stack in rx_mon callback. Because the nbuf push type NAPI is used
this is causing 'BUG: using __this_cpu_add() in preemptible' for
nbuf coming from tx_mon workqueue context.
Fix is to identify the appropriate nbuf push type based on the context.
if caller is from softirq context then use DP_NBUF_PUSH_NAPI or
if caller is from non irq context use DP_NBUF_PUSH_BH_DISABLE.
Change-Id: I71b3be70febed1c077e7d4d36274a4805a33b722
CRs-Fixed: 3631536
When FW includes new eMLSR hardware modes in
service ready indication host should be able to
store and update capability information.
Add support in policy manager to handle new HW modes
for eMLSR.
CRs-Fixed: 3618543
Change-Id: I575b93c85940e4d6469fbd038ce90123750729ff
In case of NAN, if the tput levels are between mid to high range then
apply next SNOC voting level.
Change-Id: Ifb77c8f627b5fc565767aac4baa3629b12a37582
CRs-Fixed: 3611715
