Effective MTU in mirrored mode is lower than interface MTU

[llowrey]

Windows Version

Microsoft Windows [Version 10.0.22631.3593]

WSL Version

2.2.1.0

Are you using WSL 1 or WSL 2?

• WSL 2
• WSL 1

Kernel Version

5.15.150.1-microsoft-standard-WSL2

Distro Version

Fedora 40

Other Software

No response

Repro Steps

1. Start wsl in mirrored mode
2. Set MTU to 1500 in windows and in wsl (common default)
3. In wsl: ping -4 -s1472 somehostname
4. Observe successful replies
5. In wsl: ping -4 -s1473 somehostname
6. Observe no successful replies
7. In windows: ping -4 -l1473 somehostname
8. Observe successful replies
9. Set MTU to 9000 in windows and in wsl (jumbo frames)
10. Repeat 3-8 above
11. In windows: ping -4 -l8000 somehostname
12. Observe successful replies
13. Run packet sniffer on somehostname to observe packets coming from wsl. You will observe that large packets, eg 8000 from step 11, arrive at somehostname intact but the replies to not make it into wsl.

Expected Behavior

The WSL instance should behave identically to the windows host with regard to MTU. Whatever packet size the host can send/receive, the WSL guest should be able to send/receive.

Actual Behavior

The WSL guest, when in mirrored mode, has an MTU that is capped at something less than 1500, even when the host MTU is very much larger (jumbo frames). When observing using a packet sniffer, it can be seen that wsl correctly sends packets up to the configured MTU size but the replies are dropped unless they are less than X (some value less than 1500), regardless of the configured MTU.

When not in mirrored mode, wsl is able to send/receive large packets, up to the MTU size, just fine. The problem is only observed when running in mirrored mode.

Diagnostic Logs

No response

[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 scipt will output the path of the log file once done.

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

Click here for more info on logging
If you choose to email these logs instead of attaching to the bug, please send them to wsl-gh-logs@microsoft.com with the number of the github issue in the subject, and in the message a link to your comment in the github issue and reply with '/emailed-logs'.

View similar issues

Please view the issues below to see if they solve your problem, and if the issue describes your problem please consider closing this one and thumbs upping the other issue to help us prioritize it!

Open similar issues:

• WSL2: Jumbo frames are not forwarded to mirrored interface on Linux (#11046), similarity score: 0.84
• networkingMode=mirrored doesn't work as expected (#11090), similarity score: 0.73
• Mirrored mode - WSL chooses to mirror the disconnected host wifi adapter instead of the connected host ethernet adapter (#10884), similarity score: 0.72

Closed similar issues:

• WSL2: Do not recieve UDP packets from network interface using mirrored option (#11027), similarity score: 0.75
• In Mirrored mode incoming packets from remote device on LAN are not received in WSL2 (#10535), similarity score: 0.74

Note: You can give me feedback by thumbs upping or thumbs downing this comment.

[microsoft-github-policy-service]

This issue has been automatically closed since it has not had any author activity for the past 7 days. If you're still experiencing this issue please re-file it as a new issue.

Thank you!