summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2020-06-24qcacld-3.0: Process ll stats correctlyandroid-r-beta-3_r0.3android-r-beta-3_r0.2android-11.0.0_r0.8android-11.0.0_r0.3android-11.0.0_r0.23android-11.0.0_r0.22android-11.0.0_r0.2android-11.0.0_r0.10android-msm-crosshatch-4.9-r-beta-3android-msm-crosshatch-4.9-android11android-msm-bonito-4.9-r-beta-3android-msm-bonito-4.9-android11Ashish Kumar Dhanotiya
Currently in the api hdd_process_ll_stats, if the stats type is iface stats in that case the mem copy to the final result uses the size of the structure pointer instead of size of the structure which results in incorrect value for the iface stats. To address above issue use the size of the structure for the memcopy of the iface stats. Bug: 158521704 CRs-Fixed: 2710446 Change-Id: I2b6128f80fa994a5d2ed2fdd2feeaa1ae2e341d3 (cherry picked from commit 8450514e45e4a4a8a74a451ab06b58d19561d56b)
2020-06-08Merge android-msm-pixel-4.9-qt-qpr3 into android-msm-pixel-4.9SecurityBot AutoMerger
SBMerger: 284775313 Change-Id: I6069ec58b48520fa9ff345966137fee79ced0241 Signed-off-by: SecurityBot <android-nexus-securitybot@system.gserviceaccount.com>
2020-06-08Merge android-msm-pixel-4.9-qt-qpr2 into android-msm-pixel-4.9-qt-qpr3android-10.0.0_r0.79android-10.0.0_r0.77android-msm-crosshatch-4.9-android10-qpr3android-msm-bonito-4.9-android10-qpr3SecurityBot AutoMerger
SBMerger: 284775313 Change-Id: Iced89e0c48cf34e4d49071832c9c692cbe46b4af Signed-off-by: SecurityBot <android-nexus-securitybot@system.gserviceaccount.com>
2020-06-08Merge android-msm-pixel-4.9-qt-qpr1 into android-msm-pixel-4.9-qt-qpr2SecurityBot AutoMerger
SBMerger: 284775313 Change-Id: I9f428cfe9b69bc74553e4454435acd5ce5c67c70 Signed-off-by: SecurityBot <android-nexus-securitybot@system.gserviceaccount.com>
2020-06-08Merge android-msm-pixel-4.9-qt into android-msm-pixel-4.9-qt-qpr1SecurityBot AutoMerger
SBMerger: 284775313 Change-Id: If7e19d45847f1932736c291d174c8c68c0ae44d3 Signed-off-by: SecurityBot <android-nexus-securitybot@system.gserviceaccount.com>
2020-06-05Merge branch 'android-msm-pixel-4.9-qt-security-next' into ↵Harrison Lingren
android-msm-pixel-4.9-qt AUG 2020.1 Bug: 157954141 Signed-off-by: Harrison Lingren <hlingren@google.com> Change-Id: I78b3bf5fcd9d56f26dc22d6b2b1c12f6b89c3309
2020-05-27qcacld-3.0: Fix LL Timeout over Debugfsandroid-r-beta-2_r0.3android-r-beta-2_r0.2android-msm-crosshatch-4.9-r-beta-2android-msm-bonito-4.9-r-beta-2Alan Chen
Clear the stats bitmap properly such that LL stats is complete. Bug: 156497381 Change-Id: I1238c438e9d57000006ae46474569c4f2cf60e8f CRs-Fixed: 2690186
2020-05-27qcacld-3.0: Handle tx_power_level under radio statRachit Kankane
Host driver do receives radio tx power level stats as part of radio stats even though we have different event ID for that. Handling the tx_power_level as part of radio stats only if num_tx_power_level is set. Bug: 155942196 Change-Id: I46aff51c70c444c94c9b10f32b7776ba4a1ca4e8 CRs-Fixed: 2686882
2020-05-27qcacld-3.0: Copy peer and radio stats correctlyRachit Kankane
Copy WMI_LINK_STATS_ALL_PEER stats and number of channels in radio stats properly to the buffer. Bug: 153415344 Change-Id: I3219e3c46e93d43f2684ab51a2c5d98a63a3f88e CRs-Fixed: 2649207
2020-05-27qcacld-3.0: Handle LL stats for 2nd radioRachit Kankane
With recent code change, LL stats results are returned in the user space context only. To do that, changes were made to buffer the LL stats results received from FW till the time FW completes it. This change is not taking case where FW sends LL stats for multiple radio which is resulting SKB corruption. Bug: 153415344 Change-Id: I49781f1ea9520ad0d9721536be1861d5d8151ea7 CRs-Fixed: 2649207
2020-05-27qcacld-3.0: Return LL stats resp in caller contextRachit Kankane
Return response for Link Layer stats command in caller thread's context Bug: 153415344 Change-Id: I8a6a0b21d7915cd21422dbef9b87fa17d99fb244 CRs-Fixed: 2619295
2020-05-27qcacld-3.0: Use request manager framework for LL stats response eventDundi Raviteja
We are transitioning the usage of LL stats response event to request manager framework. Bug: 153415344 Change-Id: Ice8b3d53beb47b345ed569f2b4bf790e9f5ce506 CRs-Fixed: 2274933
2020-05-18qcacld-3.0: Fix while condition in rrm_fill_beacon_ies()Gururaj Pandurangi
In function rrm_fill_beacon_ies, do while loop is checked for BcnNumIes if it is greater than IE length 0. Fix the check to be greater than 2 as the first two bytes is IE header(element ID and IE length fields both 1 byte each.) Bug: 155654263 Change-Id: I11e5de481cd49a22acafee938fbe73f839f5b0e4 CRs-Fixed: 2626729
2020-05-18qcacld-3.0: Fix integer overflow in rrm_fill_beacon_ies()Pragaspathi Thilagaraj
In function rrm_fill_beacon_ies, the total IE length is calculated as sum of length field of the IE and 2 (element id 1 byte and IE length field 1 byte). The total IE length is defined of type uint16_t and will overflow if the *(pBcnIes + 1)=0xfe. Validate the len against total IE length to avoid overflow. Bug: 155653491 Change-Id: If8f86952ce43c5923906fc6ef18705f1785c5d88 CRs-Fixed: 2573329
2020-05-18qcacld-3.0: Validate assoc response IE len before copyAshish Kumar Dhanotiya
When host sends ft assoc response to supplicant, it allocates a buffer of fixed size and copies a variable length of assoc response IEs to this fixed sized buffer. There is a possibility of OOB write to the allocated buffer if the assoc response IEs length is greater than the allocated buffer size. To avoid above issue validate the assoc response IEs length with the allocated buffer size before data copy to the buffer. Bug: 155654321 Change-ID: Ife9c2071a8cc4a2918b9f349f4024478f94b2d78 CRs-Fixed: 2575144
2020-05-08Merge android-msm-pixel-4.9-qt-qpr3 into android-msm-pixel-4.9android-r-beta-1_r0.3android-r-beta-1_r0.2android-msm-crosshatch-4.9-r-beta-1android-msm-bonito-4.9-r-beta-1SecurityBot AutoMerger
SBMerger: 284775313 Change-Id: I5010c14c1ba7d852017118894cab60acbb9b56ef Signed-off-by: SecurityBot <android-nexus-securitybot@system.gserviceaccount.com>
2020-05-08Merge android-msm-pixel-4.9-qt-qpr2 into android-msm-pixel-4.9-qt-qpr3SecurityBot AutoMerger
SBMerger: 284775313 Change-Id: I2837d212e9139f74a21bf6ee062cfd900b16cf94 Signed-off-by: SecurityBot <android-nexus-securitybot@system.gserviceaccount.com>
2020-05-08Merge android-msm-pixel-4.9-qt-qpr1 into android-msm-pixel-4.9-qt-qpr2SecurityBot AutoMerger
SBMerger: 284775313 Change-Id: Id67342a31d51a7b2c047449c175ddad3beb360d6 Signed-off-by: SecurityBot <android-nexus-securitybot@system.gserviceaccount.com>
2020-05-08Merge android-msm-pixel-4.9-qt into android-msm-pixel-4.9-qt-qpr1SecurityBot AutoMerger
SBMerger: 284775313 Change-Id: Ia01b61ae8445daaec5540a17191b2973de1350da Signed-off-by: SecurityBot <android-nexus-securitybot@system.gserviceaccount.com>
2020-05-04Merge 'android-msm-pixel-4.9-qt-security-next' into android-msm-pixel-4.9-qtHarrison Lingren
JUL 2020.1 Bug: 155195707 Signed-off-by: Harrison Lingren <hlingren@google.com> Change-Id: I7cf4254f80bba478b7755f7d42ef40562eeea112
2020-04-28qcacld-3.0: Add max index check for dscp_to_up_map arrayAbhishek Ambure
In SME layer, boundary check for dscp_to_up_map array is not present. The dscpmapping is an array of 0x40 elements. Values in dscp_exceptions are used to index dscpmapping. The indices are not validated to be less than 0x40. The dscp_exceptions array is received from association response frame. A malicious AP can send values up to 0xff, causing OOB write of dscpmapping array. Hence, max index check is added to avoid OOB write of dscpmapping array. Bug: 153345312 Test: Regression test Change-Id: I73526849677e867673fc0bd0024ed2b003e4f89e CRs-Fixed: 2569764
2020-04-21qcacld-3.0: Fix possible memleak in send_assoc_reqSrinivas Dasari
Allocated a memory to hold the mbo IEs stripped from IEs received from userspace. But this buffer is not freed in all failure cases. Move the freeing to a common label "end" to free the buffer in all cases. Bug: 153759907 Change-Id: I7ad268fed1898ac9f62e30eb4bd3740cce9bb4bc CRs-Fixed: 2662225 Signed-off-by: Sunil Ravi <sunilravi@google.com>
2020-04-20qcacld-3.0: Append MBO IE from supplicant to Assoc Request FrameSunil Ravi
The MBO IE sent from the supplicant supports multiple TLVs of the same attribute type to be present. For example, for MBO case 5.2.8, the supplicant sends 2 non-Preferred channel TLVs in the MBO IE. However, when the driver unpacks the MBO IE for the Assoc Request frame using frame parser, it supports only one unique TLV of each attribute type in the MBO IE. So the second non-Preferred channel TLV overwrrites the first TLV and the driver sends out Assoc Request frame with only one non-Preferred Channel TLV in the MBO IE causing the test case to fail. Strip the MBO IE in the Additional IEs from supplicant and append it to the end of the Assoc request frame without parsing it. Bug: 152716519 Change-Id: I35ede59983ef63268e4648bb38217ebec2454382 CRs-Fixed: 2310297 Signed-off-by: Sunil Ravi <sunilravi@google.com> Change-Id: I12444f0307da716b402ceb5b7913a75fc710cbfc
2020-04-10qcacld-3.0: Update correct MCS parameters in wiphySunil Ravi
Currently MCS parameters are not getting correctly in wiphy which results in incorrect capabilities for iw list command output. To resolve above issue, update MCS parameters correctly in wiphy band capabilities. Bug: 148982542 CRs-Fixed: 2633314 Change-Id: I830ad50aa4842bd2a79c97ed7b11b82c35148ff0 Signed-off-by: Sunil Ravi <sunilravi@google.com> Change-Id: I2d0d7a8cd7ae05807378d1764bc13c81de44507a
2020-04-08qcacld-3.0: Validate assoc response IE len before copyAshish Kumar Dhanotiya
When host sends assoc response to supplicant, it allocates a buffer of fixed size and copies a variable length of assoc response IEs to this fixed sized buffer. There is a possibility of OOB write to the allocated buffer if the assoc response IEs length is greater than the allocated buffer size. To avoid above issue validate the assoc response IEs length with the allocated buffer size before data copy to the buffer. Bug: 153344687 Test: Regression test Change-ID: Ib12385e9ff04e5172ae8b505faf959e426fda439 CRs-Fixed: 2583124
2020-04-01qcacld-3.0: Select default channel from the acs cfg listandroid-r-preview-3_r0.5android-r-preview-3_r0.3android-msm-crosshatch-4.9-r-preview-3android-msm-bonito-4.9-r-preview-3gaurank kathpalia
Select the default channel from the list that the hostpad gave instead of selecting a default channel which can lead to discrepancy in the channels given by the hostapd and the channel choosen for the SAP. Bug: 149418331 Change-Id: Ib754ebdb4954607181ecea2727bca1e7cc67f39c CRs-Fixed: 2635722
2020-03-27qcacld-3.0: Ignore roaming in progress in start bssgaurank kathpalia
Currently the hotspot fail happens if the roaming is in progress because of the check in start bss. Ignore it and just do disable roaming to the FW. If the roaming was in progress, it would disable it, or it would do a disconnect if the EAPOL was in progress. This is done to enable the hotspot as connect would be taken care by the supplicant automatically, but the hotspot needs user intervention. Bug: 150834409 Change-Id: I0030f9affe60c064d490795be92ae035923738aa CRs-Fixed: 2640136
2020-03-26qcacld-3.0: Connection fails due to reassociation in progressandroid-r-preview-4_r0.5android-r-preview-4_r0.3android-msm-crosshatch-4.9-r-preview-4android-msm-bonito-4.9-r-preview-4Abhinav Kumar
Below are the scenarios where host fails to clear roam in progress flag: Case 1: While processing disconnection request Host should clear roam in progress flag irrespective of connection state of STA. Case 2: While processing a try-disconnect request Currently, Host waits for WLAN_WAIT_TIME_STOP_ROAM (4 sec) to process disconnection, if firmware has already started roaming. In case if Host doesn't receive roam completion indication from fw, Host set connection state to not connected and fails to clear roaming in progress flag. This results host refuses all further connection request with reason connection in progress. Fix is to clear roaming_in_progress flag in both cases. Bug: 147821957 Bug: 150184372 Change-Id: I45d9771bcd546d8914321e3be1a6d0ce6566cdac CRs-Fixed: 2588803
2020-03-16qcacld-3.0: Move two fw-api host headers to driverhangtian
Move wlan_tgt_def_config.h wlan_tgt_def_config_hl.h to driver. Bug: 144319790 Bug: 150182909 Change-Id: I5891d5ef557bb00b9a1632d79aa4c396074e0053 CRs-Fixed: 2474409
2020-03-16qcacld-3.0: Set max BW for each valid channel and send to FWgaurank kathpalia
Configuration for Issue:- DUT configuration:- 1. Configure DUT's country as US where channel 165 does not support channel bandwidth of 40 mhz. AP Configuration:- 1 Configure the AP in a country where channel 165 supports channel bandwidth 40MHZ. Scenario of the issue:- 1.Connect to a diff AP on some channel x with same SSID, and then roam to this AP. Observation:- The DUT would connect in 40 mhz to this AP instead of 20Mhz, which violates the DUT's country reg rules. Expectation:- The DUT should re-connect only in 20Mhz on channel 165, or only in max BW supported by reg in that country. Issue:- The DUT does not consider the max bandwidth allowed for the channel in the country configured, and allow the re-association only in the respective bandwidth. Fix:- Send the max BW supported by the channels in the current reg domain to the FW so that it considers the max BW of the channel and AP capability and then roam in the respective BW only. Bug: 144319790 Bug: 150182909 Change-Id: I1730d6c65d3dd305dcf2ebe340c3d5ad950761d7 CRs-Fixed: 2504900
2020-03-13Merge android-msm-pixel-4.9-qt-qpr3 into android-msm-pixel-4.9SecurityBot AutoMerger
SBMerger: 284775313 Change-Id: I5ac00d045d98033360b8a724d8c5e6ce941d2cc9 Signed-off-by: SecurityBot <android-nexus-securitybot@system.gserviceaccount.com>
2020-03-10qcacld-3.0: Modify default world rule to exclude channel 13android-10.0.0_r0.73android-10.0.0_r0.72android-10.0.0_r0.66android-10.0.0_r0.65android-msm-crosshatch-4.9-android10android-msm-bonito-4.9-android10Amar Singhal
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 Merged-In: I1fb0531bc23726de448498a90e4508f0714e33a2 Change-Id: I1fb0531bc23726de448498a90e4508f0714e33a2 CRs-Fixed: 112274312 Signed-off-by: Srinivas Girigowda <sgirigow@codeaurora.org> (cherry picked from commit 546b2e599547b88fcf075dd28f38ce09f937c732)
2020-03-09qcacld-3.0: Set negotiated auth type to OPEN for SAE-pmk cache caseSunil Ravi
wpa_supplicant sends connect request with open auth and pmkid when PMK caching is enabled and if it has PMK/PMKID cached. Set rsn_auth_type to SAE when connect request has AKM as SAE auth_type as open. Set negotiated auth type to OPEN in SAE with pmk cache case as open authentication going to happen. Similar fix is applicable for FT-SAE. Handle the same. Bug: 150896394 Change-Id: I9ccc419bd439702041840b0194bb0622d7856255 CRs-Fixed: 2467813 Signed-off-by: Sunil Ravi <sunilravi@google.com>
2020-02-28Merge android-msm-pixel-4.9-qt-qpr3 into android-msm-pixel-4.9SecurityBot AutoMerger
SBMerger: 284775313 Change-Id: I5cf3da64d67a909314e82dd08f0189d2b1d1579d Signed-off-by: SecurityBot <android-nexus-securitybot@system.gserviceaccount.com>
2020-02-25qcacld-3.0: Reduce the candidate list to 5 in roam cmd for SAE authAbhinav Kumar
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. Merged-In: Ic43f44ef14ea4c3b972635682941a624cdc6dcc7 Change-Id: Ic43f44ef14ea4c3b972635682941a624cdc6dcc7 CRs-Fixed: 2551462 bug: 143129445 Signed-off-by: Isaac Chiou <isaacchiou@google.com> (cherry picked from commit 49dd69705899ad2ee3266b0e3b0727f978d69dd1)
2020-02-25qcacld-3.0: Fill Channel width for add_sta params from session entryVignesh Viswanathan
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 Merged-In: Idb1907abebf32a34f88e935a30ebb8f1bce1d59c Change-Id: Idb1907abebf32a34f88e935a30ebb8f1bce1d59c CRs-Fixed: 2324434 Signed-off-by: Isaac Chiou <isaacchiou@google.com> (cherry picked from commit dbee01d90764fd2d9c9cabb1d700ae1cf286eca6)
2020-02-25qcacld-3.0: setup IPA sys pipes if ipa_wdi_init succeedsVevek Venkatesan
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 Merged-In: Iee9783b0238a3bc96a2e73e47ffebf3b44623485 Change-Id: Iee9783b0238a3bc96a2e73e47ffebf3b44623485 CRs-Fixed: 2573929 Signed-off-by: Isaac Chiou <isaacchiou@google.com> (cherry picked from commit 9de09b5a744d931ad99e350cb6bc0642c54424a3)
2020-02-24qcacld-3.0: Prevent wlan suspend if conn in progressgaurank kathpalia
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 Merged-In: Ic173116f7ba424005d938a43c75831a6a4dc874c Change-Id: Ic173116f7ba424005d938a43c75831a6a4dc874c CRs-Fixed: 2512866 Signed-off-by: Isaac Chiou <isaacchiou@google.com> (cherry picked from commit 276984563e07e788f8d75f1257c12227593c4032)
2020-02-07Merge android-msm-pixel-4.9-qt-qpr3 into android-msm-pixel-4.9android-r-preview-2_r0.5android-r-preview-2_r0.3android-msm-crosshatch-4.9-r-preview-2android-msm-bonito-4.9-r-preview-2SecurityBot AutoMerger
SBMerger: 284775313 Change-Id: I16ea4d301133808d9420fef27e57461df72e1377 Signed-off-by: SecurityBot <android-nexus-securitybot@system.gserviceaccount.com>
2020-02-07Merge android-msm-pixel-4.9-qt-qpr2 into android-msm-pixel-4.9-qt-qpr3SecurityBot AutoMerger
SBMerger: 284775313 Change-Id: Ib284d387c70a2d666a998ba0ad933309b9dcaee0 Signed-off-by: SecurityBot <android-nexus-securitybot@system.gserviceaccount.com>
2020-02-07Merge android-msm-pixel-4.9-qt-qpr1 into android-msm-pixel-4.9-qt-qpr2android-10.0.0_r0.62android-10.0.0_r0.61android-10.0.0_r0.54android-10.0.0_r0.52android-msm-crosshatch-4.9-android10-qpr2android-msm-bonito-4.9-android10-qpr2SecurityBot AutoMerger
SBMerger: 284775313 Change-Id: Ib1be65dca032e096e4a648254bc294e1940bf83b Signed-off-by: SecurityBot <android-nexus-securitybot@system.gserviceaccount.com>
2020-02-07Merge android-msm-pixel-4.9-qt into android-msm-pixel-4.9-qt-qpr1SecurityBot AutoMerger
SBMerger: 284775313 Change-Id: I3760f7d8135a80c90e6da7b065283d14a5e44de6 Signed-off-by: SecurityBot <android-nexus-securitybot@system.gserviceaccount.com>
2020-02-05Merge branch 'android-msm-pixel-4.9-qt-security-next' into ↵Harrison Lingren
android-msm-pixel-4.9-qt APR 2020.1 Bug: 148866250 Change-Id: I7cdf29aa3bf0c15759fc17c849b1844213c85f6c Signed-off-by: Harrison Lingren <hlingren@google.com>
2020-02-04qcacld-3.0: Lower down the channel BW in 2.4ghz casegaurank kathpalia
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>
2020-02-03qcacld-3.0: Lower down the channel BW in 2.4ghz casegaurank kathpalia
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>
2020-01-31qcacld-3.0: Use policy mgr safe ch list in ACSgaurank kathpalia
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>
2020-01-08qcacld-3.0: Possible OOB write in rrm_process_radio_measurement_requestHsiu-Chang Chen
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>
2020-01-06qcacld-3.0: Takecare to stop and down vdev in monitor modeVulupala Shashank Reddy
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>
2019-12-20Merge android-msm-pixel-4.9-qt-qpr2 into android-msm-pixel-4.9android-r-preview-1_r0.5android-r-preview-1_r0.3android-msm-crosshatch-4.9-r-preview-1android-msm-bonito-4.9-r-preview-1SecurityBot AutoMerger
SBMerger: 284775313 Change-Id: Ib3cf65c3cd343a76a830ec7d77d60bd863ba7a71 Signed-off-by: SecurityBot <android-nexus-securitybot@system.gserviceaccount.com>
2019-12-16qcacld-3.0: Fix logic to drop duplicate deauth/disassoc framesandroid-10.0.0_r0.48android-10.0.0_r0.47Abhishek Singh
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>
generated by cgit v1.2.3 (git 2.25.1) at 2024-06-26 20:18:17 +0000