"The Linux Gazette...making Linux just a little more fun!"

Redirecting stdin into telnet

From Christopher Smith on Tue, 18 Jan 2000

I'm running Red Hat 6.0, and I'm trying to redirect my telnet stdin from a file. Whenever I use either a pipe or < input, the client connects, informs me that the escape is ^], and says the remote server has closed the connection. What's wrong?

Example: $ telnet csmith < input.txt

Christopher Smith

I've seen examples of telnet scripting being done this way. However, I think it probably depends on the version of telnet that you're using and there is a better way.

For example when I do an strace on my copy of telnet I find a number of system calls like:

ioctl(0, SNDCTL_TMR_STOP, {B134 -opost -isig -icanon echo ...}) = -1 ENOTTY (Inappropriate ioctl for device)

Note that result: ENOTTY which is kernel speak for "Error, this file handle doesn't refer to a terminal device (TTY)"

This suggests that telnet is detecting that its input file handle is not a terminal device, and is bailing at that point.

• (It would be nice if it gave an error message a unique error code and if they listed this constraint in their man pages).

Anyway, simple redirection is not the way to run interactive programs like telnet under scripted control. You probably want to use the 'expect' scripting language instead.

For example, here's a simple 'expect' script to control telnet sessions:

#!/usr/bin/expect -f
# Sample telnet automation
## call with autotel host username password

set host [lindex $argv 0]
set rcfile [open ~/.autotel/$host  r ]
gets $rcfile user
gets $rcfile pass
spawn telnet  "$host"
expect "login:"
send "$user\r"
expect "word:"
send "$pass\r"
interact

This appears in my book (Linux System Administration, published by New Riders Publishing). You call it like:

autotel foo

... and it will automatically look for a .autotel/foo file under you home directory, read a pair of lines for the user name and password. Then it uses them to login to the host (whose name must match the .autotel/ filename (*) ).

• (Actually the version of this on my own system read three lines from the autotel files: a location, and the username/password pair).

As I say this is a very simple 'expect' script. It shows the most basic features of the language: you can do all of the normal things like open files, read from and write to them, do basic string handling and arithmetic, etc. But the features of 'expect' for which it is renouned include the ability to 'spawn' interactive processes on psuedo-terminals (ptys), and to 'expect' certain patterns from the them, and 'send' strings back to them.

Of course 'expect' has support for the common conditional and looping structures, and the 'expect' function supports timeouts values. So you can write arbitrary handling for errors and situations that don't match your intended dialog.

There's also the 'interact' function which allows your script to turn the keyboard back over to you, so that the script then passively relays your input and the program's output. Actually the 'interact' function is even more powerful than than since it can also monitor the communications and dynamically "catch" certain key sequences, expanding them into macros, or using them as triggers to execute your own defined procedures or to break out of the interaction and complete other parts of the script.

So, I'd check out the 'expect' programming language and see if that will help. Here's an untested script that would do something like what you wanted:

#!/usr/bin/expect -f
# Sample telnet "feeder"

set host [lindex $argv 0]
set infilename [lindex $argv 1]
set infile [open $infilename r ]
spawn telnet  "$host"
while [ gets $infile line ] {
    sleep 1
    send -- $line
    }

(This would just blindly feed lines into a telnet session from your input file. It's pretty stupid, but you'd call it with something like:

telfeeder host.domain.not ./filename

... note the lack of redirection here).

Note that it's also possible to use C-Kermit (the kermit communications package from Columbia University http://www.columbia.edu/kermit) to automate and script a communications session. I wrote an article about this for SysAdmin Magazine (http://www.samag.com/archive/0607/index.shtml) back in 1997. The key point of that article (which is not online, though I could probably re-publish myself now) is that Kermit is not just a file transfer protocol and it is not limited simply to modem and serial communications, it has support for telnet and rlogin protocols.

In fact Kermit as improved since my article:

• it now supports Kerberos authentication and encryption
• it has internal SSL support
• it can use some other program like ssh for its communications channel.
• it can now operate as an alternative to FTP using providing a number of advantages over the somewhat decrepit FTP protocol.
• the license has been clarified and liberalized a bit, to allow re-distribution with free OS packages (like Linux, *BSD, etc) etc.

(Some of these were features I recommended to Frank de la Cruz, the father of Kermit, during my research and in subsequent e-mail conversations. However, I'm by no means the only person to make these sorts of suggestions and I couldn't claim any credit for their development).

One other alternatives to 'expect' that comes to mind is the Expect.pm, PERL module which add 'expect' features to the PERL 5 language. (The old PERL 4 had a comm.pl library that offered some of these features as well).

I'm sure there are others.

Hopefully this will help you solve the real problem that you're bumping into. Obviously, solving the problem goes way beyond just answering the question you asked.

Copyright © 2000, James T. Dennis
Published in The Linux Gazette Issue 50 February 2000

HTML transformation by of Starshine Technical Services, http://www.starshine.org/

					1	2	3	5
				5	6	7	8	9
10	11		13	14	15	16	17
18	19	20	21	22	23	24
26	27	28	29	30	31	32	33
34		36	37	38	39	42	41
42	43	44	45	46	47	48