WiFi P2P connection fails occasionally, i collect the netsh trace, please help to parse

Hi @Gatlin Le (WICLOUD CORPORATION)

Other informations you nedd are followed:

Detailed analysis from the Android side:

10-17 02:32:01.875 Android starts sending Provision Discovery Request with config methods 0x80.

10-17 02:32:01.913 Android receives Provision Discovery Response from Windows with config methods 0x80.

Android then repeatedly sends Probe Request scans, waiting for the target GO to have an active PBC Registrar.

10-17 02:32:21.365 The Android app hits connection timeout and cancels the connection. The Android system sends another Provision Discovery Request to Windows.

10-17 02:32:21.473 Android receives the Provision Discovery Response from Windows.

Windows side:

The timestamps for ConnectionStatusChanged and ConnectionRequested logs are captured at the entry of each callback.

The OnConnectionStatusChanged callback logic is simple; it only sends out a broadcast and should not cause blocking. I will add logs later to record the exit timestamp for verification.

Hi @Xiaojie Ma ,

Thank you for sharing the failing trace. It covers the 02:32 attempt. The decoded events show two Provision Discovery (PD) exchanges, with pairing starting only after the second one.

Using Windows trace time (UTC+8), the first ProvisionDiscoveryResponseSent occurs at 02:32:02.191. In the decoded events, I found no pairing initiation or WPS activation between that response and the second one at 02:32:21.749. BeginPendingSession then appears immediately, followed by WPSEnabled=true at 02:32:22.115. In the successful capture, WPS was enabled about 0.3 seconds after the PD response. This is consistent with Android probing for an active PBC Registrar after the first exchange and not finding one.

Your ConnectionRequested callback at 02:32:21 falls in the same second as the second exchange, so it most likely corresponds to that request rather than to delayed handling of the first. Some events remain undecoded, and the trace does not directly link the callback to a specific request, so this is not yet confirmed. The main open question is therefore why the first PD did not start a session.

About 30 seconds after WPS was enabled, the WLAN service records ConnectionComplete with ErrorCode=1460 (timeout). Android had already cancelled at 02:32:21.365, so this timeout is likely a consequence of that cancellation rather than the original failure.

Regarding the clock offset, Windows logs each PD response as sent about 0.28 seconds after Android logs receiving it (02:32:02.191 vs 02:32:01.913, and 02:32:21.749 vs 02:32:21.473). These are different logging points, so this is not an exact offset, but it is inconsistent with Android being two seconds ahead. Could you share how the two-second difference was measured?

The first PD response also precedes the previous peer's WFDMgrNotifyPeerStateChanged at 02:32:02.745, which lines up with your ConnectionStatusChanged callback at 02:32:02. The approximately 5-second disconnect-to-notification interval also occurs in the successful capture, so it is not sufficient evidence of a fault. For a controlled comparison, start the next Android attempt after the previous Windows disconnect callback returns, keeping other settings unchanged. Use the planned entry/exit logs with millisecond timestamps, and record when the old WiFiDirectDevice is closed or released. This tests whether overlapping cleanup contributes; it is not a confirmed fix.

Finally, when did Android disconnect the previous connection? The GO recorded the disconnect at 02:31:57.7, about 4.4 seconds before the new request.

Thank you.

Hi @Gatlin Le (WICLOUD CORPORATION)

1. I agree with your observation that ConnectionRequested is triggered by the second PD. The core question now is why the first PD failed to start the session.
2. Regarding the time offset: I manually ran the date command in adb shell while checking the Windows clock at the bottom-right corner (seconds display enabled). This method may introduce some deviation, and the time error is larger than I expected.
3. At 10-17 02:28:39, Android starts disconnection and sends disassoc frames to notify the peer. This is the cleanup action at the end of the previous test round. Does Windows GO rely on this disassoc frame to record the disconnection event?

Hi @Xiaojie Ma ,

The trace sequence and your callback timing point to the second PD, so the remaining question is why the first PD did not start a session.

A received disassociation or deauthentication frame is one way Windows GO can learn that a peer disconnected. Microsoft's disconnect documentation also describes OS-initiated disconnects and detection that a peer is no longer present. Android logging a transmission does not confirm Windows received and processed it. Likewise, ConnectionStatusChanged is an application notification, not the time of frame reception.

