EXOS CLI Cursor jumping

  • 0
  • 5
  • Problem
  • Updated 9 months ago
  • Solved
EXOS CLI cursor is sometimes jumping out of the windows - especially on long command lines or if the putty windows was resized during the session (which is quite a normal effort).

Have a look:


Especially if you want to change one parameter within a existing line of commands.

This Problem occurs in all EXOS versions. I try several putty versions, but all have the same issue.

Does anybody know this issue ?

Is it possible to avoid that problem ? Maybe an adjustment on Putty client ?
Are there a possibility to make EXOS CLI line redraw ?

Regards
Photo of M.Nees

M.Nees, Embassador

  • 9,168 Points 5k badge 2x thumb

Posted 2 years ago

  • 0
  • 5
Photo of M.Nees

M.Nees, Embassador

  • 9,168 Points 5k badge 2x thumb
Additional information: the issue occurs an serial connections (like in screenshot) or during ssh sessions
Photo of Evan Kuckelheim

Evan Kuckelheim

  • 658 Points 500 badge 2x thumb
I've had the same issue since we have gotten our XOS switches since the late 15 code up to the latest 21 code. An annoyance for sure but I've gotten around it. 
Photo of Stephen Williams

Stephen Williams, Employee

  • 8,838 Points 5k badge 2x thumb
You shouldn't see this issue with Telnet or SSH.  Are you seeing it on SSH?
Photo of Erik Auerswald

Erik Auerswald, Embassador

  • 12,782 Points 10k badge 2x thumb
