359 lines
16 KiB
Plaintext
359 lines
16 KiB
Plaintext
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.
|
|
|
|
There's very minimal support for X11. If you are running under
|
|
X on your Linux system, you can use the command "start x".
|
|
This will cause KA9Q to front-end the Linux X11 software, so
|
|
that you can run X-based software on other hosts. As usual,
|
|
you set a DISPLAY environment variable of the form
|
|
|
|
myhost:0.0
|
|
|
|
where myhost is the host name or IP address of your Linux system (i.e.
|
|
the address that KA9Q is using). This function is currently very
|
|
primitive. There is no access control -- once you've started X,
|
|
anyone can connect to your display from anywhere on the network. KA9Q
|
|
will put out a message whenever someone connects, so at least you'll
|
|
know. If people find this feature useful, I'll put in access control.
|
|
With the current implementation, there are still two things you could
|
|
do: (1) use xauth, (2) turn on the X server only when you actually
|
|
want to start up X software. You can do "stop x". This will not
|
|
close down existing X connections. It will just prevent new ones,
|
|
until the next "start x". Unfortunately, X involves a lot of network
|
|
traffic. Over a 9600 bps line -- which is the primary audience for
|
|
this implementation -- it's probably too slow to be useful.
|
|
|
|
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.
|