Your cleanup timestamp adds an important gap: Android reports sending disassociation frames at 02:28:39, while Windows records GODisconnectionReceived and WfdGOPeerDisconnected around 02:31:57.7. Comparing these timestamps gives about 3 minutes 19 seconds. The paired PD timestamps suggest a much smaller clock difference, although they do not establish an exact offset. Before treating this as a delayed disconnect, it is necessary to confirm that both records refer to the same connection.

The ETL starts at 02:31:48.490 on October 17 (UTC+8), so it cannot show what Windows received around 02:28:39. Within the Windows trace, the first PD response occurs about 4.4 seconds after the GO disconnect event and before WFDMgrNotifyPeerStateChanged at 02:32:02.745. Unfinished processing of the previous disconnect remains a possibility, but this ordering does not establish the cause of the session failure.

Did any other connection or test round occur between 02:28:39 and 02:32:01? Please also share the Android disassociation log through the existing private conversation, including its timestamp, reason code, and any available TX status or ACK result. An earlier ETL covering that cleanup would help correlate it with Windows. If that period was not captured, include the previous round's cleanup through the next connection attempt in the next capture.

Thank you.

Hi @Gatlin Le (WICLOUD CORPORATION)

1. I save one ETL trace for each full test run from start to finish. The timestamp of the previous Wi-Fi Direct disconnection is captured in a separate ETL file, which I can share with you later.
2. According to logs from my Windows application, there were no other connections between the prior test and this failing test (between 02:28:39 and 02:32:01).
3. My current over-the-air capture program does not cover the air traffic during disconnection. I will modify the test script later so the Wi-Fi air capture runs for the full lifecycle, from connection start through disconnection.
4. I will organize and send the Android-side disconnection logs to you.

Hi @Xiaojie Ma ,

Thank you for providing the Android logs and confirming that your application recorded no connections between the two test runs. I agree that the Android logs do not establish whether Windows received a disconnect frame. They show a local deauthentication request at 02:28:38.775 with reason=3 (DEAUTH_LEAVING), followed by a locally generated disconnect indication. Neither entry is a frame transmission or acknowledgment record, so the actual over-the-air frame type and delivery remain unverified.

The PBC scan results also provide a useful successful baseline. Android first reports inactive PBC at 02:28:00.094, then active PBC at 02:28:00.429, 335 ms later on the same clock. Separately, Windows enables WPS about 285 ms after its PD response in this run. The initial inactive-PBC scan alone therefore does not indicate the failure seen in the later test.

For teardown, Windows records the GO disconnect around 02:28:39.090 and the service's peer-state notification at 02:28:44.101. These timestamps are consistent with the Android cleanup you describe, although the separate clocks and logging points prevent an exact delivery-latency measurement. Windows had already recorded this disconnect before the additional sequence at 02:31:57.7; that later sequence and its possible relationship to the first PD remain unexplained.

The next useful check is whether the Windows application logged ConnectionStatusChanged around 02:28:44, as well as the notification already reported at 02:32:02. Please share the matching application-log excerpt through the existing private conversation. That would distinguish the service notification from its delivery to your handler.

Your plan to extend the air capture through disconnection will help. Since each ETL covers a separate test run, please also keep Windows ETW and the air capture running between runs. The current files leave the period from 02:29:11 to 02:31:48 uncovered, which limits investigation of the additional disconnect sequence.

Hi @Gatlin Le (WICLOUD CORPORATION)

I rechecked the Wi-Fi Direct logs from my application.

There was another connection at 10-17 02:31:36.797 within the window of 02:28:44 ~ 02:32:02.

I will analyze this connection from the Android side, including its setup and disconnection timing.

Hi @Gatlin Le (WICLOUD CORPORATION)

The connection at 10-17 02:31:36 was unexpected. It was torn down at 02:31:57. On Windows, the ConnectionStatusChanged callback fired at 02:32:02 to report disconnection. Before this callback, Android had already sent the next Provision Discovery Request.

My hypothesis for the failing test case: the first PD did not trigger ConnectionRequested because Windows still considered this device to be online.

Hi @Xiaojie Ma ,

Thank you for rechecking the logs and identifying the unexpected connection. Your hypothesis that a peer/session state transition affected the first PD is plausible, but the available trace does not yet confirm why that request failed to start a session.

This corrects my earlier interpretation of the disconnect timing. The previous round's disconnect was logged by your app at 02:28:44.102. The later notification at 02:32:02.746 belongs to the unexpected 02:31:36 connection you identified. Both application timestamps closely match their respective Windows service notifications, so the apparent delay of several minutes is resolved.

