5.  Other Things: NET/ROM, Finger, Mulport, Mbox, Datagrams, V Circuit and 
    AX.25 Segmentation

5.1.  NET/ROM Services

This NET/ROM information was provided by Dan Frank W9NK, author of the 
NET/ROM support for NET.EXE.

The NET/ROM support for the KA9Q package serves three purposes:

   1) Existing NET/ROM networks may be used to send IP traffic.
   2) NET may be used as a NET/ROM packet switch (if compiled that way).
   3) NET may be used to communicate with NET/ROM nodes, and its
      mailbox facility can accept connects over the NET/ROM network.

5.1.1  Setting up NET/ROM

5.1.1.1  The NET/ROM Interface

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 #ipnode 80

The first argument is the name of the previously attached interface you 
want to use.  The second 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!).  The last 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.  Coordinate this value with 
other NET/ROM users in your area.  NET/ROM route management is beyond the 
scope of this document.

You need a netrom interface command for every interface you're going to 
use with NET/ROM.

5.1.1.2.  Tracing on the NET/ROM Interface

If you want to trace your NET/ROM datagrams, don't try turning on trace 
mode for the "netrom" interface.  Nothing will break, but nothing will 
happen.  You should trace the individual AX.25 interfaces instead.

5.1.1.3.  Routing Broadcasts

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.  You should usually set 
them 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.

By default, the NET/ROM code does not broadcast the contents of your 
routing table.  This is as it should be, since usually we just want to be 
the endpoints of communications rather than relaying NET/ROM traffic.  If 
you want to be a switch station, include in your autoexec the command, 
"netrom verbose on".  (This is a compiler option, not normally included.)

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.

5.1.1.4.  The NET/ROM Routing Table

The next 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.

To drop the route to w9foo, you would type

     netrom route drop w9foo w9rly ax0

To see the contents of your routing table, you may type

     netrom route

and to see the routing entries for an individual station you can type

     netrom route info <callsign>

You may not use an alias as an argument to the netrom route info command.

I can not stress enough that "route add" and "netrom route add" are two 
different commands, with different purposes.  In general, you only need a 
"netrom route add" if you need to add a route to a NET/ROM node via a 
digipeater path.  If you find yourself using this command, ask yourself, 
"Why am I doing this?"

Note: Using the netrom route add command to create a route to another IP 
station running NET/ROM is generally a BAD idea because it implies that the 
destination station is either not coordinated in the NETROM network, or 
that it may not be on the air all the time.  Attempting to create a 
session, such as smtp, with a non-existent IP station drives the NET/ROM 
circuit crazy with futile retrys and gives you a VERY BAD reputation.

5.1.1.5.  The Importance of the Routing Table

The NET/ROM routing table is analogous to the IP routing table:  if there 
is nothing in it, your NET/ROM traffic will not go out.  You must either 
manually enter a list of routes (perhaps via your autoexec.net) or wait to 
receive routing broadcasts from your neighbors before your NET/ROM traffic 
will leave your station.

If you go to send packets via NET/ROM and nothing happens, even if you 
have trace mode on, make sure that the destination node is in your NET/ROM 
routing table.  If sending IP traffic, double check the ARP table for an 
appropriate NET/ROM ARP entry for the destination node (see below for more 
information on the use of the ARP table).  The ARP table is not used for 
NET/ROM transport routing.

5.1.1.6.  Interfacing with NET/ROMs Using Your Serial Port

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.

5.1.1.7.  The Time to Live Initializer

The "netrom ttl" command allows setting of the time-to-live initializer 
for NET/ROM datagrams.  I recommend a value of 16 for most networks.  Use 
more if you expect to go more than 16 hops.  The default is 16.

The purpose of the ttl initializer is to prevent a packet from getting 
caught forever in routing loops.  Every router who handles the packet 
decrements the ttl field of the network datagram before sending it on, and 
when it reaches 0 it is discarded.

5.1.1.8.  Using NET/ROM Support for IP

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 actually gets 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.)

5.1.2.  The NET/ROM Transport Layer

NET/ROM transport is the protocol used by NET/ROM node to communicate end-
to-end.  When a user attaches to a NET/ROM via AX.25, and asks for a con-
nect to a node in the NODES list, his local NET/ROM tries to open a trans-
port connection to the destination node over the NET/ROM network.  NET/ROM 
transport packets are carried in NET/ROM network datagrams, just like IP 
datagrams.

