net/rom manual

[dan%cs.wisc.edu@Sdsc.BITnet]

   I've been asked for some use documentation for the net/rom code.
Here it is, suitable (I hope!) for inclusion in the next manual:

---------- slice me ----------- dice me ----------------------------
   We'll work from the bottom up in describing the facilities added
for the net/rom version of net.  It appeared that for some applications,
it might be worthwhile to be able to have a callsign per interface.
So far, that has only been done for the hapn and kiss attach code,
but the extension is obvious to the eagle and pc100 drivers.  Basically,
if you give an extra argument at the end of the attach line, that argument
will be taken as the callsign for that interface, overriding ax25 mycall.
mycall is still functional, and if you want to use just one callsign for
all your interfaces, just ignore the new feature.
     
   No physical interface is completely dedicated to net/rom, which is as
it should be.  You attach all your AX.25 interfaces, of whatever sort.
Then you attach the net/rom pseudo-interface ("attach netrom").  Then
you identify to the net/rom software those interfaces you want to allow
it to use, with the "netrom interface" command.  The format of this
command is:
     
        netrom interface ax0 192 #ipnode
     
The first argument is the name of the previously attached interface you
want to use.  The second number is the net/rom quality figure.  This is
used in computing the route qualities; it represents the contribution
of this interface to the overall computation.  For a 1200 baud half-duplex
connection, 192 is the right number.  The last argument is the alias of
your node, to be used in your routing broadcasts.  The alias is never
used for anything else (as you will see!).
     
   You need a netrom interface command for every interface you're going
to use with net/rom.
     
   Once you have set up your interfaces, you need to set some timers.
There are two:  the nodes broadcast interval timer, and the obsolescence
timer.  These are set in seconds, like the smtp timer.  They are usually
set to an hour.  You can set them to something different, if you want.
If your local net/rom nodes broadcast every hour, but you want to do so
every ten minutes, you can say:
     
        netrom nodetimer 600
        netrom obsotimer 3600
     
Every time the obsotimer kicks, the obsolescence counts for all non-permanent
entries are decremented by one.  When the count for an entry falls below
five, it is no longer broadcast.  When it falls to 0, it is removed.  The
count is initialized at 6.  These will eventually be settable parameters;
you can adjust them now by changing the initializers for the variables
in the source file.
     
   When you first come on the air, you can send out nodes broadcasts to
tell the local nodes that you are available.  Use the command:
     
        netrom bcnodes ax0
     
where ax0 is the interface on which you want to send the broadcast.  Do
this for every interface on which you want to do this.
     
   Sometimes you can hear broadcasts from nodes that can't hear you.  If
your routing table gets filled with these unusable routes, your node will
grind to a halt.  The solution to this is node broadcast filtering, via
the netrom nodefilter command.  There is a filter list, which contains
a list of callsigns and interfaces.  Then there is a filter mode, which
indicates what to do with the list.
     
   If the filter mode is "none", no filtering is done.  If it is "accept",
then only broadcasts from the indicated stations on the indicated
interfaces are accepted.  If it is "reject", then all broadcasts
except those from the listed stations on the listed interfaces are
accepted.
     
   Because the net/rom code cannot at this time recognize unusable
routes and try alternates, I strongly recommend use of the filter
command to restrict broadcast acceptance to those nodes which you
know you can reach.
     
   The last category of net/rom commands are those used for maintaining
the routing table.  They fall under the "netrom route" subcommand.
"netrom add" adds a permanent entry to the routing table.  Its format
is:
     
        netrom route add #foo w9foo ax0 192 w9rly
     
This command adds an entry for w9foo, whose alias is #foo, route
quality 192, via w9rly on interface ax0.  Let's talk about what this
means.  w9foo is the *destination* node, the one to whom you want
the packets routed by the net/rom network.  w9rly is your *neighbor*,
the net/rom node to which you pass the packet to be forwarded.  Since
w9rly may appear on more than one interface (the callsign may be used
by more than one net/rom node on different bands), we specify that
we are to use ax0 to send the packet.
     
   With net/rom, like IP, we don't know exactly what route a packet
