Snap for 7574892 from 7cb4cff2411c92efa1c41f498901865461c1a8ce to sc-release
Change-Id: I723e4c01fe6a0e8d35a5144f012cc8b18af30d05
diff --git a/apps/test/chqts/src/general_test/basic_wifi_test.cc b/apps/test/chqts/src/general_test/basic_wifi_test.cc
index 6833952..af648c9 100644
--- a/apps/test/chqts/src/general_test/basic_wifi_test.cc
+++ b/apps/test/chqts/src/general_test/basic_wifi_test.cc
@@ -24,6 +24,7 @@
#include <shared/send_message.h>
#include <shared/time_util.h>
+#include "chre/util/nanoapp/log.h"
#include "chre/util/time.h"
#include "chre/util/unique_ptr.h"
@@ -31,6 +32,8 @@
using nanoapp_testing::sendFatalFailureToHostUint8;
using nanoapp_testing::sendSuccessToHost;
+#define LOG_TAG "[BasicWifiTest]"
+
/*
* Test to check expected functionality of the CHRE WiFi APIs.
*
@@ -345,26 +348,24 @@
}
const auto *result = static_cast<const chreWifiScanEvent *>(eventData);
- if (isActiveWifiScanType(result)) {
- // The first chreWifiScanResult is expected to come immediately,
- // but a long delay is possible if it's implemented incorrectly,
- // e.g. the async result comes right away (before the scan is actually
- // completed), then there's a long delay to the scan result.
- constexpr uint64_t maxDelayNs =
- 100 * chre::kOneMillisecondInNanoseconds;
- bool delayExceeded = (mStartTimestampNs != 0) &&
- (chreGetTime() - mStartTimestampNs > maxDelayNs);
- if (delayExceeded) {
- sendFatalFailureToHost(
- "Did not receive chreWifiScanResult within 100 milliseconds.");
- }
- // Do not reset mStartTimestampNs here, because it is used for the
- // subsequent RTT ranging timestamp validation.
- validateWifiScanEvent(result);
- } else {
- sendFatalFailureToHostUint8("Unexpected scan type %d",
- result->scanType);
+ if (!isActiveWifiScanType(result)) {
+ LOGW("Received unexpected scan type %" PRIu8, result->scanType);
}
+
+ // The first chreWifiScanResult is expected to come immediately,
+ // but a long delay is possible if it's implemented incorrectly,
+ // e.g. the async result comes right away (before the scan is actually
+ // completed), then there's a long delay to the scan result.
+ constexpr uint64_t maxDelayNs = 100 * chre::kOneMillisecondInNanoseconds;
+ bool delayExceeded = (mStartTimestampNs != 0) &&
+ (chreGetTime() - mStartTimestampNs > maxDelayNs);
+ if (delayExceeded) {
+ sendFatalFailureToHost(
+ "Did not receive chreWifiScanResult within 100 milliseconds.");
+ }
+ // Do not reset mStartTimestampNs here, because it is used for the
+ // subsequent RTT ranging timestamp validation.
+ validateWifiScanEvent(result);
break;
}
case CHRE_EVENT_WIFI_RANGING_RESULT: {
diff --git a/chpp/transport.c b/chpp/transport.c
index 3f1c6cc..f3f7651 100644
--- a/chpp/transport.c
+++ b/chpp/transport.c
@@ -520,6 +520,24 @@
* @param context Maintains status for each transport layer instance.
*/
static void chppProcessResetAck(struct ChppTransportState *context) {
+ if (context->resetState == CHPP_RESET_STATE_NONE) {
+ CHPP_LOGE("Unexpected reset-ack seq=%" PRIu8 " code=0x%" PRIx8,
+ context->rxHeader.seq, context->rxHeader.packetCode);
+ // In a reset race condition with both endpoints sending resets and
+ // reset-acks, the sent resets and reset-acks will both have a sequence
+ // number of 0.
+ // By ignoring the received reset-ack, the next expected sequence number
+ // will remain at 1 (following a reset with a sequence number of 0).
+ // Therefore, no further correction is necessary (beyond ignoring the
+ // received reset-ack), as the next packet (e.g. discovery) will have a
+ // sequence number of 1.
+
+ chppDatagramProcessDoneCb(context, context->rxDatagram.payload);
+ chppClearRxDatagram(context);
+
+ return;
+ }
+
chppSetResetComplete(context);
context->rxStatus.receivedPacketCode = context->rxHeader.packetCode;
context->rxStatus.expectedSeq = context->rxHeader.seq + 1;
@@ -634,8 +652,9 @@
/**
* Resets the incoming datagram state, i.e. after the datagram has been
* processed.
- * Note that it is up to the app layer to inform the transport layer using
- * chppDatagramProcessDoneCb() once it is done with the buffer so it is freed.
+ * Note that this is independent from freeing the payload. It is up to the app
+ * layer to inform the transport layer using chppDatagramProcessDoneCb() once it
+ * is done with the buffer so it is freed.
*
* @param context Maintains status for each transport layer instance.
*/