You shouldn't use NET/ROM transport when connecting to other TCP/IP 
stations.  TCP is a much better protocol than NET/ROM transport, and makes 
better use of available bandwidth.  Also, BM and SMTP are more convenient 
to use than a TCP/IP station's mailbox facility.  However, for communi-
cating with AX.25 users via the NET/ROM network, the transport facilities 
in NET will work better (and more easily) than the traditional method of 
connecting to your local node via AX.25.

5.1.2.1.  Connecting via NET/ROM Transport

To connect to the node whose alias is FOO and whose callsign is W9FOO, you 
can issue either of the following two commands:

     netrom connect foo

     netrom connect w9foo

If foo:w9foo is in your NET/ROM routing table, your station will transmit 
a connect request to the appropriate neighbor used to reach w9foo.

NET/ROM transport sessions are very much like those for AX.25.  You can 
use the disconnect, reset, kick, upload, and record commands, and the 
session command to switch sessions.

5.1.2.2.  Displaying the Status of NET/ROM Connections

The command

     netrom status

is used to display the status of all NET/ROM connections, which will 
include those used in keyboard sessions as well as ones attached to the 
mailbox.  For more detailed information on a session, you can use the 
address of the NET/ROM control block:

     netrom status <&nrcb>

where <&nrcb> is the hex address given in the short form of the command or 
in the "session" display.

5.1.2.3.  NET/ROM Transport Parameters

The NET/ROM transport parameters may be set with the various NET/ROM 
subcommands.  Their meanings are listed below:

   acktime: This is the ack delay timer, similarly to ax25 t2.
            The default is 3000 ms.

   choketime: The time to wait before breaking a send choke condition.
              Choke is the term for NET/ROM flow control.

   irtt: The initial round trip time guess, used for timer setting.

   qlimit: The maximum length of the receive queue for chat sessions.
           This is similar to ax25 window.

   retries: Maximum retries on connect, disconnect, and data frames.

   window: Maximum sliding window size, negotiated down at connect
           time.

.pa
5.1.3.  Where to go for More Information

The paper "Transmission of IP Datagrams over NET/ROM Networks" appeared in 
the Seventh ARRL Networking Conference papers, available from the ARRL.  
In it, I describe the more technical details of how the NET/ROM network 
support works.

If you want to learn about NET/ROM, talk your local NET/ROM operator out 
of his or her manual.  If you want to learn more, read the source code.  
That's about it for sources, since the NET/ROM protocols originated in a 
commercial product.

5.1.4.  About the Code

There has been a great deal of controversy about TheNET, a NET/ROM clone 
for TNCs.  This is not the place to discuss the truth of the charges 
leveled by Software 2000 against its authors, but that situation requires 
me to make the following statement:

The NET/ROM transport support in NET.EXE was not taken in any way, shape 
or form from NET/ROM (whose source I have never seen) or from TheNET.  The 
protocol code is based on protocol 6 from Tanenbaum's excellent book, 
Computer Networks, as a moderately careful reading of both should show.  
The source code is freely distributed, so the curious reader should have 
the opportunity to check this assertion if he or she so desires.

The smoothed round trip time calculation, which is not done in "real" 
NET/ROMs (and should be, by the way -- they'd work a whole lot better) is 
adapted from that used by KA9Q in the TCP protocol in NET.  The dicey 
business of adapting it to a sliding windows protocol with selective 
retransmission was done by me, all alone, after my cries for help on the 
tcp-group mailing list went unanswered :-).

I have taken the precaution of copyrighting the NET/ROM code in NET.  It 
may be freely distributed for non-commercial purposes, in whole or in 
part, and may be used in other software packages such as BBS systems if so 
desired, so long as the copyright notice is not removed from the source 
files, and the program in which it is used displays "NET/ROM code 
copyright 1989 by Dan Frank, W9NK" when it starts up.

Any person who wishes to distribute the code, or anything based on the 
code, for commercial purposes will find me very reasonable, but rather 
insistent about being compensated for the hours I've spent working on it.

Dan Frank, W9NK

5.2.  The Finger Server (to put it on someone)

Mike, KA7AXD, added the finger server to net, and he credits Gerhard, 
PA0GRI, with giving him some help.  For more information on this 
implementation of Finger, see the 7th Annual ARRL Networking Conference 
Proceedings.  Mike can be reached at mhorne@honda.fdi.tek.com.

In a subdirectory, called, finger, off of the NETHOME directory (e.g. 
\net\finger, following these examples for the PC), put files with 
identifying names followed by the extension "txt", for example, k5jb.txt, 
sam.txt, all.txt, etc.  If someone sends "finger @k5jb" (my station), his 
program responds with something to the effect:

  Known users at k5jb:
      k5jb
      sam
      all

