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 :(

[pmonajem]

Folks please prioritize this item, this is rendering the app useless for many networking tasks.
I've noticed the VS Code integrated terminal is working fine but Windows Terminal is broken, interestingly enough.

[tarekeldeeb]

Is there any workaround for this issue?

[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.