will take to its destination.  We only know the name of a neighbor
which has indicated a willingness to forward that packet (of course,
the neighbor may be the destination itself, but that's unlikely in
our application).  Net/rom sends the packet to the neighbor, with a
network header specifying our callsign and that of the ultimate
destination (in this case w9foo).
     
   We can use the netrom route add command to establish a digipeater
path to the neighbor.  For example:
     
        netrom route add #foo w9foo ax0 192 w9rly wd9igi
     
This will cause us to use wd9igi as a digipeater in establishing our
connection to the net/rom node w9rly.
     
   What if you have a net/rom node or nodes, and you'd like to attach
them to your computer via their serial interfaces, and use net as a
packet switch?  It's very easy:  you have to attach those interfaces,
using the "attach asy" command, but specifying type "nrs" instead of
"slip" or "kiss".  "nrs" is the net/rom serial framing protocol, which
is like KISS, but uses different framing characters and has an 8-bit
checksum.
     
   When you attach an nrs interface, it can be used for passing IP
datagrams or AX.25 frames over serial lines or modems.  To use it
for net/rom, you have to identify it to the netrom code just like
any other interface, with the "netrom interface" command.
     
   Now you know all the commands, but how do we actually use net/rom
for IP communications?  This takes two steps:
     
   Step one:  update the routing table.  In all likelihood, you will
use net/rom to gateway two IP subnets.  So, you'll probably want to
identify a station on each end as a gateway.  Let's say we're on the
Milwaukee subnet, and we want to talk to someone in Madison.  If
we're not the gateway, we just have a routing table entry like this:
     
        route add [44.92.0.0]/24 ax0 wg9ate-pc.ampr
     
This specifies that wg9ate should get all packets for the 44.92.0.x
subnet via interface ax0.
     
   Wg9ate has this routing table entry:
     
        route add [44.92.0.0]/24 netrom w9mad-pc.ampr
     
(presuming that w9mad is the Madison gateway).  Now, when the IP layer
at wg9ate gets datagrams for Madison, it knows that they have to go via
net/rom to w9mad.  Notice that we don't specify a "real" interface,
like ax1 or nr0, in the route entry.  The net/rom network layer will
pick the right interface based on its net/rom routing tables.
     
   We're not done yet, though.  w9mad-pc.ampr is not an ax.25
callsign.  The net/rom send routine called by the IP layer needs
to map from the IP address to an ax.25 address.  It does this via
a manually added arp entry:
     
        arp add w9mad-pc.ampr netrom w9mad
     
[We kind of fudged by using the arp table for this purpose, since
there is no way to do automatic address resolution for net/rom,
and arp messages are never sent or received for net/rom nodes.
However, the arp table does contain precisely what we have here:
mappings from IP addresses to callsigns, and it saved a lot of
code to do it this way.]
     
Notice also that no digipeaters are ever specified in the arp entry
for a net/rom node.  Also, the callsign to which we are mapping
is the final destination of the packet, not the non-destination
neighbor.  That neighbor will be picked based on the net/rom
routing tables.
     
   So, as a summary, let's look at what happens to a packet that
reaches the IP layer on wg9ate, destined for Madison.  The IP
routing code looks the destination IP address up in the table,
and discovers that it should go via net/rom to w9mad-pc.ampr.
So, it passes the packet to the net/rom send routine.  That
routine uses the arp table to translate w9mad-pc's IP address
to the callsign "w9mad".  Then it passes the packet to the
net/rom routing code.  That code checks to see if the destination
callsign (w9mad) is the same as that of any of its assigned
net/rom interfaces.  Since it isn't, it puts a network layer
header (a.k.a. net/rom level 3 header) on it, and looks for
w9mad in its routing tables.  Presumably, it finds an appropriate
neighbor for the packet, and sends in out via ax.25.  The net/rom
network does the job of actually getting the packet to its
destination.
     
   At w9mad, the packet's protocol ID causes it to be sent to
the same net/rom routing code that handled the outgoing packet from 
wg9ate (running on a different computer, of course).  Now
the destination callsign matches, so the net/rom network layer
header is stripped off, and packet is passed up to the IP layer.
(Net/rom network headers don't have a protocol ID byte, so
we just hope for the best.  If a net/rom node addresses a
net/rom transport layer packet to us, it is likely to be dropped
by IP for any of a number of reasons.)
     
-------------------------------------------------------------------