Yes. Microsoft's Telnet server runs in two modes: "stream" or "console". By default it runs in console mode and this will mean that the cursor will jump all over the screen to fill it in. By comparison, stream mode will keep input and output in a logical stream -- the way iTest needs to look at it. I think your problem will be resolved if you reconfigure the Telnet service to run in stream mode.
To do this on Windows XP or Server 2003, type the following commands at a command prompt on the PC that is running the telnet service:tlntadmn stop tlntadmn mode=stream tlntadmn start
By the way, in case you're wondering why you are seeing all of those individual commands with one character each, it is because iTest has determined that the server is in "screen mode" -- like you will see some terminal applications that use the whole screen and where you can use keys to control the screen. iTest works with these, but this mode will preclude the natural flow of commands and responses, in favor of a key-at-a-time producing a screen as a response.
Thanks, Paul. It worked. Appreciate your quick response. Small correction in the command used.
We need to use "config" sub-command.
tlntadmn config mode=stream
Thanks for the correction. The next person reading this will appreciate it!
I'm seeing the same problem and setting stream mode seems to have fixed the single character problem; however, now my backspace and arrow keys are behaving oddly. Backspace just backsup and doesn't delete (in fact it backs over the prompt) and the arrow keys move the cursor where it shouldn't be.
Is there anything else we need to set?
Sounds odd. Take a look at the Keyboard properties in the telnet session properties. You can change both of these behaviors. But it is still odd, as I wouldn't expect Windows telnet to require this. Is it possible the Windows machine is configured for a different international geography or something?
Looks like something funky is going on with the server. We're seeing odd behavior on Putty too. The backspace doesn't work no matter what we set the property to. The linefeeds are odd too. See attached.
I've seen this kind of thing before. The thing to notice is that each new line starts AFTER the previous line ends. That means that we're not getting carriage return codes at all. We're just getting newlines. From looking at this screenshot, it looks like the problem is probably with the program inside Windows here -- not Windows itself. For example, we've seen that if you run a perl or python script from within Windows, those programs have a command-line option that will ensure that they provide carriage returns when working with stream-mode interface (like Telnet).
Can you provide any more information about what you are running within Windows in this case?
Yeah it's iscsicli. It's the command line implementation of Microsoft iSCSI Initiator.
The newline problem seems to be just in iscsicli, but the backspace/arrow thing seems to be everywhere in the telnet session.
Perhaps there's a pipe utility in Windows that you could push the iscsicli output through to get the line endings normalized? As it is, I think you'll find the same problem with almost any terminal emulator in stream mode.
For example, on a quick Google, I found this page that refers to a pipe-capable utility. Don't know if it works or not.
No one has followed this question yet.