NAME
term - server for multiple communication channels on a serial link
SYNOPSIS
term [-s speed] [-n on|off] [-c on|off] [-S on|off] [-r] [-f arg] [-w arg] [-t arg] [-o] [-a] [-d lev] [-l file] [-v file] [-1] [-q] [-u tcp|unix|off] [-b port] <server>
DESCRIPTION
Term and its clients support multiple, compressed, and error-corrected communication channels over a regular serial link, typically a modem connection. The clients can set up channels to run an interactive shell on the other system similar to rlogin(1), to execute commands on the other system similar to rsh(1), to transfer files in either direction, to redirect X server connections from one system to the other, or to redirect any network port connection from one system to a port on the other. Any of these can occur simultaneously, and in either direction.
To support these multiple clients, a term daemon on each system takes control of the device connected to the modem. So you must compile term and the clients on both systems. Source is available by anonymous ftp temporarily from
physics.purdue.edu:/pub/bcr/term/
Normally source is available by anonymous ftp from
tartarus.uwa.edu.au:/pub/oreillym/term/
and
nic.funet.fi:/pub/OS/Linux/BETA/
but not at the time of this patch.
DEFINITION
Due to the fact that anything term and its clients can initiate from one end of the link they will just as happily initiate from the other, the following frame of reference will be used throughout this documentation. The remote system refers to the system at the other end of the modem link, and the local host refers to the machine you are typing on, typically the user's home system.
USAGE
Term is run as a daemon which accepts connections from its clients and establishes channels for each client's data. Term must be run on both ends. On the remote system, execute something like
term -r -n off
Then, on the local system, you can exit your comm program and type
term -v /dev/tty?? [-n off] &
where tty?? is the device name for your modem or serial port. You may be able to start the local term from within your comm program, e.g. for xcomm type
control-A x "$ term"
Once the term daemons are running at both ends they handle the transmission of data over the link. These clients connect to a local term daemon which establishes a communication channel with the remote daemon and/or remote processes. The clients are discussed in detail in term_clients(1). Briefly, trsh runs an interactive shell or commands on the remote system, tupload transfers files from the local system to the remote, tdownload transfers files from the remote to the local system, tredir redirects connections from a port on the local system to a port on the remote system, txconn redirects X server connections from the local system to the remote, and tmon monitors client statistics.
OPTIONS
Term accepts a number of command-line options which override settings established by the termrc file (see below):
- -S off|on
-
Turns off|on share mode. This option is on by default if the program is set user or group id.
- -b port
-
This causes term to listen to the specified port instead of listening to the modem. This is only usefull with a program that then connects the port to the IO device. I've been using it succesfully for making resumable internet term sessions.
- -c off|on
-
Turns off compression. Still does error correction. Consider this option if you have hardware compression (ie. v.32.bis) or are transferring compressed files. The default is to have compression on.
- -n on|off
-
Turns on line noise echoing. Talk requests, writes, and biffs to the login which is running term will then appear. This is a useful option to use on the local end (the end you are sitting at). Without this, you will never see any talk requests directed to your remote login. Default is off.
- -f off|<number>
-
Makes term send XON at specified interval. Zero is no flow control emulation, 10 is a single XON every 10 characters. The default is zero. 100 is a reasonable value.
- -s off|<number>
-
Specifies a maximum number of bits per second (baudrate) term will try to send over the serial link. Term will avoid sending characters at a higher data rate than this. This overrides the BAUDRATE environment variable. The default is to use the speed of your computer's serial port, but be warned that this may be too high if your modem runs at a lower rate over the phone line. The baudrate option is intended for systems that buffer output to the modem. During setup and tuning it is better to have <number> be too small rather than too large. For high speed links (> 38400), making it unlimited is probably advantageous. This is achieved by using the value of off. term will then rely solely on your kernel to do flow control.
- -w <number>
-
Sets the transmission window size; that is, the number of unacknowledged packets that term may send. Lower numbers may lead to better interactive response times. Higher numbers may lead to better throughput, particularly if the serial link latencies are large and the timeout length is set large. Higher numbers can also improve efficiency on noisy lines. The default is determined as a function of your baudrate.
- -t <number>
-
Timeout length in 20ths of a second. This specifies how long term will wait for an acknowledgement before retransmitting a packet. Default is 70 (i.e. 3.5 seconds), maximum 1000. Decreasing both window size and timeouts can lead to less latencies for interactive work, and faster noise recovery at the expense of total throughput speed.
- -r
-
Use this on the remote term so that client numbers won't clash.
- -a
-
Turns on seven bit line mode. Use only if you have a seven bit line, as determined by linecheck.
- -l <filename>
-
Output all log/noise/debugging to the file <filename>
- -v <filename>
-
Set the modem device to be <filename>. Appropriate usage is something like "-v/dev/ttys1"
- -1
-
Use stdout instead of stdin as the modem port. This is ignored if a -v is also present.
- -d off|<number>
-
This sets the debugging level. This is useful for monitoring packet timeout conditions and other things. Level 64 is suggested, 478 is verbose. Read debug.h and the other source files to find out what the levels do. If you are not familiar with packet protocols and pouring through source code, then this option is unlikely to help you.
- -o
-
Turns on packet send forcing. Re-transmits oldest packet if nothing to send. Default off. Of dubious utility. Not properly debugged. Very bad idea if speed is unlimited.
- -u tcp|unix|off
-
Specifies the socket type term should use. Consider off if you need extra security on the remote side and tcp if your home directory is NFS or AFS mounted. The default is unix.
- -q
-
Make term quieter. Multiple `-q' options make term more quiet.
- <server>
-
Use this to tell term to use a unique socket name. Then for term clients to work, you will need the following:
-
setenv TERMSERVER <server> (csh, tcsh)
-
or:
-
export TERMSERVER=<server> (sh, bash)
-
This option is normally used only if your machine has multiple modems so that users can specify which term server they wish to use.
ENVIRONMENT VARIABLES
- BAUDRATE
-
Used to set the speed. Overridden by termrc or command line setting.
- SHELL
-
Default shell for trsh.
- TERMDIR
-
Where to find the .term directory in private mode. This directory will contain the socket used by all term clients. The default is HOME.
- TERMSHARE
-
Where term runs from in shared mode. The default is /usr/local/lib/term.
- TERMMODE
-
What mode term will attempt to use. 0 == private, 1 == system shared, 2 == user shared.
- TERMSERVER
-
This should specify the <server> name, if you used one.
FILES
There are several files referenced by term and by its clients a user may create to improve efficiency.
- termrc
-
The termrc file is used for configuring term to run efficiently. You might not be able to get term to work at all without this file.
- hosts.term
-
While not required, the hosts.term file can be usefull for adding your own aliases for internet hosts you access frequently. The hosts.term file may be placed in any the of $TERMSHARE, /usr/local/lib/term, /usr/lib/term, /usr/etc, and /etc directories and uses the same syntax as /etc/hosts. When using private or user shared mode, then you can also use the $TERMDIR/.term, ~/.term, or ~/term directory.
- termnet
-
The termnet file is currently a dummy file, which existence in any of the directories allowed for the hosts.term file activates full term networking at the price of causing some term clients to no-longer work when connecting to localhost. Eventually configuration options will be added to this file.
DIAGNOSTICS
The -d option provides debugging output. See term_setup(1) or linecheck(1) for further diagnostic information.
SEE ALSO
- term_clients(1)
-
The man page for the term clients.
- term_setup(1)
-
The man page for term setup.
- termrc(1)
-
The man page for the term configuration file.
- linecheck(1)
-
The manual page for the linecheck program for debugging your serial link.
- termtest(1)
-
The manual page for the termtest program for exercising term and clients.
- term/INSTALL
-
Documents how to install term on your machine.
- term/README
-
The original documents for term from which these man pages were written.
- term/README.security
-
Describes in more detail how term's shared mode works.
- term/README.porting
-
How to compile and link network-using programs to take advantage of term's transparent network emulation.
- term/Term.HOWTO
-
A detailed description of how to make term work. It may be somewhat out of date with the current version of term.
- term/FAQ
-
Answers to some frequently asked questions.
- term/TERMRC
-
Another description of the syntax and options the user may set in ~/.term/termrc.
- term/CREDITS
-
Credits for many of the people who have contributed to term.
- term/CHANGES
-
A list of changes to the program since these manuals were edited (version 1.19).
BUGS
If a remote client stops consuming its input but leaves the channel open, the local term daemon will continue to resend unacked packets. Term by default requires a line which passes through all ascii values from 0 to 255. Xyplex-type terminal servers may require the use of set session passall to work correctly.
AUTHOR
Michael O'Reilly, [email protected], original author
Bill C. Riemers, [email protected], current developer