Age | Commit message (Collapse) | Author |
|
SBMerger: 284775313
Change-Id: I16ea4d301133808d9420fef27e57461df72e1377
Signed-off-by: SecurityBot <android-nexus-securitybot@system.gserviceaccount.com>
|
|
SBMerger: 284775313
Change-Id: Ib284d387c70a2d666a998ba0ad933309b9dcaee0
Signed-off-by: SecurityBot <android-nexus-securitybot@system.gserviceaccount.com>
|
|
SBMerger: 284775313
Change-Id: Ib1be65dca032e096e4a648254bc294e1940bf83b
Signed-off-by: SecurityBot <android-nexus-securitybot@system.gserviceaccount.com>
|
|
SBMerger: 284775313
Change-Id: I3760f7d8135a80c90e6da7b065283d14a5e44de6
Signed-off-by: SecurityBot <android-nexus-securitybot@system.gserviceaccount.com>
|
|
android-msm-pixel-4.9-qt
APR 2020.1
Bug: 148866250
Change-Id: I7cdf29aa3bf0c15759fc17c849b1844213c85f6c
Signed-off-by: Harrison Lingren <hlingren@google.com>
|
|
Currently the driver in case of force SCC picks up
2.4ghz SCC channel if any other STA/AP is already
up on that channel, so in the process of shifting
in the API sap_validate_channel it picks up 2.4ghz
and calls a reg API to set the freq related params
to it. Now since the frequency for 2.4ghz is 40 mhz
capable the max BW supported for 2.4ghz becomes 40 and
the driver starts the SAP on 40mhz.
Now since the OBSS scan is offloaded to the hostpad
and now since it was driver which started the SAP
on 40mhz there is no mechanism to start OBSS scan
from driver, which leads to channel blockage if
any legacy 11g, 11b lient is operating on the channel.
Fix is to lower down the BW to 20Mhz if the SAP does a
force SCC in 2.4ghz.
Bug: 145577504
Test: au drop test
Merged-In: I0d85dfb5e9e8332957d853173063e77d18ea600c
Change-Id: I0d85dfb5e9e8332957d853173063e77d18ea600c
CRs-Fixed: 2581495
Signed-off-by: Isaac Chiou <isaacchiou@google.com>
|
|
Currently the driver in case of force SCC picks up
2.4ghz SCC channel if any other STA/AP is already
up on that channel, so in the process of shifting
in the API sap_validate_channel it picks up 2.4ghz
and calls a reg API to set the freq related params
to it. Now since the frequency for 2.4ghz is 40 mhz
capable the max BW supported for 2.4ghz becomes 40 and
the driver starts the SAP on 40mhz.
Now since the OBSS scan is offloaded to the hostpad
and now since it was driver which started the SAP
on 40mhz there is no mechanism to start OBSS scan
from driver, which leads to channel blockage if
any legacy 11g, 11b lient is operating on the channel.
Fix is to lower down the BW to 20Mhz if the SAP does a
force SCC in 2.4ghz.
Bug: 145577504
Change-Id: I0d85dfb5e9e8332957d853173063e77d18ea600c
CRs-Fixed: 2581495
Signed-off-by: Isaac Chiou <isaacchiou@google.com>
|
|
Currently the driver uses a global safe channel
list, and also keeps another safe channel list in
policy mgr which results in duplicate copies
of the same thing.
Also there are many possible issues which are seen
if the global list implementation is used.
Issue 1:-
The global unsafe ch list is maintained for each
channel and is updated as part of ACS scan cb.
So if a user does ACS again and again ( SAP on off)
then the result of unsafe channels of the previous
ACS request would be updated as part of the ACS cb
of the new ACS scan request.
In the function of sap_get_freq_list, the driver
filters out the channels which are unsafe, and the
same channels are not chosen as the best channel for
SAP operation.
Now the filtration of the channels would happen
according to the previous ACS request, and the driver
would remove the channels from the ACS scan list.
But those channels were unsafe when the previous ACS
happened, and may not be unsafe now, and can be used
to turn on the SAP (can be chosen as the best channel)
Issue 2:-
If the channels are truly unsafe, then the driver
filters out the channel in the function sap_get_freq_list,
and do not chose them for the SAP.
It may happen that the channel list that the driver
preferred as part of do acs becomes unsafe, and the
channels that were unsafe at the time of do acs becomes
safe while the driver was scanning the ACS channels to
find other APs.
Now since the channels that were unsafe at the time of
ACS req are safe now, they could have been chosen as the
best channel but they were not scanned, so the ACS channel
weight of these channels would remain maximum, and they
would be sorted at last of the sorted list.
Also the channels that were as part of the ACS channels list
became unsafe, hence the driver would also assign maximum
weight to them, and they would too become unusable channels.
This would result in all channels having the same weight that
is maximum weight, and so the sorting algorithm does not have
to sort any channel now since all of the weights are same.
The first channel in the sorted list would be channel number
1 of 2.4Ghz, and would get chosen, but this may not be
correct if the HW mode is 5ghz only.
Fix:-
Safe and unsafe channels can be checked by using
policy mgr safe channel list too, so it is better
to keep just one unsafe channel list.
The driver would not filter out the unsafe channels
for ACS scan, and would filter out the unsafe channels
as part of the ACS scan done callback.
Bug: 142287550
Change-Id: Ief236db9e73864e5cb2d290a8106799f9e80f82d
CRs-Fixed: 2530241
Signed-off-by: Isaac Chiou <isaacchiou@google.com>
|
|
In case if two measurement requests calls update_rrm_report() twice,
possible out-of-bounds write for the allocated report array, report[]
in rrm_process_radio_measurement_request.
Bug: 147103218
Change-Id: Icc8b7aa14bbcc1219d28025e599c9976a3525bba
CRs-Fixed: 2564485
Signed-off-by: Hsiu-Chang Chen <hsiuchangchen@google.com>
|
|
In monitor mode there is no disconnect, so vdev stop and down is
not handled. Make sure to stop and down the vdev before vdev delete.
Bug: 142158571
Change-Id: I25f5a0e01deda8f2e16e102113b10f32e89b3e38
CRs-Fixed: 2357047
Signed-off-by: Isaac Chiou <isaacchiou@google.com>
|
|
SBMerger: 284775313
Change-Id: Ib3cf65c3cd343a76a830ec7d77d60bd863ba7a71
Signed-off-by: SecurityBot <android-nexus-securitybot@system.gserviceaccount.com>
|
|
In wma_is_pkt_drop_candidate the enum values used to check the
frame subtype is not proper and disassoc subtype is compared to
SIR_MAC_MGMT_DISASSOC instead of IEEE80211_FC0_SUBTYPE_DISASSOC.
Similar enum mismatch is present for deauth frame.
Also the frame received time is updated even when the frame was
dropped and thus the received time of the frame keeps on increasing.
Thus the condition to check if frame is allowed after
WMA_MGMT_FRAME_DETECT_DOS_TIMER ms always fails if driver
continuously keep on getting the frames.
This can lead to dropping of valid deauth/disassoc frames in case
if RMF is enabled and some rouge peer keep on sending rogue
deauth/disassoc frames and thus even if peer send valid deauth
peer will not get disconnected.
Fix this by using proper enum values to map the frame subtype.
Also update the rcvd time stamp only when the frame is allowed,
as this timestamp should be used to block the duplicate
frames for WMA_MGMT_FRAME_DETECT_DOS_TIMER ms.
bug: 141690880
Change-Id: I4f480e21369b585d78f240c5f4f062d010d889a8
CRs-Fixed: 2256679
Signed-off-by: Isaac Chiou <isaacchiou@google.com>
|
|
At present, IPA sys pipes setup done before ipa_wdi_init,
so chances for IPA uC is not yet up and running. As wdi init
succeeds only if uC is up and running, setting up IPA sys pipes
after ipa_wdi_init succeeds.
bug: 144733838
Change-Id: Iee9783b0238a3bc96a2e73e47ffebf3b44623485
CRs-Fixed: 2573929
Signed-off-by: Isaac Chiou <isaacchiou@google.com>
|
|
Currently the driver does not check if the state
is key exchange in progress and suspends wlan
before set-key happens which further results in
FW also in wake up state.
This would result in delayed EAP exchange, and also
in power loss.
Scenario:-
1. Turn on STA and try to connect to enterprise network
2. Turn off display.
Here the display turn off would trigger APPS suspend
while the STA is trying to connect, and authenticate
and since there is no check in driver to prevent
suspend in set key in progress state, it would result
in a FW assert, as the expectation of FW is to allow
suspend only after set key has been done.
Fix is to prevent WLAN-suspend in case of connection
in progress, and allow suspend only in connected
and authenticated state.
bug: 145103580
Change-Id: Ic173116f7ba424005d938a43c75831a6a4dc874c
CRs-Fixed: 2512866
Signed-off-by: Isaac Chiou <isaacchiou@google.com>
|
|
In monitor mode during driver unload VDEV, PDEV and PSOC objects
are leaking because stop adapter is not cleaning up monitor mode
vdev. Destroy monitor mode vdev object during stop adapter such
that VDEV object and its parent PDEV, PSOC objects can be cleaned
up properly.
bug: 142158571
Change-Id: Ic5778d03226a880981a4b6affbeeee357e007f65
CRs-Fixed: 2576722
Signed-off-by: Isaac Chiou <isaacchiou@google.com>
|
|
Currently the sta_context in add_bss params which is used to send the
peer_assoc command to the FW, the ht_enable and vht_enable are set based
on the AP's capability from the beacon. However, the channel width is
set based on the assoc response frame from the AP.
In a scenario where the AP advertises HT and VHT IEs in the beacon but
does not send HT and VHT IEs in the assoc response frame, we will end up
connecting in VHT/HT mode but with incorrect channel width.
Update the sta_context channel width also based on the AP's capability
from the beacon so that the connection would happen in the right channel
width even if HT/VHT IEs are missing in the assoc response frame.
bug: 142350508
bug: 144981147
Change-Id: Idb1907abebf32a34f88e935a30ebb8f1bce1d59c
CRs-Fixed: 2324434
Signed-off-by: Isaac Chiou <isaacchiou@google.com>
|
|
Current driver configuration is as follow:
1. SME active roam command queue timeout is 30 seconds
2. SAE auth timeout is 5 seconds
3. Max BSS count in roam command (CSR_MAX_BSSID_COUNT) for SAE
authentication is 8
As SAE auth timeout is 5 seconds and SME active command queue timeout
are 30 seconds, so only 6 SAE auth timeouts (30/5 = 6) are enough to
trigger SME active command queue timeout for roam command.
In case of continuous SAE auth time out, Driver will try SAE
connection till 8th candidate. So when driver tries to process SAE
connection for 7th BSSID, device leads to crash as by this time
SAE roam command(connect command) gets removed from SME active roam
command queue.
Fix is to reduce the candidate list to 5 in roam command for SAE
authentication considering SME roam command queue timeout is of 30
seconds.
Change-Id: Ic43f44ef14ea4c3b972635682941a624cdc6dcc7
CRs-Fixed: 2551462
bug: 143129445
Signed-off-by: Isaac Chiou <isaacchiou@google.com>
|
|
In SAP mode, one peer sends multiple deauth frames which
results in queuing multiple WM status change cmd which
is added at head of queue. WM status change cmd is added
at head of queue for other peers which results in delay
in processing the cmd for first peer. The WM status cmd
is processed and peer is deleted and connection is
initiated by the same peer. The remaining WM status change
cmd is now processed and del_sta is triggered. On receiving
del_sta response, cleanup_trigger in sta_ds is checked
and eWNI_SME_DISASSOC_RSP message is posted to SME instead
of eWNI_SME_DISCONNECT_DONE_IND since the sta_ds entry is
added newly. This will result in active command timeout
since WM status change cmd is not removed from active queue.
Fix is to drop deauth or disassoc frame after the first one
is processed and use normal priority to queue WM status
change cmd.
bug: 141690880
Change-Id: Ib87fa7496d4adb6e25c30de657ce62101ca6f263
CRs-Fixed: 2291442
Signed-off-by: Isaac Chiou <isaacchiou@google.com>
|
|
Currently the array of scan channel list is of size
SIR_ESE_MAX_MEAS_IE_REQS, but the memory is allocated dynamically
for the channge which can be greater than SIR_ESE_MAX_MEAS_IE_REQS.
So use dynamic array for this as memory is allocated for this every
time.
bug: 139058079
Change-Id: I3c854b339c49d9f628033aa6742d57568ec14954
CRs-Fixed: 2560184
Signed-off-by: Isaac Chiou <isaacchiou@google.com>
|
|
SBMerger: 279089054
Change-Id: I614beadbc81f6ef0a6ecff39deacc02be07d930c
Signed-off-by: SecurityBot <android-nexus-securitybot@system.gserviceaccount.com>
|
|
SBMerger: 279089054
Change-Id: Ia843d30b7fd916f4f690386689be0e451864b090
Signed-off-by: SecurityBot <android-nexus-securitybot@system.gserviceaccount.com>
|
|
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.
Since the number of requested EIDs is directly controlled by the
frame sent by AP, validate this value before using it to allocate
memory.
Bug: 144843138
Change-Id: Icbac3e952de0d7ae3144e9b319f2c51ccdf93ac5
CRs-Fixed: 2571480
Signed-off-by: Sunil Ravi <sunilravi@google.com>
|
|
In the function hdd_dns_make_name_query, the driver is performing a
validation check that includes the use of length of the received string
as an array index. As the length and string both are user controlled,
the user can send the length as zero. As the policy states that the
given attribute is NLA_BINARY, so there would be no validation check
that can ensure the correct input. Therefore in the case of a malformed
packet with null length string, it can cause a possible integer
underflow.
To avoid this vulnerability change the attribute type from NLA_BINARY to
NLA_NUL_STRING. This will cause all the checks to be performed at
validate_nla.
Change-Id: I0bb569b71a88a07745d364dad23cf1210af4212e
CRs-Fixed: 2409913
Bug: 141099048
Signed-off-by: Srinivas Girigowda <quic_sgirigow@quicinc.com>
(cherry picked from commit 395c752bcb965db80a8d6b296f31150b05c99670)
|
|
In the function hdd_dns_make_name_query, the driver is performing a
validation check that includes the use of length of the received string
as an array index. As the length and string both are user controlled,
the user can send the length as zero. As the policy states that the
given attribute is NLA_BINARY, so there would be no validation check
that can ensure the correct input. Therefore in the case of a malformed
packet with null length string, it can cause a possible integer
underflow.
To avoid this vulnerability change the attribute type from NLA_BINARY to
NLA_NUL_STRING. This will cause all the checks to be performed at
validate_nla.
Change-Id: I0bb569b71a88a07745d364dad23cf1210af4212e
CRs-Fixed: 2409913
Bug: 141099048
Signed-off-by: Srinivas Girigowda <quic_sgirigow@quicinc.com>
|
|
Change-Id: I6d6ffde3b6fd2f4d5487e17fa6095a747b1df57a
Signed-off-by: Petri Gynther <pgynther@google.com>
|
|
Currently the driver does not mark the SRD channels
as passive which leads to hostapd starting P2P-GO
on a SRD channel, but since driver does not allow
the same, P2P-GO fails.
Fix is to inform the wiphy about the SRD channels by
making them as passive so that the hostpad does not
give the command to start the P2P-GO on the particular
SRD channel.
Change-Id: I5eaa457b8819d7a22d2e592d1b79fff15b364f40
CRs-Fixed: 2491045
Bug: 138939517
Signed-off-by: Vinay Gannevaram <quic_vganneva@quicinc.com>
|
|
Currently the driver does not mark the SRD channels
as passive which leads to hostapd starting P2P-GO
on a SRD channel, but since driver does not allow
the same, P2P-GO fails.
Fix is to inform the wiphy about the SRD channels by
making them as passive so that the hostpad does not
give the command to start the P2P-GO on the particular
SRD channel.
Change-Id: I5eaa457b8819d7a22d2e592d1b79fff15b364f40
CRs-Fixed: 2491045
Bug: 138939517
Signed-off-by: Vinay Gannevaram <quic_vganneva@quicinc.com>
|
|
If 11w is enabled, mmie should be included in broadcast
multicast rmf, length check need consider it to avoid buffer
overflow
CRs-Fixed: 2270117
Bug: 139890137
Change-Id: I6c2ebe18fb5b6e4246ba6d28c1dbc55175279e30
Signed-off-by: Srinivas Girigowda <quic_sgirigow@quicinc.com>
|
|
In hdd_apf_read_memory_cb, context buffer length is checked
against sum of packet offset and event length, packet offset
and event length are extracted from FW response and can lead
to integer overflow, which will allow to pass the length check
and eventually will lead to buffer overwrite when event data is
copied to context buffer.
To avoid this issue, validate the event length against the
available length in the context buffer, which can be obtained
by getting difference of packet offset from the context buffer
length.
Change-Id: I53798e56403f1c550f0a762645ccd67a1dc8500d
CRs-Fixed: 2436502
Bug: 139886621
Signed-off-by: Srinivas Girigowda <quic_sgirigow@quicinc.com>
|
|
in wma_ibss_peer_info_event_handler, the driver has a upper
bound check on num_peers and not a lower bound check.
the num_peers should be a positive value.
Since there is no check to see if num_peers is set to 0,
this check can underflow and result in multiple OOB writes
once the loop has incremented more than 32 times.
Fix is to check whether num_peers is a positive value,
and return if not found true.
Change-Id: I599151cc6720ed931142ad6a519add6957fea467
CRs-Fixed: 2324139
Bug: 139886106
Signed-off-by: Srinivas Girigowda <quic_sgirigow@quicinc.com>
|
|
Currently the function lim_process_assoc_req_frame uses frame_len
without validation to parse the IE buffer which could lead to
out-of-bounds memory access if the frame_len is less than or
equal to LIM_ASSOC_REQ_IE_OFFSET(4).
Add check to validate the frame_len with LIM_ASSOC_REQ_IE_OFFSET
before sending frame_len - LIM_ASSOC_REQ_IE_OFFSET to
cfg_get_vendor_ie_ptr_from_oui to parse the only IE buffer.
Change-Id: Iaa9e8db4a2605169c9ad3904878a2e626eb6de8b
CRs-Fixed: 2259707
Bug: 139883000
Signed-off-by: Srinivas Girigowda <quic_sgirigow@quicinc.com>
|
|
When first WMI_RADIO_LINK_STATS_EVENTID is received radio stats buffer
is allocated based on num_radio param. There is an option for pending
following events. So update wma_unified_link_radio_stats_event_handler
to check if following events are valid wrt num_radio values to avoid
buffer overwrites.
Change-Id: If4675bada5492c3bae98c655b45cac6dc76b6431
CRs-Fixed: 2309399
Bug: 139882999
Signed-off-by: Srinivas Girigowda <quic_sgirigow@quicinc.com>
|
|
QBSS IE uses min length of 4 bytes for version 1 and
min length of 5 bytes for version 2. Min length used
for IE is 5 bytes in driver which can cause WPA IE
parse failure if QBSS IE is 4 bytes resulting in failure
in fetching scan results due to security mismatch and
subsequently connection failure.
Fix is to skip the IE which has length less than the
minimum valid length.
Regression cause is I8e42fb7e9674845d152d2ec26a592e02a1b562ab.
Change-Id: I00fbffad221e2d9ecedcb87c9607ac8abd7c55b1
CRs-Fixed: 2364663
Bug: 138641772
Signed-off-by: Vinay Gannevaram <quic_vganneva@quicinc.com>
|
|
qcacld-2.0 to qcacld-3.0 propagation.
Some stations send association request with zero length of SuppChannels
IE then currently dot11f decodes it to an invalid value.
To fix this, set the minsize of SuppChannels IE to 2.
Change-Id: If44807d2f2b8a62e5a137ca3d17af2e2654f72f2
CRs-Fixed: 2303702
Bug: 138641772
Signed-off-by: Vinay Gannevaram <quic_vganneva@quicinc.com>
|
|
Currently ch 144 is disabled by default for
world reg rules.
Enable channel 144 by default for world reg
rules.
Change-Id: Id6e8f7db21380e052a1fe6ebff3db95437c7f1a8
CRs-Fixed: 2509880
Bug: 138389722
Signed-off-by: Vinay Gannevaram <quic_vganneva@quicinc.com>
|
|
Currently ch 144 is disabled by default for
world reg rules.
Enable channel 144 by default for world reg
rules.
Change-Id: Id6e8f7db21380e052a1fe6ebff3db95437c7f1a8
CRs-Fixed: 2509880
Bug: 138389722
Signed-off-by: Vinay Gannevaram <quic_vganneva@quicinc.com>
|
|
Change-Id: I3cda47d6d90c9658a6fe36998e72764c5403ac24
Signed-off-by: Petri Gynther <pgynther@google.com>
|
|
Currently the driver sends the CSA IEs in the
beacon every beacon interval, and updates the
CSA IE count in every beacon.
If the wlan gets suspended in between the
updation of CSA IEs, the CSA is delayed
till the next resume, which could lead to
STA kickout event, if there is delay between
the CSA period, and the channel switch time.
Fix is to take a wakelock till CSA is completed
in order to avoid the STA kickout.
Bug: 138612266
Change-Id: Iff03476433c755cbddc7568ffbd24ddb81fd1c90
CRs-Fixed: 2504039
Signed-off-by: Rajeev Kumar <quic_rajekuma@quicinc.com>
|
|
Change-Id: I6be4d210c011bf532a9fdd3ef6839acb117adcb8
Signed-off-by: Petri Gynther <pgynther@google.com>
|
|
Change-Id: Ied6e4b8f2a2c9cc2fefb989bffb83816b6694212
Signed-off-by: Petri Gynther <pgynther@google.com>
|
|
Remove all calls to cdp_remove_peers_for_vdev().
cdp_remove_peers_for_vdev() is called from vdev_resp_handler
to remove all vdev peers. All the peers associated with the vdev
are deleted before vdev stop and hence this call to
cdp_remove_peers_for_vdev() is redundant.
Delete only the self peer and remove the code to delete the
vdev peers.
Change-Id: I8a91509917a371b860058a66831d8417b3a78671
CRs-Fixed: 2002372
Bug: 135964915
Signed-off-by: Vinay Gannevaram <quic_vganneva@quicinc.com>
|
|
Currently, channel switch validated as true only in case of
safe channel. For unsafe channel, channel switch will be failed.
Change-Id: Ic1d11525c8ad5d93ffb31e5802083e73956704c0
CRs-Fixed: 2494488
Bug: 135760299
Signed-off-by: Vinay Gannevaram <quic_vganneva@quicinc.com>
|
|
BUILD_TAG is enabled by default.
This causes the following git error to be seen during Pixel 3/3a WiFi module build:
fatal: ambiguous argument '~..HEAD': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions, like this:
'git <command> [<revision>...] -- [<file>...]'
Disable BUILD_TAG for Pixel 3/3a WiFi, just like has been done for C2F2 WiFi.
Hand-ported from commit b6328e584e25 ("Wifi: Disable the configuration for BUILD_TAG")
Test: Build Pixel 3/3a WiFi module without errors
Change-Id: Iff3c7eb4ca4adf3b83a99af79b0ee9c8034d159c
Signed-off-by: Petri Gynther <pgynther@google.com>
|
|
In wma_unified_radio_tx_mem_free() function, results buffer array may be
dereferenced with large index value, that may result OOB memory access.
Fix the same by correcting incrementing pointer to results buffer.
Change-Id: I57a26dba9db32758c7d7fd51b99d3364a8020a9d
CRs-Fixed: 2308644
Bug: 136197213
Signed-off-by: Srinivas Girigowda <quic_sgirigow@quicinc.com>
|
|
In wma_unified_radio_tx_mem_free() function, results buffer array may be
dereferenced with large index value, that may result OOB memory access.
Fix the same by correcting incrementing pointer to results buffer.
Change-Id: I57a26dba9db32758c7d7fd51b99d3364a8020a9d
CRs-Fixed: 2308644
Bug: 136197213
Signed-off-by: Srinivas Girigowda <quic_sgirigow@quicinc.com>
|
|
Channel 13 can cause regulatory violation when enabled in world
mode in OFDM mode. Therefore disable channel 13 in world mode.
Bug: 134633080
Test: Check support channel list by "iw list" and "iw reg get" in world
mode
Change-Id: I1fb0531bc23726de448498a90e4508f0714e33a2
CRs-Fixed: 112274312
Signed-off-by: Srinivas Girigowda <sgirigow@codeaurora.org>
|
|
The 3rd party AP with Vendor IE OUI 001018, Vendor Data
02 FF 00 9C 00 00 and NSS 4x4 is not able to handle OMN/SMPS
frames sent by DUT in 2.4Ghz. This leads to the AP dropping
the data rates to 1Mbps and low throughput is seen.
This is because the connection is done with NSS 2x2 and when Coex
scenarios occur, the DUT switches dynamically to 1x1 by sending
OMN/SMPS frames. To overcome this issue, the workaround is to
blacklist the above AP and do connection in 1x1 only.
Add the vendor OUI of the 3rd party AP to gActionOUIConnect1x1
default INI string to connect in 1x1.
Change-Id: Idc0f3238e3521bb20c592b44de77216125e69504
CRs-Fixed: 2352946
Bug: 133798139
Signed-off-by: Rajeev Kumar <quic_rajekuma@quicinc.com>
|
|
When scheduler thread is suspended, it will not process
any messages until it is resumed. If messages are posted
to scheduler thread when it is suspended, it will lead
to KP due to scheduler buffer becoming full.
Add check for hdd_ctx->hdd_wlan_suspended in __hdd_tx_timeout
before posting any message to scheduler.
Change-Id: Ic0bc6ec0dda23e2a6eaf59adb21f0bca5f2707df
Bug: 133292713
CRs-Fixed: 2428339
|
|
Change-Id: I4d3783cff4547c4fb9ff46b401ba592b2da043b9
Signed-off-by: Petri Gynther <pgynther@google.com>
|
|
When scheduler thread is suspended, it will not process
any messages until it is resumed. If messages are posted
to scheduler thread when it is suspended, it will lead
to KP due to scheduler buffer becoming full.
Add check for hdd_ctx->hdd_wlan_suspended in __hdd_tx_timeout
before posting any message to scheduler.
Change-Id: Ic0bc6ec0dda23e2a6eaf59adb21f0bca5f2707df
Bug: 133292713
CRs-Fixed: 2428339
|