Header Only - DO NOT REMOVE - Extreme Networks

EXOS CLI Cursor jumping


Userlevel 6
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

44 replies

Userlevel 6
Additional information: the issue occurs an serial connections (like in screenshot) or during ssh sessions
Userlevel 2
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.
Userlevel 6
You shouldn't see this issue with Telnet or SSH. Are you seeing it on SSH?
Userlevel 7
Stephen Williams wrote:

You shouldn't see this issue with Telnet or SSH. Are you seeing it on SSH?

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.
Userlevel 5
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.
Userlevel 6
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.

code:
configure cli columns 196
[/code]
Hope this helps.
Userlevel 7
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.
Userlevel 6
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
Userlevel 7
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).
Userlevel 6
Grosjean, Stephane wrote:

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

Which Putty Settings do you mean ??
Userlevel 7
Grosjean, Stephane wrote:

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

yes, for the terminal emulation part.
Userlevel 6
Grosjean, Stephane wrote:

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

Here my settings:



Userlevel 7
Grosjean, Stephane wrote:

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

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.
Userlevel 7
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
Userlevel 7
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))
[/code]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 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)
[/code]
Erik
Userlevel 7
Erik Auerswald wrote:

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))
[/code]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 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)
[/code]
Erik

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.
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.
Userlevel 7
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.
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.
Userlevel 7
dfroe wrote:

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.

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.
Userlevel 7
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. 😞
Userlevel 7
Erik Auerswald wrote:

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

Can you reproduce a ssh session, in VT100 emulation, being resized and then making the cursor jump?
Userlevel 7
Erik Auerswald wrote:

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

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
Userlevel 6
Erik Auerswald wrote:

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

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
Userlevel 7
Erik Auerswald wrote:

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

In case this is not clear: I agree with the annoyance of this behavior.

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

Reply