dombegin commented 4 years ago

Current Version 10.0.19025.1

I have this weird issue where I can no longer use SSH connections to remote servers from WSL2. I remember that it was working ok in early builds but I am not sure at which point it started to fail.

Any idea on how to resolve this would be appreciated.

What happens

When connected to a remote server, SSH connection hangs after a very short time. I am sometimes able to type a few letters but then it hangs and have to close WSL. It does this with every SSH connections to every server.

For instance, on the following screenshot, you can see that I was able to type a few numbers but the connection froze at the last "1".

Probably related, SSH git cloning is not working either. It starts receiving objects but stops shortly after. I have to CTRL-C to stop. Here's an example hanging at 46%.

> GIT_SSH_COMMAND="ssh -vvv" git clone --verbose git@github.com:microsoft/dotnet.git

...

In WSL1, everything works smoothly and have no issues. It's only in WSL2 that this happens.

Note that git cloning through HTTPS works fine as well.

Just let me know if there is additional trace I can run to help since I know this is probably going to be hard to repro.

therealkenc commented 4 years ago

Just let me know if there is additional trace I can run to help since I know this is probably going to be hard to repro.

No easy guesses off the cuff, and nothing similar on the books I know of. The usual "are you running any third-party VPN or firewall software" question applies. Is it correct to say git.exe and ssh.exe from a Windows cmd.exe prompt does not exhibit the hangs?

dombegin commented 4 years ago

The usual "are you running any third-party VPN or firewall software" question applies

No active firewall / vpn

Is it correct to say git.exe and ssh.exe from a Windows cmd.exe prompt does not exhibit the hangs?

Exactly, everything works fine from cmd/ps and from WSL1 as well

nadddy commented 4 years ago

I am getting exact same issue after upgrading to windows 10 2004 and upgrading to wsl2.

randand commented 4 years ago

I have the same problem. Mu linux distribution is ubuntu, I tested both 18.04 and 20.04. When the windows host is connected through a VPN, ssh is not working. Also git does not connect to the server. The problem is only present in wsl2, on the same pc and using the same host vpn, WSL1 works fine.

lpysj commented 4 years ago

I too have the same problem. I just upgraded to Windows 2004 and WSL 2 and cannot connect to hosts on the VPN network. I can however connect to hosts on AWS.

When I'm using Powershell to connect to the VPN hosts it works fine, problem is only under WSL 2.

Interestingly when I use docker (with the wsl2 backend enabled), to start a alpine container from within wsl2 and I try to ssh into one of the hosts from there it works just fine.

xkotj commented 4 years ago

I have the same issue. WSL1 in VM - connection to SSH server is ok. (VPN) WSL2 in VM - connection to SSH server is ok (VPN), but when I grep for example larger output from text file it hangs and shows broken pipe aftewards. W10 - 2004 Ubuntu-20.04

matheusmb commented 4 years ago

I started having this issue since two days ago. I'm not exactly sure what changed, I didn't make any new install/upgrade. Running W10 - 2004, Ubuntu 18.04 @ WSL 2

redsoft7 commented 4 years ago

Same problem:

W10 - 2004 (Version 10.0.19041.329)
Ubuntu 20.04 in WSL 2 Sometimes it hangs on the grep command, other times when I edit files with nano. The problem only occurs on servers in VPN, in lan servers the ssh connection does not block.

lbergnehr commented 4 years ago

This (in PowerShell) appears to work around this issue for me:

New-NetFirewallRule -DisplayName "WSL" -Direction Outbound -InterfaceAlias "vEthernet (WSL)" -Action Allow

Inspired by this comment: https://github.com/microsoft/WSL/issues/4585#issuecomment-610061194.

jeffersonfelixdev commented 4 years ago

Same problem here Ubuntu 20.04 in WSL2 running on Windows 10 2004 SSH over VPN hangs when I type a simple "ls -a" or "top"

jonas154 commented 4 years ago

I have also the same problem with 2004, connecting via SSH over VPN works but then simple commands like top freezes everything.

bpottier commented 3 years ago

I'm having this issue too. SSH will hang randomly when connected to VPN. Sometimes from cat or grep or sometimes immediately upon connecting to a host.

