Currently, kernel provides the multicast address list to the driver
and driver appends this list with new peer multicast address which
are not included in the list. This is done in irq thread.
But with recent changes, for NDI, driver will update this list on
the peer addition and deletion which is executed in scheduler thread.
This may lead to issue when request to update the multicast
list comes from scheduler thread while irq thread request is in
progress and vice-versa.
So, to handle such situation, add spin lock which will protect the
multicast address list.
Change-Id: I9093a92d3714abd875dcd02743f711a5bed26090
CRs-Fixed: 3518989
Currently, driver gets peer multicast address list from kernel for
all interfaces and it send this list to firmware. For NDI, on NDP
confirmation indication, driver appends the multicast list with
new NDP peer added and then send it to firmware. But this is done
for first NDP peer only, kernel does not provide multicast list
again as kernel already configures the multicast addresses, unless
there is some reset happens in kernel.
This can cause issue as firmware is expecting the updated multicast
filter on each NDP confirmation (new peer is added) to enable the
NS frame exchange. As new peer is not added in the filter, firmware
will reject the NS frame.
So, to fix this, update the multicast list on NDP peer addition and
deletion.
Change-Id: I6371199ae5c3a8f4088987f1e6f10c39cbed1685
CRs-Fixed: 3518887
current observation is as following,
(1) RX UDP data length less then 12 bytes and they are aggregated
by FISA.
(2) aggregated UDP data might not be supported by user APP or they
are forwarded to other netdev.
if above two is met, kernel panic appears.
no solid conclusion from kernel network currently,
as a SW WAR from wlan driver side, check if current UDP data
length < 16 bytes, skip FISA aggregation.
Change-Id: Ia9e46705c7ace6a6e5580494231056adf214d7b2
CRs-Fixed: 3330035
As part of roaming, roamed event is sent to the userspace.
This marks the end of roaming and userspace begins CSI
restart for the new BSS. But, the channel information of
the new BSS is not yet updated to the vdev. This leads to
sending wrong channel in the for CFR capture.
To fix this, update the channel info of the new BSS before
sending userspace update.
Change-Id: I3af5aadf6041e56f2261aaebd7d2c1a108f63c65
CRs-Fixed: 3500062
Currently cck and ofdm flags are filled wrongly for monitor
mode data packets based on preamble and wireshark deriving
incorrect phy type for 11G & 11B.
This change is to update cck and ofdm flags based on packet
type.
Change-Id: I5fcdc463ea2a6d83253e39cc377a2471aeb4e144
CRs-Fixed: 3447567
Currently, For legacy modes monitor mode reporting incorrect tx rate
for data packet in radiotap header due to packetcapture_hdr rate
is hardcoded as '0'.
This change calculates the data rate of legacy packets using mcs
reported in tx completion.
Change-Id: I2a651b8fb36947672bd30f8a635f0e643219e520
CRs-Fixed: 3442376
Currently monitor mode HT & VHT data packet tx rate is not
matching with ota packet tx rate due to incorrect mcs value.
This change is to update proper mcs value for HT & VHT modes.
Change-Id: Ib4fb06a06ce35a4e8e683e5a22c8be226492b13f
CRs-Fixed: 3442509
Currently, Fw did not set NACK reason code
to Host when Fw is not ready for WoW.
As part of the new change, Fw will send NACK
reason code along with WoW NACK to host.
Make changes in host to store and print
NACK reason code.
Change-Id: Ic978af9572c8de37df3fb926083aac5e6ddefda7
CRs-Fixed: 3481177
Currently for REASSOC command host starts vdev ops
and tries to use vdev. In parallel if host receives
interface down and starts vdev trans then proceeds
to stop adapter and destroys the vdev, this leads
to null pointer dereference if vdev is destroyed
first.
This happens because driver doesn't wait for vdev ops
to complete after starting vdev trans.
To address this issue, start vdev trans and wait for
vdev ops to complete before proceeding to execute
further.
Change-Id: I363d05f742f7569dffed70cfa9b6bb9a0a766d9e
CRs-Fixed: 3445858
When the Intra band INI is enabled and the STA connected in 6 GHz
band the channel count and frequency are not sent in the
WMI_ROAM_CHAN_LIST command as the band is not defined or unknown.
As a result of this DUT is unable to trigger partial roam scan in
the current connected 6 GHz channel and does a full roam scan.
Add the 6 GHz band check in the Intra band enabled case.
Change-Id: I765c233d1e6bf71cab186041ebd7df2293be6f05
CRs-Fixed: 3469197
If while roaming from 2.4 GHz to 5 GHz band with SAE
encryption, rates shouldn't be filled from the current
session/AP as this may lead to incorrectly filling rates
for instance this may lead to incorrectly filling CCk rates
for SAE Pre-Auth while roaming from 2.4 GHz to 5 GHz. As
even though with roaming offloaded, sae pre_auth due to
crypto limitations of fw has to be triggered by the driver.
Change-Id: I2293563db047e10ec8a2ade9f3b2a602cf3e3edf
CRs-Fixed: 3336853
Currently host driver does not update dot11 mode info correctly
for getbssinfo command if the dot11 mode is 11AX or 11BE.
With this fix add a logic to update the dot11 mode info
correctly in response to the getbssinfo command.
Change-Id: I9ebec3ab43fe4cff1cab5f646bcc93a8c6654fd0
CRs-Fixed: 3353630
Here upper layer configures roam band via the SETROAMBAND
NCHO command. This means DUT should be restricted to roam
to the configured band only but as per current PCL filtration
logic, DUT is allowed to roam beyond the configured band AP
also. Roam Band definition is:
0: auto (all supported bands)
1: 2.4 only
2: 5 only
3: 2.4 + 5
4: 6 only
5: 2.4 + 6
6: 5 + 6
7: 2.4 + 5 + 6
Fix is to update the PCL filtration logic in wma_send_set_pcl_cmd
and make sure DUT doesn't roam beyond the configured band AP.
Change-Id: Ia2353e8ff982609a4ab5a35715886648f140cd22
CRs-Fixed: 3158456
Upon reception of assoc request from an already associated
PMF-enabled STA, the SAP is expected to start SA-Query
mechanism.
On the other hand, host driver drops all the
retried assoc request frames if the STA is already in
connected state. This is valid as long as the original
assoc request is currently under processing(to prevent
duplicate processing). However, for reassoc attempt cases,
this assoc request with retry bit set could be the first
assoc request under processing.
Therefore, change the logic to drop only retry-bit set
assoc requests in non-PMF STA cases.
For PMF-enabled STA, drop the assoc requests only if
key installation is pending. Otherwise, send SA query.
Change-Id: I1f3a564864e70f4e11994698389be427ac202fa3
CRs-Fixed: 3446033
Currently host drops an AP from scan list if host country is set to
US and AP country is non-US. This implementation violates our
standard regulatory scan policy.
To address this issue, introduce a new INI to differentiate
between our standard regulatory policy with others.
Change-Id: Ie6bd2d1925048aef427136b34d00d361955f40b2
CRs-Fixed: 3377242
Send the driver disconnect internal reason code as an event to user space
using QCA_NL80211_VENDOR_SUBCMD_DRIVER_DISCONNECT_REASON vendor command.
Change-Id: I19959e097c5709d63fbd941583b934e291c3af1c
CRs-Fixed: 3371396
In api sch_set_fixed_beacon_fields(), the channel switch announcement
method selection was based on config "CONFIG_CHANNEL_HOPPING_ALL_BANDS"
due to which peer STA may not be able to switch channel when MTP
is working as SAP and doing channel switching.
Modify the check in order to select the channel switch method based
on nature of peer STA and operating/target frequency.
Change-Id: I3deb09245496d65e6bb3ec27ed7eefd3dcaa27bc
CRs-Fixed: 3293983
If is_pre_cac_on is set, in __wlan_hdd_del_virtual_intf firstly
frees the sap context by calling hdd_clean_up_interface and then
frees the pre cac by calling hdd_clean_up_pre_cac_interface this
will fails to access the sap context which is already freed.
So, replace order of calling, firstly hdd_clean_up_pre_cac_interface
and then hdd_clean_up_interface.
cds flush work will cancel the work which will not delete the pre cac
vdev. Replace with qdf_flush_work will wait for a work to finish,
executing the last queueing instance.
Assign NULL to fn and arg of pre cac work to ensure proper cleanup
of work.
Change-Id: I093bf627ce7a73e7c4f7c4cf30e2ec56814a80ed
CRs-Fixed: 3286477
Before sending peer create command to firmware, defer the
messages to LIM so that peer create confirm event is
protected from disconnect. If the messages are not defered,
disconnect gets processed and the lim timers are not
aborted as part of disconnect sequence and back to back
connect followed by disconnect causes ANR
Defer the LIM messages during peer create and allow the messages
after peer create confirm is received.
Change-Id: Ifffbb4897a4fa85dd83c94eb84be72295905b785
CRs-Fixed: 3421721
Currently, our host logic is "If an STA connection is in
progress in another adapter, driver disconnects the STA and
completes the SAP operation (start BSS or stop BSS)". This
is due to below reasons:
In the old kernel version and for STA+SAP concurrency support
from GUI, the first STA connection gets triggered and while it
is in progress, SAP start/stop also comes up. Once STA association
is successful, the STA connect event is sent to the kernel which
gets queued in the kernel workqueue and the supplicant won't
process M1 received from AP and send M2 until this NL80211_CONNECT
event is received. Workqueue is not scheduled as RTNL lock is
already taken by hostapd thread which has issued start_bss/stop_bss
command to the driver. The driver cannot complete start_bss/stop_bss
as the pending command at the head of the SME command pending list
is hw_mode_update for STA session which cannot be processed as SME
is in WAITforKey state for STA interface. The start_bss/stop_bss
command for SAP interface is queued behind the hw_mode_update
command and so it cannot be processed until hw_mode_update command
is processed. This is causing a deadlock so disconnect the STA
interface first if a connection or key exchange is in progress and
then start or stop the SAP interface.
As part of connection mgr changes, removed dependency on WAITforKey
state in serialization, and h/w mode also is not sent immediately
after the STA connection, So no possibility of the above deadlock
scenario.
The fix is to avoid disconnection on the STA interface during the
start or stop of the SAP interface.
Change-Id: Iad3ada091e505007cc6901a461be3b88fc051f4e
CRs-Fixed: 3339784
Currently if SCC frequencies are added in pcl list and
rest 5 GHz frequencies are required to be added with lesser
weightage then all 5 GHz/6 GHz frequencies are added including
SCC channels. so in pcl duplicate entries are found for SCC
frequencies with different weightage.
Fix is not to add SCC frequencies during addition of 5 GHz/6 GHz
frequencies if SCC frequencies are already present in pcl.
Change-Id: I03123e4bf8caee62b0fcd0c3ae78d6cd7187c7de
CRs-Fixed: 3209858
In function wlan_hdd_populate_weigh_pcl weight is populated
to 0 only if weighed_valid_list is 0 otherwise weight of
non-pcl entries will be populated as 20 less than weight
of last pcl entry but weighed_valid_list is set to 1 in
policy_mgr_get_valid_chan_weights. So, non-pcl entries
are also sent to upper layer.
Fix is to change weighed_valid_list to 0,
if there is existing p2p connection.
Change-Id: Ic0d86021c00fd95e5bc20eeabea56e2a69658599
CRs-Fixed: 3140467
Currently support is not there for 3rd mode when CLI+CLI
connection is there on DUT.
Update PCL table for 3rd mode when CLI+CLI exsits and add
support to fetch index based on new connection band and
concurrency.
Change-Id: I6041c40b3208d0b33dff2b4f9dc854d2d2dc17a1
CRs-Fixed: 3050537
Add feature flag for conditional compilation of feature to enable
p2p+p2p on a device.
Change-Id: I2c95b39c3db6e51213f7625383c365799fff9e31
CRs-Fixed: 2991307
INI g_enable_go_force_scc states the force MCC to SCC mode.
Mode 1-strict: Implement force scc strictly as part of start bss
Mode 2-liberal: Turn on p2p go on provided channel and move
first p2p go to the new p2p go channel after set key.
Currently for p2p-GO forceSCC, support is present where no matter
what is the GO negotiated channel in start_bss, driver will force
the other GO/STA/GC channel (on the same band) to the current GO
channel. This is force SCC strict mode where value 1 is used for
g_enable_go_force_scc ini. In this mode GC will have to do full
scan as the GO channel may be different from actual negotiated
channel. DUT may see some issues if GC dosent do full scan in
this mode.
As part of this change, add support for value 2(Liberal mode)
in g_enable_go_force_scc ini. As part of this liberal mode,
driver will allow the GO to start in MCC mode and after set key,
it will check any other concurrent GO and will do forceSCC for
that GO to the newly formed GO channel.
Change-Id: Ifc7beb06335616c51dc064f48a78b825dbdbda25
CRs-Fixed: 2992098
Check fw capability to support p2p + p2p concurrency from
soc_fw_ext_caps and based on fw capability, set policy
mgr concurrency for p2p + p2p.
Change-Id: Ia32f81f37174e9d722911b1fae6d4897d0af9816
CRs-Fixed: 2991300
From the caller, the args comes as pm_ctx but in definition
it's assigned as work_info which causes crash.
Change-Id: I9928a2c3862407b02cb34356ad54895e1d3069c7
CRs-Fixed: 3035090
Add support to allow/disallow three port combinations on
same band based on PCL table
Change-Id: Id2e9ad7d17bab6ea0aff6913b25f0eb330dc6c13
CRs-Fixed: 3028527
