[WSL 2 (Consomme)] Loopback connections stall under ephemeral port churn: registration fails on 2.7.8.0 and 2.9.4.0, fixed ports immune, Docker excluded

[3900563672]

Windows Version

Microsoft Windows [Version 10.0.26200.9168] (Windows 11 Pro).

WSL Version

2.7.8.0 (Microsoft Store). The same failure reproduces on 2.9.4.0 (Preview channel, 2026-08-19; wsldevicehost.dll v1.2.48.0, built 2026-07-09).

Version note: the guest-side port-tracking fixes #41051 (non-main-thread bind tracking, PIDFD_THREAD) and #41125 (listen() implicit autobind) both first ship in 2.9.5 (tag b4e4ed9e, 2026-08-11). The latest stable 2.7.12 (2026-08-18) does not contain them, and 2.9.4.0 does not either. Verified against the official tags (git merge-base --is-ancestor on a local mirror): merge commits 55d45784 (#41051) and 96b220c7 (#41125) are ancestors of 2.9.5/2.9.6/2.9.7 only, and the fix code (PIDFD_THREAD, listen() ParseListen) is present in the 2.9.5 tree. A third port-range fix, #41085 (mirrored-mode ephemeral-range cap, merge 86b51fc), also first ships in 2.9.5; it is mirrored-specific, while this report is Consomme mode and reproduces on 2.9.4.0, which already contains that path's precursor #40597 - so the observed failures point at the guest-side tracker fixes (#41051/#41125) rather than the mirrored host-side path. As of 2026-08-19 no installable artifacts exist for 2.9.5+ (GitHub releases ship source archives only), so runtime verification on the fixed range is pending its Store release.

Are you using WSL 1 or WSL 2?

WSL 2 (Consomme networking). This machine never runs wslrelay.exe; Windows-side loopback listeners are held by wsldevicehost.dll inside dllhost.exe.

Kernel Version

6.18.33.1-1 (default kernel).

Distro Version

Ubuntu 26.04.

Other Software

• Docker Desktop 29.7.2 - excluded by a three-round ON/OFF control (see Actual Behavior).
• The repro is a single-file Go program (Go 1.26, stdlib only; source below). No other software participates.

Repro Steps

1. Save the following as main.go and run it inside the WSL guest:

package main

import (
	"fmt"
	"net"
	"time"
)

func main() {
	for round := 1; round <= 8; round++ {
		ln, err := net.Listen("tcp4", "127.0.0.1:0")
		if err != nil {
			panic(err)
		}
		port := ln.Addr().(*net.TCPAddr).Port

		start := time.Now()
		dialed := false
		for time.Since(start) < 30*time.Second {
			c, err := net.DialTimeout("tcp4", fmt.Sprintf("127.0.0.1:%d", port), 200*time.Millisecond)
			if err == nil {
				c.Close()
				dialed = true
				break
			}
			time.Sleep(10 * time.Millisecond)
		}
		fmt.Printf("round %d: port %d ok=%v (%v)\n", round, port, dialed, time.Since(start).Round(time.Millisecond))
		ln.Close()
	}
}

2. Observe: round 1 connects in ~50 ms; from round 2 the port is unreachable for the full per-round deadline in most runs. On 2026-08-18 this hit 5/5 runs from a healthy baseline (30 s deadlines); with a 90 s deadline the worst run showed rounds 2 and 4-8 never becoming reachable while rounds 1 and 3 succeeded at ~52 ms.

3. The same loop with -rounds 200 -timeout 30s was used for the 200-round run reported in Actual Behavior; the full probe (with Windows-side verification and fixed-port mode) is available on request.

Expected Behavior

Every fresh ephemeral loopback listener registers and connects within ~50-100 ms, every round, with no degradation within a run. Explicit ports and ephemeral ports behave identically.

Actual Behavior

