View Single Post
Old 10-21-2015, 01:26 PM
umbongo umbongo is offline
Registered User
Join Date: Oct 2015
Posts: 13
Does this cut-down version exhibit the problem?

In other words, if you're already connected with SecureCRT to your jump host, and you're sitting there at the jump host's shell prompt and you run this cut-down script, do you see the problem occur?
Yes, of course! I tested it before posting. It was actually far down the path of my non-programmer's diagnostic approach. I wanted to make sure it wasn't another part of the script that was causing an issue. The script is rather lengthy so didn't want to post the whole thing up. To re-iterate: the script I posted experiences the problem when initiated from the script menu once connected to the jump server.

BTW, the 'ssh' and 'telnet' you're sending as commands to your jump host should not be considered as relevant to SecureCRT's synchronous property...
Yes, I know... that's what makes the problem even more odd! I understand the concept of synchronous and that it applies to the connection to the jumpserver.

If in your script you're running a loop issuing 'telnet' and 'ssh' commands on your jump host to multiple hosts, you will want to make sure that you perform a WaitFor...() operation on ALL commands you send (even the 'exit' at the end). Otherwise, things could get out of sync.
It is running in a loop in th production script, however the example is not. Also if everything is connecting using telnet then everything works perfect. It is the switch to SSH that breaks it, so I would think that proves the waitFor and sends are OK. The only ifference really is that telnet login is interactive so has to be automated. But to my untrained eye the logic seems OK there.

The way to handle this specifically is to know what the prompt will always be for your jump host, and set that as a special one that you wait for after each "exit" command you use to "disconnect" the jump host from the secondary host.
On the host I'm testing SSH on I know exactly what the prompt is and I did set it statically as part of troubleshooting using "objTab.Screen.WaitForString "router#"... but it made no difference.

Another possibility is that the remote system might be sending an escape sequence that contains text that could be found that doesn't appear on the screen. For example, some UNIX shell prompts include escape sequences that set the "title" of the window; such titles can include the prompt text, which can result in WaitForString*() returning unexpectedly. You can set Screen.IgnoreEscape = True, to make sure that escape sequences don't cause problems with your WaitFor()s.
Excellent! I'll try that and report back!

To have an idea of what's actually being sent to SecureCRT, you can turn on "Raw" logging (File -> Raw Log Session), run your script, and then go take a look at the raw log file to see what the remote is sending to SecureCRT (some of which doesn't get displayed to the terminal screen because it's part of an escape sequence).
Ermmm... OK... I'm actually disappointed I didn't think of that myself. But I guess my problem is so obscure I'll give myself some slack!

Thanks for the initial look at this. I'll try your last two suggestions and let you know how it goes!