EasyMesh agent fails to update the phymode requested by controller.
EasyMesh controller sends the channel selection request package to notify
EasyMesh agent to change phymode and channel. EasyMesh agent should change
them accordingly.
Update the phymode of the SAP, then restart the SAP.
Change-Id: Iab881b0bfbd1764072b48d426610adc8967111cd
CRs-Fixed: 3181195
If normalize_acs_weight INI setting covers the DFS channel,
the existing DFS channel weight factor will be override.
Fix it by using the minimal weight factor for both setting.
Change-Id: Ie0fa3371bd99ee8d50c7abc81ddc8cd0eb84f9aa
CRs-Fixed: 3196688
If force SCC enabled, user trigger SAP CSA and target channel
doesn't cause MCC with existing STA/CLI. Then overide strict flag to
true, so that driver can skip the overlap interference check and
allow the CSA go through. This is to allow SAP/GO force SCC in
same band.
Change-Id: I7844f7329b922456594cad1402a0d2ac0d0927c5
CRs-Fixed: 3178725
When getting chan param for SAP, the bandwidth is downgraded if some
channel in the bandwidth is disabled if puncture flag is not set in
chan param.
Check phymode in sap_ctx, if it is 11be, enable puncture when getting
chan param.
Change-Id: Id80a76c3fc8bb96e714b1b70159637ece876488f
CRs-Fixed: 3201043
Based on the ini "sta_sap_scc_on_indoor_chan" the behavior of
STA+SAP in scc is as follows:
1. STA is on 2.4 GHz & SAP is on 2.4 GHz and SAP user configured
initial channel was on 5 GHz, then move SAP to 5 GHz initially
started channel
2. When STA + SAP are doing SCC on indoor only channel and
a) STA moves to 2.4 GHz -> then SAP moves to initialy started
channel
b) STA moves to another indoor only channel -> SAP follows
STA channel
c) STA moves to non-indoor, non-dfs channel -> SAP follows
STA channel.
d) STA moves to DFS channel -> SAP moves to 2.4 GHz channel
e) STA disconnects -> Move SAP to initially started channel
3. STA is on 2.4 GHz & SAP is on 5 GHz non-indoor, non-dfs channel
and STA moves to 5 GHz channel, then SAP should follow STA to 5 GHz
if SAP was initially started on 5 GHz channel. Else SAP restart
is not required and SAP will remain on the 2.4 GHz channel
Change-Id: I655dffff026d8147e13599dddc024980ba157be5
CRs-Fixed: 3186965
In SAP ACS, 6 GHz non-PSC channels will increase the SAP ACS
scan time, and 6 GHz non-PSC channels are not favorite channels
for standalone AP, so skip non-PSC channels in ACS SCAN.
Change-Id: I5ac69c81c29feba9b75fcef36d6e205f3716afdf
CRs-Fixed: 3189215
Make puncture work for 11be. Puncture is in EHT operation IE. It should
be supported for 11be mode without MLO IE.
Change-Id: I4406e81895a53d2975aaf5049c8e98a879522888
CRs-Fixed: 3184867
Add a new field max_mcs_index in mlme_legacy_priv to save max mcs
index of current vdev.
Add a new field max_real_mcs_idx in hdd_station_info to save max
mcs index of the connected station.
Change-Id: I28908515cbe5c18c79f14f8645defd5c82e3a6f0
CRs-Fixed: 3065838
When N79 enabled and disable 5G and 6G band, 5G SAP will swith to 2G
band with CSA. CSA reason should be CSA_REASON_BAND_RESTRICTED.
Change-Id: Icd6cf62ee1f58834a97663f784b50f925782a3ef
CRs-Fixed: 3165067
Move the channel frequency and bandwidth check after
wlansap_get_csa_chanwidth_from_phymode API call. The API
may change the target channel bw if SAP works in concurrency
with STA on same channel.
Change-Id: I717c58e4a9e7eb6ea66b0eb56933b5508d4d83c0
CRs-Fixed: 3161386
Remove the old SAP-CSR flow for start bss, stop bss and
channel change req processing which is disabled currently
under the SAP_CP_CLEANUP macro.
Cleanup the redundant checks in the deauth, disassoc
response processing in CSR.
Change-Id: I5a360fc267688b51ca645551108b65646a3c8c1a
CRs-Fixed: 3164259
There is no need to check channel state based on AP bandwidth because
even subchannel is invalid, it is OK for 11be AP to start.
Check channel bandwidth with puncture in lim_pre_vdev_start.
Change-Id: Idad8f96164e979c5139b2ffa7d2be9c1764fbb0f
CRs-Fixed: 3159137
Remove the redundant structures and operations in CSR module
for the stop bss request/response processing to/from SAP/NDI
modules.
Change-Id: I0db36caa509699fe5e0e9709d3e3689e551aad4f
CRs-Fixed: 3148791
Remove the usage of redundant legacy structures in CSR/SAP
modules and simplify the channel change request flow from
the SAP module to LIM.
Similarly change the channel change flow for monitor mode.
Change-Id: Ib91f65307d456919f68892f45f3aa9b4fed0f0d3
CRs-Fixed: 3148761
Remove redundant structures and operations in SME/CSR.
Currently, start bss request is prepared in CSR module using
csr_roam_profile, which is built from sap context.
To remove redundencies, prepare the start bss request in SAP
module and serialize the start bss request.
Change-Id: Icd468fe2a48d5324c1485d83b05e27400c9dbd9a
CRs-Fixed: 3142912
Replace blacklist/whitelist with denylist/allowlist in
qcacld3.0. and replace blm with dlm.
Change-Id: I9ba61dde3b3ea008ca3777448d1f8dab83d33ec1
CRs-Fixed: 3091211
Add check if sap_ctx->chan_freq_before_switch_band is valid
active channel for that country. If yes, the chan_freq_before_switch_band
channel can be used for new CC, otherwise host should skip the
chan_freq_before_switch_band.
Change-Id: I4ac2fee1dd584abba0708c2b7ef0826f384acb2d
CRs-Fixed: 3136454
If STA is active on 5G DFS channel, SAP CAC duration will
be set to zero during starting. This causes the FW indicates
CAC completion event very shortly after vdev start request.
That is before SAP fsm processes BSS start success event.
SAP fsm is still in SAP_STARTING state. In this state,
the sap_cac_end_notify will only indicate the CAC end event
to hostapd. hostapd will be pending on CAC start event from
driver.
Fix by skip the CAC end event if CAC duration time is zero,
then the sap fsm will indicate CAC start/end event when
BSS start event comes up later.
Change-Id: Ib4c2ada8754bd08c0567ce9009ebec2349098b75
CRs-Fixed: 3138466
During CSA max bw is selected for SAP in STA + SAP concurrency
for non-dfs channel and SAP is tear down after 60 sec of operation
due to STA is in 20Mhz and SAP is in 40Mhz with
IEEE80211_HT_CAP_SUP_WIDTH_20_40 flag disabled.
This change is to select 20Mhz BW during CSA if channel bonding is
disabled.
Change-Id: If4ed3d9a080ed976a0f4be6704848ae4494c7bbc
CRs-Fixed: 3126074
Remove redundant structures in CSR for SAP functionality
and add a new flow to post SAP requests from SAP module to
LIM.
Change-Id: If3339cf138140ea148bbd263960907fb3a01de43
CRs-Fixed: 3123072
If the SAP is moved to DFS channel on 5G by Pre-CAC SAP interface,
Pre-CAC interface will be stopped but not deleted. Then the
driver will have two sap context objects. When the Radar event
comes to SAP interface, the existing APIs
(like sap_is_conc_sap_doing_scc_dfs) will still check Pre-CAC SAP
context to get concurrency status without checking Pre-CAC SAP's
status even though the Pre-CAC SAP is inactive. It will get wrong
result and finally cause the current SAP stuck in Radar detected
DFS channel.
Fix by check sap_context state active or not in sap concurrency
check API.
Change-Id: I5adf9e6a3ac7b45983fb627c99d9d92fe5815751
CRs-Fixed: 3127425
Channel width is getting updated in 2 different types, NL type
in some places and rest of the places in internal type.
As the enum types are different between NL type and internal
driver type, SAP channel width changes in the SAP config
during beacon updates. Due to this SAP restarts with
different channel width during SSR.
Hence updated to use only the internal channel width enum type.
Change-Id: Ifd595c079ed7c33692cb96d2514fd1259210e67d
CRs-Fixed: 3124721
If EHT is enabled and channel width is bigger than 80 MHZ, static
puncturing is applicable to this SAP.
Consider punctured channel as valid candidate channel with weight
as max ACS weight for the SAP supporting static puncturing.
Indicate puncture bitmap to hostapd. Hostapd need puncture bitmap
when generating EHT operation IE.
Change-Id: I157878cc405c83114cd82f5fac63375c02e48cab
CRs-Fixed: 3101970
This change is to update sap interface restriction mask
enum check to NL80211_IFTYPE_AP bit mask.
Change-Id: If5a6748425502b1f27654a2e6bfa0e5c2b8554de
CRs-Fixed: 3118953
Set tx power for SAP interface if it is unsafe channel and
if user sets restriction mask.
If interface unable to find safe channel and if restriction
mask is set then stop the SAP.
Change-Id: Ibdec18b9b749f18b1e9d704974f4cbaabbc4e613
CRs-Fixed: 3103307
Remove unwanted parameters from start_bss_req and use
the parameters from vdev instead.
Change-Id: Ifea96bf7908b0dae66807b7a346684fe46fdcd4e
CRs-Fixed: 3105488
CAC duration of new channel should be able to get before CSA. During
CSA, CAC duration of new channel is used to populate max channel
switch IE.
Change-Id: I25d430d3eb663c90555ebad7a214b0789ea8c1ce
CRs-Fixed: 3102581
Initialize sap bw as MAX BW in
policy_mgr_valid_sap_conc_channel_check() as
wlansap_get_csa_chanwidth_from_phymode() take care
of selecting BW for sap and it has a check that will
take minimum of selected BW and initialized BW.
If this BW is not initialized with Max BW then in cases
where original BW is 0 (20 Mhz) (cases such as channel
switch happens from 2.4Ghz to 5Ghz), the above mentioned
check will result in selected BW being 0 (20 Mhz) for
non-DBS HW.
Change-Id: I29febf09036ffa0163df58ce51b399abe2a43fe2
CRs-Fixed: 3101285
Host won't print acl mac address if size equal to MAX_ACL_MAC_ADDRESS.
The logic is unreasonable and add this change allows to print acl mac
address if size equal to MAX_ACL_MAC_ADDRESS.
Change-Id: Iabf10c7c5584d4217be98f7e1f3e67c94a6096a1
CRs-Fixed: 3100336
Add ini "disable_mcs13_support" to disable mcs13 to when SAP working
on 80p80MHZ/160MHZ/320MHZ and mcs12_13 supported.
Change-Id: Iff7043cc422cbe00fa771fe5fad9ad992d6deaf5
CRs-Fixed: 3062196
Fix filling of the SBS range, in current freq range.
And Add is current mode SBS in required APIs.
Change-Id: Ief334aa236ad18512ac5d8cf80b3a2d13d77529a
CRs-Fixed: 3093159
"sap_radar_found_status" is used to check Radar event detected
or not in CAC wait state. Clear "sap_radar_found_status" before
SAP starts to avoid the stale value saved in previous sap start or
CSA. This can happen when the SAP is restart state and get
"stop ap" request from userspace. The invalid value will
cause the wlansap_start_beacon_req retrun without deliver start
beacon msg and cause the no beacon in OTA.
Change-Id: I6336510881333e2775c29dcc167a77d5d745ace9
CRs-Fixed: 3085312
Currently, SAP state machine is moved to INIT state when SAP
start is aborted due to timeout or SSR. SAP is not cleaned up
in such cases as eWNI_SME_STOP_BSS_REQ (which further issues
vdev down and cleanup the peers properly) is not sent to
below layers(firmware).
Replace qdf_wait_for_event_completion to
wait_for_completion_timeout in start_bss which will wait
till the normal operation execute irrespective of firmware
state/SSR.
Change-Id: Ifff2ca9658769cb1145f1c5cb278cd7551cb8c00
CRs-Fixed: 3058550
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
At present, we select max possible band width for SAP in concurrent of
STA+SAP. If STA is working on 160Mhz, the SAP will follow the same
BW as STA. But customer doesn't want to move SAP to 160Mhz
if the original SAP starting BW is 80Mhz since the 160Mhz SAP will
have DFS limitations.
This change avoid 160Mhz selection for 5G SAP force SCC if
1. the channel switch request is not user initiated and
2. the original BW setting is not 160Mhz
Change-Id: I25a7c2ba6679eab8e3884e5b2332d7ed163de12e
CRs-Fixed: 3068284
In 3rd party platform, CNSS driver will provide
LTE avoidance channel frequency ranges by API
cnss_utils_get_wlan_unsafe_channel_sap.
Based on requirement, in single SAP case or SAP+SAP
case, ACS channel list should be filtered out based
on vendor unsafe channel frequency ranges.
Change-Id: I583c1bb2583c783858c54e8643fbe1af69d492b1
CRs-Fixed: 3061043
It may break the vdev MLME SM and lead to unexpected
behavior, if handling a new Radar event when the previous
one is still under processing.
To avoid that, ignore the new Radar event for SAP if it's
already in CSA restart state.
Change-Id: I98a77bb62133e8af660648583b0a2abda57121ab
CRs-Fixed: 3069540
Currently "is_forcescc_restart_required" flag is updated
for first go when any new go comes up. Force scc is
done as part of set key and it is expected that when CLI
joins second GO, first GO moves to new GO's channel but in
case of AUTO GO when no client is connected to first GO
and second GO comes up then "is_forcescc_restart_required"
is set for existing GO but when any client joins first GO
then as part of set key CSA is triggered for same target and
current frequency because "is_forcescc_restart_required" is true
for first AUTO GO. As target and current frequencies are same,
CSA fails and "is_forcescc_restart_required" sets to false. When
CLI joins second GO then CSA for first GO doesn't happen as
"is_forcescc_restart_required" is already changed to false as
part of first CSA attempt.
Fix is to trigger CSA only if current and target session ids are
different.
Change-Id: Ib875cdd93e08f4edc912589b867b733a1d57bdf3
CRs-Fixed: 3067847
Along with 11BE feature macro, check for Kernel 11be macro to avoid
compilation issues when kernel doesn't support 11be.
Change-Id: I9fb84b6263cbdca4cde93e3a581acdbfe0fe2b34
CRs-Fixed: 3066175
In current scenario, SAP is unable to switch from 2.4GHz to
5Ghz if previous CSA happens with reason CSA_REASON_CHAN_PASSIVE.
For instance, SAP starts on 5Ghz with Country US, and later it
changes to country 00 after MCC. Since in country 00, all 5Ghz
channels are passive, so SAP switches to 2.4Ghz with reason
CSA_REASON_CHAN_PASSIVE. Again if MCC happens to country US then
SAP is unable to switch from 2.4Ghz to 5Ghz. This is because
chan_freq_before_switch_band and chan_width_before_switch_band
are not filled in CSA_REASON_CHAN_PASSIVE case.
As part of fix, in wlansap_get_chan_band_restrict(), update the
chan_freq_before_switch_band and chan_width_before_switch_band
incase channel switch reason is CSA_REASON_CHAN_PASSIVE.
Change-Id: I9610b17cff3f6e0e5257270d2fccd5586c9913f9
CRs-Fixed: 3055017