• Ephemeral (127.0.0.1:0) registrations fail frequently even from a healthy state, and the failure self-amplifies within a run. After a full host reboot: 183/200 (91.5 %) fresh ephemeral binds never became reachable within 30 s; the stall rate worsened monotonically across the run (82 % / 92 % / 94 % / 98 % per quarter), and the longest continuous stall was 49 rounds (>= 24.5 min). The failure is binary: either 11-26 ms success or >30 s unreachable.
• Fixed ports are immune: 29/29 rounds <1.1 ms; 128 concurrent fixed-port binds all reachable.
• Each intercepted bind costs a fixed ~10.4 ms round trip through the synchronous registration chain (guest seccomp -> localhost handler -> GNS channel -> Windows-side bind); latency under concurrent churn tracks concurrency linearly (128-way p50 1.32 s, 99.27 % >1 s) while throughput stays constant at ~96 binds/s. A cache-warm control locates the serialization in the guest-side notification-processing chain.
• Windows-side residue: device-host-owned loopback connections stay in TIME_WAIT for 81-187 s depending on close direction; same-four-tuple reuse fails fast with WSAEADDRINUSE (no SYN transmitted). Source anchor: the installed wsldevicehost.dll v1.2.14.0 matches openvmm commit 0bb5cf75 by trace-line fingerprint (tcp 27/27, udp 7/7, dns_tcp 2/2), where the TimeWait transition has no expiry timer (// TODO: start timer), SYN retransmission is disabled (SIO_TCP_INITIAL_RTO), and the Windows-side socket has no SO_REUSEADDR. Full measurement tables are in my follow-up on hvsocket new-session transport dies after wsl --terminate and after Modern Standby resume (accept4 110); separately, Relay processes stick in accept(12) and log every ~62s until SIGKILL #41286.
• Docker Desktop is not a factor: three rounds after a fresh reboot (ON / OFF / ON) produced identical behavior.

Impact

Local development services that bind ephemeral loopback ports inside WSL (language servers, dev proxies, port-forwarders, test harnesses opening many short-lived connections) become intermittently unreachable from Windows for 30 s+, and the path degrades within a single run. No error appears in the guest or Windows event logs.

Workaround

Use fixed ports: explicit (127.0.0.1:) binds register synchronously and never stalled in 29/29 rounds on this machine.

Diagnostic Logs

• Full WPR networking trace captured with the official collect-wsl-logs.ps1 -LogProfile networking (2026-08-18, ~102 MB, includes a repro run inside the capture window: rounds 1-3 half-blackhole, rounds 4-8 full registration stall).
• A new capture (2026-08-19, WSL core + TCPIP/Winsock providers, 36 s window) is attached in a comment on this issue; it includes a fresh 3-round probe run with a >30 s registration stall in round 3, plus logs.etl, the WSL service traces (service.0-2.etl), appx/optional-component state, the guest network configuration before/after, and the repro program + capture log.
• The ~102 MB bundle remains available via email per CONTRIBUTING.md.
• The complete evidence chain, measurement tables, and a step-by-step repro manual are in my comment on hvsocket new-session transport dies after wsl --terminate and after Modern Standby resume (accept4 110); separately, Relay processes stick in accept(12) and log every ~62s until SIGKILL #41286 (linked above).

Questions

1. Is a TimeWait state without an expiry timer, on a socket without SO_REUSEADDR, intended for loopback connections owned by the device host?
2. Is disabling SYN retransmission (SIO_TCP_INITIAL_RTO) on Consomme sockets intended, given a dropped SYN then has no backstop?
3. The registration failures are consistent with running in the range missing fix: port 0 tracking not working for threads #41051/Track implicit autobind ports from listen() in Consomme networking #41125 (first shipped in 2.9.5), but the self-amplifying degradation (91.5 % stall rate, monotonically worsening) is not obviously explained by those two fixes - is this worth a separate look? I can re-run the full battery on 2.9.5 once it reaches the Store.

Related issues checked before filing

#40109 (bind(0) -> EADDRINUSE), #40187 (port-0 inline resolution), #41039/#41051 (non-main-thread tracking), #41117/#41125 (listen autobind), #40803 (IPv6 port-retention leak), #41162 (mirrored UDP retention), #40597/#41085 (mirrored-mode host ephemeral-range deny/cap - same 2.9.5 boundary, different (mirrored) path), microsoft/openvmm#2313 (TCP retry/timeout acknowledged backlog). None covers this combination (Consomme + TCP loopback + ephemeral churn + registration chain).

[github-actions]

No logs.etl found in the archive. Make sure that you ran collect-wsl-logs.ps1 as administrator and that the logs.etl file is in the archive.

Diagnostic information

appxpackage.txt not found
optional-components.txt not found
No logs.etl found in archive.
Error while parsing the logs. See action page for details

[3900563672]

Logs attached: a fresh WPR capture taken today (2026-08-19, 36 s window, WSL core + TCPIP/Winsock providers) with a 3-round probe run inside the capture window.

• Round 1 (port 43047): healthy, connected in ~14 ms guest-side / ~53 ms Windows-side check.
• Round 2 (port 37825): healthy, ~12 ms / ~53 ms.
• Round 3 (port 45117): stalled for the full 30 s per-round deadline - the failure reproduced while the trace was running.

The archive contains logs.etl, the WSL service traces (service.0-2.etl), appxpackage.txt, optional-components.txt, the guest network configuration before/after, the repro program, and the capture-window repro log.

The full ~102 MB networking trace from the official collect-wsl-logs.ps1 -LogProfile networking (2026-08-18, with the 8-round repro inside it) remains available via email per CONTRIBUTING.md if the wider provider set is needed.

wsl-netlogs-issue41383.zip

[github-actions]

Diagnostic information

Detected appx version: 2.7.8.0

[chemwolf6922]

Hi hh (@3900563672) .
The log suggests this is the same issue fixed in #41051.
You could try out this fix by installing from source. Or use this build I generated several days ago on master that contains this fix: https://github.com/chemwolf6922/build-wsl/actions/runs/31764537928.
Please note this is a dev build and may contain other issues. It's recommended to switch back to a release or pre-release version after the test.

[3900563672]

Hi Feng Wang (@chemwolf6922), thanks for confirming and for the build link.

We will test the dev build with the same port-0 probe used in the report (churn rounds + health-state transient stress) and report the results here. We can also confirm from the official tags that the fix commits (#41051 merge 55d4578, #41125 merge 96b220c) are already ancestors of 2.9.5, so if the dev build clears the window we will re-verify once 2.9.5+ reaches the Store channel.

Plan: run the probe on the dev build, then follow up with the numbers.

[3900563672]

Hi Feng Wang (@chemwolf6922),

We ran the port-0 probe on the dev build as planned. Results:

Test	Dev build (2.9.7.19, c9f0d36)	2.9.4.0 baseline
8-round churn (port 0)	8/8 reachable	2/8
40-round stress	40/40 reachable	5/40
Registration latency (listen → connect)	~1 ms	50–100 ms (healthy state)
Windows-side reachability	8/8	6/8 rounds stalled
Relay error count (UtilAcceptVsock)	0	—

The ephemeral-port registration window is gone on this build: every fresh 127.0.0.1:0 listener became reachable from both the guest and the Windows side, and registration no longer degrades within a run. This is consistent with the #41051/#41125 fix being effective.

We verified the dev build source (c9f0d36) includes both #41051 (merge 55d4578) and #41125 (merge 96b220c); as planned, we will re-run the same probe once 2.9.5+ reaches the Store channel.

Separately, while measuring I noticed the fixed per-connection registration cost is higher than on 2.7.8.0/2.9.4.0 (listen() now takes a synchronous seccomp round trip). I plan to re-measure on the Store release and share the numbers here, in case this is worth a look.

Thanks again for the build link.