GEMini Atari/GEMini_Atari_CD-ROM_Walnut_Creek_December_1993.iso/files/telecomm/nhclb120/readme.2

Text File | 1993-09-26 | 15KB | 337 lines

KA9Q TCP is an implementation of TCP/IP for the PC.  This is a Unix
port based on a version from mid-1989.  Unfortunately the more recent
versions of KA9Q are harder to port to Linux.

I don't have a manual for this exact version.  There's builtin help.
The commands primarily set parameters (the ip and tcp commands), or
start services.  In general the same command is used to set and
examine parameters.  When you type the command with no value, it shows
the current value.

To use KA9Q, put startup.net and possibly domain.txt in your home
directory, and run "net".  You will probably need to tailor
startup.net for your configuration.  See the section at the end of
this document on configuration.  Note that you can give an argument to
the "net" command.  It will be used as the startup file in place of
startup.net.  By default, startup.net and other files are in your home
directory (the value of the environment variable HOME).  You can put
them somewhere else by using the environment variable NETHOME.

If you are using SLIP, note that you must first dial the modem and
establish a SLIP connection.  The exact details on doing this are
different at each site.  Unfortunately you're probably going to need
help from system or network support staff in order to use SLIP.
Because SLIP effectively connects you to someone's local network,
using it normally requires logging in with a password.  I recommend
using kermit's script facility to dial and set up SLIP.  It did not
seem work adding a similar facility to KA9Q.

If your site does not current support SLIP, they will probably have to
do a bit of systems work.  For Unix systems, typically this will
involve adding a SLIP device driver, and then enabling routing.  (An
appropriate driver is available for the Sun, although I don't know
where.  I believe it can be installed without Sun source.)  Many
terminal servers will support SLIP directly, so enabling it will
merely involve changing a configuration file.

Aside from configuration commands (which typically go into
startup.net), the most common commands are probably telnet and ftp.
Both take a host name.  Once you are connected, the "escape character"
(initially ^]) lets you do some special things.  You type it followed
by another character. Except for the escape character, the characters
are folded, so that c, C, and ^C are equivalent.  Here's a list of the
special characters:

  escape character (i.e. two in a row) - send a real escape character
  x or ^x - return to command mode
  b or ^b - send break
  c or ^c - send interrupt process
  o or ^c - abort output
  t or ^t - are you there?
  h or ^h - send telnet erase character
  u or ^u - send telnet erase line
  ?       - print this help message

Once you return to command mode, the "session" command can be used to
switch between connections.  With no arguments, it shows the current
sessions.  With a number, it will reconnect you to that session.
There's a disconnect command to kill a session (also some stronger
ways of doing it).

Telnet normally operates in full duplex, with the other system
echoing.  However if that system refuses echoing, or if you use the
command "echo refuse", KA9Q will echo locally.  In this case you have
the normal line editing functions.  Several control characters have
special functions.  Note that in local echo mode, you do not need to
hit the escape character first.

  escape character - return to command mode
  ^v - quote the next character
  ^b - send break
  ^c - send interrupt process
  ^o - abort output
  ^t - are you there?

Telnet will pass your TERM environment variable as the terminal type
if the other end asks for it.  It will implement flow control locally
if the other end understand the remote flow control option.  If the
other end does a "telnet sync" correctly, it will suppress output when
appropriate.  E.g. when talking to a Unix system, if you type ^C or ^O
in the middle of a large output, output should stop immediately.
However there may be a pause before getting the next prompt, as some
previously buffered data is probably still going to be transmitted.

The "ip stat" and "tcp stat" commands are useful to get statistics.
"Ip stat" shows both the IP and SLIP level.  If header compression is
being used, it will show how many packets were compressed and how many
were oot.

FTP is sort of odd.  It looks like you are in an interactive
conversation with the FTP server at the other end, with no local
command prompt.  Most commands are passed directly to the remote
server, but in fact there is a local command parser, which will
intervene for a few commands:

   cd, dir, list, get, ls, mkdir, nlst, rmdir, put, type

get and put should be used to transfer files.

It's possible to run a server which others can connect to, though I
haven't tried it except for ftp.  The command is "start ftp", etc.
For ftp, a login is required.  The file ftpusers, in your home
directory, contains a list of users and passwords.

