Repository navigation
WSLC 2.9.10: E_UNEXPECTED with Mihomo TUN; GNS sets default gateway equal to guest IP #41543
Description
Windows Version
Microsoft Windows [Version 10.0.26200.9168] (Windows 11 Pro 25H2)
WSL Version
2.9.10.0 (pre-release)
Are you using WSL 1 or WSL 2?
- WSL 2
- WSL 1
Kernel Version
6.18.40.1-1 (reported by wsl --version)
Distro Version
Not applicable: this concerns WSLC. No regular WSL distributions are installed.
Other Software
- Clash Verge Rev 2.5.2 with Mihomo TUN. The bundled core version has not been verified.
- Tailscale 1.102.3 is also installed and was active during diagnostics; it has not been independently isolated.
- No Docker Desktop installation is currently present.
- VirtualMachinePlatform is enabled. The failure persists after a full Windows restart.
- No custom WSLC
settings.yamlwas found.
The existing .wslconfig is included for completeness, without assuming that WSLC uses the regular distro networking configuration:
[wsl2]
vmIdleTimeout=-1
networkingMode=mirrored
[general]
instanceIdleTimeout=-1Repro Steps
- Enable Mihomo TUN in Clash Verge Rev. The host TUN network in this environment is
198.18.0.0/30. - Disable the Windows system HTTP proxy.
- Run:
wslc system session terminate
wslc listwslc run --rm hello-world also fails, but wslc list provides a smaller reproduction without an image download.
Expected Behavior
The WSLC session should initialize and list containers with TUN enabled. If this network configuration is unsupported, an actionable error would be helpful.
Actual Behavior
Catastrophic failure
Error code: E_UNEXPECTED
The message is translated from the Chinese UI; the error code is unchanged. wslc system info works.
| Configuration | Result |
|---|---|
| TUN enabled, system proxy disabled | wslc list fails with E_UNEXPECTED |
| TUN disabled, system proxy enabled | wslc list succeeds; hello-world reaches image pulling, then encounters a registry timeout (E_FAIL) |
| TUN re-enabled, system proxy disabled, session recreated | wslc list fails again with E_UNEXPECTED |
The comparison changed both TUN and system-proxy state; not every combination has been independently tested. The trace below identifies a guest route-configuration failure before image fetching. The proxy-only registry timeout is a separate problem, not the subject of this report.
Diagnostic Logs
A focused WPR trace was collected using the WSL profile from this repository's 2.9.10 diagnostics/wsl.wprp, around one failing reproduction, then decoded with tracerpt -of XML -lr. This was not the complete networking collection script.
GNS configures a guest adapter with:
{"IPAddress":"198.18.0.1","PrefixLength":30,"GatewayAddress":""}It then sends this route request for the same guest adapter:
{"RequestType":"Add","ResourceType":"Route","Settings":{"DestinationPrefix":"0.0.0.0/0","Family":2,"Metric":0,"NextHop":"198.18.0.1","SitePrefixLength":0}}The guest reports:
GnsEngine: Error in netlink transaction.
NetlinkResponse.cpp:25: Netlink returned error: -22
The Windows trace records GnsChannel.cpp:68, with the message Error returned from GNS after sending message followed by the route request above, type 55. Result=-1, and hr=0x8000FFFF. This propagates through HcsVirtualMachine.cpp:520 and WSLCVirtualMachine.cpp:475 to the CLI.
The host route snapshot associates 198.18.0.0/30 with Mihomo. The guest's configured IP address and requested default gateway are identical. This suggests an address/gateway selection issue with this TUN configuration, but the underlying cause has not been established.
I searched for related reports and found #41002 / #41003 and #41082 / #41130. Those describe off-prefix gateways and ENETUNREACH; this case records netlink -22 with the gateway equal to the guest address on 2.9.10. If this is already tracked, please feel free to link or close this report as a duplicate.
The full ETL is retained locally and has not been uploaded; relevant excerpts are included above. It can be provided through the documented log-sharing route if needed.
Thank you for your work on WSLC and for taking a look. Please let me know if a specific additional trace or configuration detail would help narrow this down.
Activity
github-actions commentedon Sep 9, 2026
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:
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 networkinginstead, following the instructions in Collect WSL logs for networking issuesOnce 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 [email protected] 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'.
XIYBHK commentedon Sep 9, 2026
Thank you for the guidance. I collected logs using the official
collect-wsl-logs.ps1 -LogProfile networkingscript from an elevated PowerShell session while reproducing the WSLC failure with Mihomo TUN enabled.The Windows-side ETW/WFP/pktmon logs and host networking state are included. No regular WSL distribution is installed on this machine, so Linux-side tcpdump/iptables collection was unavailable; this is a limitation of this capture. The collected ETL again records the route to
0.0.0.0/0via198.18.0.1, with the guest IP also198.18.0.1, followed by netlink error-22.The original archive is 44,054,446 bytes, larger than GitHub’s per-file attachment limit, so I split it into three binary parts and placed each part in a ZIP file. Please download and unzip all three, then concatenate the extracted parts in order. For example, in Windows Command Prompt:
copy /b WslLogs-2026-09-09_11-36-12.tar.gz.part1+WslLogs-2026-09-09_11-36-12.tar.gz.part2+WslLogs-2026-09-09_11-36-12.tar.gz.part3 WslLogs-2026-09-09_11-36-12.tar.gzSHA-256 of the reconstructed
.tar.gz(verified locally from the ZIP contents):Please let me know if a different capture is needed for this WSLC-only setup. Thank you for taking a look.
WslLogs-2026-09-09_11-36-12.tar.gz.part1.zip
WslLogs-2026-09-09_11-36-12.tar.gz.part2.zip
WslLogs-2026-09-09_11-36-12.tar.gz.part3.zip
github-actions commentedon Sep 9, 2026
No logs.etl found in the archive. Make sure that you ran
collect-wsl-logs.ps1as administrator and that thelogs.etlfile is in the archive.Diagnostic information
XIYBHK commentedon Sep 9, 2026
Apologies for the attachment format: the previous ZIP files contain binary parts of the complete official networking archive, so the automated parser cannot inspect them individually. The original archive does contain
logs.etl; it remains available through the three parts and reconstruction instructions above.For automated analysis, I am attaching a separate, directly readable ZIP containing the earlier focused WPR trace described in the issue body. Its
logs.etlis the unmodifiedwsl.etlfrom that capture, renamed for the parser. The text metadata is from the later official networking collection on the same machine; a README inside the ZIP records this provenance. This smaller attachment is a focused reproduction trace, not a replacement for the complete networking capture.Thank you for your patience.
WslLogs-focused-20260909.zip
github-actions commentedon Sep 9, 2026
Diagnostic information
saitanallensantiago26-beep commentedon Sep 11, 2026