Currently, PCL returns all 5 GHz channel and SCC channel for SAP
when an ML-STA is present. But this may lead to a case
where the CSA request might be for a DFS channel which needs CAC.
This needs a dedicated mac and ML-STA can't move to MLMR in such
cases. When firmware attempts to move STA to MLMR from MLSR,
firmware asserts as the other mac is occupied by DFS SAP for
CAC operation.
So, allow CSA to a DFS channel only if the channel is present in
PCL list as it covers the supported channel list anyway. Fix
policy mgr table entries also by allowing SCC channels only.
Change-Id: I079fa6beea97fcd7c926ad4bd2bf928a0442d146
CRs-Fixed: 3484572
During wlan0 vdev0 roaming, before roam sync received, 2nd sta wlan1
vdev2 connect req came, disabled RSO of vdev0, so vdev0 roam aborted, and
disconnected.
To fix it, serialize roaming disable during connect too, don’t disable
roaming of other connected sta until serialization allowed in
wlan_serialization_activate_cmd ->cm_connect_active
Change-Id: I64eca8bc4de27e0b0afd0af2af3e83f3874fcecd
CRs-Fixed: 3515381
In ML-STA + STA concurrency currently, when legacy STA is being
brought up the RSO of existing ML-STA is stopped and not re-enabled
later. Therefore, ML-STA cannot roam after concurrent STA bringup.
Modify the RSO enable logic for ML-STA as follows:
1. All the links should be up.
2. The vdev should be an assoc vdev
3. The if_mgr_enable_roaming should happen on an interface other
than ML-STA links.
The condition-3 prevents enabling RSO for the assoc vdevs when the
link vdev connect complete event is processed.
Change-Id: If86a81b99d18eaa99a25e419c85197d9d0d826ac
CRs-Fixed: 3493333
When roaming from OWE SLO to OWE MLO, host considers it as SLO roaming,
although FW sends both assoc link and partner link information to host.
Currently host adds partner link to sta_ctx->wlan_connected_links in
mlo_roam_update_connected_links, since it already receives partner
link information from FW. Then RSO fails to translate to stop state in
cm_fw_roam_complete because partner link is not up.
To make RSO state translation work, host need add partner link to
sta_ctx->wlan_connected_links when partner link connection is
triggered, which is mlo_roam_prepare_and_send_link_connect_req.
Do not add partner link to sta_ctx->wlan_connected_links in
mlo_roam_update_connected_links.
When roaming from OWE MLO to OWE MLO, host triggers disconnection in
partner link, which should not enable roaming in connected STA.
Change-Id: I99938a0805d60287eb2714e5d271579ac2fb4aeb
CRs-Fixed: 3498822
When STA roams from multi link AP to single link AP, because MLO link
vdev is not disconnected yet, PCL is updated according to MLO station
connection and SLO station connection concurrency scenario.
After MLO link vdev is disconnected, PCL should be updated again
according to SLO station connection scenario.
Change-Id: I6a297c05a605fefe27c20a90d36e419819e6415d
CRs-Fixed: 3497055
when STA roams from multi link AP to single link AP,
the non-assoc link gets cleaned up(through disconnect path) and
RSO gets disabled as part of this. But RSO doesn't get re-enabled
when link cleanup is completed. So, STA can't roam further.
Remove the check which skips RSO enable if the current
disconnecting vdev is of type MLO link. Next API
policy_mgr_get_roam_enabled_sta_session_id() can fetch the
right valid vdev to enable RSO. Don't update PCL to
firmware as there is no need to update again as part of link
cleanup. Firmware has already got the PCL as part of assoc
vdev RSO enable.
cm_roam_switch_to_init() takes care of not allowing RSO enable
in disconnect case as the assoc vdev CM is in
WLAN_CM_S_DISCONNECTING state.
Change-Id: I155bb93868653d5575f81559c48b86b40cf5d59c
CRs-Fixed: 3487290
eMLSR + NAN concurrency is not supported currently, so handle it
as mentioned below
1. eMLSR+NAN: If NAN is coming up when eMLSR is active, disable
one ML link so that eMLSR gets disabled.
2. NAN+eMLSR: If eMLSR is coming up when NAN is already enabled,
disable one link so that eMLSR doesn't get enabled.
Also, cleanup the APIs to carry a generic flag to indicate that
a concurrent connection is coming up instead of mode specific flag
as there is no dependency on modes to handle concurrency.
Change-Id: I625f8b18f9d7e991922d22af53f3e8743a3727bd
CRs-Fixed: 3443900
When P2P CLI is connected first and then STA is connected,
disable TDLS on existing interface and enable TDLS on the STA
vdev.
When existing STA + TDLS exists, disable off channel when P2P
connection is started and re-enable off channel for TDLS once
connection is complete. Don't teardown TDLS peers once the
P2P client connection is successful.
Change-Id: I91d152a3a052706289c06cebc932c84a69fdbc00
CRs-Fixed: 3455639
If CSA on SAP/P2P GO causes MCC with the current STA TDLS vdev,
then teardown the TDLS connections, disable off channel and send
disable TDLS to firmware.
If CSA causes MCC -> DBS or MCC -> SCC then allow TDLS and update
the peer off channel list to firmware
Disable TDLS off-channel before SAP/P2P GO vdev restart.
Once CSA is complete, TDLS off-channel will be re-enabled based
on the concurrency.
Add interface manager changes to notify STA channel switch.
Change-Id: I36b359a7e1cf570cfb2b2f0e6abedf148a8fd174
CRs-Fixed: 3445112
Disable TDLS offchannel on SAP start if concurrent STA with
TDLS exist.
Enable TDLS off channel after SAP start if SAP and
STA are not in MCC.
If TDLS is enabled, and off channel is required, update
TDLS off channel to be the SAP channel.
Change-Id: Ica508889acbae5e2dc4269d4d7518cf01d62714f
CRs-Fixed: 3444747
In MLO STA 2.4 GHz + 5 GHz High band and SAP concurrency case,
5 GHz Low band SAP will move to MLO 5 GHz link's home channel for
SCC after MLO STA is up.
But GO starts on 5 GHz high band when SAP CSA is in process and
pass the policy mgr concurrency check because the SAP channel
is still 5 GHz low band.
Fix by defer GO BSS start if any CSA is in progress and also
check any AP start is pending for STA, SAP force SCC concurrency
handling.
Change-Id: I0fcd799017d5048f3574687f913a396ab4d7ade1
CRs-Fixed: 3418351
Currently, if there is a legacy connection and a new STA
connection comes up with EMLSR capability, Host does not
advertise EML caps in assoc request. But there is no support
to enable EMLSR mode if the legacy connection goes away.
Thus, add support to handle this concurrency scenario as
follows
1) Host should advertise EML support capability in assoc
request.
2) After association is complete, force disable one of the
EMLSR links.
3) Once the legacy connection goes down, re-enable the
disabled link.
Change-Id: I5d9f37827e2a9f0571fa9733b4779668bd987f92
CRs-Fixed: 3363115
Currently, unsafe channels are avoided when SAP restart happens.
If WMI_COEX_FIX_CHANNEL_CAPABILITIES is advertised by firmware
and if the SAP is started in a fixed channel, don't restart even
if the current operating channel is unsafe.
Change-Id: I5f7d632bcc00a1b5351dad64aca0ce16f1057537
CRs-Fixed: 3381394
In 11be capable configuration, for connection attempt
to MLO AP from non-MLO type vdev, downgrade to 11ax
mode association for that vdev.
User can still connect in ML mode from MLO type vdev.
Change-Id: I1e7cf940a778a20f2f4d5d24283ffb6aae52781b
CRs-Fixed: 3312163
Currently, roaming is disabled with requestor "RSO_CONNECT_START"
on the STA when concurrent P2P-client is connected .
It's re-enabled once the P2P-client is disconnected but with
requestor RSO_INVALID_REQUESTOR. Roaming module still doesn't
re-enable roaming as it expects roam-enable command from the
requestors(i.e. RSO_CONNECT_START in this case) which disabled
roaming.
Pass right requestor to re-enable roaming.
Change-Id: Icb3deeed788ca248391b4b84288229aea2bdb8c2
CRs-Fixed: 3330219
Add a support to check if low latency SAP is present on 5 GHz
channel then do not allow STA/GC to connect on 5 GHz for
both gaming and lossless audio profile.
Change-Id: I8e1c62dfea3c27306e338392448f5cc6eed912aa
CRs-Fixed: 3302763
Add INI g11be_oui_allow_list to config 802.11be AP oui which
is allowed to get connected in 802.11be mode.
If the INI is empty, all the ap are allowed to get connected
in 802.11be mode. If INI is set to "ffffff 00 01", then STA
is not allowed to connect to any AP in 802.11be mode.
Change-Id: I98e545ba909c1746237a20c365f8297f16fe666f
CRs-Fixed: 3304021
Currently, supplicant sends roc request and hostapd sends
vdev start request to host driver. After processing these
request, host driver sends it to firmware.
But for ROC request having long dwell time, firmware can not
handle vdev start req as it waits for ROC request completed
(timeout occurs). This is leads to crash in firmware.
So, to fix this issue, host driver aborts p2p roc request
before starting BSS (sending vdev start request).
Change-Id: I956428cf94015ac6c4ff7063ef9b060146e4377b
CRs-Fixed: 3270079
Currently rso enable for open and secure connection is handled
incorrectly.
For secure connection roaming should be enabled
after key exchange is complete.
For open connection rso enable is done twice.
Fix is for enabling roam offload for open and secure connection.
Change-Id: I0abde2a6001f176c97e4aa59947260a50c48e6cc
CRs-Fixed: 3271248
Handle the following the eMLSR STA concurrency scenarios
1) eMLSR STA + SAP/P2P GO/NAN - Send a force disable link request to
FW on any one of the eMLSR links. FW will decide which link to disable.
2) eMLSR STA + STA/P2P Client - Send a force disable link request to
FW on any one of the eMLSR links. FW will decide which link to disable.
This action happens before vdev start of the new connection request.
3) eMLSR STA + TDLS - TDLS connection is not allowed since eMLSR STA is
given higher priority.
4) If there is already an existing connection, then eMLSR is not allowed.
Once the other connection goes down, the disabled eMLSR link is restored.
The concurrency handling API is invoked from corresponding interface
manager APIs.
Change-Id: Ib7d5da5dcb8eb3ea16c6e50c8fcadc20972d7d05
CRs-Fixed: 3185078
-Wimplicit-fallthrough is being enabled by default. Some compilers
such as clang require the attribute instead of just a fallthrough comment.
Change-Id: I7e38c098c58146dc2c762d86ff3eae97a21aa98b
CRs-Fixed: 3217408
Add support to handle 2 sap and 1 ml sta link.
Currently, get pcl fails for fourth connection when
2 sap link and 1 ml sta link is present due to which
fourth connection is not allowed as pcl len is becoming 0.
Fix is to add handling for fourth connection when existing
concurrency is P2P/SAP + P2P+SAP + 1 ML STA link.
Change-Id: Ief969018da14096f758fea4bd06d17e7e8d039b7
CRs-Fixed: 3219328
Sta is not allowed to connect/roam in 6 GHz frequency or indoor
frequency in non-DBS target if SAP is active.
But STA roams to 6 GHz AP when SAP is active since the PCL allows
6 GHz frequency.
While populating PCL to firmware, check if 6 GHz and indoor
frequencies are allowed for non-dbs target and set the
weight appropriately if the channels are not allowed
Change-Id: I0e5fdc5b3c4177283d91cdfc58359336cc11910d
CRs-Fixed: 3205494
When SAP and GO home channels are in MCC in same band,
implement below requirement to avoid MCC:
1. SAP starts at first and GO starts later, then SAP will
force SCC to GO's home channel after GO starts up.
2. GO starts at first and SAP starts later, then SAP will
force SCC to GO's home channel during starting up.
3. SAP and GO SCC in same band, SAP changes channel to
the other channel in same band, GO will follow SAP and
move to SAP home channel.
4. SAP and GO SCC in same band, GO changes channel to the
other channel in same band, SAP will follow GO and move
to GO home channel.
And all the force SCC cases, if the target channel of force
SCC is not supported by the SAP or GO, then driver will
select other band's channel for the interface.
Change-Id: I7b24f3a972a401fd144a0c81dc19bd48ba224d85
CRs-Fixed: 3176087
Add logic to disable a link vdev if concurrency doesn't allow it.
Send mlo_force_link_inactive in peer assoc for this and add
it in deleted table on connection complete.
Also disable the link if roam sync indication indicate
that link is disabled.
Change-Id: Ib0615308a669a5fd9d2b8ef6f8ab3f50953f658d
CRs-Fixed: 3192728
Call enable/disable link APIs from connect/disconnect/roam etc.
Cleanup policy_mgr_handle_sap_mlo_sta_concurrency and
policy_mgr_handle_sap_plus_ml_sta_connect API as
policy_mgr_handle_sap_cli_go_ml_sta_up_csa and
policy_mgr_re_enable_ml_sta_on_p2p_sap_down will take care of
ML STA + SAP/P2P cases.
Also optimize policy_mgr_handle_ml_sta_link_concurrency to consider
only ML STA+STA cases and called from connect/disconnect/roam etc.
Change-Id: Ib8b9b2a490832ea5cbe1d86e58009e1437b331b9
CRs-Fixed: 3189685
Currently STA can scan and come up on 6Ghz or 5Ghz indoor channel
if hardware is non-dbs and SAP is present
As part of this change, do not allow STA to connect on 6Ghz and
5Ghz indoor channel for non-dbs hardware if SAP is present
Change-Id: I48ed8483225e35d8b898b0325eee398f74e41c97
CRs-Fixed: 3196247
In GO+SAP Case, SAP starts firstly, GO starts on same band
but different channel. SAP forces SCC check is done in
hdd_hostapd_sap_event_cb in the event handle of eSAP_START_BSS_EVENT.
But at the time the GO's connection entry is not added to
policy mgr list. It is added after WLAN_IF_MGR_EV_AP_START_BSS_COMPLETE
is received by SAP interface manager. SAP can't find the same
band GO's channel at this time.
Fix by move the SAP forces SCC check in SAP interface manager
after WLAN_IF_MGR_EV_AP_START_BSS_COMPLETE event is received.
Change-Id: I54663bdd887e3d591d7fd9ee7ce76572b1ef21f7
CRs-Fixed: 3176076
Move MLO STA-SAP concurreny handling to Policy Mgr which
is present in CSR currently.
Also, Move MLO STA-STA concurreny handling to Policy Mgr
which was part of If Mgr currently.
Change-Id: I2b8de17c3d31b43ff1f6b81a7de07b88888d7fb5
CRs-Fixed: 3153393
If all the partner links are in quiet status, do not send force inactivity
on the link.
Change-Id: Icf5356f9d05e871dcf602e2382a1d150dd057aed
CRs-Fixed: 3101961
Treat MLO STA as a single entity in roam processing:
only process roam related requests on assoc vdev.
Change-Id: Ida9665771e00236c491f58dc764cc6e470dcb6df
CRs-Fixed: 3104659
Rename Legacy to non ML STA and MLO to ML STA in
if_mgr_handle_ml_sta_link_concurrency and related function.
Move if_mgr_get_ml_and_non_ml_sta_count to policy manager
util API. So that it can be used by other modules.
Change-Id: I61260ddf1c6008d8601efaac8d0e9e768e253499
CRs-Fixed: 3105269
As in SBS ML STA, both links are on 5Ghz, reject the 5Ghz
non-ML STA connection, to avoid enabling same band roaming on
both STA.
Also do not allow the SBS ML STA, if a non-ML STA is present
on 5Ghz.
Allow it only if primary interface is set OR dual STA roaming
is disabled.
Change-Id: I20a23ed3b4d87c9acac5417a6f2d484fc80f47d6
CRs-Fixed: 3103246
A MLO with 1 link not active will lead to HW mode as SMM instead
of SBS, so check and see if SBS MLO is present and take
decision as per it.
Change-Id: Ide487d56d6375892b91ab615b9ad314dba2c9991
CRs-Fixed: 3102349
In dual sta case, while vdev0 roaming, vdev1 tried to connect and
stop vdev0 roam. in lim_process_assoc_rsp_frame,
lim_is_roam_synch_in_progress return false, hdr is parsed as invalid
addr, assert when access hdr->sa.
Change-Id: I917dc064dbca5600fe3586ec08103fa62a1348ee
CRs-Fixed: 3100427
Handle SAP + MLO_STA concurrency after MLO connect, by disabling
one of the SBS link if 2.4Ghz SAP is present.
Also if roam happen to non SBS MLO remove the disable restriction
of MLO.
Change-Id: I7d9503a01bb23cd06808b46c090f0dee39c96af6
CRs-Fixed: 3096310
Handle SAP and MLO STA concurrency such as:
1) If MLO STA is present with both links
in 5/6 Ghz then SAP comes up on 2.4 Ghz,
then Disable one of the links.
2) If there is channel switch for sap from
2.4 ghz to 5 ghz, then enable both the
links as they were disabled by previous
operations when sap was on 2.4 ghz.
3) If MLO STA is present with both links in
5/6 Ghz and SAP, which was present on
2.4 ghz, stops then renable both the as
one of the links were disabled because
of sap on 2.4 ghz.
Also, in case where MLO STA roamed from
5 + 6 link to 2.4 + 5/6 link force scc
will happen and the disabled link has
to be enabled.
Both links should only be enabled if mlo
sta has more than one links.
Change-Id: I0fd0093b20336ae32325981589c399b44a44b64e
CRs-Fixed: 3092202
Handle MLO STA + Legacy STA concurrencies such that:
1) Don't disable any link if STA form SCC with any of the
link.
2) Disable the link on the same MAC which can cause MCC.
a) On non-SBS devices disable the ML link on the same
band as STA, As the same band means the same MAC
in non-SBS mode.
b) On SBS devices, disable the ML link on the same MAC:
- If STA freq is 2.4Ghz disable the 2.4Ghz link.
If a 2.4Ghz link is not present, disable any of the
5/6Ghz links (FW to decide the link depending on
SBS mode, low share or high share).
- If STA freq is 5Ghz and can lead to SBS with on of
the link, disable the non-SBS link (link which will
remain on the same MAC).
- If STA freq is 5Ghz and cannot lead to SBS with
one of the links, disable the link on the same MAC/
band.
e.g:
STA freq: STA ML combo: NON SBS Action: SBS Action:
------------------------------------------------------------------
2Ghz 2Ghz+5/6Ghz Disable 2Ghz Disable 2Ghz
5Ghz 2Ghz+5/6Ghz Disable 5Ghz Disable 2.4Ghz
if both 5Ghz lead
to SBS, else
disable 5Ghz
5Ghz(lower) 5Ghz+6Ghz Disable 5Ghz Disable 5Ghz
5Ghz(higher) 5Ghz+6Ghz Disable 5Ghz Disable 6Ghz
2Ghz 5Ghz+6Ghz Disable Any Disable Any
Change-Id: Ie8ca51b5e108c1cfce1a02fc97f4849c617216b7
CRs-Fixed: 3090333
Currently, the host does not check STA+STA concurrency
before sending VDEV/PDEV level PCL command to FW.
1. In case of STA Standalone connection, Host should send
PDEV level PCL commands to FW and marks all channels in PCL
as allowed.
2. In the case of STA + STA connection in MCC/SCC, Host
should send PDEV level PCL command for primary vdev id and
mark all channels in PCL as allowed.
3. In case of STA + STA connection in DBS, Host should
send VDEV level PCL command for both vdev id and via PCL
list host should make sure band is restricted to maintain
only DBS.
4. Initially STA + STA connection in DBS and then one STA
got disconnected. In this case, After disconnection Host
should send PDEV level PCL command for connected vdev id
and mark all channels in PCL as allowed.
Change-Id: I59cf5dfd1bf8fb26e360a8b0b5456fe05037376a
CRs-Fixed: 3084156
When connect from wpa_supplicant and roam from F/W happens at same
time, supplicant hold cm cm_req_lock and wait rsp from scheduler
thread, sheduler thread is blocked to wait for cm_req_lock.
Change-Id: I6b9010972d29be9a32d3b85ee72891ed62b50801
CRs-Fixed: 3087169
When vdev0 STA roamed to another channel, vdev1 SAP CSA for SCC
when ROAM_SYNCH_IN_PROG, will disable roam, but no RSO stop to F/W,
F/W RSO isn't disabled, but host vdev0 will enter RSO_STOPPED, host
F/W RSO state out of sync.
If vdev0 STA next roam sync come soon, it won't be handled for host
RSO_STOPPED, neither roam sync complete nor disconnect will happen,
F/W will asert after wait roam sync complete timeout.
To fix it, Only do SAP CSA check after roam complete and RSO
reenabled, can avoid host F/W RSO state out of sync issue.
Change-Id: I77ccf30cac38f62c6ef8330c6da00364249b242e
CRs-Fixed: 3076935
If p2p go+go concurrency exist and g_enable_go_force_scc ini sets
to 2(liberal mode) then 1st p2p go channel should move to 2nd
p2p go channel after set key. Again, when user initiates CSA to
one p2p go then the force SCC doesn't happen to other p2p go.
But the expectation is all p2p go should move to same channel
which is initiated by user.
As part of fix, move all p2p go to same channel when user
initiates.
Change-Id: I1664e5a7d545d29c32b94e8e4831c71a9cc0ae23
CRs-Fixed: 3064245
Update the concurrency policy for STA mode.
For an upcoming STA connection:
1. Disallow the 2nd STA connection if multiple STA connections are
not allowed.
2. Allow the secondary MLO link when primary link is connected.
3. Disallow ML STA when ML STA/SAP is present.
4. Disallow the 3rd STA.
5. Allow for the other cases.
Change-Id: I70c41177b7a3a9aa9cbac0aaced08c6eafca2b6d
CRs-Fixed: 3012577
In if_mgr_validate_candidate() adds SBS
check to allow a STA connection on SBS
channel when MCC is not allowed .
Change-Id: Ia8007a4beabf546ff293986124f4ef985ccaeacc
CRs-Fixed: 3052797
Fixes in this change include:
- Add debug prints
- Don't disable roaming in case of MLO link connection
- Minor compilation fixes
Change-Id: I0aa9e8b2fd634b6dba1926796d95db997946aac3
CRs-fixed: 3013039
In case of STA + STA or STA + P2P CLIENT concurrency
in MCC, no need to update the beacon interval while
processing connection on the second interface.
Currently, the driver only bypass beacon interval
validation for P2P CLIENT connection in case of
STA + P2P CLIENT concurrency in MCC.
Fix is to bypass beacon interval validation for the
second sta connection so that connection can happen
in MCC for STA + STA.
Change-Id: I4c3f8b1ed0b22f809a291eb88dfd95255cebe5e2
CRs-Fixed: 2934503