Here's a list of commands:

   ! - call a recursive shell
   arp - set arp parameters
   ax25 - configure ham interface
   attach - define an interface - must be used for each interface
   bootp - request our IP address from a server
   connect - for AX25, define call sign for interface
   cd
   close
   disconnect
   dir - do a directory on the local system
   domain - configure domain name system
   eaglestat
   echo - refuse or accept - request to disable telnet remote echo
   eol - Unix or standard end of line options [standard is recommended,
    even for use on Unix systems]
   escape - change escape character
   etherstat
   exit
   finger
   forward - divert packets from one interface to another
   ftp - open an ftp connection
   hapnstat
   help - print command list
   hostname - set/examine host name
   kick
   log
   ip - set/examine IP level parameters
   memstat
   mbox, mode - AX25 commands
   mulport
   netrom
   nrstat
   param - set/examine interafce parameters
   ping - send ping to a host
   pwd
   rdate [offset] [host] - set date/time from UDP time daemon.  see below
   record
   remote
   reset - kill connection
   route - set up routes
   session - see above: move to a different session
   shell - call a subshell
   smtp - mail handling
   start - start server
   stop - stop server
   tcp - set/examine tcp parameters
   telnet - open telnet connection
   trace - enable low-level debugging (no arguments - show current status)
    trace to <file> - put trace output on file (use "con" for console)
    trace <device> [<bits>] - trace packets on device
        device is typically "sl0" or "loopback"
        bits are in hex:
            1 - output, 10 - input (else no tracing)
            100 - dump data in ascii, 200 - hex (else headers only)
    trace cmdmode|allmode - show trace just when at command level?
    trace telnet [on | off] - show telnet options and urgent data
   udp - set/examine udp parameters
   upload
   wait - control mail select

The rdate command uses the old-style time protocol (often known as
"rdate"), on UDP port 37, to get the date and time, and then sets the
system clock.  Note that the protocol always gives time in GMT.  If
your system clock is running on GMT (which is the normal way Unix
should run), this is fine.  Otherwise, you'll need to specify the
offset in minutes.  For time zones west of GMT, this should be a
negative number. For the Eastern U.S., when not in daylight time, the
offset is -300, because EST is 5 hours (300 minutes) west of GMT.
If no host is specified, a UDP broadcast is used.

This configuration of KA9Q has been tested only with SLIP.  Code is
also included for the KISS device (for ham radio) and Linux generic
Ethernet support using /dev/eth.  /dev/eth should either work or come
close to working: it's based on diffs made from a recent version of
KA9Q.  I don't know of anyone who has tested KISS.  Past experience
suggests that users will prefer Kermit to SLIP unless you use SLIP
with header compression.

Note that this program depends up non-blocking I/O and the select
system call.  In Linux 0.12, these did not work.  There are patches,
nonblock.tar.Z and select.patch, on the major distribution machines.
Don't forget: after patching a kernel source file, you must do a make
in each directory where you changed a file.  The main make file
doesn't rebuild things all the time when it should.  Linux 0.95
and later has all the necessary patches.


CONFIGURATION:

Here's some advice on preparing a configuration file.  I assume you're
planning to use SLIP (dialup IP) or Ethernet.  I'm going to explain my
configuration file line by line, as it's likely to be close to what
you need:

   attach asy 0 /dev/tty64 cslip sl0 2048 1500 9600

You must include an attach command in every configuration file.  It
defines the device.  For SLIP, the line above should be about right.
Some variationos:
   - /dev/tty64 is the serial line.  Obviously you can adjust this
    to use a different line.
   - cslip specifies SLIP with Van Jacobsen header compression.
    If you're using normal slip, use "slip" instead of "cslip".
    In my opinion, response on normal SLIP is too slow for it
    to be very useful.
   - 9600 is the line speed.  Use whatever speed you are set for.
    If you have a "smart" modem, we recommend turning off
    any error correction or compression.  These features
    introduce enough delay to be objectionable.

The following attach command could be used for Linux generic
Ethernet (/dev/eth)
  attach linux arpa eth0 1500 1.2.3.fa.fb.fc
The last item is your Ethernet hardware address, in hex.  It should
be printed when your system boots.  E.g. if it prints 01 02 03 04 05 06
then you put in 1.2.3.4.5.6.  Each of the six numbers is in hex, and
may be one or two digits.

  wait 0