Yes, I do. :-(

EDIT: I tried to reproduce this with SSH on EXOS 15.3 and 21.1, but was not able to do so.
(Edited)
Photo of Frank

Frank

  • 3,662 Points 3k badge 2x thumb
Yeah, I've noticed that, too. (SecureCRT, connecting via SSH). Typically when I'm at the bottom of the screen with long/wrapping lines and/or up-arrowing (hey, a new verb!) to a previous long line and then wanting to in-line edit said line.

I usually just try to work around it by resizing the window and then trying again.
Photo of Stephen Williams

Stephen Williams, Employee

  • 8,838 Points 5k badge 2x thumb
This behavior has always been around.  it has to do with the console driver and the CLI colums. 

When you login you can change the columns to 196 and it should fix most of what your seeing. 

Note: this is a per session command. 

configure cli columns 196

Hope this helps.
Photo of Grosjean, Stephane

Grosjean, Stephane, Employee

  • 12,592 Points 10k badge 2x thumb
The "config cli columns" command has been introduced in 16.1. As Stephen said, this issue should only happen in console, because there're no ways to know the size of the window. So it defaults to 80. Since 16.1, you can change that per session.
Photo of M.Nees

M.Nees, Embassador

  • 9,168 Points 5k badge 2x thumb
Hi Stephane, Hi Stephen,

my problem occurs on both console and ssh!

I cannot believe that i have to set/define (every) session the count of needed columns?!

On every other compareable CLI interface i do not have care about this - not on a linux cli, not on other LAN Switch CLI interfaces.

I am not an expert on this but i believe at session startup (and maybe later if the window will be resized) the column count have to be detected automatically.

On EOS i do not have such problems. Maybe both developer groups should share their knowledge to achieve such basic features for all EXOS customers.

Regards
Photo of Grosjean, Stephane

Grosjean, Stephane, Employee

  • 12,592 Points 10k badge 2x thumb
I remember to have experienced once or twice that issue on telnet/ssh as well. What terminal emulation are you using? (not the program, but the settings).
Photo of M.Nees

M.Nees, Embassador

  • 9,168 Points 5k badge 2x thumb
Which Putty Settings do you mean ??
Photo of Grosjean, Stephane

Grosjean, Stephane, Employee

  • 12,592 Points 10k badge 2x thumb
yes, for the terminal emulation part.
Photo of M.Nees

M.Nees, Embassador

  • 9,168 Points 5k badge 2x thumb
Here my settings:


Photo of Grosjean, Stephane

Grosjean, Stephane, Employee

  • 12,592 Points 10k badge 2x thumb
I do not use Putty, but I was hoping to find some terminal emulation parameters. In SecureCRT I use VT100, and I barely have issues with telnet/ssh.
Photo of Erik Auerswald

Erik Auerswald, Embassador

  • 12,782 Points 10k badge 2x thumb
Hi,

I see this issue as well with telnet and SSH. The initial SSH connection sets the correct window size, but if the window is resized, this is not detected by EXOS.

I have to use configure cli lines / columns manually to adjust to the new window size.

I am using OpenSSH on GNU/Linux.

Erik
Photo of Erik Auerswald

Erik Auerswald, Embassador

  • 12,782 Points 10k badge 2x thumb
Well, I remembered somewhere seeing a resize script for EXOS... the Python Getting Started Guide (February 2015) from Extreme shows a file named "TermSize.py" on page 22, but no code for this. Thus I hacked up the following:
# source for terminal_size() function:
# http://stackoverflow.com/questions/566746/how-to-get-console-window-width-in-python/3010495#3010495
def terminal_size():
    import fcntl, termios, struct
    h, w, hp, wp = struct.unpack('HHHH',
        fcntl.ioctl(1, termios.TIOCGWINSZ,
        struct.pack('HHHH', 0, 0, 0, 0)))
    return w, h

columns, lines = terminal_size()

# columns must be in the range [80, 256]
if columns < 80:
    columns = 80
elif columns > 256:
    columns = 256

# lines must be in the range [24, 128]
if lines < 24:
    lines = 24
elif lines > 128:
    lines = 128

import exsh
exsh.clicmd("configure cli columns {0}".format(columns))
exsh.clicmd("configure cli lines {0}".format(lines))
I suggest to save the script as resize.py on the switch.

You can use it after resizing the terminal window:
  1. log into switch
  2. check terminal size used by EXOS
  3. resize terminal window
  4. run Python script from above
  5. check terminal size used by EXOS
Example:
~$ ssh admin@192.168.42.3
ExtremeXOS
Copyright (C) 1996-2016 Extreme Networks. All rights reserved.
This product is protected by one or more US patents listed at http://www.extremenetworks.com/patents along with their foreign counterparts.
==============================================================================

Press the <tab> or '?' key at any time for completions.
Remember to save your configuration changes.


* SW2.1 # show management | include size
CLI screen size                  : 24 Lines 80 Columns (this session only)
* SW2.2 # # ... resizing terminal window ...
* SW2.2 # show management | include size
CLI screen size                  : 24 Lines 80 Columns (this session only)
* SW2.2 # run script resize
* SW2.3 # show management | include size
CLI screen size                  : 47 Lines 100 Columns (this session only)

Erik
Photo of Grosjean, Stephane

Grosjean, Stephane, Employee

  • 12,582 Points 10k badge 2x thumb
Hi,

Yep I didn't include the code but this was something similar. The problem here is that it won't work on console. Again, it shouldn't happen over telnet/ssh. The reason to introduce the command "config cli columns" was a workaround for console.
Photo of David Froehlich

David Froehlich

  • 252 Points 250 badge 2x thumb

I can just affirm having the same issue all the time, too.

It is simply incomprehensible for me that we still need need to waste time with silly things like telling a console to resize itself.

The technical Background is quite well explained here on StackExchange: http://unix.stackexchange.com/questions/207782/how-are-terminal-length-and-width-forwarded-over-ssh-and-telnet

The mentioned RFC 1073 describing how to (re-)signal terminal sizes through Telnet goes back to 1988(!). This is even older than the first publication of the Spanning Tree Protocol. Speaking for myself as a network engineer, I expect my network gear to simply support such mandatory features to make my life easier. We have more sophisticated work to do so I do not want to have constant battles with my switch console. When being onsite and doing my work I simply need systems assisting me - which basically applies to the terminal resizing and other things as well (like a more convinient STP implementation for example, but that's another story).

I hope Extreme XOS will support this kind of terminal resizing some day. Not neccessarily due to a bunch of feature requests; simply because it makes sense, and (at least some) people simply expect 28 years old stuff to work - out of the box. Anyway, thank you for sharing your workaround, Erik.

Photo of Grosjean, Stephane

Grosjean, Stephane, Employee

  • 12,592 Points 10k badge 2x thumb
To sum up.

The issue is known for console access. And yes it's very annoying, I experience it as well... the 'config cli columns' is here to help.

The issue shouldn't happen for telnet/ssh, but I believe that could happen if you resize it. I would encourage you to configure your terminal emulator to open a session with a good width (like 100 for example) and not change it.
Photo of David Froehlich

David Froehlich

  • 252 Points 250 badge 2x thumb

Your suggestion is to simply not change the size of a terminal after connect? Are you serious? I thought fixed-size terminals died after the VT100 era...

You simply cannot predict which terminal width you'll need at the moment when you are connecting to a CLI. You will need to make it smaller at some point when you have to compare CLI outputs with a Notepad, you will have to make it larger when you issue a command with a larger output and so on. Working with a fixed-sized terminal might work in theory - but not in reality and everyday life of an ordinary engineer. Of course when talking about command outputs it would be pretty neat if all show command would respect the current terminal width and dynamically output smaller or larger views depending on the current width; like everybody has been used for decades when using unix-like systems for instance.

So we have yet another annoying issue, and we are waiting for it to be fixed.
"The issue shouldn't happen [...], but I believe that could happen [...]".
For me this sounds pretty much like a bug.

Photo of Grosjean, Stephane

Grosjean, Stephane, Employee

  • 12,582 Points 10k badge 2x thumb
I shouldn't answer from a phone.

For telnet/ssh I have been told in the past it should work. I don't have issues with telnet/ssh, but I agree I may have experienced it once or twice. So the possibility of a bug is high. But I failed to reproduced it. Now, I must be old school, I work with SecureCRT and in full screen. So maybe SCRT has a better VT100 emulation and/or being in fixed size is helping. I'm assuming from people's feedback that resizing is the problem in telnet/ssh. But I don't know for sure, actually.

I do understand how annoying this is, I use CLI a lot too. The main dev already has a clear understanding of my point of view on that matter.

That kind of feedback is important.
Photo of Erik Auerswald

Erik Auerswald, Embassador

  • 12,782 Points 10k badge 2x thumb
For what it's worth, terminal window resizing in SSH sessions just works for GNU/Linux inside XTerm and gnome-terminal using OpenSSH with Bash or Busybox ash as shell. It does not depend on Bash's checkwinsize option. There are no artificial limits for window sizes either.

I think it annoying that EXOS does not adjust automatically to a changed terminal window size for SSH sessions. :-(
(Edited)
Photo of Grosjean, Stephane

Grosjean, Stephane, Employee

  • 12,582 Points 10k badge 2x thumb
Can you reproduce a ssh session, in VT100 emulation, being resized and then making the cursor jump?
Photo of Erik Auerswald

Erik Auerswald, Embassador

  • 12,782 Points 10k badge 2x thumb
Hello Stephane,

I tried to reproduce this connecting via SSH to an EXOS 21.1 VM and an EXOS 15.3 X450e switch, but the line wrap worked fine when changing the window size. So the situation seems to be better than I remembered.

On the other hand, a usual GNU/Linux server or an Arista switch automatically adjust the size on terminal window resizing, resulting in correct paging, for example. In this regard I'd say that there is room for optimization. ;-)

Erik
Photo of M.Nees

M.Nees, Embassador

  • 9,168 Points 5k badge 2x thumb
I can only emphatically agree with Erik - setting the column count of a ssh session should be done automatically (not via manually command or python workaround script). As Eric describes other compareable vendors support such basic feature.

From my side i claim that EXOS have to provide tsuch functionality (as an network admn is have better things to keep in mind than the column count of my terminal).

I will be glad if you discusse that with PLM and transfer that demand to engineering.

Thanks.
Matthias
Photo of Grosjean, Stephane

Grosjean, Stephane, Employee

  • 12,582 Points 10k badge 2x thumb
In case this is not clear: I agree with the annoyance of this behavior.

Erik: I understand you didn't reproduce the issue. Correct?
Photo of Erik Auerswald

Erik Auerswald, Embassador

  • 12,782 Points 10k badge 2x thumb
Stephane, I did not reproduce the jumping cursor issue using SSH when trying today.

Automatically setting columns and lines according to the terminal size on every resize should be considered a feature request, it is standard behavior on GNU/Linux and Arista switches.
Photo of David Froehlich

David Froehlich

  • 252 Points 250 badge 2x thumb

You want an example? Well, I just typed a few commands on a recent XOS Switch (16.1.3.6 patch1-11), and the CLI get messed up even without any resizing of my terminal.

1) Open a PuTTY SSH to XOS.

2) Execute the following command:
download image 1.2.3.4 foo.bar vr VR-Default
It will intentionally throw an error without doing anything.

3) Press Key-Up to recall the last command.

