Hacker Chronicles 2/HACKER2.BIN/474.HOWTO.DOC

Text File | 1987-06-11 | 27KB | 513 lines

         Getting Started with the KA9Q TCP/IP Networking Code
                by
            Brian Lloyd, WB6RQN

           Editted 870525 by Bdale N3EUA to Reflect Changes


Phil Karn, KA9Q, Bdale Garbee, N3EUA, and Mike Chepponis, K3MC,
have constructed a very nice networking package for packet radio.  Their
documentation is clear, interesting, and informative.  Unfortunately it
is more of a reference than a tutorial and, as such, is not as useful to
the first-time user.  This document is an attempt to provide you with the
information you need to get up and running right now!  After it works you
can go back and read all the other informative material and understand
better what you did.

Configuring the TNC for network operation:

First step is to prepare your TNC-2 for use with TCP/IP.  The standard
firmware for the TNC-2 is not very computer friendly and, as such, is not
very useful when it comes time to make your computer speak with other
computers.  To that end Mike wrote the KISS (Keep It Simple Stupid) TNC
code.  There are two ROM versions for the TNC-2.  The first is contained in
a type 2764 or 27C64 EPROM.  This version contains the KISS code in it.
The second version is contained in a type 27256 or 27C256 EPROM and
contains both the standard TAPR 1.1.3 TNC code and a loader that will
permit you to download the KISS code into the TNC.  Check the EPROM you
have received and determine which type you have.  If you are burning your
own EPROMs you probably do not need these instructions.

Open up your TNC and locate the ROM.  It is in the socket labled "U23."
Using a small nail file or screwdriver gently pry up the existing EPROM.
Carefully press the new EPROM into place being sure that the orientation is
the same.  If you are installing the 2764 type of EPROM you will need to
make a small modification to the TNC.  There is a location on the board just
above the first RAM socket labled JMP-6.  Turn the board over and cut the
trace joining the two pads.  Solder a two-pin jumper header in place.  When
using a type 2764 the jumper at JMP-6 should be removed and installed when a
type 27256 EPROM is being used.  That should complete the hardware part of
the installation.

Attach your TNC to your PC using an RS-232C cable.  You can use the same
cable that you were using to connect your PC to your TNC.  If you are doing
this for the first time and are not sure about your cabling, a cable with
just pins 2, 3, and 7 passed through is sufficient.  Some PCs like to see
the signals Clear To Send (CTS, pin 5), Data Set Ready (DSR, pin 6), and
Data Carrier Detect (DCD, pin 8) asserted.  You can set this up by
jumpering pin 4 to 5, and pin 20 to pins 6 and 8 at the female DB-25
connector that goes to the PC.

Now to verify that the TNC still works.  Apply power to the TNC and turn it
on.  The STA, CON, and PWR LEDs should come on and the STA and CON lights
should go out again about 1 second later.  If you have the type 2764 EPROM
with the KISS code in it one or both of the STA and CON LEDs will begin to
flash.  If the CON LED flashes you have 8Kb of RAM in the TNC.  If the STA
LED flashes you have 16Kb of RAM.  If both LEDs flash you have 32 Kb of
RAM.  The flashing of the LEDs verifies the proper operation of the TNC.

If you got the combined loader and TAPR version EPROM, checkout is a
slightly different process.  You can test your TNC-2 using two methods.  The
first method is to connect your TNC to a terminal program and send the
character 'h' or 'H' to the TNC.  The result should be the standard TNC
startup message.  Exit from the 1.1.3 mode of operation by issuing the
reset command to the TNC.  The second method involves downloading the KISS
code to the TNC.  Use the mode command to set the baud rate of the comm
port to the proper value, e.g. it matches the DIP switch setting on the
back of the TNC, and copy the file kisstnc2.hex to the appropriate comm
port.  If the download was successful the STA and/or CON LEDs will begin
flashing as described in the previous paragraph.  If the download is not
successful check the cable from computer to TNC, check the baud rate on the
TNC, and check to insure that the computer is indeed sending data to the
TNC.

    [NOTE: running KISS causes the stored parameters in the TNC, i.e.
     MYCALL, NEWMODE, TXDELAY, etc., to be destroyed.  Every time you
     shift from KISS to TAPR modes you MUST reset the parameters.]

This completes the testing and setup of the TNC.

Installing and Configuring the Net Software:

There are two programs that make up the network software.  They are located
on distribution disk 1 in a directory called /EXE.  The two programs are
NET.EXE (the networking code) and BM.EXE (the mail program).  Copy these
programs to the place on your hard disk where you keep command programs.