The unexpected connection also differs from the other successful attempts in this application log. The app records its connection attempt at 02:31:36.797 and reports success 35 ms later, compared with 3,227 to 3,395 ms for the other seven successes. Its subsequent disconnect entry records a different remote IP address. These are useful clues for your Android analysis, but the application's elapsed time does not establish the duration or sequence of the complete PD/WPS exchange.

For the failing request, the first PD response at 02:32:02.191 precedes the Windows peer-state notification at 02:32:02.745 by about 554 ms. However, the GO had already recorded the link disconnect at 02:31:57.743. The question is whether some higher-level peer/session state was still pending when the first PD was processed. The decoded events do not show whether the first request was suppressed because the peer was still considered online.

After the second PD, the app logs another connection attempt at 02:32:21.890. It remains pending after the initial 6-second wait and eventually reports 0x800705B4 after about 30.3 seconds. This is the HRESULT form of Win32 error 1460, ERROR_TIMEOUT, matching the WLAN service timeout. It confirms the later attempt's outcome, but does not explain the first PD's failure to start a session.

In the Android analysis you are preparing, please identify what initiated the unexpected connection and correlate its setup and teardown with the Windows log. On the application side, please clarify when, or whether, its WiFiDirectDevice was closed or released. The log contains Disonnect entries during Stop, but no explicit close or release entry for this connection before the first PD. Please also clarify what triggered GetGOChannel at 02:32:01.568, shortly before the first PD response. These details would help establish what the app and Android were doing during that transition.

For the next capture, start Windows ETW and the air capture before the application starts the publisher, and keep both running through disconnection and between runs. The current failing ETL starts at 02:31:48.490, after the unexpected connection's setup. Please share the matching captures through the existing private conversation.

For a controlled comparison, change only the timing of the next Android attempt: wait until Windows reports Disconnected and the app finishes handling that notification, while keeping the existing cleanup logic and other settings unchanged. Compare repeated runs with the current timing and check whether ConnectionRequested and WPS activation follow the first PD. Please include the failure count and total attempts for each timing condition. If the unexpected connection recurs, please note it separately, since its origin may matter more than the timing of the next attempt. This tests the transition hypothesis; it is not a confirmed fix.

Hi @Gatlin Le (WICLOUD CORPORATION)

The unexpected connection at 02:31:36 on Oct 17 is unexpected only from our test workflow. It happened because we modified the SSID for Android Wi‑Fi connection, and our Android app automatically connected to the Windows GO when the screen woke up. From Windows’ perspective, this connection is no different from previous ones, and its disconnection behaves the same. The only difference is the shorter interval between the disconnection of this unexpected link and the next normal connection attempt. I’m concerned this may affect the timing of the ConnectionStatusChanged callback.

Among my 8 connection failures, 7 occur under this scenario. I plan to focus on verifying the following items:

1. Whether Windows PC’s ConnectionStatusChanged is triggered promptly when Android tears down the Wi‑Fi Direct connection. If not, how long is the delay before it fires.
2. If a new connection is initiated before ConnectionStatusChanged from the prior connection completes on Windows, whether the first PD will inevitably fail to trigger ConnectionRequested.

I will also collect test traces. If my hypothesis is validated, I will share them with you for review.

Hi @Xiaojie Ma ,

That identifies the source of the earlier connection and makes the shorter reconnect interval the next comparison to prioritize. Finding this scenario in 7 of 8 failures supports investigating it, but does not establish that every attempt in that timing window must fail.

For your first check, the existing captures already provide a baseline. The GO records a disconnect at 02:28:39.090, followed by your app notification at 02:28:44.102. In the failing run, the corresponding times are 02:31:57.743 and 02:32:02.746. Both intervals are about 5 seconds, and in each case the app log follows the Windows service notification within about 2 ms. These samples do not show the shorter reconnect interval increasing the notification delay. They show the first PD occurring before that notification in the failing run.

The API documentation describes ConnectionStatusChanged as a connection-status notification but does not specify a delivery deadline. The observed 5-second interval is therefore a measurement to compare across runs, not enough by itself to classify the behavior as expected or defective.

Please keep the callback-entry timestamps and add the exit timestamps you planned, without changing the handler's behavior. This separates the time before the callback starts from the time spent executing it. Calculate Windows intervals from ETW and application timestamps on the same clock, and correlate Android and air-capture events rather than applying the earlier manual clock offset.

