[Pre-release 2.7.10] Non-interactive `ssh host <command>` hangs under mirrored networking (OpenSSH IPQoS mid-session retag)

[cavanaug]

Windows Version

Microsoft Windows [Version 10.0.26200.8655]

WSL Version

2.7.10.0 (pre-release)

WSL version: 2.7.10.0
Kernel version: 6.18.33.2-2
WSLg version: 1.0.73.2
MSRDC version: 1.2.6676
Direct3D version: 1.611.1-81528511
DXCore version: 10.0.26100.1-240331-1435.ge-release
Windows version: 10.0.26200.8655

Are you using WSL 1 or WSL 2?

• WSL 2
• WSL 1

Kernel Version

6.18.33.2-2 (6.18.33.2-microsoft-standard-WSL2)

Distro Version

Debian GNU/Linux 13 (trixie)

Other Software

• OpenSSH_10.0p2 Debian-7+deb13u4 (client inside WSL)
• .wslconfig uses mirrored networking:

[wsl2]
networkingMode=mirrored
firewall=false
dnsTunneling=false
autoProxy=false

• Active NIC at time of repro: Intel Wi-Fi 6 AX201 (also reproduced to LAN host)
• No HP “LiveQoS” NDIS filter present; Microsoft QoS Packet Scheduler (ms_pacer) is enabled

Repro Steps

1. Install WSL pre-release 2.7.10.0 with networkingMode=mirrored.
2. From WSL, use stock OpenSSH defaults (ssh -G <host> reports ipqos ef cs1).
3. Interactive login works:

ssh <host>

4. Any non-interactive remote command hangs after authentication:

ssh <host> true
ssh <host> 'echo ok'
ssh -T <host> true

5. Same hang occurs to LAN hosts and to hosts reached via public DNS/WAN.
6. Workaround restores remote commands:

ssh -o IPQoS=none <host> true
# or in ~/.ssh/config:
# Host *
#     IPQoS none

7. Does not reproduce in either of these controls (same hosts / same style of non-interactive command):
   • Non-WSL (native Windows / non-WSL SSH): ssh <host> <command> works.
   • Non-pre-release / stable WSL (same distro/OpenSSH settings/hosts): ssh <host> <command> works.

Failure is specific to WSL pre-release 2.7.10.0 in this environment.

Expected Behavior

ssh <host> <command> should complete normally (auth, exec, exit), same as interactive ssh <host>.

Actual Behavior

• Interactive ssh <host> succeeds.
• Non-interactive ssh <host> <command> authenticates, then hangs indefinitely (no command output, no exit).
• ssh -vvv shows the session stalls after sending the exec request with channel receive window stuck at 0, e.g. open confirm rwindow 0, and never receives a window adjust / exit-status.
• Immediately after the command channel is set up, the client switches QoS (set_sock_tos / non-interactive path). OpenSSH default is interactive EF, bulk/non-interactive CS1 (IP_TOS 0x20), with a mid-session retag when the session becomes non-interactive (OpenSSH/Debian IPQoS updates in 1:10.0p1-7+deb13u3+).

Diagnostic Logs

Theory: WSL pre-release mirrored networking mishandles OpenSSH’s mid-connection DSCP/TOS change (EF → CS1). Interactive sessions never take the bulk retag path, so they keep working. Stable WSL does not show this failure.

Workaround: IPQoS none (or a single fixed class such as IPQoS ef / IPQoS af21) so OpenSSH does not retag mid-session.

Happy to gather Feedback Hub / networking logs if useful.

[cavanaug]

Confirmation / scope

This does not reproduce outside the WSL pre-release path:

1. Non-WSL (native Windows / non-WSL SSH clients to the same hosts): works — non-interactive ssh <host> <command> completes normally.
2. Non-pre-release WSL (stable WSL, same distro/OpenSSH config/hosts, including mirrored networking as applicable): works — no hang.

Failure is specific to WSL pre-release 2.7.10.0 (kernel 6.18.33.2-2) in this environment.

[github-actions]

Logs are required for review from WSL team

If this a feature request, please reply with '/feature'. If this is a question, reply with '/question'.
Otherwise, please attach logs by following the instructions below, your issue will not be reviewed unless they are added. These logs will help us understand what is going on in your machine.

