0 votes
by (520 points)

In SshSession.cs near line 1209 in the internal T WaitFor<T,S>(FinishCheck<T,S> finishCheck, int timeout, WaitFlags flags, S state, T timeoutDefaultValue, T closeDefaultValue) function there seems to be an error of misinterpretation about timeouts.

When scripting, I expect the timeout value to measure the time between receipt of data from the terminal. I encountered a case where my timeout value was shorter than the keepalive frequency set by the server. In this case, the keepalive packets from the server were resetting the timeout monitor, but the terminal wasn't returning any data, so my scripting never timeout, and I got stuck.

1 Answer

0 votes
by (147k points)
Hello, would it be possible to let us know how to reproduce the scripting issue? Which API do you use, and how? And which version of Rebex components do you use?
by (520 points)
it was observed in an older version... 2016 R1.

the behavior was observed when connecting to a JUNOS device, whose keepalive frequency was set to 15 seconds and our timeout was 25 seconds.

When doing a ReadAll, the CLI would send no output (as no command had been sent) but the keepalive packets were triggering the method to stop and the timeout value wasn't being checked because it was being treated as a network packet timeout not a terminal value timeout.

We are using the Scripting API.
by (147k points)
Thanks, we'll try reproducing this!
However, would it be possible to try this with 2020 R5 release to make sure this is still happening? 2016 R1 is already more than 5 years old...
Also, a communication log of the scripting session created with LogLevel.Verbose could be useful, as it would reveal what's actually going on. See https://www.rebex.net/kb/logging/ for more information on logging. (And only enable LogLevel.Verbose once connected and authenticated to prevent revealing private information.)
...