For your second check, compare attempts started before callback entry with attempts started after callback exit, keeping the connection path, cleanup logic and other settings unchanged. If an attempt starts while the handler is running, record that separately. Count both successes and failures for each condition and check whether ConnectionRequested and WPS activation follow the first PD. Please also keep the eighth failure separate for comparison, since the shorter-gap scenario may not explain every failure.

Please share traces and matching application logs from successful and failing runs through the existing private conversation, even if the results do not confirm the hypothesis. Start capture before the automatic connection and keep it running through its teardown, the next PD and both callback entry and exit. That comparison can help determine whether the failure follows the notification timing or persists after the previous callback has finished.

Thank you.

Hi @Gatlin Le (WICLOUD CORPORATION)

My targeted testing covers three connection attempts. The first two succeeded, while the third failed.

With AI tool analysis, we found the Android device clock is 820 ms ahead of Windows.

Attempt 1

Android:

Starts connection and sends Provision Discovery Request at 14:22:29.957; disconnects at 14:23:00.645

Windows:

ConnectionRequested fires at 14:22:29.344 and exits at 14:22:33.335

ConnectionStatusChanged is triggered at 14:23:04.806 to report disconnection

Attempt 2

Android:

Starts connection and sends Provision Discovery Request at 14:23:30.043; disconnects at 14:23:59.535

Windows:

ConnectionRequested fires at 14:23:29.674 and exits at 14:23:33.220

After Android disconnects, Windows does not trigger ConnectionStatusChanged.

Attempt 3

Android:

Starts connection and sends Provision Discovery Request at 14:24:03.853

Receives Provision Discovery Response at 14:24:03.930

Android keeps waiting for Windows afterwards

Cancels connection at 14:24:50.821 and sends another Provision Discovery Request, which fails to transmit. Retransmission succeeds at 14:24:52.544

Windows:

The disconnection event from the second connection was never reported. For the third attempt, ConnectionRequested was never triggered.

Hi @Xiaojie Ma ,

From the latest logs you shared through private message. This capture separates the notification delay from the time spent in the handler, and also shows two later PD requests that need further context.

The GO records a peer disconnect at 14:22:59.796. The service notification and your OnConnectionStatusChanged entry both fall in the 14:23:04.806 millisecond, and the exit is logged at 14:23:04.809. The interval from the GO peer-disconnect record to handler entry is about 5.01 seconds. The entry and exit markers are 3 ms apart. This sample does not support a long-running handler as the explanation for that 5-second interval.

The next PD response at 14:23:29.479 is about 24.7 seconds after that exit marker. It is followed by a pending session, ConnectionRequested at 14:23:29.674, WPS activation, and application success at 14:23:33.220. This demonstrates a successful reconnect after the callback's logged exit, but does not test the window immediately before or during that callback.

The trace also records PD responses at 14:24:03.182 and 14:24:51.815, with the WLAN service logging WFD_INCOMING_PROVISION_DISCOVERY_REQUEST for both. Neither is followed by another BeginPendingSession or WPS enable event in the decoded trace, and the supplied app log contains no further ConnectionRequested entry. After the second successful connection, I also do not see another decoded WfdGOPeerDisconnected or disconnected notification before the ETL ends. Some events remain undecoded, so this does not establish why those later requests did not advance.

Could you describe what was changed or being tested in SpecialTest, and whether those later PD requests came from the same Android device after tearing down the connection established at 14:23:33? Please include the corresponding Android teardown and PD log excerpt, or air capture if available, through the existing private conversation. That would help distinguish a request made while the connection remained active from a reconnect after Android had already disconnected.

The ETL ends at 14:25:23.349, while the app's final Stop begins at 14:30:33.485, so that final Stop sequence is outside this capture.

Hi @Xiaojie Ma ,

Thank you for mapping the three attempts to the logs. This clarifies that Android disconnected after attempt 2 and that the two later PD exchanges belong to the failed attempt 3, including its cancellation and retransmission sequence.

The important difference from attempt 1 is that, after the second successful connection, the decoded ETL contains no further WfdGOPeerDisconnected or disconnected service notification before it ends at 14:25:23.349. Your application log also has no corresponding ConnectionStatusChanged entry. This gives a reason to investigate how the second teardown was detected and processed, beyond the approximately 5-second notification interval measured for attempt 1.

The PD responses at Windows 14:24:03.182 and 14:24:51.815 both have corresponding incoming-request records in the WLAN service, but neither is followed by a new pending session, WPS activation or an application ConnectionRequested entry in the available data. The decoded events do not show whether the first request was suppressed because the peer was still considered online. Some events remain undecoded, so this is not yet a confirmed cause.

