The following command to the Juniper box seems to fix the problem!
`set cli terminal xterm`
I don't know if it will cause other problems, however....
Xterm is an extension of ANSI. So xterm has extra escape sequences for colors and other stuff. iTest will ignore these extra escape sequences completely. iTest does not really support Xterm terminal type.
For most cases, if you set the terminal type to XTERM in iTest, nothing bad will happen.
I tried to use the usual mechanism for prompt training, but this did not work for a Juniper device and step capture did not work. After creating the prompts manually, step capture worked fine. Is this a known issue?
It depends on Juniper box. Some h/w acquired by Juniper is labelled JunOS - but is not JunOS and has a very primitive or strangely behaving telnet server on the device. In these cases, our capture cleanup heuristics may not work.
If you can provide an access to the device, it may be possible to build these new heuristics in future versions of iTest.
It will also be useful if you can provide a wireshark capture of a typical interaction with the device using Telnet (not SSH because SSH data is encrypted).
iTest: (ip.addr eq 10.155.2.32 and ip.addr eq 10.154.1.101) and (tcp.port eq 23 and tcp.port eq 4617)
PuTTY: (ip.addr eq 10.154.1.101 and ip.addr eq 10.155.2.32) and (tcp.port eq 4619 and tcp.port eq 23)
ftp://ffftp%40fanfaresoftware.com:Ff448@ftp.fanfaresoftware.com/DevSupp/juniper.pcap
Both iTest and Putty are sending the same ANSI escape sequence to the device:
\033[A
But the device responds differently. This is because of "terminal type" negotiation. If you can capture in wireshark what terminal type putty is sending to the device and set the same terminal type text in iTest, your problem will be resolved.
BTW - you can see the terminal type when you open a brand new telnet session because terminal types are negotiated by the client and the device when the session starts.