How to collect WSL logs

Download and execute collect-wsl-logs.ps1 in an administrative powershell prompt:

Invoke-WebRequest -UseBasicParsing "https://raw.githubusercontent.com/microsoft/WSL/master/diagnostics/collect-wsl-logs.ps1" -OutFile collect-wsl-logs.ps1
Set-ExecutionPolicy Bypass -Scope Process -Force
.\collect-wsl-logs.ps1

The script will output the path of the log file once done.

If this is a networking issue, please use .\collect-wsl-logs.ps1 -LogProfile networking instead, following the instructions in Collect WSL logs for networking issues

Once completed please upload the output files to this GitHub issue.

See Collect WSL logs (recommended method).

If you choose to email these logs instead of attaching them to the bug, please send them to wsl-gh-logs@microsoft.com with the GitHub issue number in the subject, and include a link to your GitHub issue comment in the message body, and reply with '/emailed-logs'.

[cavanaug]

Networking logs attached / emailed

Collected with official collect-wsl-logs.ps1 -LogProfile networking on WSL 2.7.10.0 pre-release (networkingMode=mirrored).

Emailed slim networking package to wsl-gh-logs@microsoft.com (subject: microsoft/WSL#41101 networking logs).

/emailed-logs

Package contents (slim)

• pktmon.etl, tcpdump.log, wfpdiag.cab
• Linux/Windows network state before & after repro
• .wslconfig, Lxss registry exports, HNS/VFP state
• ssh-repro/ with ssh -vvv captures for jpc-z9.lan and private4.cavanaughs.org

Omitted only for size limits: full WPR logs.etl (~432MB uncompressed). Full archive is available locally if the WSL team wants it.

Capture notes

During this collection window the hang did not reproduce — ssh -o 'IPQoS=ef cs1' <host> true exited 0 (see verbose logs). The failure remains intermittent on this pre-release; it previously reproduced reliably here, and still does not reproduce on stable WSL or native Windows SSH to the same hosts.

SSH verbose excerpts gist: https://gist.github.com/cavanaug/1466c7bf2de1a1dc9990473fbebfff01

Happy to re-run collection when the hang is actively reproducing (or include the full logs.etl via another channel).

[cavanaug]

/emailed-logs

[github-actions]

Diagnostic information

Found '/emailed-logs', adding tag 'emailed-logs'

[github-actions]

Diagnostic information

Found '/emailed-logs', adding tag 'emailed-logs'

[cavanaug]

Update: currently not reproducible after host reboot (same WSL build)

Status: The hang is not reproducing on this machine right now, even with OpenSSH IPQoS left in the failing posture (IPQoS ef cs1 / stock mid-session retag).

What we verified is unchanged since filing

• WSL still 2.7.10.0, kernel still 6.18.33.2-2 (not a newer WSL activated by reboot)
• OpenSSH still 1:10.0p1-7+deb13u4
• .wslconfig still networkingMode=mirrored

What changed environmentally

• Windows host was rebooted (~2026-07-18). After that, non-interactive ssh <host> <command> completes normally again.
• Verbose SSH still shows the same mid-session DSCP retag path that previously correlated with the hang:
  • interactive / early: IP_TOS 0xb8 (EF)
  • after exec/non-interactive: IP_TOS 0x20 (CS1)
  • then rcvd adjust arrives and the command exits 0
    Previously, after the CS1 retag the channel stalled at rwindow 0 with no window adjust.

Theory
Reboot likely cleared transient mirrored-networking / Wi‑Fi / Hyper‑V (HNS/VFP) state, not a WSL version bump. The OpenSSH client behavior is unchanged; the datapath after the mid-flow DSCP change is healthy again.

This may indicate a deeper latent bug: failure depends on accumulated or wedged network state (uptime, roam, sleep/resume, VPN, filter bindings, etc.) rather than “always broken on this build.” If so, it can reappear over time on the same pre-release + mirrored config even though it looks fine immediately after a clean boot.

Ask
Worth keeping open / watching for recurrence. Happy to re-run collect-wsl-logs.ps1 -LogProfile networking while hung if/when it returns (earlier emailed capture was taken when the hang was not active).