This should only be needed with older version of the kernel.  It
disables the select system call.  Instead, runs in a tight loop
continuously testing for input.  Unfortunately select has a history of
problems under Linux.  It appears to be fine in version 0.96.  However
in earlier version, select did not work properly when there was
another program running.  (In some cases it works OK unless the other
program uses select.  E.g.  if you enter emacs in another window, your
FTP comes to a halt.)  If you are trying to use KA9Q while another
program is running, and you find that the connection hangs, you might
try "wait 0".  Otherwise, you should leave the default setting, which
is "wait 100".  The argument to wait is in milliseconds.  It's the
amount of time to wait in the main loop.  The select will trigger if
input arrives on the serial line, or you hit a key.  Otherwise it
waits this amount of time.  I don't recommend values larger than 100.
Smaller values might possibly be useful in some siuations.

  route add default sl0

This says that all packets should be sent out the SLIP line.  Presumably
this is what you want.  If you are using Ethernet, of course you'd
use the name of your Ethernet device instead of sl0, e.g.
  route add default eth0

  bootp

This says that the system will find out its IP address by sending a
BOOTP request out the serial line.  Since dialups are normally
in "hunt groups", you will probably get a different line each time
you dial up.  Thus your IP address will probably not be the same.
BOOTP is a way of asking the terminal server (or whatever else
you're connected to) to tell you your IP address.  If your terminal
server does not support BOOTP, you explicitly set your IP address
using a command of the form
   ip address [1.2.3.4]
where 1.2.3.4 is your IP address.  You would use this command
instead of the BOOTP command.

  tcp mss 64
  tcp window 256

These commands set TCP performance parameters.  These control a
tradeoff between overall throughput, jerkiness of output, etc.  These
parameters seem to give good performance for interactive connectionos.
For FTP you might want larger values, particularly if you are going
over a long-haul network like the Internet.  For FTP the best value
for mss is at least 512, and probably more like 1024, with window
between 2 and 4 times mss.  However Linux has fairly small buffers for
the serial line, so you may not be able to get away with parameters
much larger than the ones shown here.  If you are using Ethernet,
of course you'll want larger values.  I suggest starting with
  tcp mss 1460
  tcp window 5840
This should work for traffic on the local Ethernet.  If your
traffic tends to go through routers, a safer set of values is
  tcp mss 512
  tcp window 2048

  domain suffix rutgers.edu
  domain add [128.6.4.4]

These parameters control the domain system.  That's the set of servers
you use to look up host names.  You'll need to adjust these for your
campus.  The suffix is tacked onto all host names you type, unless
they already have a dot in them.  This lets you type "athos" instead
of "athos.rutgers.edu".  Set it for the domain you most commonly use.
The address 128.6.4.4 should be the address of a domain server on your
campus.  All name lookups will be directed to that server.  You can
define more than one, by using several "domain add" lines.

If your campus does not support the domain system, you can use a host
table instead.  In that case you would omit the "domain" commands.
The host table is called "domain.txt", in your home directory.  It's
in the format of a domain master file.  The most important entries
look like
   athos.rutgers.edu. IN A 128.6.4.4
Note that IN and A must be in upper case, and the name must include
the whole suffix, and end in a dot.

Note that this is a very old domain implementation, and is not up to
the level of the current MS/DOS version.  It does not use TTL's.
Every time you type a name, it first looks in domain.txt.  If there's
an entry there, it will be used.  Otherwise, it will query the domain
server you specified.  If it gets an answer, that information will be
added to domain.txt.  If a host changes its address, you'll be in
trouble, because you'll continue getting the old information from
domain.txt.  Thus it's probably a good idea to remove domain.txt now
and then.

  start finger
  start telnet

These start daemons to respond to incoming finger and telnet
connections.  This is optional, but most people will probably find
them useful to help people find you.  The finger server uses files
stored in a subdirectory "finger" of your home directory.  Files
should have names of the form xxx.txt, where xxx is a user name.
Finger with no arguments will list all users on the system (i.e.  it
will look for all files ~/finger/*.txt, and list the names).  Finger
with a specific user name will display the text of that file, i.e.
~/finger/xxx.txt.

The telnet server is really more like a talk link.  When someone
telnets to your machine, you'll get a message saying that there is an
incoming telnet connection.  At that point you should escape to the
coommand level (using ^] or whatever your escape character is), do
"session" to see the session number of the incoming connection and do
"session NN" to connect to it.  At that point you'll be in an
interactive link with the person.  There is also a server designed to
allow "real" telnet connections, i.e. connections that create a real
login session.  It is activated with the command "start telunix".
However that code is incomplete, and currently does nothing useful.