Terminal screen redraw issues when ssh-ing from WSL2 console after recent Windows updates

[bpkroth]

Environment

Windows build number: [run `[Environment]::OSVersion` for powershell, or `ver` for cmd]
Windows Terminal version (if applicable): 1.6.10571.0

Platform ServicePack Version      VersionString
-------- ----------- -------      -------------
 Win32NT             10.0.19042.0 Microsoft Windows NT 10.0.19042.0

Any other software?
WSL2

Steps to reproduce

My windows machine updated the other night and now I'm having weird terminal issues when I ssh to a remote host from a local WSL2 terminal.
Plain old shell generally seems to work on the remote end, but the moment it needs to go to some form of full screen redraw interface (e.g. less, top, vim, etc.) the screen can't refresh anymore. In some cases, long output (e.g. ps -AH u) will cause it to stall output as well.
Seems to work okay for local sessions though.
The remote machines also work okay from a different Windows laptop's WSL that I have (for the moment since I haven't rebooted to apply the update yet), so it doesn't appear to be the remote end point that's the problem.
It also works okay if I ssh from a Putty terminal emulator on my problematic workstation, so it appears to really be a problem with the terminal emulator on this machine. I have tried starting bash from

• the various Windows Console programs terminal emulator (Win-R -> bash, pwsh, cmd)
• the powershell terminal
• the new "Windows Terminal"
  These all exhibit the same behavior.

When the problem occurs I can enter the magic ~.~. sequence to kill the ssh session and return to the host terminal session. At this point the cursor itself is gone (no longer a white block, underscore, etc.), though I can type again. Running reset in the local bash session recovers the local behavior without needing to restart the console window, but I still get the same issue once I try to ssh to a remote host again.

Expected behavior

Free flowing characters over ssh :)

Actual behavior

Characters stop flowing :(

Links

Feedback hub report: https://aka.ms/AAbi4mw

[DHowett]

Hmm. HMM. This sounds a lot like a window resize issue.

Can you run stty -a > stty.log before SSH, and then stty -a >> stty.log (note the >>) blindly after you get back to local bash after ~.~.?

Then paste the contents of stty.log. 😄

[bpkroth]

So, here's what I think you asked for:
(redirect stty -a output to a file, both before and after an ssh session that causes the problematic issue and is terminated with ~.~.)

speed 38400 baud; rows 56; columns 194; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; discard = ^O; min = 1; time = 0;
-parenb -parodd -cmspar cs8 -hupcl -cstopb cread -clocal -crtscts
-ignbrk brkint ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon -ixoff
-iuclc -ixany imaxbel -iutf8
opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt
echoctl echoke -flusho -extproc
speed 38400 baud; rows 56; columns 194; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; discard = ^O; min = 1; time = 0;
-parenb -parodd -cmspar cs8 -hupcl -cstopb cread -clocal -crtscts
-ignbrk brkint ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon -ixoff
-iuclc -ixany imaxbel -iutf8
opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt
echoctl echoke -flusho -extproc

Did a vimdiff assuming the break was at speed ... for the before/after ssh on local session. Seems to be the same.

Here's the version on ssh if I redirect it (again, prior to doing something that sets the terminal off):

speed 38400 baud; rows 56; columns 194; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; discard = ^O; min = 1; time = 0;
-parenb -parodd -cmspar cs8 -hupcl -cstopb cread -clocal -crtscts
-ignbrk -brkint ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon -ixoff
-iuclc -ixany imaxbel -iutf8
opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt
echoctl echoke -flusho -extproc

Here's the version after an initial ssh to the remote host (copy and pasted, no redirect):

speed 38400 baud; rows 56; columns 194; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>; eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; discard = ^O;
min = 1; time = 0;
-parenb -parodd -cmspar cs8 -hupcl -cstopb cread -clocal -crtscts
-ignbrk -brkint ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon -ixoff -iuclc -ixany imaxbel -iutf8
opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt echoctl echoke -flusho -extproc

Aha, these are starting to look different (redirected version is different from interactive version). Is that normal?

However, I see nearly the same results on the local stty as remote (for both bare or redirected comparisons). The only difference is the brkint setting which is -brkint in the remote cases.

Anyways, not sure if that helps you at all. Let me know if you need more details.

Thanks much for the speedy response!

[bpkroth]

Here's another interesting way to get it to stop outputting:

echo {a..z}{a..z}

(no output)

However, this doesn't cause an issue:

echo {a..z}{0..9}

(full cross-product output)

Tried that after trying to count how many lines or characters ps -ef output stopped at (9 and 593).

If I login again to that remote machine from another console window, the previous one's processes are as expected (e.g. nothing hung/spinning. Previous ps has already terminated, though its parent bash and ssh haven't). Sending various signals (e.g. SIGWINCH) don't seem to be able to recover the terminal (though I can kill it).

[bpkroth]

Closing this. Pretty sure there's an MTU issue in WSL2 land now, not the terminal.

If I do the following:

ping -Mdo -s 1373 $remote_host

The packets stop responding, though -s 1372 works fine, as does the ssh session.

A simple workaround for the moment is to do the following in the WSL2 VM (at least until I can track down where it's really going wrong):

ip link set mtu 1400 dev eth0

Note: this may have to do with the fact that my path is going from WSL2 -> host Hyper-V -> host VPN -> ... -> remote host.

[bpkroth]

Just to close the loop on this, here's a couple of other references for more details/fixes regarding MTU path discovery issues with VPN and WSL2:
microsoft/WSL#4246 (comment)
microsoft/WSL#6602
microsoft/WSL#5638
microsoft/WSL#4698 (comment)