Arista echoes command even though it doesn't process it (early in login process)

We are seeing what seems to be a race condition with ssh logins on arista devices.

Here’s the symptom:

(Channel opened)
DEBUG:netmiko:write_channel: b'\n'
DEBUG:netmiko:write_channel: b'terminal width 511\n'
DEBUG:netmiko:read_channel: Last login: Mon Aug 15 20:10:51 2022 from 10.33.118.14


--- Banner text elided ---

DEBUG:netmiko:read_channel: terminal width 511

DEBUG:netmiko:read_channel:
DEBUG:netmiko:read_channel:
DEBUG:netmiko:read_channel:
DEBUG:netmiko:read_channel:
.
.
.
DEBUG:netmiko:read_channel:
DEBUG:netmiko:read_channel:
DEBUG:netmiko:read_channel:
terminal width 511

DEBUG:netmiko:read_channel:
DEBUG:netmiko:read_channel:
DEBUG:netmiko:read_channel: hostname#
DEBUG:netmiko:read_channel:
.
.
.
20 seconds of read_channel:
.
.
.
DEBUG:netmiko:read_channel:write_channel: b'\n'
DEBUG:netmiko:read_channel:
DEBUG:netmiko:read_channel:
hostname#
DEBUG:netmiko:Pattern found: ([>\#])
hostname#
DEBUG:netmiko:write_channel: b'exit\n'

Pattern not detected: 'Width set to' in output.

Things you might try to fix this:
1. Adjust the regex pattern to better identify the terminating string. Note, in
many situations the pattern is automatically based on the network device's prompt.
2. Increase the read_timeout to a larger value.

You can also look at the Netmiko session_log or debug log for more information.

Notice that the term len 511 string was sent before the prompt was displayed.

Here’s an example showing that this can lead to data loss:

$ ssh hostname
Password: 
Last login: Mon Aug 15 20:19:46 2022 from xxx
 
--- banner message elided ---


hostname# cdefghinjklmopqrstuvwzyz
% Invalid input
hostname# cdefghinjklmopqrstuvwzyz

The input is abcdefghijklmnopqrstuvwxyz\r entered via a keyboard macro immediately after typing return for the password. In this particular case, the first three characters are dropped (I pressed up arrow to see what was actually read by the CLI). If I’m fast, it’s pretty easy for the entire string to be missed. (Sometimes it’s echoed back, but it’s not actually read by the CLI, as can be seen above.)

Looking at the Arista implementation of session_preparation(), it looks like there is no synchronization with the CLI before sending the string to set the terminal width. Indeed, adding a call to

self._test_channel_read(pattern=r"[>#]")

prior to the call to set_terminal_width() resolves the issue. Looking at history, it looks like this was removed as part fo the optimizations in #1960 .

[tlaberge]

We love our vendors. I will open a case with them, too. Thanks for the quick response.

[ktbyers]

I think this should help with the issue:

https://github.com/ktbyers/netmiko/pull/2944

There still could be problems as Arista is really doing something it shouldn’t do here (i.e. echoing the command when the CLI is not actually ready to process it and also double echo of the command…though it is possible there are other low-level CLI things going on here that I don’t have enough knowledge on).