Then, if he sends, "finger all@k5jb", my program sends the contents of 
all.txt to him.  You can see the results of the finger command on your own 
computer by doing one of the three variations of the command: finger, 
finger @your_hostname, finger someone@your_hostname.  This will show what 
your files look like to someone else.  I use the all.txt to hold all the 
current IP addresses I have assigned in the local area.  (Users use FTP to 
get it from me as their first exercise of FTP.)

5.3.  Mulport -- Run your own router!

The multi-port code that is optionally compiled into net is called GRAPES 
Multiport, and sometimes "Mulport", from the compiler switch by that name.  
(Grapes is an acronym for "Georgia Radio Amateur Packet Experimenters 
Society".)  It permits your station to handle certain packets received on 
one port, and retransmit them out a second port.  (NET has to be compiled 
with the compiler directive MULPORT defined in config.h.  Mulport code 
adds about 3.3k bytes to the .exe file.)

5.3.1.  Mulport planning and setup

To use mulport, you must build are two tables (files).  These 
files are named DIGILIST and EXLIST (Digipeater list and exception list).  
Calls in these files are used in the rules that follow.  These files are 
simple ASCII text files containing the callsign of each station involved 
and the interface name of the port needed to reach it.  The port name is 
the same name you used in the attach statement for that port.  There is a 
special callsign "lan" that tells mulport which port feeds your LAN or 
default port.

5.3.2.  Digilist file

The asynchronous port names in the following examples came off of my 
setup.  They are ax0, ax1, ax20, ax21, etc.  An example of a digilist file 
is:

   lan ax20
   k5jb-5 ax20
   n0els5 ax20

5.3.3.  Exlist file

An example of an exlist file is:

   k5jb ax21
   k5jb-11 ax0
   kb0qj-10 ax0
   n5owk-2 ax1
   n5owk-1 ax1

The files digilist and exlist must be carefully constructed because the 
mulport.c routine that reads them is not very robust; a badly formed file 
can crash the program, or make it run erratically.  The program only reads 
the first two fields of each line, and it doesn't do much error checking.

The following exlist and digilist file rules are important:

     1. Don't put comments in the file unless you put them on the same 
        line with an entry, e.g. w1aw-10 ax0 115kb link to the moon

     2. Don't make the call sign total length over 11 characters (highly 
        unlikely error)

     3. Don't make the interface name over four characters.  ("dr0a" is 
        max.)

     4. Make sure the lines are well under 80 characters long if you add 
        comments.  In fact, make sure they are less than 77 characters to 
        be safe.  Us an ASCII text editor just like you use on other net 
        files.

Regarding comments.  The program reads the first two fields on each line 
and throws the rest away.  There can be a maximum of 10 call - port pairs 
in each file.  The bigger these lists, the more work you put on the ax25 
parts of NET.

Place these files in the NETHOME directory.  (In the examples for MS-DOS 
this is in \net.  As usual, if environmental variable NETHOME is not used, 
NET will find the files if they are in root.)

5.3.4.  Mulport Rules

Here are the rules that mulport follows (in pseudo C notation):

If(our call is in the received packet header digipeater list)
   if(it is not the last one on the list)
      if(the call following ours is contained in digilist)
         send the packet out the port specified in digilist
      else
         send the packet out the port from whence it came.
   else /* our call is last one in digipeater list */
      if(destination call is in exlist)
         send the packet out the specified port
      else
         if(there is a lan entry in digilist))
            send the packet out the lan port
          else
             send if out the port from whence it came

Rules functionally restated:  If packets digipeated through our switch are 
to be digipeated by another station put that other station's call in 
digilist if it is not on the same port from which those packets are 
received.  (For return packets to be handled correctly, you may have to 
also apply the next rule.)

If packets digipeated through our switch are intended for a directly 
reachable station, put that station's call in exlist if it is not on the 
"lan" port.

5.4.  AX.25 and NET/ROM Mailbox

5.4.1.  A two way communication

(This is pretty much old hat information, but at the time it was revolut-
ionary when I added some user friendliness to the non-IP user.  I am leav-
ing it in the manual for historic reasons.)

