Bug Report: WSL2 Network Behavior Diverges from Windows During Mixed Interface Conditions

[99sono]

Windows Version

Microsoft Windows [Version 10.0.26200.6901]

WSL Version

WSL version: 2.6.1.0 Kernel version: 6.6.87.2-1 WSLg version: 1.0.66 MSRDC version: 1.2.6353 Direct3D version: 1.611.1-81528511 DXCore version: 10.0.26100.1-240331-1435.ge-release Windows version: 10.0.26200.6901

Are you using WSL 1 or WSL 2?

• [x] WSL 2
• [ ] WSL 1

Kernel Version

6.6.87.2-1

Distro Version

Ubuntu 24.04

Other Software

No response

Repro Steps

Steps to Reproduce

1. Connect both Ethernet and Wi-Fi to your Windows machine.
2. Ensure Ethernet is active but does not have external internet (e.g., ISP outage).
3. Use PowerShell to ping www.google.com — it succeeds via Wi-Fi (e.g mobile phone personal hotspot).
4. Open WSL2 terminal and run ping www.google.com — it fails with 100% packet loss.
5. Run docker pull ollama/ollama inside WSL2 — it succeeds, albeit slowly.
6. Disconnect the Ethernet cable. You now have just your mobile phone personal hotspot connected to your computer.
7. Retry ping www.google.com in WSL2 — it now succeeds.

(base) sono99@somedesktopcomputer:~()$ ping www.google.com
PING www.google.com (142.250.178.196) 56(84) bytes of data.
^C
--- www.google.com ping statistics ---
11 packets transmitted, 0 received, 100% packet loss, time 10223ms

(base) sono99@somedesktopcomputer:~()$ ping www.google.com
PING www.google.com (142.250.178.196) 56(84) bytes of data.
64 bytes from pnzrha-aj-in-f4.1e100.net (142.250.178.196): icmp_seq=1 ttl=117 time=102 ms
64 bytes from pnzrha-aj-in-f4.1e100.net (142.250.178.196): icmp_seq=2 ttl=117 time=56.8 ms
64 bytes from pnzrha-aj-in-f4.1e100.net (142.250.178.196): icmp_seq=3 ttl=117 time=12.3 ms
64 bytes from pnzrha-aj-in-f4.1e100.net (142.250.178.196): icmp_seq=4 ttl=117 time=15.1 ms
^C
--- www.google.com ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3005ms
rtt min/avg/max/mdev = 12.309/46.522/101.790/36.455 ms
(base) sono99@somedesktopcomputer:~()$ lsb_release -r
No LSB modules are available.
Release:        24.04
(base) sono99@somedesktopcomputer:~()$

The difference between failing to ping and succeeding is on unplugging the ethernet cable.

###WSL2 config

• WSL2 Configuration:

  [wsl2]
  memory=80GB
  processors=0
  networkingMode=mirrored
  

Expected Behavior

WSL2 demonstrates inconsistent and unreliable network behavior when both Ethernet and Wi-Fi interfaces are connected, but only one—typically the slower Wi-Fi—provides actual internet access. While Windows correctly prioritizes the functional Wi-Fi connection for external traffic, WSL2 terminals often fail to establish outbound connectivity under these conditions. Notably, Docker operations such as docker pull may still succeed, likely due to integration with the Windows host network stack. However, to restore full network functionality within WSL2, physically disconnecting the non-functional Ethernet cable becomes a necessary workaround.

Expected Behavior

WSL2 should mirror Windows' routing behavior and use the active interface with internet access (Wi-Fi) even when Ethernet is present but non-functional.

Actual Behavior

Actual Behavior

WSL2 fails to reach external hosts via ping or other terminal-based network tools when Ethernet is present—even if Ethernet lacks internet access and Wi-Fi is fully functional.

Diagnostic Logs

You can see in the Cline issue:
https://github.com/cline/cline/issues/7109

The docker pull command worked perfectly for updating a Docker image.
However, there were clear issues with the ping command when executed from within WSL2.
In contrast, the ping command worked reliably 100% of the time from Windows PowerShell.

Running wsl --shutdown or wsl --restart did not resolve the issue.
The only effective solution was physically disconnecting the Ethernet cable from the network interface that lacked external internet connectivity.

[github-actions[bot]]

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-networking-logs.ps1, 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 [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'.

[99sono]

WslLogs-2025-11-06_10-21-11.zip

Uploading logs produced with collect-wsl-logs.ps1

[github-actions[bot]]

Diagnostic information

.wslconfig found
Detected appx version: 2.6.1.0

[99sono]

/emailed-logs

[github-actions[bot]]

Diagnostic information

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

[99sono]

Network logs were apparently 36 MB and needed to be sent via email.