Iskratel Si3000 echo consisting of ANSI characters only

[denisbondar]

Hey, everybody!
How to deal with devices like the Iskratel SI3000 optical line terminal, which in response to input characters returns a horrible echo in the form of ANSI characters. For example (scrapli transmits a command configure and the device returns this ANSI sequence):

\e7c\e8\e7o\e8\e7n\e8\e7f\e8\e7i\e8\e7g\e8\e7u\e8\e7r\e8\e\7e\e8

Well, what happens if you enter the command manually in Telnet terminal and watch the exchange with Wireshark (below I show the character-by-character entry of the command > and what the device < responds):

> c
< \x1B7c\x1B8\x1B[1C

> o
< \x1B7o\x1B8\x1B[1C

> n
< \x1B7n\x1B8\x1B[1C

> f
< \x1B7f\x1B8\x1B[1C

> i
< \x1B7i\x1B8\x1B[1C

> g
< \x1B7g\x1B8\x1B[1C

> u
< \x1B7u\x1B8\x1B[1C

> r
< \x1B7r\x1B8\x1B[1C

> e
< \x1B7e\x1B8\x1B[1C

(Somehow I didn't think it would be better to take a shorter command for the demo.)

In general, I get this echo response to any information sent towards the device.

Naturally, the scrapli algorithms do not see in the response what they sent to the device, and nothing works.

How can I solve this problem, considering that I need the functionality of a network driver in this case?

[carlmontanari]

damn @denisbondar always coming in hot with some wild ones 😁 !!

am I understanding correctly that this is happening on write -- and thats why scrapli never thinks the command it sent is actually there/done? if "yes", this could probably be solved the same way we did in scrapligo here -- I just never got around o bringing it into scrapli(py). If we bring this to scrapli(py) (which I am super down to do) we just gotta make sure its not super slow since it very well could be... if it is we could make it optional perhaps.

Lemme know if I misread that or if I'm tracking correctly and we can figure out what to do. thanks for bringing this up @denisbondar !

[denisbondar]

As an "head-on" solution option. Maybe add some option to disable checking of the passed command via echo?

[denisbondar]

This is the Channel.send_input() method, which calls _read_until_input() to wait for a match between the command sent and the text returned from the device.

Channel creation is hard-coded in the Driver initialization and it is not possible to use its alternative implementation.

Maybe an additional ansi escape cleanup can be added at this point so that it fits the case describing too?

[carlmontanari]

Maybe add some option to disable checking of the passed command via echo?

yeah that's possible for sure. does the prompt come back "nicely" after entering the input? or is there more ansi craziness in the prompt output too? an eager_input option or something here seems like it would be reasonable, ya?

not possible to use its alternative implementation

you could get crazy with types.MethodType 🤣 but I get what you mean 😄

Maybe an additional ansi escape cleanup can be added at this point so that it fits the case describing too?

yeah, ideally I don't wanna play whack-a-mole with ansi patterns for forever. do you know what the deal is with these ansi patterns and why our regex doesn't catch them?

so yeah - sounds like we have a few things to do:

1. add the fuzzy read until like scrapligo
2. add something like an eager_input flag for send stuff here
3. maybe expand ansi pattern

[denisbondar]

I created a PR #316 with the corrected regular expression.

[carlmontanari]

dang, nice work!!! love the idea of the pattern just handling this and then we can keep the roughly match for other use cases (the origin of this was pasting in certificates and stuff in Nokia srl). probably won't get to test this till this weekend as ill want to run it on all the virtual stuff I have available but it looks great -- and very good call adding comments because... yea... stuff is impossible to remember and scary looking!

[denisbondar]

It would be great if you could add all the ANSI-ESC combinations you have to the test to check for changes in the PR #316 and for the future.

[carlmontanari]

It would be great if you could add all the ANSI-ESC combinations you have to the test to check for changes in the PR #316 and for the future.

yeah... about that :) haha. I think the only platform I know for sure has some ansi in normal output is arista ceos. so I'll test that and add a test case. otherwise this may be a "yolo" moment and we update tests if/when things break for folks... not ideal but I think usually the ansi stuff is more corner case so hopefully minimal issues (also, people can pin their stuff, I don't feel too bad about changing things :))

[denisbondar]

🔥 See you on the weekend! Have a good week!

[carlmontanari]

resolved in #316 !

[denisbondar]

Aren't there enough changes for a new release? 🥹

[carlmontanari]

hah yep. ill release this week. ive been pretty consistent about jan 30th and and July 30th releases (there's some old blog post about it somewhere), so ill stick to it. may do it tonight if I have time, but release will be 2024.01.30 regardless (im lazy, but also like to be consistent :P)