Can't change MTU

[JiaChen-Zeng]

• Your Windows build number: Microsoft Windows [Version 10.0.17763.379]

• What you're doing and what's happening: (Copy&paste the full set of specific command-line steps necessary to reproduce the behavior, and their output. Include screen shots if that helps demonstrate the problem.)

shinoka:/mnt/c/Users/mid1886$ ifconfig eth0
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 10.191.16.107  netmask 255.255.255.0  broadcast 10.191.16.255
        inet6 fe80::151c:9ca1:45ee:a0e5  prefixlen 64  scopeid 0xfd<compat,link,site,host>
        ether 54:bf:64:8a:ec:4c  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

shinoka:/mnt/c/Users/mid1886$ sudo ifconfig eth0 mtu 1000
[sudo] password for shinoka:
shinoka:/mnt/c/Users/mid1886$ ifconfig eth0
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 10.191.16.107  netmask 255.255.255.0  broadcast 10.191.16.255
        inet6 fe80::151c:9ca1:45ee:a0e5  prefixlen 64  scopeid 0xfd<compat,link,site,host>
        ether 54:bf:64:8a:ec:4c  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

• What's wrong / what should be happening instead:

MTU should be set to 1000, but it doesn't changed.

• Strace of the failing command, if applicable: https://ideone.com/6L6rlc (Sorry I can't use gist)

[therealkenc]

Looks stubbed.

ioctl(3, SIOCSIFMTU, {ifr_name="eth0", ifr_mtu=1000}) = 0

Use netsh.exe and interop as a work-around.

Legit enough ask, although it is real close in spirit to #1930. WSL has limited support for low-level networking, and enumerating all the things ifconfig(8) and ip(8) can't do one submission at a time would get repetitious fast (ref #1809).

If you can describe your use case in rough detail it will probably help prioritize. Me I'd take the work-around.

[JiaChen-Zeng]

Thank you for your reply.

I have a problem that if I cat a large file over ssh, ssh will freeze. Also commands like vi works abnormally. It is exactly like this question. It seems that changing MTU will fix this problem.

I also tried change MTU using netsh on the Windows side.

netsh interface ipv4 set subinterface "イーサネット" mtu=1000 store=persistent

This can normally change the network interface on the Windows side. However, when I ran ifconfig, it still showed the MTU unchanged. netsh didn't affect WSL's network settings.

[therealkenc]

It is exactly like this question.

Good cite; appreciate you sharing, thanks.

netsh didn't affect WSL's network settings.

Tried your netsh repro. Yeah, laugh. If you look at the MTU ifconfig(8) on WSL reports for interface lo (loopback) it says 1500 too. It isn't. A loopback MTU would be higher (Windows claims 4294967295).

Pretty sure your MTU changed fine, and that 1500 is just hard-coded in WSL. Which is to say, writing the MTU is stubbed, and reading the MTU is stubbed too, seems. Don't sweat that though. If Windows says it is 1000, it is 1000. There is no "WSL's network settings". WSL doesn't have a ipv4 stack; it is all Windows.

[JiaChen-Zeng]

I tried to set MTU to a very low value like 700. However, ssh still freezes. If MTU is actually changed, then I don't know what to do to fix my problem...

[therealkenc]

If MTU is actually changed, then I don't know what to do to fix my problem...

That part I can't help you with much. That serverfault link is great on its own merits, but there is no real way to tell if (a) MTU is really the problem even if the symptom is the same and (b) even if it is, whether changing the MTU is some kind of universal solution to "the problem" isn't certain. I am not even sure what, precisely (in specific detail), is causing the ssh connection over a OpenVPN tunnel to hang in the first instance. [I do ssh on WSL over (Windows) OpenVPN all the time without workarounds; but then me telling you that doesn't help you any, does it.]

We can chase the rabbit for a bit if you want, but given I won't be able to reproduce the problem on my side we're pretty limited for options here. First, when it hangs, try resizing the window -- which is #2138. Yes, nutty, and yes, long shot. But I've seen it unstick stuck connections first-hand so it is worth a try. [ed] Or try that while killall -CHLD ssh suggestion (a post which I only just noticed). n.b.: this is still a total long-shot.

Next, see if you can reproduce your scenario as closely as humanly possible with a win32 ssh. You can try MSFT's new(ish) OpenSSH. You can also try Cygwin's. The Linux version and the win32 ports are all largely (read: entirely) the same source under the hood. If the exact same scenario doesn't hang, then at you you have a kludgy work-around, and we learn something. If the win32 ssh also hangs, then at least we learn it isn't a WSL thing.

[turtlemonvh]

This may deserve a new issue, but it's related and the ticket is still open.

I ran into an issue where the MTU of the vEthernet interface for WSL didn't update when I joined a VPN. This led me to look for a way to persist MTU settings across restarts, which worked when using @m-azuma's command (above).

Should I expect interface MTU to change automatically? (i.e. is this a bug?)

If not, is the a recommended way for me to detect the changed MTU settings in the guest when the network changes and adjust setting accordingly?

[therealkenc]

This may deserve a new issue, but it's related and the ticket is still open.

This one can serve as the landing zone, to the extent the OP ask (which is changing the MTU) is still open on WSL2. In a more perfect world one could imagine the vEthernet MTU changes flowing in both directions, at least in principle. What this issue needs most is a big like count (more than a new issue).

[JamesKehr]

From a technical TCP/IP standpoint this sort of behavior is expected unless something in between tells a side that the MTU is wrong. The ICMP "needs fragmentation" message can trigger corrective behavior if the message is enabled and not dropped. Which in most cases it is not sent or is dropped because security people don't like ICMP.

The best option, in my opinion, is to enable MSS clamping if the VPN product supports the option. MSS clamping was made for exactly this situation and most major VPN products should have support.

When MSS clamping is enabled the VPN server enforces a maximum MTU size by altering the MSS option in the TCP header during the handshake. This option should fix the issue without requiring intervention on any OS.

Options like using the netsh command or running a script/command that changes the MTU or enables tcp_mtu_probing on the WSL2 distro can be used when MSS clamping is not available.

[microsoft-github-policy-service]

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

Thank you!