4) Scroll left and position your cursor right after the filename for example.

5) Start typing anything and continue typing.

6) As soon as there is a line wrap going to happen at the end of your window, the terminal gets messed up like seen on Matthias' first screenshot.

And common, recalling a command and editing it, that's nothing unusal. I guess that even worked on VT100's back in the 80's..

Photo of Erik Auerswald

Erik Auerswald, Embassador

  • 12,782 Points 10k badge 2x thumb
I'd wager that results from the error message not taken into account correctly for cursor positioning (I could reproduce this using XTerm, OpenSSH, EXOS 15.3).

If I remember correctly just recalling or editing inside a line needing wrapping results in the "jumping cursor" when connected via serial console using a terminal window size that is different from the configured CLI size.
Photo of Grosjean, Stephane

Grosjean, Stephane, Employee

  • 12,582 Points 10k badge 2x thumb
Indeed.
I guess I didn't notice it because I need to type a lot to have it happen, way more than any command allows.

That shouldn't happen, a CR should be opened to have this investigated.
Photo of Henrique

Henrique, Employee

  • 10,302 Points 10k badge 2x thumb
As already mentioned, this issue happens for Telnet/SSH/Console and the workaround is to increase the column size (available in EXOS 16.1 or higher releases).

Since that adjustment is done per session, it's complicated to perform this after each login.

I'll check internally about a possible FR to "automatically set columns and lines according to the terminal size on every resize" and get back to this thread.
Photo of Alexandr P

Alexandr P, Embassador

  • 12,042 Points 10k badge 2x thumb
Thank you!
Photo of Alexandr P

Alexandr P, Embassador

  • 12,042 Points 10k badge 2x thumb
Hello, all!

22.2.1.5 patch1-4
Connect through Console.
After deleting some part of command cursor is still jumping up.
BUT
In unlike previous versions behaviors - in 22.2.1 rest part of command is dissapear.



Thank you!
Photo of Alexandr P

Alexandr P, Embassador

  • 12,042 Points 10k badge 2x thumb
With Telnet no issue.

Thank you!
Photo of Drew C.

Drew C., Community Manager

  • 37,366 Points 20k badge 2x thumb
When you are connected via a serial line, there is no way for the system to negotiate the window size with the terminal
https://unix.stackexchange.com/questions/317497/command-wraps-around-same-line-after-80-characters

I think you can use the configure cli columns command to adjust this when you're working with the console.
Photo of Alexandr P

Alexandr P, Embassador

  • 12,042 Points 10k badge 2x thumb
Thank you, Drew!