If you have enabled mbox (mbox on) non-TCP/IP users can connect to your 
station and get something besides a blinking cursor.  Previous to the 
inclusion of the mailbox (mbox) users were connected to a dormant ax25 
terminal session.  You had to enable the session on your end, to receive 
their typing.  (With version K28, such sessions are automatically made 
active.

Dan Frank, W9NK, incorporated the interception of NET/ROM and AX.25 con-
nections when he did his NET/ROM code.  The initial mbox enabled a user 
to do three things, send a message, initiate a telnet (chat) or discon-
nect.  I added the ability for a user to read mail addressed to him and 
download files that were put in a special place so their content and size 
could be controlled so as to not flood the AX.25 network.

An incoming AX.25 connection to your ax25 call requires the user to enter 
a carriage return (or any information frame) to bring up the mailbox 
banner and prompt.  This is because there is no protocol information in 
the AX.25 link layer connect request (SABM).  If you specify the ax25 
mboxcall and the user connects to that call the mailbox prompt will be 
sent immediately after connect.  The NET/ROM mailbox also is activated as 
soon as the incoming connection is completed over a NET/ROM circuit.

With version, 890421.0g (K5JB.g or later), the user is able to read mail, 
kill his mail, see who has mail, get a help message, get directory lists 
and download text files.  See below for an explanation of files and 
directories that support this mbox version.

Mail handled by mbox is normal mail handled the same as SMTP so non IP 
users can participate in the TCP/IP mail network.

Operating note:  If your neighbor NET/ROM has parameters set a certain 
way, the incoming AX.25 link creating a NET/ROM circuit may stay estab-
lished after the initiator is gone.  Your neighbor NET/ROM will begin the 
next connection with a NET/ROM protocol packet instead of an AX.25 SABM.  
If you have stopped and restarted your program, it will send a DM to the 
NET/ROM.  The effect is that the user never gets the prompt from your 
station (unless he sends the connect command a second time to his terminal 
NET/ROM).  If you observe that you have "permanent connections" with your 
neighbor NET/ROM, it is good practice to make an AX.25 connection with it 
and disconnect, either before exiting the program, or after restarting it.

A new command ax25 t4 deals with stale ax25 connections.  Normally after 
NET/ROM transactions your station will disconnect the circuit after 15 
minutes of inactivity.

Incidentally, it is not a good idea to set T3 to other than 0 when dealing 
with NET/ROM because it only causes unnecessary polling.

5.4.2.  Mbox File placement.

In the following examples, the MS-DOS backslash is used in path names.  In 
Unix, substitute forward slashes, of course.

If you have defined them, mbox will use environmental variables NETHOME, 
NETSPOOL and PUBLIC to find its files.  Mbox searches the directory, 
specified by NETHOME for the file helpbox.hlp, used by the help command.  
It searches $(NETSPOOL)\mail, (e.g. if NETSPOOL = \spool, it searches the 
file \spool\mail) for a *.txt files containing the users' call signs.  (In 
MS-DOS you can specify drive letter in paths.)  It uses the directory 
defined in PUBLIC as its file area.  If PUBLIC is \public\mbox, it will 
use that directory.  The PUBLIC file area should only contain files that 
are suitable for downloading over AX.25 links.  (In other words, no 
binaries, and no monsters).

If you didn't define these environmental variables, mbox searches the 
default directories, \net, \spool\mail, and \public, respectively for the 
above functions.  Note that in most instances internal MS-DOS file 
operations don't really care if you use "\" or "/" in these path 
separators.  Unix does, so to be consistent the compiled code uses "/".

In the Unix version, the default directories are placed differently.  If 
no environmental variables are specified, spool will be  /usr/spool.  
Public will be /usr/public

There are provisions to put a short help file in the NETHOME directory 
(\net in our example) that is sent to a user in response to "h".

Here is an example of helpbox.hlp that I use.  It contains information on 
commands that are not compiled into the mbox prompt:

This is a mail box part of a TCP/IP program.  You can read mail addressed 
to you or send mail to someone else in the local area, or someone else on 
the TCP/IP network.  Briefly, here are some of the commands:

b    Is for bye, like in bye-bye.  I'll disconnect.
c    Enters chat, a telnet session.  You have to disconnect to quit.
k N  Kills your message N.  If you change your mind, disconnect.
l    Lists all messages for you
ll N Lists last N messages for you.
ls   (or w) Lists downloadable file names that are in a public directory.
m    Lists calls of those who have mail here.
g (filename) gets a files from your directory.  Use, g morehelp, to get a
     more complete help file.
r N  Reads your number N message.
u    Shows current users on the mailbox.
v    Shows what NET version this is.

If you want to get in on this TCP/IP thing, leave me a message.

Enjoy!  Joe, K5JB
(end of helpbox.hlp)

Helpbox.hlp is short because people are prone to type "h" when they can't 
think of anything else to do.  A short file makes the results over a poor 
path merciful.  "Morehelp" in the \public directory is much more inform-
ative.  A sample morehelp file is in the samples provided with this kit.

