Telnet session

  • Thread starter Yannick Turgeon
  • Start date

Yannick Turgeon

Hello all,

I'm currently trying to pass commands to a telnet session and get the texte
generated (stdin + stdout) by the session. The problem I get is that the
Telnet.read_until() function seems to freeze after a couple of command. I
did a simplify script that reproduce the problem each time (I'm using 2.3.4
on W2K):

-------------------- Begin of script --------------------
import sys
import re
from string import *
from telnetlib import Telnet

TELNET_USER = "myUser"
TELNET_PWD = "myPassword"
TELNET_HOST = "localhost"


NEWLINE = "\r\n"
REMOVEJUNK = 1 #Remove Telnet output junk (formating chars?) before

def printRead(texte):
print texte

p = re.compile( '(.\[[0-9]{1,2};[0-9]{1,2}H[0-9]?|.\[K)+')
print p.sub('\n', texte)

# Loging in
tn = Telnet("localhost")
printRead(tn.read_until("login: ", TIMEOUT))
printRead(tn.read_until("password: ", TIMEOUT))
printRead(tn.read_until(TELNET_PROMPT, TIMEOUT))

# Send commands
tn.write("echo foo" + NEWLINE)
printRead(tn.read_until(TELNET_PROMPT, TIMEOUT))
tn.write("echo bar1" + NEWLINE)
printRead(tn.read_until(TELNET_PROMPT, TIMEOUT))
tn.write("echo bar2" + NEWLINE)
printRead(tn.read_until(TELNET_PROMPT, TIMEOUT))
tn.write("echo bar3" + NEWLINE)
printRead(tn.read_until(TELNET_PROMPT, TIMEOUT))
tn.write("echo bar4" + NEWLINE)
printRead(tn.read_until(TELNET_PROMPT, TIMEOUT))
tn.write("echo bar5" + NEWLINE)
printRead(tn.read_until(TELNET_PROMPT, TIMEOUT))
tn.write("echo bar6" + NEWLINE)
printRead(tn.read_until(TELNET_PROMPT, TIMEOUT))
tn.write("echo bar7" + NEWLINE)
printRead(tn.read_until(TELNET_PROMPT, TIMEOUT))
tn.write("echo bar8" + NEWLINE)
printRead(tn.read_until(TELNET_PROMPT, TIMEOUT))
tn.write("echo bar9" + NEWLINE)
printRead(tn.read_until(TELNET_PROMPT, TIMEOUT))

# Closing the connextion
tn.write("exit" + NEWLINE)
-------------------- End of script --------------------

The output looks like (command sent in read. Not included in the script
echo foo
echo foo

echo bar1
echo bar1

echo bar2
echo bar2

echo bar3
echo bar3

echo bar4
echo bar4

echo bar5
echo bar5

echo bar6
echo bar6

echo bar7 <----- From here read_until() is freezing forever without a

echo bar8 echo foo

echo bar9
--------------- End of output -----------------

It not related to the number of command sent. If your replace one of the
firsts "echo bar" by "dir", you'll get the error immediatly. It seems to be
related to the number of line generated by Telnet.

Anybody know why? How to correct this?



Eddie Corns

Yannick Turgeon said:
Hello all,

I don't see anything obviously wrong in the structure, a simpleminded
translation to linux worked as expected even with a command to generate a
recursive directory listing which, on my machine, is huge.

What happens if set REMOVEJUNK to False?, I had to do that to see any output
but I don't know what Windows generates. I guess what you're trying to filter
out is ANSI control sequences but I suspect you may not have that right and
you're removing ALL output.

A minor point, you only need to do the re.compile once, moving it outside the
function would be more efficient.


Yannick Turgeon

Hello Eddie,
What happens if set REMOVEJUNK to False?
Same thing except. It does not remove, in that script, "good" output
(textual). And the first symptom of the problem is not bad output but it's
the fact that Telnet.read_until() is freezing after at a given moment, in
our case on "echo bar7". Without a timeout, the function never return.

It's certainly related to Windows. I'm cooked again! I have to interact with
a windows program (not just send a command and get the ouput but instead (1)
start a program, (2) send a commande, (3) get the result, (4) send another
command based on the precedent result). I tryed first with popen3: no
interaction possible if one of your command depends from a precedent program
answer. Pexpect would do the job but it's not working on Windows. Telnet
would do the job too, but it doesn't seem to work correctly on Windows. I
just looked at Perl telnet lib... and I've got nausea, headache and
urticaria! And I don't even know if it would work better, so...

Thanks for your help. At least I know that my script would work fine on
linux and it's probably Windows related.


Yannick Turgeon

I found the answer... but not the solution. The problem comes from the fact
that Microsoft does not use a *real* telnet server. It's documented in Perl
Net::Telnet doc. They are not fully respecting telnet protocol. Windows
Telnet Server resend the text and ANSI char that would appear in a cmd.exe
window. Curious? Sure! So each time you send a command from a client that
lead to "push" the previous command out of the vitual "display" space,
Windows Telnet Server resend all the resulting "display". You can try it
with a Windows telnet session where the client is started from cmd.exe.
You'll see that after login (here though!), you can write 7 "echo" commands
and get the reply without "pushing" previous "echo" out of the window. On
the 8th "echo" ("echo bar7" in the script given in this thread), the window
is redraw. And when programmaticaly telneting this kink of server, you get
ALL what the screen would contain if it were a cmd.exe window. Yes! ALL!
Even what you already receive. Making the read_until() function unusable.

Here is what I've fond on Perl Net::Telnet doc:
By default MS-Windows doesn't come with a TELNET server. However third party
TELNET servers are available. Unfortunately many of these servers falsely
claim to be a TELNET server. This is especially true of the so-called
"Microsoft Telnet Server" that comes installed with some newer versions

When a TELNET server first accepts a connection, it must use the ASCII
control characters carriage-return and line-feed to start a new line (see
RFC854). A server like the "Microsoft Telnet Server" that doesn't do this,
isn't a TELNET server. These servers send ANSI terminal escape sequences to
position to a column on a subsequent line and to even position while writing
characters that are adjacent to each other. Worse, when sending output these
servers resend previously sent command output in a misguided attempt to
display an entire terminal screen.

Connecting Net::Telnet to one of these false TELNET servers makes your job
of parsing command output very difficult. It's better to replace a false
TELNET server with a real TELNET server. The better TELNET servers for
MS-Windows allow you to avoid the ANSI escapes by turning off something some
of them call console mode.

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Latest member

Latest Threads