Your Android timestamps place the start of attempt 3 only 4.318 seconds after the reported disconnect of attempt 2, without needing any clock adjustment. This supports testing the short reconnect interval, but does not establish that a request in that interval must fail or that the previous callback was executing. The later PD occurred around cancellation, so it is not a separate fourth connection attempt.

I would treat the 820 ms offset as approximate for now. Subtracting it from Android's PD response receipt at 14:24:03.930 gives Windows 14:24:03.110, about 72 ms before the ETL response-sent record. Could you share which matching events and logging points were used to derive that offset?

The most useful next evidence is the Android teardown excerpt around 14:23:59.535, compared with attempt 1's teardown, including any deauthentication/disassociation reason and TX status or acknowledgment information available. Please share that and any air capture covering the second teardown through the existing private conversation. This can help determine whether the teardown reached the Windows GO and where the disconnect sequence stopped progressing.

Hi @Gatlin Le (WICLOUD CORPORATION)

1. The AI tool reads the Android Unix timestamp via adb and the Windows timestamp. It ran 7 measurement cycles, yielding an average time offset of 817 ms. The value was rounded to 820 ms to account for adb communication latency.
2. From air capture analysis: During the first disconnection, Android sent a Deauth frame to the GO, and the GO replied with a Disassociate frame. For the second disconnection, no Deauth frame from Android to the GO was observed in the air capture.

From 14:23:59.535 when Android started tearing down the Wi‑Fi Direct connection until I stopped the air capture at 14:25:22, the GO kept transmitting frames toward Android, but none received an ACK. This likely explains why the Windows Wi‑Fi chip never reported the peer disconnection on the second attempt. It seems the Wi‑Fi driver lacks a fallback mechanism for this scenario.

Hi @Xiaojie Ma ,

Your air-capture findings strengthen the case for investigating how the GO detects loss of the previous connection. They do not yet establish that the driver has no fallback mechanism.

Microsoft's WDI and WiFiCx documentation describes both explicit disconnection from received Deauth/Disassociate frames and implicit disconnection when the peer can no longer be detected. Those pages do not specify a peer-loss detection timeout for this situation. The remaining question is whether detection was delayed, failed, or was not propagated through the disconnect notification path.

Your report that no Deauth was observed during the second teardown, followed by GO transmissions with no observed ACKs, is consistent with the missing decoded WfdGOPeerDisconnected, service notification and application ConnectionStatusChanged through the available capture. It makes incomplete removal of the previous peer state a stronger hypothesis for attempt 3. The decoded events still do not show whether that state prevented the new session, and some events remain undecoded.

Thank you also for explaining the seven clock measurements. They provide a working offset estimate, but averaging and rounding do not remove uncertainty from the timing of the adb reads. I will keep cross-device timings approximate; no further clock measurements are needed to investigate the prolonged lack of a disconnect notification described here.

Please share the relevant air-capture file or packet excerpt for both teardowns and the later PD exchanges through the existing private conversation, together with the Android teardown log for attempt 2. Please include frame types and retry/ACK or Block ACK details, so the unacknowledged traffic can be matched to the previous peer connection. This will help check whether the second teardown omitted an explicit notification and whether the GO continued retrying traffic that required acknowledgment.

If that comparison confirms repeated unicast failures without a corresponding disconnect indication, the matched air capture, ETL and application logs would support a focused driver/firmware investigation with the PC or Wi-Fi adapter vendor. The current evidence does not identify which component caused the missing disconnect.

Thank you.

Hi @Gatlin Le (WICLOUD CORPORATION)

Unfortunately, I did not save the air capture file just now. I will re-capture the full logs and share the analysis results with you later.

I think we are seeing two kind issues:

1. Peer offline reported with around 5 seconds delay: When the peer sends a Deauth frame on disconnection, Windows fires ConnectionStatusChanged after roughly a 5‑second delay. This was the issue I observed in my early tests. It only temporarily affects connections to this single device within that 5-second window.
2. Peer offline is not reported for a very long time (and may never be reported, requiring long-duration testing): The peer does not send a Deauth frame when tearing down the connection. The PC Wi‑Fi adapter keeps sending frames to the peer with no ACK received. The adapter never reports that the peer has gone offline, which blocks connections to this device for an extended period. This issue emerged during my targeted testing. I also encountered the first issue in the same targeted test runs.

I have contacted the RTL Wi‑Fi engineer to confirm the mechanism by which their Wi‑Fi adapter reports peer offline status.