Subject: Linux-Activists - TERM Channel digest. 94-3-29-8:49
From: "Linux Activists" <[email-masked]>
To: "Linux-Activists" <[email-masked]>
Date: Fri, 29 Apr 1994 20:50:11 +0300

Topics:
	 Re: Linux-Activists - TERM Channel digest. 93-11-16-1:33

----------------------------------------------------------------------

From: [email-masked]
Subject: Re: Linux-Activists - TERM Channel digest. 93-11-16-1:33
Date: Fri, 29 Apr 1994 11:29:46 +0300

%I've been swearing I'd do this for a long time now. Here's the first
%draft of the first part, basically dealing with how to set up term,
%and potential gotchas (much of it just rehashes the man pages, which I
%think are pretty good - any comments on stuff that this or the man
%pages miss?). Later parts will deal with tredir, X (both in and out),
%mail, sxpc, pop, term applications and anything else people can think
%of. Feedbacak/Help greatly desired and appreciated.
%
%-----------------------------------------------------
%                       Term HOWTO (Draft)
\documentstyle{article}
\begin{document}
\parindent 0.0em
\parskip 0.1in

\title{Term HOWTO}
\author{Bill Reynolds}
\date{April 29, 1994}
\maketitle
\section{Introduction}
{\bf About This Document} 

This HOWTO attempts to clear up some of the counfusion of using {\tt
term}, Michael O'Reilly's remarkable program that allows you to
mulitplex you serial line and set up an esatz network connection.
Currently this document only expands on the (rather good) documents
provided with {\tt term} on how to set up a {\tt term} connection.
Future versions will explain how to use some of {\tt term}'s more
advanced features. I've seen a document on how to use mail with {\tt
term}, hopefully these HOWTO's can be merged together.

{\bf What is {\tt term}}?

{\tt term} is a program, written by Michael O'Reilly
([email-masked]), that is run over a serial line to
allow multiple connections to operate concurrently - {\em i.e.\/} you
can be downloading a file over your modem while working on a
(different) remote system via the same modem connection. {\tt term}
can also be used to open up X client windows over a serial connection.
Through the {\tt tredir} utility, {\tt term} can provide many of the
``traditional'' network services: mail, news, ftp, telnet, etc.  In a
sense, {\tt term} is very much like other serial protocols such as
SLIP or PPP. {\tt term}'s advantage is that it can be run entirely
from user space, requiring neither kernel support nor support from
system or network administrators.

\section{ Setting Things Up}
{\bf Nomenclature} 

I'm assuming you're dialing up a system through some sort of terminal
server. I use the terms ``local'' and ``remote'' to refer to the home
and network connected systems respectively (unless I use them to mean
something else :-).

{\bf Build Term} 

Hopefully, this should just involve a {\tt make}, if this doesn't
work, you may have to do some hacking. Make sure that you've got the
same version on all machines you want to run term on - different
versions of term are incompatible. Seek out and destroy any old
binaries on your system - or know how to avoid them.

{\bf Test Term } 

Do a {\tt make test} to build term's test daemon. Test works by
running two copies of term on your system, a ``local'' and a
``remote'' copy. Both of these will read your {\tt termrc }, so you
can adjust their behaviour. Run {\tt test} as {\tt ./test} so as to
avoid your system's {\tt test}. You should now be able to do a {\tt
trsh} and a {\tt tupload } (try {\tt tupload ./term /usr/tmp} - you
should get a copy of the term binary in {\tt /usr/tmp}). The local
term's output should show up in {\tt local.log}, the remote's in {\tt
remote.log}. You can start term up with a {\tt -d255} flag to enable
debugging output to be written to these files, or enable debugging in
your {\tt termrc}.

Check the commands on the terminal server (help or ? will usually get
you started). Try to make the link as transparent as possible - going
for the 8 bit options whenever possible. This may mean changing the
way you log in to a system, e.g. if the server uses rlogin, you may
have to use it and give it the -8 flag to make it transparent.
Especially watch out for xon/xoff flow control, you don't want that,
try to enable rts/cts (hardware) flow control. You may need to check
your modem docs to learn how to configure it to do 8-bit rts/cts
communications.

{\bf Run linecheck} 

On the remote system {\tt linecheck linecheck.log} On the local system
run {\tt linecheck linecheck.log > /dev/modem < /dev/modem} When it's
done, you'll find the the characters numbers to escape in your termrc
(for the other end!) at the bottom of the {\tt linecheck.log} files.
On my system, my local {\tt linecheck.log} said nothing and my remote
{\tt linecheck.log} said to escape 29 and 157. Therefore, my local
{\tt termrc} escapes these characters and my remote {\tt termrc}
escapes nothing.  Remember, if I {\tt escape} a character on one end,
I have to also {\tt ignore} it on the other.

If linecheck hangs, try using \newline 
{\tt linecheck linecheck.log 17 19 > /dev/modem < /dev/modem}\newline
this will escape your xon/xoff (flow control)
characters, which will hang your line if you've got software flow
control. If this solves the hanging problems, you'll want to {\tt
escape}/{\tt ignore} 17/19 in both {\tt termrc}'s. If your terminal
server has other demonic characters that will shut it down, try
running linecheck with those characters escaped, as above.

In summary, my local termrc has the lines\newline
{\tt 
escape 29\newline
escape 157\newline
}
and my remote termrc has the lines\newline
{\tt 
ignore 29\newline
ignore 157\newline
}
since my {\em remote\/} {\tt linecheck.log } said to escape 29 and 157.