If you are running on a floppy based system I recommend that you create a
bootable floppy and copy these programs to the floppy.  Test to make sure
that everything is there by executing the programs.  Type the command "net"
and, if the installation of the network code was successful, the message
"KA9Q internet protocol package" and the prompt "net>" will appear on the
screen.  This means that the network code is running and awaiting commands.
Exit from the net code with the command "exit."  Now run the command "bm."
The screen should display the message "Bdale's Messy-DOS Mailer" and a
prompt.  You can type 'q' to quit.  If all this has occurred, all is well
so far.

First step is to configure the mailer (BM).  To make BM work properly you
must create the following directories on your disk:

    \spool
    \spool\mail
    \spool\mqueue

Copy the file SEQUENCE.SEQ to the \spool\mqueue directory. Copy the files
HOSTS.NET and BM.RC to the root directory of the default drive used when
net is running.  If you are on a floppy based system you need to put BM.RC
with NET.EXE, BM.EXE, AUTOEXEC.NET, and AUTOEXEC.BAT in the root (\)
directory (more on AUTOEXEC.NET later).

You will need to edit the file HOSTS.NET to know about all the systems with
which you will exchange mail.  This is how the mailer will translate the
name into the IP address.  Here is an example of some of the entries I have
in my machine for other local TCP/IP stations:

    44.96.0.2    WB2SEF
    44.96.0.16    N8FJB
    44.96.0.17    KA3LYQ

All this does is translate the address Mike@WB2SEF into the network address
44.96.0.2 so that IP can route it to the proper network node.  This saves
you from having to remember lots of numbers.  With the release dated 870526,
the telnet and ftp commands also will use thes symbolic host names.

Next edit the file BM.RC.  This file lets the mail system know about local
host name, user name, and the name of "punt to" system.  Here are some
example entries:

    host WB6RQN
    user brian

The third entry, called gate, is where you specify the name of the system
to which you "punt" mail.  Should you try to send mail to a host that is
not in your HOSTS.NET file the mailer will route the mail to the system
specified in the gate entry.  This presumes that the gate system is smart
enough to figure out to whom the mail is addressed so that the mail can be
forwarded.  At this time the mailer is not "smart" enough to act as a mail
forwarding node.  This field is only here should you be lucky enough to
have another computer with a smart SMTP mailer.  Any UNIX 4.2 or 4.3 BSD
system has such a mailer.

You should also set some of the other fields in the BM.RC file, including
the smtp path (make it \spool\mail), the timezone, and the name of an
editor to use when you are creating messages.  You can comment out the
editor definition if you want, in which case the mailer will use a simple
text entry routine instead of letting you use your favorite editor to create
the text of each outgoing message.

Later on you can read the documents BM.DOC and SMTP.DOC to get more
information.  You at least have enough info to get your mailer running now.

Now you need to configure and run net.  Configuring net to run may be
performed manually every time you start up NET.EXE but that gets old pretty
fast.  There are usually many commands that must be typed precisely the
same way every time net is started.  Fortunately Phil thought of this and
provided the AUTOEXEC.NET file.  The intention here is to place all the
commands that you always execute in a file to be read and executed by
NET.EXE whenever you start up.  To this end you will want to edit the file
AUTOEXEC.NET prior to running NET.EXE.  Just use a text editor to enter the
commands into the file AUTOEXEC.NET as you would type them at the "net>"
prompt.

When NET.EXE first starts up you need to tell it about many things, i.e what
comm ports you have, what your IP address is, what your host name is, what
other systems you will communicate with, what services you wish to provide,
etc.  Let us start by describing the communications media (comm ports) that
you have.

The attach command tells net about your comm ports and in what mode the
ports will operate.  Currently three types of comm hardware are supported:
standard PC async comm adaptors, the HAPN TNC board for the PC, and the
3Com Ethernet controller.  Each of these devices has its own version of the
attach command.  Here is the attach command for an async adaptor card.  You
would use this to attach your pc to a TNC-2 running the KISS code.

    attach asy 0x3f8 4 ax25 ax0 1024 256 4800

This means attach an asynchronous adapter whose port address is 3F8 hex
using interrupt line 4 (both standard for com1:), as an ax25 device (KISS
TNC), using a buffer size of 1024 and a maximum transmission unit (the
largest packet you are allowed to send) of 256 bytes, running at 4800
bauds.  The name of this device will be ax0 (until you exit from net).
This is probably a pretty good place to start.  If you want to also do
this on com2, making you a dual-port or dual frequency switch, you would
probably add the line:

    attach asy 0x2f8 3 ax25 ax1 1024 256 4800