Ubuntu 18.04 in WSL2 on Windows 10 2004.

maxdobeck commented 3 years ago

No VPN or firewall & I'm on WSL2

git clone git@github.com:maxdobeck/gimme.git
Cloning into 'gimme'...
Received disconnect from 192.30.255.112 port 22:11: Bye Bye
Disconnected from 192.30.255.112 port 22
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

ssh -vvv -T git@github.com
OpenSSH_8.2p1 Ubuntu-4ubuntu0.1, OpenSSL 1.1.1f  31 Mar 2020
debug1: Reading configuration data /home/max/.ssh/config
debug1: /home/max/.ssh/config line 1: Applying options for github.com
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: include /etc/ssh/ssh_config.d/*.conf matched no files
debug1: /etc/ssh/ssh_config line 21: Applying options for *
debug2: resolving "github.com" port 22
debug2: ssh_connect_direct
debug1: Connecting to github.com [192.30.255.112] port 22.
debug1: Connection established.
debug1: identity file /home/max/.ssh/id_rsa type 0
debug1: identity file /home/max/.ssh/id_rsa-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_8.2p1 Ubuntu-4ubuntu0.1
debug1: Remote protocol version 2.0, remote software version babeld-fceaa46c
debug1: no match: babeld-fceaa46c
debug2: fd 3 setting O_NONBLOCK
debug1: Authenticating to github.com:22 as 'git'
debug3: send packet: type 20
debug1: SSH2_MSG_KEXINIT sent
debug3: receive packet: type 20
debug1: SSH2_MSG_KEXINIT received
debug2: local client KEXINIT proposal
debug2: KEX algorithms: curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group14-sha256,ext-info-c
debug2: host key algorithms: ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,sk-ecdsa-sha2-nistp256-cert-v01@openssh.com,ssh-ed25519-cert-v01@openssh.com,sk-ssh-ed25519-cert-v01@openssh.com,rsa-sha2-512-cert-v01@openssh.com,rsa-sha2-256-cert-v01@openssh.com,ssh-rsa-cert-v01@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,sk-ecdsa-sha2-nistp256@openssh.com,ssh-ed25519,sk-ssh-ed25519@openssh.com,rsa-sha2-512,rsa-sha2-256,ssh-rsa
debug2: ciphers ctos: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com
debug2: ciphers stoc: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com
debug2: MACs ctos: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: MACs stoc: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: compression ctos: none,zlib@openssh.com,zlib
debug2: compression stoc: none,zlib@openssh.com,zlib
debug2: languages ctos:
debug2: languages stoc:
debug2: first_kex_follows 0
debug2: reserved 0
debug2: peer server KEXINIT proposal
debug2: KEX algorithms: curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256
debug2: host key algorithms: ssh-dss,rsa-sha2-512,rsa-sha2-256,ssh-rsa
debug2: ciphers ctos: chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr,aes256-cbc,aes192-cbc,aes128-cbc
debug2: ciphers stoc: chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr,aes256-cbc,aes192-cbc,aes128-cbc
debug2: MACs ctos: hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: MACs stoc: hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: compression ctos: none,zlib,zlib@openssh.com
debug2: compression stoc: none,zlib,zlib@openssh.com
debug2: languages ctos:
debug2: languages stoc:
debug2: first_kex_follows 0
debug2: reserved 0
debug1: kex: algorithm: curve25519-sha256
debug1: kex: host key algorithm: rsa-sha2-512
debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug3: send packet: type 30
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug3: receive packet: type 1
Received disconnect from 192.30.255.112 port 22:11: Bye Bye
Disconnected from 192.30.255.112 port 22

But if I revert to wsl1 wsl.exe --set-version Ubuntu 1

wsl -l -v
  NAME      STATE           VERSION
* Ubuntu    Running         1

It works ! 👍

ssh -T git@github.com
Hi maxdobeck! You've successfully authenticated, but GitHub does not provide shell access.

matheusmb commented 3 years ago

This (in PowerShell) appears to work around this issue for me:
New-NetFirewallRule -DisplayName "WSL" -Direction Outbound -InterfaceAlias "vEthernet (WSL)" -Action Allow
Inspired by this comment: #4585 (comment).

It didn't work for me. I had to restart the PC once or twice to fix it.

jasonkcarter commented 3 years ago

I am also having the same issue. The Windows Firewall rule posted by @lbergnehr did not work for me. I can navigate a few directories, but commands like vim and ls do not work. I can also not sync with rsync from WSL2. It just hangs and eventually throws a broken pipe error.

redsoft7 commented 3 years ago

Changing MTU fixed the problem for me: https://github.com/microsoft/WSL/issues/4698#issuecomment-628682785

ladefoged commented 3 years ago

I had this problem when using Docker for Windows with WSL2.. After shutting down docker the problem didn't occur anymore.

tmtron commented 3 years ago

I also have this problem in WSL2 - nothing of these worked for me:

OS: Windows 10 Pro 10.0.19041 N/A Build 19041

dpiow commented 3 years ago

I have the same issue with WSL 2 Windows 10.0.18363.1082 Kernel update 4.19.128 Distribution: Debian GNU/Linux 9 (stretch) via a regular console (not Windows Terminal), no VPNs, no firewalls (except the built-in) etc

Once logged into ssh server the session hangs up shortly. WSL 1 works like a charm.

johan718 commented 3 years ago

This may be unrelated, but I can't SSH into my EC2 instance in AWS. I get a message that the host closed the connection. I can SSH from PowerShell and Putty just fine with my keys.

I'm using Ubuntu 20.04 LTS with WSL2 Windows Version 10.0.19041 Build 19041

hmageste commented 3 years ago

Same problem here. Connecting through ssh to a linux server hangs when I try to use some Linux commands.

I am using Ubuntu 20.04.1 LTS Windows 10 Pro Version 2004 OS build 19041.685

ThaDaVos commented 3 years ago

Having the same issue.... but I cannot connect at all, it just hangs, eventually times out and then it works just fine...

Ubuntu 18.04 LTS Windows 10 Pro 2004 OS build 21296.1000 (Insiders)

onsen194 commented 3 years ago

I will post for the first time. It does not hang when using a local LAN connection server, It seems to hang when using a remote connection server.

ver 　Microsoft Windows [Version 10.0.19042.746] wsl --list -v NAME STATE VERSION

Ubuntu-20.04 Running 2

I haven't figured out the cause, but I found two workarounds. 1) Specify the -t option additionally with the ssh command. WSL version 1 did not require such a specification. 2) Execute the cmd.exe / c ssh command. It does not occur on windows openssh client.

nadavpa commented 3 years ago

I also have this issue in WSL2. It happens when I print a long list such as ls -la or cat file.txt I then reconnect immediatly after it hangs and all works fine. But it happens every day (on the first connection after restart) and drives me nuts. ssh -t did not help. I use a VPN Doesn't happen for non-VPN ssh connections Turning off Docker for windows didn't help Happens in Windows Terminal + other terminals

rob-baker-ar commented 3 years ago

I am getting this too using rsync and SSH from a WSL2 based Ubuntu 20.04.

I can confirm this works for me:

Changing MTU fixed the problem for me:

4698 (comment)

From that comment: sudo ifconfig eth0 mtu 1350

...But that needs to be run every time the VM reboots which is not ideal. I'm not certain what would be needed to set the MTU to that value on the VM permanently - I don't have anything in /etc/netplan or in /etc/network/interfaces to edit (but I suppose technically that is a little out of scope for this issue).

onsen194 commented 3 years ago

Thanks to nadavpa and rob-baker-ar for their comments. In my case, resizing the MTU did not resolve the hang.

ssh -V OpenSSH_for_Windows_7.7p1, LibreSSL 2.6.5 $ ssh -V OpenSSH_8.2p1 Ubuntu-4ubuntu0.1, OpenSSL 1.1.1f 31 Mar 2020

This is an event where ssh hangs, but since the effectiveness of the workaround is different, It may be due to another problem.

anton7811 commented 3 years ago

Same issue. Windows 10 build 20H2. The only solution works - rolling back to WSL1 as mentioned by @maxdobeck: wsl --set-version WSL_NAME 1

mario-lukic commented 3 years ago

This (in PowerShell) appears to work around this issue for me:
New-NetFirewallRule -DisplayName "WSL" -Direction Outbound -InterfaceAlias "vEthernet (WSL)" -Action Allow
Inspired by this comment: #4585 (comment).

This seems to help a little bit. I had problems when using SSH via WSL2, while running Wireguard Client ( on Windows ). SSH would freeze constantly ( top or htop would freeze the connection ). Now it seems to be working better for some servers that are closer ping wise, but still breaks (freezes) for servers farther away....

SSH works just fine when using it from Powershell, while VPN is on.

onsen194 commented 3 years ago

Thanks to anton7811 and mario-lukic for their advice. In my case, it doesn't seem to be related to WSL2 or firewall settings. After reconfiguring the remote router, the hang event disappeared. I can no longer pursue it. A bitter smile. In my case, the network settings are the same, so the provider is suspicious.

CircuitGuy commented 3 years ago

I have a VERY vanilla case that should be easy for most anybody else to reproduce.

I'm having this issue with both a fairly old and a fairly new version of WSL-2 on 2x PCs. Unlike some other people, I'm running a fairly vanilla setup. Windows firewall is turned off entirely in the PC with the newer build of Windows. All of this is over a local LAN, no VPNs, no wireguard tunnels.

Symptoms/Reproduction: ssh into a Raspberry Pi. Yank the Pi's power. The WSL ssh client just hangs. I can't type. Ctrl+C doesn't close the connection. I've walked away for > 1 hr to see if there was some kind of timeout (there's not).

PC One:

Win10 20H2 OS Build 19042.804
kernel 5.4.72-microsoft-standard-WSL2

Other is running a slightly older OS and I believe it had some hacks to get WSL-2 installed:

Win10 1909 OS Build 18363.1379
kernel 4.19.128-microsoft-standard
cmd 'wsl -l -v' returns Version 2

Edit: P.S. I'm not seeing any other 'random' behavior others are describing. Every command I've tried runs over SSH no problem. It also stays up over long-ish periods (few hours is longest I've tried). My first guess is that others are having some sort of small network issue and WSL-2 isn't handling the network stack as expected.

falloutphil commented 3 years ago

I am seeing the same freeze-on-ssh issue as these two comments in particular: https://github.com/microsoft/WSL/issues/4690#issuecomment-650253296 https://github.com/microsoft/WSL/issues/4690#issuecomment-654251040

We tried to move from OpenVPN (where the problem will occasionally happen - once or twice a day), to MS's own Azure VPN Client. Now any SSH from WSL2 will still connect OK, and then typically freezes with the first command generating stdout/err. Normally an 'ls', or 'cat' is enough to cause the freeze.

After a long time SSH eventually barfs out: packet_write_wait: Connection to 10.x.x.x port 22: Broken pipe

It's a bit of a WSL-killer with VPNs essential to homeworking for us.

damien-666 commented 3 years ago

This was stopping us moving to WSL2 as we are using Azure AlwaysOn VPN which failed every time we ran an ssh session and did an ls but worked when we used OpenVPN. I struggled searching for the answer for weeks and finally raised with Mircosoft Azure support who advised to change the MTU to 1400 or 1300 using the command:

“sudo ip link set dev eth0 mtu 1400”

This worked for me - hope it helps.

AlexVigogne commented 3 years ago

Hello fellows,

I have the same issue as you, and when you set the -v option, i found that specifying the cipher can help. Maybe you should try with -c chacha20-poly1305@openssh.com cipher (it's openssh default option).

Hope it will help !

SeWieland commented 3 years ago

It seems to be realted, however it's even a bit stranger on my side... Everything works as expected for like 30 seconds, thereafter the connection freezes. However I experienced that establishing the SSH connection and just waiting a few minutes somehow fixes the problems sometimes. I could then eventually use the connection the whole day without any freezes.

This only happens to me in WSL2 and changing the MTU did not work for me yet.

dombegin commented 2 years ago

For people with HP laptops, our team was able to resolve most of their SSH hanging issues in WSL2 by disabling the "LiveQoS NDIS 6 Filter Driver" on all ethernet/wifi adapters.

It looks like there is some conflict between WSL2 and this driver.

It has been mentioned in #5787 by @dpiow as well here

Hope this helps.

izderadicka commented 2 years ago

I can confirm that decreasing MTU on eth0 solved the problem for me: sudo ifconfig eth0 mtu 1300 or sudo ip link set dev eth0 mtu 1300

Possible problem is IP packet fragmentation as explained here http://www.snailbook.com/faq/mtu-mismatch.auto.html . In my case it's caused probably by VPN.

Unfortunately change is not permanent (and changing in windows did not helped): for now I have this in .bashrc:

update MTU on eth0

MTU_SIZE=1347 if [[ $(ifconfig eth0 | sed -nr 's/.*mtu ([0-9]+)/\1/p') -ne "$MTU_SIZE" ]]; then sudo ifconfig eth0 mtu $MTU_SIZE; fi

Actual MTU size would be probably individual - if caused by local VPN then you can check in windows - run command: netsh interface ipv4 show subinterfaces - check interfaces - see which one is used by VPN and check MTU size. Or you can experiment as described here: https://askubuntu.com/questions/1127497/how-can-i-change-mtu-size-permanently

eromoe commented 2 years ago

I am over VPN and meet ssh hang in wsl2, which never happened in msys2/cygwin . Change MTU works, but @izderadicka This MTU settings make all ssh connections super slow. I don't know much about network technical, do you have any suggestions?

izderadicka commented 2 years ago

Right now it works fine for me. I'm no networking expert. I've set MTU to MTU size of VPN - to get largest packets without fragmentation in tunneling. You might try to play also with setting of VPN/FW - as I understand it's not problem of WSL2 only appears if connection is going through some VPN/FW.

AnimeshRy commented 2 years ago

Still an issue, none of the fixes stated above have worked. I've tried restarting and pretty much all options but the ssh is stuck

OldStarchy commented 2 years ago

I'm not sure if this is related;

Working from VSCode git will occasionally stop working, without warning. usually after I push a branch or two, ssh commands will start hanging

$ GIT_SSH_COMMAND="ssh -vvv" git fetch --prune
OpenSSH_8.2p1 Ubuntu-4ubuntu0.3, OpenSSL 1.1.1f  31 Mar 2020
debug1: Reading configuration data /home/sorokin/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: include /etc/ssh/ssh_config.d/*.conf matched no files
debug1: /etc/ssh/ssh_config line 21: Applying options for *
debug2: resolving "gitlab.com" port 22
debug2: ssh_connect_direct
debug1: Connecting to gitlab.com [172.65.251.78] port 22.
debug1: connect to address 172.65.251.78 port 22: Connection timed out
debug1: Connecting to gitlab.com [2606:4700:90:0:f22e:fbec:5bed:a9b9] port 22.
debug1: connect to address 2606:4700:90:0:f22e:fbec:5bed:a9b9 port 22: Network is unreachable
ssh: connect to host gitlab.com port 22: Network is unreachable
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

I don't know what to do about this other than wait and eventually, it will start working again. For example, I tried about 5 times before deciding to search this issue and write this comment, but now it's working again. In the meantime, I tested the same git fetch operation (same repo) from a different system (native ubuntu) with no troubles.

If I had to guess it could be something to do with a resource getting locked and then having to wait for it to timeout before using it again, but I really have no idea how any of this works.

sunilkum84 commented 2 years ago

I can confirm that decreasing MTU on eth0 solved the problem for me: sudo ifconfig eth0 mtu 1300 or sudo ip link set dev eth0 mtu 1300

Possible problem is IP packet fragmentation as explained here http://www.snailbook.com/faq/mtu-mismatch.auto.html . In my case it's caused probably by VPN.

Unfortunately change is not permanent (and changing in windows did not helped): for now I have this in .bashrc:

update MTU on eth0

MTU_SIZE=1347 if [[ $(ifconfig eth0 | sed -nr 's/.*mtu ([0-9]+)/\1/p') -ne "$MTU_SIZE" ]]; then sudo ifconfig eth0 mtu $MTU_SIZE; fi

Actual MTU size would be probably individual - if caused by local VPN then you can check in windows - run command: netsh interface ipv4 show subinterfaces - check interfaces - see which one is used by VPN and check MTU size. Or you can experiment as described here: https://askubuntu.com/questions/1127497/how-can-i-change-mtu-size-permanently

I had similar issue and this command helped to solve the problem I have added this command "sudo ifconfig eth0 mtu 1300" to me ~/.bashrc

giovannicandido commented 2 years ago

Having the same problem on wsl 2 ubuntu 20.04 the ssh connection just freezes. Changing the MTU didn't help me.

SSH from windows host just works stable

NiklasBr commented 2 years ago

I have this issue as well, Ubuntu 20.04 on Windows 10 Pro with WSL2, changing MTU did not work

lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 20.04.3 LTS
Release:        20.04
Codename:       focal

Edition Windows 10 Pro
Version 21H1
Installed on    ‎2021-‎01-‎18
OS build    19043.1320
Experience  Windows Feature Experience Pack 120.2212.3920.0

stela2502 commented 2 years ago

The only real workaround that worked for me is to use cmd -> ssh.exe. Far from optimal as it clearly states that network integration with WSL2 is not working as it should.

I hope Microsoft will ditch the windows kernel soon and switch to a linux kernel as all other (important) operating system have done. Even if I am not looking forward to a virus being fitted to attack a linux kernel.

ktpx commented 2 years ago

Most annoying issue in history. Same problem here. no suggested fix works.

anton7811 commented 2 years ago

In fact, MTU adjustment works. I had to set it to 1350. 1400 doesn't work.

But the real problem is NAT in WSL2. This is the most unexpected and unwanted staff. That's what I think should be removed. I rolled back my environment to WSL1.

ktpx commented 2 years ago

Maybe worked for you.

andreasmarkussen commented 2 years ago

To diagnose if MTU is the culpit try these commands

# This works for me - prints 80 dashes
ssh username@172.29.1.10 printf -- '-%.0s' {1..80}
# This works aswell - prints 580 dashes
ssh username@172.29.1.10 printf -- '-%.0s' {1..580} 
# This fails for me - just hangs
ssh username@172.29.1.10 printf -- '-%.0s' {1..618}

So while we say that the MTU is an issue on WSL, it also exists on Git Bash for Windows (MINGW64) It did fail once, but not permanently. I saw it working with 80, 580, but fail on 718, and work on 750, so this seems better than WSL, but still inconsistent.

I was also running on WSL2, over a ZeroTier connection which has its own MTU issues, however, when I connected directly to the machine, I did not have the issues. I could just connect with no issues.

So there are most likely several layers of issues in this issue.

clee704 commented 2 years ago

To diagnose if MTU is the culpit try these commands
# This works for me - prints 80 dashes
ssh username@172.29.1.10 printf -- '-%.0s' {1..80}
# This works aswell - prints 580 dashes
ssh username@172.29.1.10 printf -- '-%.0s' {1..580} 
# This fails for me - just hangs
ssh username@172.29.1.10 printf -- '-%.0s' {1..618}
So while we say that the MTU is an issue on WSL, it also exists on Git Bash for Windows (MINGW64) It did fail once, but not permanently. I saw it working with 80, 580, but fail on 718, and work on 750, so this seems better than WSL, but still inconsistent.

I was also running on WSL2, over a ZeroTier connection which has its own MTU issues, however, when I connected directly to the machine, I did not have the issues. I could just connect with no issues.

So there are most likely several layers of issues in this issue.

Thanks for the command. In my case it seems it works fine until 1314 and stops working from 1315.

I had this issue for a while, but until today it was temporary - running tmux after ssh often froze but after reconnecting and tmux a it worked. But it became more severe since today. Now I cannot do tmux a or even top because it always freezes. I use VPN. No issue with PuTTY.

stela2502 commented 2 years ago

Great support Microsoft!

Honestly - there are a lot of users having this issue and you just not care?! Or is this problem too complicated to solve? I am really looking forward to a Windows without the windows kernel :-D

microsoft / WSL

SSH connections hanging from WSL2 #4690

What happens

4698 (comment)

update MTU on eth0

update MTU on eth0