{\bf Try Running {\tt term}}:
    
Log into the remote system, making the link as transparent as possible
(if you haven't already).
Fire up {\tt term} on the remote end. I use the following:\newline
{\tt 
exec term -l \$HOME/tlog -s 38400 -c off -w 10 -t 150. 
}\newline
Let's run down each option one by one (note that I could just as
easily have put these options in my termrc. I did it this way because
it saves editing a file while getting term set up).

{\tt exec} means to destroy your current shell, running the given program
in its place.  I {\tt exec} things because I don't intend to use my login
shell again, so it's just wasting memory. If you're debugging the link
and can reliably kill the remote term, you might not want to do an
exec.

{\tt -l \$HOME/tlog}. This logs errors to the file {\tt tlog} in my
home directory.  Very useful for debugging. No reason not to do this.

{\tt -s 38400}: I've got a 14400 baud modem, with compression. For
optimal compression ratios, I want to be able to push bits down the
pipe as fast as possible. For a slower modem, you should use something
lower.  Note that if you have a slower machine with 16450 uart on your
serial port, high baudrates can cause data loss by overloading the
chip on your serial port. Term will recover from this, but if you see
a lot of error messages in your log file, (or get overrun warnings
from linux kernel versions 0.99pl15 and up) you again might want to
lower this number.

{\tt -c off}: This turns data compression off. I've got a compressing
modem, and I don't want to compress things twice.

{\tt -w 10 -t 150}: Again, these are options to optimize my fast modem
link.  I have set my window to 10 and my timeout to 150. This is per
the recommendation in the {\tt term\_setup} man page.

 Suspend your comm program (\verb+^\+\,{\tt Z} under kermit). You don't
want it running while term is running, because it will fight with term
over the serial port. If you can convince your modem to not hang up
when you exit your comm program (when it toggles DTR), you could just
exit the program at this point.

 Now run term locally. I use: \newline{\tt term -r -c off -l
\$HOME/tlog -s 38400 -w 10 -t 150 \verb+\+\newline < /dev/modem >
/dev/modem \& }\newline The only option here that is different from
the other end is the {\tt -r} option. You need this on one end,
otherwise term clients will spontaneously die on you. I need to tell
term where the modem is, so I point both standard input and output at
{\tt /dev/modem} (that's what the {\tt <} and {\tt >} do). I also run
it in the background, so I can use this screen for something else if I
want to.

Term should work now :-). Try a {\tt trsh}, and see what happens. If
you hang, or your link seems slow, take a look at your {\tt tlog} on
each end.  Are you getting timeouts or error messages? If so, then
you've configured something incorrectly. Try again (after you've
finished reading this :-). Note that the connection won't seem
blazingly fast, especially if your using compression - it will be a
little jumpy. The real speed comes in during file transfer and the
like.

\subsection{Gotchas to Watch Out For}

 Are you running the right binary? Term has been updated quite a lot,
and many systems have different versions of the programs floating
around. Make sure you're using the right version. Note that this
applies to linecheck too. You can use bash's `type -a' or the
`whereis' command to find which program is being run. Term versions
after 1.11 should print out their version number when they start up.
(Although version 1.14 claims to be 1.12. Sigh.)

 Do you have the right {\tt termrc}? Is it called {\tt
\$HOME/.term/termrc}? Some systems have pre-installed termrc's, make
sure they're gone before you set things up. If your running things as
root, lookout for {\tt /.term}.  Term creates files (sockets actually)
while it's running, so it has its' own directory, {\tt \$HOME/.term},
where the file {\tt termrc} goes (note, there is {\em no\/} leading
dot in {\tt termrc}!).

Once you've got term running, you might want to try to get things
optimized. A good way to measure the speed of your link is to run {\tt
tmon} in one window while up/downloading a file in another. Try both
(big) text files and compressed files, the plain text should go a
factor of two-ish faster than the compressed files. The parameters you
want to fiddle with are compression ({\tt -c}), windows ({\tt -w}) and
timeout ({\tt -t}).

{\tt Compression } you want this on if you don't have a compressing
modem.  If you do have such a modem, turn compression off, otherwise
you'll be compressing things twice, which typically {\em increases\/}
the amount of data transmitted. Compressing modems are ones that use
the MNP-5 or V42Bis protocols. Check your modem documentation and the
message when your modem connects.

{\tt Windows} this is the number of chunks of data, or packets, that
term will let go over the line before it gets an acknowledgement (or
ack) from the remote term. For fast modems, increasing this can be a
win, for slower links this can overwhelm the remote end.

 {\tt Timeout} the time term will wait for an ack. If you've increased
windows, and you're getting timeouts in your logfile, try increasing
this.

For 14400/V42Bis, I use {\tt -c off -w 10 -t 150}. I typically get
around 1700 cps on compressed files and 3500 cps on ascii files using
tupload.

{\bf TODO} 

Escape chars. How term works. Term options. Term docs - read'em
dammit!  mail (in and out), news, pop, X (in and out), sxpc, patches.
How to use tredir, how it works. Tredir gotchas: inetd.conf, suid for
low port \#'s.  How to automate things - example scripts.  Apps that
use term (call for a list?). Writing a client.
\end{document}

_____________________________________________________________________________
Bill Reynolds  [email-masked] | 

------------------------------

End of TERM Digest
******************
-------