This is a discussion on Re: Sending a file via telnet - Protocols ; In article , Lloyd Sumpter wrote: : On Fri, 29 Aug 2003 14:36:03 +0000, Frank da Cruz wrote: : > In article , : > Lloyd Sumpter wrote: : > : I'm using Linux (Mandrake 9.0) to access a device ...
: On Fri, 29 Aug 2003 14:36:03 +0000, Frank da Cruz wrote:
: > In article
: > Lloyd Sumpter
: > : I'm using Linux (Mandrake 9.0) to access a device that only
: > : communicates using Telnet. I need to send a file (Motorola
: > : S-records). How do I send a file with telnet? I tried using cut-n-paste
: > : from another window: seemed to work but was SLOW and cumbersome - this
: > : file is 2000 lines long!
: > :
: > Use C-Kermit as the Telnet client:
: > http://www.columbia.edu/kermit/ckermit.html
: > How to send the file depends on what protocols are supported by the
: > device. Choices include:
: > . Kermit protocol (straightforward, built into C-Kermit)
: > . X- Y- or Zmodem (can be invoked by C-Kermit as an external protocol)
: > . "ASCII" (use C-Kermit's TRANSMIT command for this)
: > I suspect "ASCII" is what they use. Type "help transmit" at the
: > C-Kermit prompt to find out about it.
: > - Frank
: That just might work - thanks!
It will work. Kermit has been used to send files consisting of S-records
via "ASCII" protocol to devices that support only serial-port or Telnet
access for 20 years -- which is to say we have some experience with this.
Kermit's TRANSMIT command is a transport-independent way of sending files
a line at a time without error detection or correction, to be used in
cases like this one where no higher level protocol is available (FTP,
HTTP, Kermit, XYZmodem, etc). It has all sorts of options to let you control
handshaking, pacing, and whatnot. Again, HELP TRANSMIT explains the
TRANSMIT command, and HELP SET TRANSMIT explains the options and settings.
Obviously this is less desirable than an error-detecting-and-correcting
file transfer protocol, but when you have no other choice this is what
you have to do. Meanwhile, the S-records themselves contain framing and
checksum information, so after you have uploaded them, you still get
error detection when you actually try to *use* the S-records.
A typical setup might be:
if fail exit 1
There might be some additional wrinkles depending on which TCP port
you connect to and whether (and to what degree) it supports, uses, requires,
or misimplements Telnet protocol -- all of this can be handled. If you
have problems or questions, read the "help set host" text or send email to
At this point if any dialog is required to log in or set up the transfer,
do it here using INPUT, OUTPUT, and IF FAIL commands as explained here:
Then to upload the file:
set transmit prompt 0 ; explained below
transmit blah.hex ; send the file
close ; close the connection
The "transmit prompt" tells Kermit what to wait for after sending each
line before it sends the next line; 0 means don't wait for anything.
Normally it waits for Linefeed (10), because that's what you get in
situations where the receiver of the transmission echoes incoming lines.
Another consideration is how you tell the receiver that the transmission
is finished. I'm assuming you just close the connection (as shown above).
You can also have Kermit send a character or string of your choice, that
you can specify with the "set transmit eof" command, e.g. \4 for Ctrl-D,
which you would use if the receiver was the Unix 'cat' command, or \26 for
Once you have this working, you can also use it for the serial port
connection; just replace the "set host" command with something like:
set modem type none
set flow rts/cts ; or xon/xoff, whichever the device uses
set port /dev/ttyS0 ; or whatever
if fail exit 1
set speed 38400 ; or whatever
Readers really should take a look at Kermit when trying to puzzle out how
to do any moderately complicated or obscure communications task, especially
if it is to be automated. Kermit does:
telnet (secure: Kerberized or SSL/TLS or SRP)
ftp (secure: Kerberized or SSL/TLS or SRP)
http 1.1 (clear text)
http 1.1 (SSL/TLS)
and it can also act as a scripting and file-transferring front end for
your SSH client.
Procedures coded for Kermit are transport independent (except for the
part where you open the connection) and platform independent: the same
procedure runs on all varieties of Unix, as well as on Windows, VMS and
other operating systems where the many Unix-specific tools suggested by
other posters tend not to be available.
C-Kermit was included in the Red Hat 9 distribution, although I discovered
recently that it does not get insalled by default and it's not obvious how
to get it off the CD. No worries, it's easy to download from Columbia U:
Put it a fresh directory and:
tar xvf cku209.tar
mv ./wermit /usr/local/bin/kermit
and, if it is to be used for dialing out, give it the same owner, group,
and permissions as minicom. Detailed installation instructions are here:
Or if you prefer, there's an RPM here:
(but this version is slightly behind the one at Columbia).