If SAP start on 6 GHz, client associate request will not have HT
capability, so sta_ds->ch_width update too late in function
lim_update_sta_ds, but it is used by lim_populate_matching_rate_set
and lim_populate_eht_mcs_set, it lead to update 20 MHz eht mcs set
and caused other bandwidth eht mcs set not update and keep 0 finally
pass it to target. It will impact TX performance a lot.
Move forward functions to update sta_ds->ch_width for 6 GHz.
And update a typo of bw_160_rx_max_nss_for_mcs_10_and_11, it write
as tx.
Change-Id: I1c1cbe1daf8bfdf163d73c7aba5e7335e99e8157
CRs-Fixed: 3863495
currently if bss_max_idle_period is greater than default configured
value of sta_keep_alive then same value will be sent to FW. If any
AP sets bss_max_idle_period to greater than sta_keep_alive then reset
is not done on vdev stop due to which same value will be set for
new connection.
Fix is to not to send bss_max_idle_period as time period limit because
same value is updated in bss_max_idle_period of interface. So, default
configured value of sta_keep_alive_timer is required to be passed for
threshold validation. value reset is required once vdev stop happens
to avoid same keep alive even if bss_max_idle_period is not advertised
by AP.
CRs-Fixed: 3861815
Change-Id: I457a436a4c8a561600e93b3d5deaa0399fbd2c7d
As per current design, peer conflict detection logic allows
a peer with particular mac/mld to be created as long as
the ml dev context is same. However, this causes issues
for ML-STA wherein 2 different peer ML-STA could have same
mac address. In this case, the second peer creations should
be disallowed.
To fix this, skip the mac/mld conflict checks on the ml-dev
context of the ML-SAP and handle it separately.
In addition to the current checks add the following checks
for ML-SAP and reject the peer creation if:
a) MLO peer exists for the link mac of peer with different AID.
b) MLO peer exists for the MLD mac of peer with different AID:
c) If the associating client's MLD != one of the link mac address
and there is an MLO peer with different AID.
Change-Id: I75935e2362d6db1411c6a67f1e9db35f3b3963f2
CRs-Fixed: 3719956
Currently, STA do CSA on the given channel width, provided by the
AP. But sometimes in the fault conditions, AP provide channel width
which is not supported by STA.
For example, in this case, STA is connected with AP in 11AX mode.
During CSA, AP provides the 320 MHz channel width. But STA supports
maximum 160 MHz in 11AX mode and thus, it leads to disconnection.
So, to fix this, add check for dot11mode and restrict the channel
width to the maximum allowed channel width for the corresponding
dot11mode.
Change-Id: I29593db740afe6b23ea334bb499c46377868cd9b
CRs-Fixed: 3848635
STA is associating on 20 MHz, whereas the SAP is operating
in 80 MHz. During the rate set preparation for the client,
instead of intersecting the 20 MHz MCS(sent by the peer in
EHT Cap) with the self cap of APUT, the validation happens
for the 80 MHz MCS set of STA and APUT. However, while sending
peer assoc to firmware, the 20 MHz MCS rate set of the client
is being used.
To fix this, generate the EHT MCS rate set of the client by
intersecting the MCS params corresponding to the STA's assoc
channel width.
Change-Id: I1baf79a3705922531d2ff3db8199633a35793129
CRs-Fixed: 3849051
Post link switch the order of VDEV to link info in OSIF
changes and for the next connection, need to restore the
order. This restore currently happens when there is set
MAC address update before every connect, but however if
set MAC address is not received then the unrestored order
of VDEV will be used during connect which can be undesirable
in certain cases.
To avoid going ahead with connection with unrestored VDEV
mapping, make sure this is reset to proper order via
notifying HDD once assoc VDEV connect request becomes active.
Change-Id: Id3ba542820f7c2bc9c721a49735738df00b6e5d5
CRs-Fixed: 3827913
Sending deauth on one of the links in MLO connection will result
in removing anchor link in FW and driver shall silently remove the
next link without initiating another deauth. For this reason the
status of MLO peer is set to DISCONN_INITIATED on sending first
deauth frame so that subsequent links do not send again.
The MLO peer context holds the list of all object manager peers for
that MLD connection and failure to add to the context shall result
in termination of connection. Currently the failures are not handled
and the object manager peer is not having any MLO peer context and
this results in sending deauth frame on both the links.
Handle the error of peer create and MLO peer attach on roaming
to abort the roam sync.
Change-Id: I4d5a766b673b36edb44d19065237aa35ff7d5f1d
CRs-Fixed: 3837890
Fix compilation failures caused by type mismatch
between format and argument.
Fix some kernel-doc errors.
Change-Id: Id55c19eff1dd62102feffac1785b5fe825555fde
CRs-Fixed: 3805434
Currently if STA + LPC is running and new interface is brought up
in case of monitor_mode_concurrency ini enable case only LPC
is terminated. if monitor_mode_concurrency ini is disabled LPC
will not be terminated and LPC will continue to run in concurrency
scenario.
To fix the issue remove check for monitor_mode_concurrency and delete
LPC interface directly in concurrency scenarios.
CRs-Fixed: 3849400
Change-Id: Ie0d7f6f942b973e5fc7944430cf5aaa9b0bdf538
Use mgmt_txrx_frame_hex_dump to dump mgmt frame and optimize
frame dump and logs
Change-Id: I56f244fecfa2602c6b763f5734d36199b8c3f165
CRs-Fixed: 3838935
When roam happened in F/W and send roam stats to host driver,
host driver send these roam stats info to user space by event
without cache them.
Change-Id: I772c0a5035896715204f6eee277090ed1f33e97c
CRs-Fixed: 3790270
A race between cfg80211 ap stop and wiphy system suspend can lead
to either DPM WD or serialization VDEV disconnect active command
timeout since scheduler thread gets suspended as part of wiphy
suspend and both cfg80211_disconnect and wiphy suspend/resume acquire
RTNL lock.
To address this race condition avoid ap stop when wiphy
suspend is already completed since scheduler thread gets suspended
as part of wiphy suspend and it can't process ap stop.
Change-Id: I5792b524a27326ca9e020600db2b82e16cc7ea96
CRs-Fixed: 3834305
As part of 802.11be_D4.1 new param Ext Max Tx power is added
in TPE for 320 MHz and while packing the TPE IE in beacon frame
max tx power will be calculated based on max_tx_pwr_interpret.
And max_tx_pwr_interpret is filled irrespective of channel bandwidth
which leads to TPE IE length more than 9 for legacy case also.
Pack tpe ie manually to consider max_tx_pwr_interpret to calculate
tx power only for 320 MHz and legacy method for less than 320 MHz.
CRs-Fixed: 3750566
Change-Id: Ibacb634c24d08886ccf2848a8dc8e2ecdf6b247a
When driver mode is changed from other mode to mission mode, regulatory
update will happen, flag is_regulatory_update_in_progress is set.
country_change_work thread is used to clear the flag, if other threads
holding OP lock, the work thread exits without clearing flag
is_regulatory_update_in_progress. SAP start is
blocked until timeout later.
To fix it, if failed to update regulatory, country_change_work thread
clears flag is_regulatory_update_in_progress too.
Change-Id: I97440ec14e5153f44a6a1b6028eb8dd9e75ccb5d
CRs-Fixed: 3831855
wma_self_peer_remove call wma_remove_peer with
del_vdev_req->self_mac_addr as peer mac address.
But wma_remove_peer still uses the pointer of self_mac_addr
to reference it after call wmi_unified_peer_delete_send.
Potentially the peer deleate event wma_peer_delete_handler
may come first and free the del_vdev_req memory.
In that case wma_remove_peer may access invalid memory,
wma_remove_objmgr_peer may fail to release the ref count on peer.
Fix by save del_vdev_req->self_mac_addr to local stack to
use it after send wmi_unified_peer_delete_send.
Change-Id: Idd9d765a13287144917d4774287da8b7ec4ea7ed
CRs-Fixed: 3815077
Change maximum value for SET_KEEP_ALIVE_INTERVAL_LEGACY command
to 255 as per new requirement.
Change-Id: Icfb7ec4700131685eb17feba4bf68e82bb2b6316
CRs-Fixed: 3830310