Note: If the user came in with AX.25, you can butt in by initiating a 
connect with the connect command but it is not a good idea.  The session 
you create will take the control block used by the mailbox leaving the 
mbox as an orphan.  Only disadvantage of this is that a small amount of 
memory will not be freed until you stop and restart net.  Frequency of 
this occurrence was considered so small that no code was written to free 
up this memory.  You can't butt in on a NET/ROM mbox session, though you 
can issue a netrom connect to the destination node and then issue a 
connect to the station who is using your mailbox.  This will be a separate 
session from the mbox session.  See the "mbox s" command for a graceful 
way to butt in.

5.4.3.  Mbox user commands

Once a session is started, the mbox tells the user whether or not he has 
mail, and tells him how many messages there are, before the initial 
prompt.  The prompt, which is compiled in, doesn't show all the possible 
commands.  It shows,

  "Read #, Kill #, List, LLast #, Send, Chat, What, Help, Bye >".


"Read" works without an argument if there is only one message.  If there 
are more than one, the message number must be used as an argument.  (e.g. 
r 3 reads message number 3.  At least one space is required.)

"Kill" deletes a message if there is only one.  If there are more, "Kill" 
must be followed by the message number.  Kill takes effect after "Bye".

"List", or "l" lists the entire list of messages for the user.  When the 
user connects, the user is advised of the number of messages he has, but 
only lists unread messages.  If the user wants to see the whole list he 
can use this command, or for a partial list, the one that follows.

"Llast n" or 'll n" lists the last n messages.  If n is missing, it lists 
all the messages.

"Send" has the same syntax as the standard WA7MBL/W0RLI/CBBS send command.  
It has provisions to handle incoming BBS traffic correctly.  (Recognizes 
the BBS "SID", such as [CBBS-v6.4-$H]; SP, SB, ST, as well as S; the @ BBS 
field; the < fromcall field; and the $BID field.  It does nothing special 
with the SP, SB, and ST fields except add the recognition to the message 
header.)  Non-BBS users can also use the from redirection, e.g. 
   s k5jb@k5jb <w1aw
sends a message to k5jb at host k5jb and marks it as from w1aw, even 
though it may have been sent by wb5fwe.

"Chat" closes the mbox session and passes the user off to a telnet 
session, never to return without disconnecting and reconnecting.  He is 
advised of this fact before it happens.

"What" is an alias for the LS command without arguments.  It lists 
contents of the public directory.

"Help" sends the user the contents of a file, helpbox.hlp.  See the 
example above.

"Bye" logs the user off, cleans up his files, and disconnects.

Additional commands not shown at the prompt are:

"Get" causes a file located in the public directory to be sent to the 
user.  It is intended for text files, but will download a binary file to 
the hapless user, so don't put any within his reach.  Location of the 
public directory is discussed in 5.4.2.  The filename is case sensitive in 
Unix.  ("d", for "download" is an alias for the "get" command.)

"Ls" is a directory listing function.  It lists contents of the public 
directory.  It uses the wildcard pattern of the host machine for 
selectively listing file names.  Ls <directory> lists contents of a 
subdirectory.  ("What" is an alias for "ls" with no argument.)

"Mail" sends a list of users who have mail (files in $(SPOOL)/mail that 
have the extension, .txt).

"Users" shows the same information as the mbox command shows at the 
console.  (See 6.2.24.)

If you compiled your code with AX25_HEARD defined, there will be a "j" 
command (jheard) that will cause the mailbox to show the most recent info 
frames heard, with their associated interfaces and protocols.  (Display is 
same as the one you get with the ax25 heard command.)  This function takes 
a lot of space so it is not normally included.

