If the first addba response frame is not sent out successfully for some
corner cases, the ba_status will be always set to DP_RX_BA_IN_PROGRESS.
The processing for next coming addba request frames will be in dead loop.
Which will block finishing the addba exchanging procedure.
Add checking with the return of lim_send_addba_response_frame, if failure,
will recover the ba_status to inactive status to give chance for next
coming addba request frame.
And also use pe_err_rl instead of pe_err to avoid excessive logging.
Change-Id: Ifc6adc166b5093742b34dd7d74924f9d54146ea4
CRs-Fixed: 2579510
1. Convert channel to frequency and use frequency
Regulatory API to check DFS status.
2. Skip dfs check for 6G channels.
Change-Id: I54b6d6a3ad25c192af4eec4e7f43932bada728b5
CRs-Fixed: 2580568
If the requested info field in beacon report request is present,
the driver tries to allocate memory for the target beacon report
EIDs from the number of requested EIDs received from the frame.
In SLUB disabled builds, the qdf_mem_malloc function doesn't
validate if the size provided is 0 and returns the value
ZERO_SIZE_PTR(((void *)16)) for the pointer. When this pointer
is dereferenced, it causes invalid address dereference.
Since the number of requested EIDs is directly controlled by the
frame sent by AP, validate this value before using it to allocate
memory.
Change-Id: Icbac3e952de0d7ae3144e9b319f2c51ccdf93ac5
CRs-Fixed: 2571480
Cleanup peer id from the callers of cdp APIs from
where the peer ID was passed, and use mac address
instead to identify the STA.
Change-Id: Ie6dcae77e959439a71c11b1a2fa0daddcaa6e719
CRs-Fixed: 2529822
psessionEntry->pSchBeaconFrameBegin is allocated with fix length
SCH_MAX_BEACON_SIZE. Do not copy the value to the buffer exceeding
psessionEntry->pSchBeaconFrameBegin.
Change-Id: I539692c01753b991a963b0416177cf5b474cfdf8
CRs-Fixed: 2577689
Currently the host driver checks if the BTM offload is enabled
via ini configuration and sets the BTM enabled bit of the
extended capabilities if BTM offload is enabled. The supplicant
decides if BTM is needed to be enabled or disabled based on the
PMF capability of the AP, since the STA is MBO certified.
When driver sets the BTM capability based on the btm_offload ini,
even if the AP supports MBO and doesn't advertise PMF, BTM is
honored by the MBO certified STA. This violates the MBO spec
that PMF is mandatory for MBO. So with the BTM capability
controlled by userspace, the BTM capability will be advertised
to MBO AP only if PMF is advertised as required for that AP.
Don't modify the BTM capability, and advertise it as it is
provided by the userspace. Firmware will drop the packet if
BTM capability is not advertised during initial connection.
Change-Id: I55b4e46a44011ce7a1982244df17ea32632f7ff3
CRs-Fixed: 2568311
There is a race condition while handling the below scenario,
1. NAN enable request is received from framework.
2. Policy mgr opportunistic timer expired and set hw mode
initiated to Single MAC mode in scheduler thread at
the same time
As the opportunistic timer handler doesn't have any info if
NAN enable initiated in DBS mode, it's configuring the hw
mode to Single Mac Mode just before NAN enable request is sent
to firmware. So the NAN enable request is sent to firmware in
Single Mac Mode which is not allowed by firmware.
NAN enable/disable is also similar to connection in progress
status in case of STA. So provide NAN enable/disable status
through hdd_is_connection_in_progress() to the opportunistic
timer handler. Opportunistic timer handler restarts the timer as
connection(NAN enable/disable) is in progress.
Also set hw_mode_change_in_progress before checking the
connection progress status. This is to avoid a possible race in
the below scenario,
1. NAN-enable sets the state but scheduler thread had read the
state just before that
2. NAN-enable read the hw_mode_change_in_progress just
before it gets set by scheduler thread.
Change-Id: I1a184c84520deb3f6ad1ec010a0fdefda96a5364
CRs-Fixed: 2566841
In case set key is sent to firmware and Roaming updated the session
before set key resp is processed in LIM, the limPrevMlmState will
be 0 and thus updating limMlmState to limPrevMlmState will result
in improper limMlmState, leading to sync issue.
So do not update the limMlmState in invalid state in set key resp.
Also update limPrevMlmState to limMlmState during roaming.
Change-Id: I96291e7c3eb34df8b5741745448c76cf63b1f200
CRs-Fixed: 2574731
Peer assoc command send to firmware updates peer params in
firmware ex. peer_new_assoc, peer_associd, need_gtk_2_way etc.
If RSN capability flags are present in peer assoc request of SAP and
P2P-Go peers, host updates need_gtk_2_way, need_ptk_4_way peer assoc
params to firmware.
If need_gtk_2_way, need_ptk_4_way params are not updated for RSN capable
peers of SAP/P2P-Go, firmware is not able to hanlde data packets(HTT)
before the key installation(WMI) is successful.
Change-Id: I0a24aab3ac4ff4ca061782f6a4d0ba62dd227b04
CRs-Fixed: 2575133
