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.
  */