Note: Downloading (receiving) of files (resulting from: read mail, list 
directory, get file) can be aborted by the recipient if he sends a char-
acter to the mbox while the downloading is taking place.  (Empty line 
alone won't do it.)  A disconnect will stop the downloading.  After queued 
transmit packets are sent, the message, "Interrupted at your request", 
will be sent before the prompt.

When a user reads a message, mbox reads that message out of the call.txt 
file.  A temporary file, call.$$$ is created for a message that is sent 
and that file is not deleted.  You can brouse this file if you are curious 
about the last message read.  When a user reads or kills a file, the old 
call.txt file is renamed to call.bak, and a new call.txt file is created.  
All these mail related files are are in the \spool\mail directory.  
(MAILSPOOL environmental variable with "\mail" tacked on.)

Addition of the AX.25 mbox is probably the most significant thing that has 
been done to convert the net suite from a networker's toy to an interest-
ing and useful addition to routine packet radio environment.  At least, it 
provides a window for those who are learning about packet to peer through 
to the possibilities of TCP/IP.  It is difficult to stifle adding goodies 
in this area of net.

To witness fascination amateur radio operators have with BBSs, notice the 
transformation of NOS from a TCP/IP program with incidental mailbox to a 
full blown BBS with incidental TCP/IP.

5.5.  Virtual Circuits and Datagrams

The "mode" command sets the manner in which packets are transmitted over 
AX.25.  The mode command is given for each interface and can be either 
"vc" or "datagram".  Default is "datagram".

In "vc" (virtual circuit) mode, IP packets are encapsulated in AX.25 I 
frames and are acknowledged at the link layer according to the AX.25 
protocol.  Link layer connections are opened if necessary.  With the 
proper setting of the AX.25 T2 (response delay) timer, AX.25 acknowledg- 
ments can be piggybacked on I frames carrying other IP datagrams (e.g., 
TCP level acknowledgments), thereby eliminating the extra overhead 
ordinarily incurred by link layer acknowledgments.

In both modes, ARP is used to map IP to AX.25 addresses.  (Programmer's 
note: The defaults can be overridden with the type-of-service (TOS) bits 
in the IP header.  Turning on the "reliability" bit causes I frames to be 
used, while turning on the "low delay" bit uses UI frames.  The effect of 
turning on both bits is undefined and subject to change.)

5.6. ROSE Transport

If included at compilation, NET is capable of easily conducting sessions 
over ROSE circuits.  ROSE networking software prior to version 3.0 
replaced the protocol identifier (PID) in user AX.25 information frames 
with 0xF0, the "no layer 3" PID, when it delivered them to their destin- 
ations.  Version 3.0 and later ROSE switches preserve the user's PID.  
Depending on the types of ROSE switches (or other virtual circuit net- 
working schemes) you encounter, you and the other IP stations you work 
with, will have to take steps in NET (or NOS) to deal with these net- 
working schemes.  (With NET version k34, and later, the vcipcall is used 
to replace the "vcircuit" scheme that was introduced in k15.  NET no 
longer has the "rosebash" command that would insert IP PID in pre-version 
3.0 ROSE circuits.)

There are two conditions that have to be satisfied BY BOTH IP stations in 
order to use ROSE transport circuits.  1. Stations using ROSE must be 
prepared to work in virtual circuit (VC, or "Connected" mode), and 2. If 
the ROSE circuit sends packets with F0 PID, both stations must be able to 
discard them.

In its native datagram mode NET communicates with other NET or NOS 
stations using un-numbered information frames (UI) but by using the mode 
command NET can be made to exclusively use VC mode on a given interface 
(port).  Since VC mode is lower performance than datagram, its exclusive 
use should be avoided.  NET version k34, and later, have the command, arp 
add <hostid> vax25 <call), that causes outgoing packets to take the 
virtual circuit.  "vax25" is a pseudo hardware type that signals the other 
layers in NET to use virtual circuit.

Incoming packets from TCP/IP stations, if carried by ROSE virtual circuits,
must be handled specially.  If they contain IP or Netrom PIDs they can be
handled normally but if they contain F0 PID they have to be trapped or they
will be routed to the AX.25 mailbox.  ROSE switches send unexpected alias
frames that are trapped by using the ax25 vcipcall command (explained 
shortly.)

Normally it would be beyond the scope of this document to tell NOS users 
how to run their NOS but ROSE information seems to be sparse (or incor-
rect).  Any version of NOS will work fine on a ROSE circuit that contains 
switches running 3.0 or later ROSE versions, but if but one of the switch-
es in the circuit is running a version prior to 3.0, NOS must be modified 
to deal with it.  The rest of this discussion assumes that all ROSE 
switches in a circuit have the later code.

If you have a version of NOS designed to work specifically with ROSE (e.g. 
TNOS) follow the author's instructions.  I understand it uses a separate 
AX.25 call sign for IP users, similar to NET.

With PA0GRI NOS or JNOS, and probably others, do the following:
  1.  Use the ax25 route add command to create a route to the destination
  2.  Use the ROSE's "reliable mode".  (See below)
  3.  Use the ax25 route mode <target> vc command to make NOS use vc.
  4.  Stifle the NOS mailbox's "jumpstart" (mbox jumpstart off).
  5.  Use the arp, route, etc. commands you would use with a local user.
  6.  Coordinate what you are doing with the station on the other end.