If you are instead going to use com2: to connect with another PC using a
hardwired connection (some of us do have multiple PC's) you might want to
use com2: to connect to the other PC.  We would want to use SLIP to do this
so the attach command would be:

    attach asy 0x2f8 3 slip sl0 1024 576 4800

If you have an HAPN TNC card for your PC you will want to enter the
following attach command:

    attach hapn 0x3f8 4 ax25 h0 1024 256 csma

This tells net to use an HAPN board with the port address 3F8h and interrupt
request line 4.  The speed of the board is determined by the board so the
software has no control over that function.  The last parameter, listed as
'csma' in the example, may also take on the value 'full' for full duplex
operation.

If you happen to have more than one PC you may wish to connect them using
an Ethernet.  The net software supports the 3Com 3C500 board for the PC.
The command to attach this board is:

    attach 3c500 0x300 3 arpa ec0 5 1500

This tells net that there is a 3Com 3C500 board at I/O address 300h using
interrupt request line 3 is given the name ec0.  Net should reserve five
buffers and the largest Ethernet packet may be 1500 bytes long.

A word about the selection of the value for the maximum transmission unit.
For standard TNC's and radios 256 is probably the largest value you should
use.  This insures compatibility with the rest of the AX.25 community and
insures that you are legal if you are operating unattended (part 97 of the
FCC regulations specifically mentions the AX.25 protocol in permitting
unattended digital operation above 50 MHz).  The smallest value you may use
is 64.  Performance improves with larger values IF you can get them to the
other end without errors.  I suggest you stick with 256 until you can run
some experiments of your own.  If you have a good transmission path and
all the stations and gateways are attended, feel free to use larger values.
It will result in improved performance (see the discussion of the mss and
window parameters).

If you are using a TNC running the KISS code (you probably are if you are
operating amateur packet radio) you will need to set the parameters in the
TNC.  This is accomplished with the kiss command.

There are five settable parameters in the kiss code.  They are:

1.  Transmitter keyup delay (TXD).  This is how long the TNC will wait
    after keying the transmitter prior to beginning to send data.  The
    proper value for this parameter is dependent on your configuration.
    This value is in 10's of milliseconds.  Acceptable values range from
    0 (0 ms) to FFh (2,550 ms or 2.55 seconds).

2.  Persistence (p).  This is the probability that the TNC will key your
    transmitter if a slot is found empty (the channel is free).  Acceptable
    values range from 0 (p = 1/255 = 0.4%) to FFh (p = 255/255 = 100%).
    The default value is 40h (25%).  The optimum value is somewhere close
    to 1/n where n is the number of users on the channel.

3.  Slot time (ts).  This is how long that the TNC will wait between samples
    of the channel.  Acceptable values range from 0 (0 ms) to FFh (2,550 ms
    or 2.55 seconds).

4.  Tail timer (tt).  This is how long the TNC will keep the transmitter
    keyed after the last character has been transferred to the HDLC
    controller.  This value must be long enough to permit the last two
    characters, the CRC (two bytes), and the trailing flag to be
    transmitted.  The default value of 3 (30 ms) is sufficient for speeds
    of 1200 bauds and above.  If you are running at 300 bauds you will
    want to put in a correspondingly larger value.

5.  Full Duplex.  A zero value (the defalult value) means operate the TNC
    in half-duplex CSMA mode (listen before you transmit).  A non-zero
    values means transmit whenever there is data to send.

Let us assume that on the channel associated with ax0 that I have a radio
that requires a transmit keyup delay of 200 ms, I want persistence to be
50% (p=0.5), and I want the slot time to be 300 ms.  I would enter the
following commands:

    kiss ax0 1 14
    kiss ax0 2 80
    kiss ax0 3 1e

Note that the parameters are always specified as hexidecimal values.  Do
not make the mistake of typing 100 thinking that you are entering the
value one hundred.  The command processor only looks at the last two digits
so the result of the mistake would be to enter a value of 00.

Now that we have described the media we probably want to tell net who it
is.  Net will need to know its host name, AX.25 link address, and IP
address.  Here are the commands from my system.  You will substitute your
own name and addresses.

    hostname WB6RQN-PC.dc.ampr.us
    mycall wb6rqn-1
    ipaddr 44.96.00.01

The 'mycall' field contains the AX.25 link address just like you normally
use (if you are using this over telephone or Ethernet links, ignore the
discussions about AX.25 -- it is used solely for radio operation).  The
'mycall' line MUST come before any attach commands in the autoexec.net file.
The 'ipaddr' field is your network address.  Because network addresses
must be unique I suggest you contact the person in your area responsible
for keeping track of network addresses.  If there is no one providing that
service I suggest you contact me and I will see to it you are assigned an
address or block of addresses that are compatible with the rest of the
network.  If you do not need to communicate with anyone outside the
confines of your systems, just pick a likely looking value.

If you are currently an active digipeater in your area you can also make
your system continue to be a digipeater for those poor souls unlucky
enough to still be running ordinary AX.25.  The command for this is:

    digipeat on

Now you need to construct the routing table.  This table is used by the IP
to determine how to forward your packets.  Each entry consists of two or
three parts, the IP address of the destination, the link upon which it is
to be forwarded, and the IP address of the next station in line if there
can be more than one IP address on the link (used if the mode is ax25
and not used if the mode is slip).  Here are three sample entries, one for
a station more than one hop away via ax25 to be forwarded by 44.96.0.7,
one for station one hop away on ax25, and one for a station on the other
side of a slip link:

    route add 44.96.0.5 ax0 44.96.0.7
    route add 44.96.0.2 ax0
    route add 44.96.0.12 sl0

The first number following the command 'route add' is the destination IP
address.  The second field, e.g. ax0 or sl0, is the media and must match up
with one of your previous attach commands.  The last field is the next
station in the path if the destination is more than one hop away.  This is
an optional field and only needs to be used if the media is a broadcast
media such as Ethernet or AX.25 and the destination is more than one hop away.

There are two other special types of route entries; the default entry and a
cluster entry.  Here is a default entry:

    route add default ax0 44.96.0.99

This means that if the address does not match any entry in your table,
route the packet to 44.96.0.99 via ax0.  Hopefully the switch at 44.96.0.99
will be able to forward the packet to its destination.  This generally
works well if you are merely an end node (a leaf) in the network and all
your traffic goes to a single gateway.

The other option for routing is cluster routing.  It allows you to send
blocks of addresses in a certain direction.  This is useful if all the
users in a given area have some common part to their IP addresses.  Here is
an explanation of cluster routing and addresses in general.

The IP address is thirty-two (32) bits long.  It is generally represented
as four 8-bit numbers, with each number being written in decimal form.  For
example, my IP address is 44.96.0.1.  This number can be represented as the
hexadecimal value 2C600001 or 00101100011000000000000000000001 in binary.
We can break this out as follows:

decimal           44        96         0         1
hexadecimal       2C        60        00        01
binary         00101100  01100000  00000000  00000001

Normally when you make an entry in the routing table, all bits of the
address are significant, e.g. an exact match is needed for the address to
be recognized.  On the other end there is the default route in which any
address matches.

Cluster routing falls somewhere between these two extremes.  Cluster
routing allows you to specify how much of the address is to be considered
valid.  In order to determine how many bits in the address are valid you
enter the address in a special format:

      route add 44.96.0.64/26 ax0

This means that only the first 26 bits of the address are to be considered
significant.  This is a form of wild card for the address.  Here is that
address in binary to show the mapping:

               00101100  01100000  00000000  01??????

The question marks in the above address show the least significant six bits
being "wild," or matching any corresponding bits in the address.  Here are
some examples:

44.96.0.67     00101100  01100000  00000000  01000111  (a match)
44.96.0.89     00101100  01100000  00000000  01011001  (a match)
44.96.0.01     00101100  01100000  00000000  00000001  (no match)

This works because the routing process in the net code will, when
presented with an address, search for an exactly matching entry.  Failing
to find that it will then look for an address that matches on the most
significant 31 bits, then 30 bits, and so on.  If presented with the
address 44.96.0.67 IP would, after 6 tries, match the address to the
example given above.

By judiciously assigning addresses we can make the address aid us in
routing the packets.  The users within a LAN should have something in
common in the high order part of the address so that we can use a single
entry in the routing table to make things go in the proper direction.  Here
in the Washington DC area all addresses begin with 44.96.0.  This identifies
this general area and may be used to provide routing to us.  Once the
packet arrives in our general area cluster routing is then used to further
route the packets to the appropriate area.  In DC and the parts of Maryland
immediately surrounding DC the low order byte ranges from 0 to 63.
Northern Virginia users get numbers in the range of 64 to 127.  The
Baltimore users get 128 to 191 while the Harrisburg, PA, users get 192 to
255.  The idea being that we can use the top two bits in the low order byte
of the address to identify LANs within the address.  That way the bits in the
high order part of the address will get you into the general area, the next
part of the address will get you to the proper LAN, and the least
significant bits will get you to the proper host or user.

Because of errors when people set up their routing tables the use of
default and cluster routing can cause routing loops to occur.  Imagine what
would happen if two stations had their default routing pointing at each
other like this:

host 1 (44.96.0.1): route add default ax0 44.96.0.2
host 2 (44.96.0.2); route add default ax0 44.96.0.1

In this case a packet that got routed using the default route would bounce
back and forth between the two stations forever.  There is a command that
can prevent this from going on forever: the Time-To-Live (ttl) command.
Every IP packet has a ttl field in it that is decremented by 1 at every hop
and decremented by 1 for every second it is in the network.  Normally net
sets the ttl field to 255.  If you know that no host is more than 5 hops
away you might issue the following command:

    ttl 5

This means that all packets from your host/station are sent with ttl set to
an initial value of 5.  These packets will now be discarded if they haven't
reached their destination after 5 hops.  This limits the traffic in the
network should somebody inadvertantly create a routing loop.

The next information we want to include is some information used by TCP to
determine how much data it can send at one time and how much data may be
outstanding before it stops to wait for an ack from the other end.  Here
are the example values:

    mss 216
    window 1080

The parameter mss stands for maximum segment size and represents the
largest single transmission that TCP will send.  The 'window' parameter is
how many bytes may be outstanding at any one time before you wait for an
ack.  If you have a pretty good link you can increase the value of window.
If window is larger than mss TCP will run as a sliding window protocol.
Since TCP uses selective reject (resend ONLY those segments that were
damaged or lost) this is not a very expensive proposition.

The net program now compares the mss and mtu values given in the attach
command for the media being used.  Since TCP and IP each have a 20 byte
header (a total of 40 bytes), an mss of 216 corresponds to an mtu of 256.
If you are using mixed mtu's, set the mss to correspond to the largest mtu
you are using and let net adjust the mss downward for the media that are
using smaller values for mtu.  In any case window should always be a
multiple of mss to prevent the transmission of "shortie" packets every once
in a while.

If you are running on a radio channel at 1200 bauds remember that a
1024 byte transmission will take seven seconds, a time that can make you
unpopular if you have to share the frequency with AX.25 TNC's that can not
adapt to the high channel utilization.  In those cases it is probably
better to reduce window and/or mss values.  Remember that efficiency
suffers very quickly as you reduce the value of mss though.

The mss and window values are somewhat interesting.  They are the ones
that your TCP will ask the OTHER station to use.  When the session is
initially set up the two TCPs will exchange mss and window values.  This
permits stations to automatically adjust to the capabilities of the other
station.  For this reason try to get your friends to all use the same
values.

The last items are what services you will provide.  You must start the
services or others won't be able to make use of your system for mail or
file transfers.  You will simply be a switch for other users (in fact,
for a switch on a hill that may be just what you want).  You will still be
able to initiate file transfers or telnet sessions but no one will be able
to initiate one with you.  Should you forget to start the servers anyone
trying to access those services on your maching will just receive a "Closed,
(reset)" message for their trouble.  For the sake of consistancy you
will probably want to start the following services:

    start telnet
    start ftp
    start smtp
    start echo
    start discard

Telnet is the keyboard-to-keyboard "talk" mode, ftp is the file transfer
protocol, smtp is the mail system (simple mail transfer protocol), and echo
is the echo server (it just sends back any packets it receives -- good for
finding out if a switch is out there and running).  The discard server
simply throws away anything it receives (write only memory, no?).  It is
used primarily for testing TCP and IP and you do not want a whole lot of
information cluttering up the receive queues.

Running the network:

The first step toward getting on the air is to load the KISS code into your
TNC if you are using the EPROM with the bootloader (this step is not
required if you have the 2764 EPROM with the KISS code already in it).  You
do this by having the PC copy the file kisstnc2.hex to the port to which
the TNC is connected.  I do this by setting the parameters for the comm
port with the mode command then using the copy command to send the hex code
to the TNC.  I do this inside my autoexec.bat file like this;

    mode com1:4800
    copy kisstnc2.hex com1:

Now start the networking program running by issuing the command "net."  You
should be rewarded by having the "net>" prompt appear on your screen.

At this point you are up and running.  I suggest that you start by doing a
telnet with someone else who is up and running.  If your friend's IP
address is 44.96.0.5 then just do the following:

    telnet 44.96.0.5

If it tells you "established" you are on the air and running TCP/IP!  There
are many things you can do and adjust so I suggest that you read the rest
of the documentation.  Have fun and happy networking!