Cannot scroll buffer in Terminal with inbox telnet client

[sierrab1989]

Hi, I love the new Windows Terminal. I've manage to add my routers and switches to it but the only issue I have is that I can't scroll. Once I log into my switch using ssh, I can't seem to scroll up to see what's above. Kindly let me know how I can activate scrolling.
PS. scrolling works for regular CMD or PowerShell.

[DHowett]

Hi, please make sure you're using the bug report template when you file issues.

What SSH client are you using?

[sierrab1989]

Hi Dustin, Actually I'm able to scroll through on SSH logins. I'm currently using the OpenSSH Beta. It's with Telnet that I'm not able to scroll. Regards,

[DHowett]

Cool. Which telnet client?

[sierrab1989]

for telnet i'm using the one that you add on the windows feature.

[shermp]

Hi, I'd just like to state that I'm seeing the same issue.

I'm using Terminal 1.0.1401.0

It's only happening with telnet, not SSH. I'm using the inbuilt Windows 10 telnet client.

It happens with both PowerShell and Command Prompt running in Terminal. I can successfully scroll using the old Console, with both Command Prompt and PowerShell.

I hope this helps.

[JunhwanPark]

Hi,
I'm using Teminal Preview 1.0.1402.0

• Power Shell

> ssh junhwan@dell2
$ vi test.cpp

After connecting to ssh, when I edit the source with vi (vim), when I scroll the mouse, strange characters are displayed. I haven't experienced it in other ssh tools.

I use the set mouse=a option in the .vimrc file. This happens when using this option.

[szsong]

Any chance getting this as higher priority? This is a bug that breaks compatibility with Microsoft's own existing functionality (telnet) and it could be a blocking bug that forces people dropping Terminal :(

[shaunthorne]

Is there any workaround for this issue?

I found a temporary solution. Plink from PuTTY works acceptable in this case.

As mentioned in PuTTY documentation, "Plink is probably not what you want if you want to run an interactive session in a console window" but it works with Windows Terminal even better than native MS telnet.exe

[mosebac]

Hi,

I confirm @shaunthorne 's workaround is working and is an acceptable solution in this case.

I've been trying to use Windows Terminal as the default console application for GNS3 network simulation software, and had the same buffering issues everyone is talking about.
Using Plink works like a charm : wt -w0 split-pane --tabColor #C678DD --colorScheme "One Half Dark" --title %d --suppressApplicationTitle plink -telnet -P %p %h

thx

[zadjii-msft]

Nope. We'll make sure to update this thread when there is. In the meantime, might I recommend the Subscribe button?

That way you'll be notified of any updates to this thread, without needlessly pinging everyone on this thread ☺️

[PetSerAl]

I have the same issue with build-in telnet client. And I think, that I understand reasons for that behavior. Windows console have such thing as screen buffers and build-in telnet client use them. Also old console window does not actually have scroll-back buffer: all scrollable region is part of screen buffer, while in Windows Terminal screen buffer have size of the window.
So you loose scroll-back because it leaves screen buffer, and it is very likely that build-in telnet client updates its screen buffer in such way, that it prevents Windows Terminal from capture scroll-back. For example, when remote side disconnect telnet session, as build-in telnet client display message about that, top four lines of remote session console screen get captured in scroll-back by Windows Terminal.

[tatroc]

The work around I used was wsl.
wsl ~ --exec telnet 10.77.77.2

I saw others mention using plink, but when I control+c, plink would exit. Using WSL + telnet does not have this issue.

[erh-git]

The work around I used was wsl. wsl ~ --exec telnet 10.77.77.2

For those of you here trying to get GNS3 to use the new Windows Terminal (like me), I just want to leave a note to spare you the hours of frustration I spent trying to get it to work.

The command above launches the default WSL instance -- for me, this was a WSL2 instance. The WSL2 instance runs on a special/hidden virtual Switch, while the GNS3 VM on Hyper-V runs on the Default Switch. Communication between these two switches is restricted.

The solution is to install a WSL1 instance and specify that instance in the console application:

wsl --install -d Debian
wsl --set-version Debian 1

(use whichever distro you like, note that for Debian I had to sudo apt-get install telnet as well)

Then use this Distro to launch your telnet sessions: wsl.exe -d Debian telnet 10.77.77.2

(I don't know the significance of including or omitting ~ --exec, in my testing the results were the same)

My final GNS3 Console Command looked like this: wt.exe -w 0 --suppressApplicationTitle --title %d wsl.exe -d Debian telnet %h %p

[Blackers33]

Hi,

I confirm @shaunthorne 's workaround is working and is an acceptable solution in this case.

I've been trying to use Windows Terminal as the default console application for GNS3 network simulation software, and had the same buffering issues everyone is talking about. Using Plink works like a charm : wt -w0 split-pane --tabColor #C678DD --colorScheme "One Half Dark" --title %d --suppressApplicationTitle plink -telnet -P %p %h

thx

This solution is not satisfying because plink does not offer command history with arrow up and down.

the original issue has not been solved yet.

[nukoseer]

I spent some time trying to figure out what's going on under the hood about this telnet issue. What I see is that normally when we press RET on an empty terminal the LINE FEED (\r\n) sequences are usually sent along with some VT sequences (for placing the cursor etc.). I think the LINE FEED sequences are eventually used to set the viewport position (the request reaches up to Terminal::SetViewportPosition) when the viewport becomes larger than window, and after this point we are able to scrollback by moving the viewport. However, when I send RET while telnet is running, some VT sequences are sent, but there is no LINE FEED sequence, which means there will be no calculation effecting viewport(?). The viewport will always be at its default size and there will be no way to scrollback.

Here are sequences I get with and without telnet (I read them from Terminal::Write in Terminal.cpp).

telnet on CMD:

• \x1b7\x1b[0m\x1b[2;1;30;120;;1;1$v\x1b[32;30;1;30;120$x\x1b8
• \x1b[30;1H
• \x1b[30;1H\x1b7\x1b[30;1H\x1b[0mnukoseer@nukoseer:~$ \x1b8\x1b7\x1b[30;1H\x1b[0mnukoseer@nukoseer:~$ \x1b8\x1b7\x1b[0m\x1b[2;1;30;120;;1;1$v\x1b[32;30;1;30;120$x\x1b8\x1b[30;1H\x1b7\x1b[30;1H\x1b[0mnukoseer@nukoseer:~$ \x1b8\x1b7\x1b[30;1H\x1b[0mnukoseer@nukoseer:~$ \x1b8\x1b[30;22H

CMD:

• \x1b[4;13H
• \r\n
• C:\\Users\\PC>

I don't know if this is helpful at all, but just wanted to share my findings.

[zadjii-msft]

I also don't know if this just magically got better after 1.22, with the big-ol conpty rewrite.

[j4james]

I think nukoseer's log above is evidence that they're already using the new conpty rewrite. It appears that the Windows telnet client is scrolling the buffer with a ScrollConsoleScreenBuffer call, which we're now translating into a copy rectangle (DECCRA) sequence. That's the \x1b[2;1;30;120;;1;1$v in that log.

This is no better or worse than it was before (well except that it's now a lot more efficient). The fundamental issue is that the conhost buffer in this situation is the same size as the viewport (as has been previously mentioned), so telnet's attempt to scroll just appears to us like it's copying a block of data within the viewport.

But with the new conpty translation, it might now be possible to detect that as a special case (i.e. a ScrollConsoleScreenBuffer call covering the entire viewport) and map that to a linefeed instead of a DECCRA. I'm not convinced that's a good idea, but it's perhaps something to think about.