ROSE's "reliable mode" suppresses enough of the spurious F0 PID infor- 
mation frames to make it usable by any regular version of NOS.  To use it, 
use your neighbor ROSE switch's digipeater call sign instead of its 
regular call sign in setting up your AX.25 route command.  Even in the 
"reliable mode" ROSE persists in sending a zero length F0 PID I frame to 
the connecting station after receiving an SABM, and when the far end 
disconnects, ROSE sends an F0 PID I frame telling all about it.  The 
latter frame briefly spawns an AX.25 NOS mailbox session, but it is 
harmless since the ROSE switch immediately disconnects.

Now back to running NET.  For outgoing frames, to avoid dedicating the 
async port to the VC mode, you use the arp add command to specify that 
you want to use virtual circuit to the other station, and specify a 
unique call sign (ssid) for your ax25 vcipcall.

In summary, in order to set up a ROSE circuit to send IP frames, you must 
do the following:

  1.  Set up a virtual circuit IP call sign e.g.

      ax25 vcipcall k5jb-8

  2.  Use arp add on the other station's call sign and route, e.g.

      arp add wb5cqu vax25 wb5cqu-10 k5jb-6 817105

      where wb5cqu is the other station's host name, vax25 is the "hard- 
      ware" type that signals to use virtual circuit, wb5cqu-10 is the 
      AX.25 call sign of the other station, k5jb-6 is the call sign of 
      the local ROSE switch, and 817105 is address of the other station's 
      neighboring ROSE switch.

  3.  Use the route add command as you normally would, e.g.

      route add wb5cqu ax0

      where wb5cqu is the host, same as above, and ax0 is the name of the
      interface to use.

  4.  Put the other station's hostname and IP address in your hosts.net

  5.  Coordinate with the other station so he can build a route back to
      you.  Have him/her use your vcipcall in the arp entry.

If you are replacing an earlier version of NET, remove all references to
the vcircuit command and associated interfaces.  Change any previous vc
interfaces references to their base interface names, e.g. change vc0 to
ax0.

The only thing you do differently when using ROSE, as compared to setting 
up a datagram circuit over a non-ROSE path, is to set your ax25 vcipcall, 
and use "vax25" instead of "ax25" in the arp add command.

It is noteworthy that ROSE circuits imply slow responses, so set your tcp
irtt (initial round trip time) to a fairly large value, at least 60000,
(60 seconds).  Otherwise, tcp will flood the ROSE network with unnecessary
duplicates.  One thing that ROSE can't seem to stand is being flooded, 
which causes it to flounder.

5.7  AX.25 Segmentation

KA9Q's NOS has an AX.25 segmentation scheme.  In order to cooperate with 
NOS, I added this scheme to NET.  This section describes what segmentation 
is and how to manage it.

The reason for AX.25 segmentation is to permit sending a stream of AX.25 
frames containing IP frames, with the IP and TCP header contained in only 
the first frame of the stream, thus avoiding repetition of these 40 bytes 
in each AX.25 frame.  Segmented frames are identified by a PID byte of 
0x08 instead of IP PID of 0xCC in each AX.25 Information frame.

First, let's review some terminology relating to relevant parameters.

TCP mss is maximum segment size for TCP, not to be confused with AX.25 
link layer segmentation discussed here.  Its value is global for all 
interfaces.  Also, the word "fragmentation" is used in this document where 
IP level fragmentation is discussed.  I removed the earlier AX.25 "frag- 
mentation" attempts from NET.

Send mss is a value that is negotiated during TCP session setup.  Each 
station in the session has an independent send mss.

Interface mtu is maximum transmission unit, set at attach time, but 
changeable later, or even selectable on a route by route basis (with 
version k33 and later).  It controls IP level fragmentation and is a 
factor in establishing the send mss for a TCP session.

AX.25 Paclen (ax25 paclen) establishes the maximum packet length in both 
the AX.25 virtual circuit (connected mode) and datagram (unconnected 
mode).  It is global to all interfaces.  Note that I chose to control 
datagram size differently than is done in NOS.  (Footnote 1)

Segmentation is only used in the AX.25 connected mode (virtual circuit).  
It is not used in AX.25 UI frames (datagram mode) nor is it used on 
NET/ROM circuits.  (Segmentation is in current versions of NOS NET/ROM 
files but it will not work over NET/ROM the way it is written in NOS.)

Interface mode (e.g. mode ax0 v) is either virtual or datagram.  Each 
interface has its own mode.  If the special hardware type "vax25" is used 
instead of "ax25" in the arp add command virtual circuit will be used to 
reach the destination.

TCP session setup proceeds as follows:

Each station's tcp send mss is established during tcp session synchroniz- 
ation (SYN).  The originating station proposes an mss equal to its tcp 
mss.  The destination examines its own setup for the value of mtu that it 
wants to use for that route.  If the route table entry for that destin- 
ation contains a value for metric other than zero it uses that value for 
mtu, otherwise it uses one of the following depending on whether the 
interface is set for vc or datagram mode.  If set for vc mode, it uses 
interface mtu.  If set for datagram it uses the smaller of interface mtu 
or paclen.  It subtracts 40 from whichever number it chooses (to prevent 
unnecessary IP fragmentation) and compares the result to the proposed mss.  
For the balance of this session its send mss will be the smaller of this 
result or the mss proposed by the other station.

In Summary, each station's send mss is the smaller of:

   1. The other station's tcp mss, or
   2. A. The route metric minus 40 if one is specified, or
      B. If interface is vc mode, its interface mtu minus 40, or
      C. If interface is datagram mode, its paclen or its mtu, 
         whichever is smaller, minus 40.

If the negotiated send mss is greater than the transmitting station's 
paclen minus 40, and it is operating in the vc mode, it will transmit 
AX.25 segments.

If you don't want to mess with AX.25 segmentation, in your attach command 
set your interface mtu to 256 and accept NET's defaults for the rest.  If 
you want to use smaller packets, set your interface mtu to the same size 
as planned ax25 paclen and set your tcp mss to your planned ax25 paclen 
minus 40.  (Footnote 3)

If you want to set up a particular AX.25 segmentation scheme, to prevent 
generating final runt packet segments, calculate interface mtu by using 
the formula,

  mtu = N * (paclen - 2) - 1

where N, the desired number of AX.25 segments per IP frame, is greater 
than 1.  (The segmentation method adopted creates paclen - 1 size data 
chunks).

Then, set your tcp mss to the mtu - 40.

For this to be coordinated, the other station would need to use a tcp mss 
that is at least as large as your interface mtu minus 40, and a paclen at 
least as large as yours.  (In other words, same numbers as yours should 
work fine, but other numbers can work too.)

Stated another way:
If you set your tcp mss to a value that is no more than the other
station's paclen minus 40, (e.g. tcp mss = 216, other station's paclen =
256) he will not send AX.25 segments to you.  If you leave the route
metrics set to zero and set your station's interface mtu to no greater
than your paclen (e.g. 256 for both) your station won't transmit AX.25
segments.

These numbers will not prevent your station from having to receive and 
queue segmented AX.25 frames if, like in my case, it is acting as a switch 
between two other stations that have negotiated tcp send mss that causes 
AX.25 segmentation.

In conjunction with this segmentation addition, I modified one command and 
added another to NET.  They are the param command and the ax25 segment- 
ation command.  They are discussed in Chapter 6.

Footnotes:

Footnote 1. I'm sorry that paclen (AX.25 packet length), tcp mss (maximum 
segment size), and interface mtu (maximum transmission unit), aren't bet-
ter coordinated in NET.  It makes it much more complicated than it needs 
to be, and in some cases makes setting correct packet sizes very awkward.  
I am working on better coordination; in the interim, if you use standard 
values provided as defaults NET should work fine.  

Note that, unlike NOS, UI datagram size will be no bigger than paclen.  To 
tie it only to interface mtu causes real problems if you want to use I 
frame segmentation and UI datagrams on the same port.

For more discussion of these values, see PA0GRI's NOS documentation, near 
its end.

Footnote 2.  Note that the actual packet data size is governed by other 
things also.  The sending choke window grows and shrinks, based on perfor-
mance.  AX.25 segmentation, if it is to occur, starts after the first few 
transactions has established sufficiently large choke window.  Be sure 
your tcp window and ax25 windows are adequate to not stifle performance.

During a session, while doing its work, the IP router will compare out- 
going datagram size to the interface mtu (or the route metric, if it is 
non zero) and fragment the packet at the IP level if necessary.)

Footnote 3.  Netrom interface presents some special problems. When netrom 
is attached its mtu will be set to paclen minus 20, but greater than 43 
and less than 237.  This number will cause send mtu to take on a sane 
value if another station initiates a connection to NET, but outgoing 
connections over netrom will have a proposed send mss a little bit too 
large (216 bytes) which will be trimmed only if the destination station 
does it because of its netrom interface mtu (hopefully 236).  The other 
station's actions would reduce the send mss to correct value of 196.  The 
NRS interface mode used for serial communication with a TNC using NET/ROM 
has also been constrained at attach time to paclen - 20.
