Media Share 9/MEDIASHARE_09.ISO/network/wnos4doc.zip/WNOS4DOC.EXE/WNOS4MAN.TXT

Text File | 1992-05-30 | 43KB | 1,106 lines

                   DB3FL WAMPES NOS (WNOS) Version 4 Manual


                              Mike Chace (G6DHU)

         Based on the original German document by Mike Bentrup DB3FL

                       Document Version 1.0 (May 1992)

                           Program Version WNOS4a6






1.  Introduction

WNOS is a version of NOS (the Network Operating System) based on earlier
work  by  Phil  Karn (KA9Q), Kelvin Hill (G1EMM), Gerard van der Grinten
(PA0GRI), Anders  Klemets  (SM0RGV),  Peter  Glasmacher's  (DK5DC)  GNOS
program and WAMPES from Dieter Deyke (DK5SG).

Special Features of WNOS include;

     More friendly User Interface

     New AX.25 Server (from WAMPES)

     Convers Server (from WAMPES)

     Real time data compression on SMTP, NNTP and Convers interlinks

     Automatic route saving for IP, ARP, NET/ROM and AX.25

     Dynamic timers based on link layer traffic conditions

This manual is not really designed to provide beginners with an  overall
grounding  in the use of the NOS software. More importantly, it provides
a guide for users familiar with TCP/IP use in other NOS variants, as  to
how  to  use  WNOS  as  well  as  explaining  the new principles in this
software. Installation programs and so on are not provided, but all  the
information on directory structure and configuration is provided herein.

Beginners  should  be  able  to  find  plenty  of  other  tutorials  and
information  about  TCP/IP and NOS in general from other sources, should
they wish to know the "basics".













2.  WNOS


2.1.  About This Manual

This is the first attempt at a  reasonably  complete  manual  for  WNOS.
Don't  be  surprised  if  some  bits are missing or don't quite follow a
logical sequence. Thanks to Thomas (DG8FBV) for proof reading the German
original drafts and providing feedback.

This manual tackles a number  of  different  areas  of  WNOS  and  first
provides  an  overview  of  the  hardware  required  and  of the startup
procedures used to run WNOS. Following this  is  a  description  of  the
display  features  and of the file and directory structure required. The
main body deals with a detailed description  of  each  of  the  commands
supported  by  WNOS.  Note  that  some  commands and options will not be
available since they depend on which features have  been  compiled  into
the distributed executable program (WNOS.EXE). A summary of the commands
available in any given program may be displayed by the "?" command.

The final sections deal  with  short  cuts,  an  overview  of  the  most
important  RFCs (Request For Comments), the Internet Protocol definition
documents.

At this point I'd like to  thank  all  those  involved  with  tests  and
trials,  bug  fixing and bug hunting! Special thanks go to Peter (DK5DC)
who provided code from his GNOS system. Thanks also  to  Dieter  (DK5SG)
for  permission  to  use  parts  of  the WAMPES software. Also to Thomas
(DG8FBV) and Heinz (DL8YQ) who tested many versions to  destruction  and
became  "professional  testers"  to  the extent that the key combination
CTRL-ALT-DEL became an everyday part of life!

UK Note from G6DHU: Thanks to all those who beta test my UK  version  of
WNOS;  G1ERT,  G6PWY, G4OTJ, G4BIO and all those who use the software in
this country.

Suggestions for improvement, problems and  bug  reports  are  of  course
always welcome.


2.2.  About WNOS

WNOS is an extension of, and improvement upon the  foundations  laid  by
Phil  Karn  in  his original version of NOS. The "W" in the program name
stands for WAMPES. This doesn't mean that all of the  WAMPES  system  is
implemented  in  WNOS,  just  the  AX.25  Autorouter, Convers server and
client and other smaller features.  This  involved  a  lot  of  work  in
porting  WAMPES code from its Unix environment to DOS. Also, the move to
a different style of C compiler brought its own problems. In  any  case,
WNOS  Version  4  is now rid of most of the bugs and problems present in
earlier versions.

WNOS being mainly German in  origin,  is  designed  foremost  with  that
Packet  Radio environment in mind where auto routing of AX.25, crossband
digipeaters and Hop-to-Hop acknowledgement are all daily facts of Packet
Radio life.









2.3.  WNOS In Comparison

The command syntax of WNOS (and NOS)  owe  much  to  that  of  the  Unix
operating system. For instance, directories are delimited by "/" instead
of the DOS "\". Not all WNOS  functions  make  the  conversion  of  file
syntax  from  Unix  to  DOS-style and so the Unix approach is more often
than not, the correct one in WNOS commands.

At a first glance, WNOS bears little relation in its look  and  feel  to
that of the original NOS. The reasons are twofold. Firstly, WNOS removed
NOS's more irritating features, and secondly, the user interface in  NOS
is   very  primitive  for  today's  machines.  A  continual  process  of
improvement over some two years has made WNOS what it is today.


2.4.  Features

The AX.25 server automatically drives the ARP and IP routing tables.  In
this  way,  incoming  IP  traffic  can  be  sent to other hosts with the
minimum of operator intervention. IP traffic from NET/ROM routes is also
now  dealt  with  in  the same way thereby removing one of the remaining
inconveniences.  Lastly, AX.25 routes, the ARP and IP routing tables and
the NET/ROM routes are all saved to disk at periodic intervals.

Interface parameters have also been made more flexible and extended thus
allowing  settings  such  as  Paclen  and  the  AX.25 timer values to be
specified  separately  for  each  configured  interface.  In  this  way,
interfaces using high speed links can be optimized for performance.

The user interface of WNOS has also been improved over time. WNOS3 began
by  providing a single status line at the top of the screen with summary
details about each active session. For WNOS4, two status lines  are  now
displayed one of which includes a permanent monitor on the level of free
memory "coreleft" available. This  gives  useful  warning  of  when  the
program is running short on working memory.

When hopping into a session,  one  finds  that  the  upper  status  line
displays  the important parameters for that link. Through this, one gets
a  quick  and  simple  summary  of  the   progress   of   the   session.
Unfortunately,  due  to  the 25 line limit of most displays, any further
extension of this user interface is now likely to prove difficult.

The new features different from WNOS3;

     LZW Data Compression is now extended to NNTP and Convers.

     The Domain  Name  Server  and  Client  code  has  been  extensively
     modified;  a  configurable  size domain cache has been built in and
     the domain name translation function reinstated.

     The NNTP  Server  and  Client  code  has  been  optimised  and  its
     functionality extended.

     The POP code has also been modified and reorganized.











     The trace functions have been  reworked  for  greater  speed,  less
     wastage without compromize on functionality.


2.5.  Protocol Timers

Particular attention  has  been   paid  to  the  TCP  timers  in  WNOS4.
Especially  in  the cases where fast links (eg Ethernet) meet slow AX.25
links, attention has to be paid to synchronisation during the change  in
link  speed. TCP frames are often carried upon AX.25 but the AX.25 layer
acknowledgements have little effect upon the TCP layer. WNOS attempts to
rectify this situation by deriving TCP layer timer values from knowledge
about the AX.25 link layer.

In datagram mode (AX.25 UI frames), nothing needs to be done, since  all
timing  is  handled  by  the TCP layer. If however, either AX.25 virtual
circuits or IPCAM modes are used at the link layer, TCP timer values are
multiplied   by   a   factor  of  10  to  allow  for  the  usually  slow
acknowledgement and forwarding of frames on  the  link  layer.  After  a
maximum  wait  of  300  seconds,  unacknowledged TCP segments are resent
irrespective of the link layer conditions. This  ensures  that  the  TCP
layer  is  not  controlled  too  stringently  by  the  underlying  AX.25
connection. In practice, this timing method results in an overhead of  a
little under 5%.

If data arrives so quickly on the fast link, that it cannot be forwarded
onto  the  slow  link, the sending host on the fast link is sent an ICMP
control message (Source Quench). This then allows the slow link to catch
up  in  sending  the  data on to its intended destination. WNOS monitors
this sort of condition continuously in order to minimise  the  overheads
in forwarding traffic.


2.6.  Internals

In contrast to NET (the forerunner of NOS), the core of the program runs
in  a  quasi-multitasking  environment.  Each  main action runs within a
small piece of code known as a  process  (A  summary  of  the  currently
active  processes  may  be  displayed  by  the  "ps"  - (Process Status)
command). This environment allows NOS to be much more powerful than  its
predecessor  which  had  to finish each task before another could begin.
One mustn't forget that just because the sysop isn't typing anything  at
the  console,  the  program isn't just idly waiting. It is busy updating
timers, coordinating tasks, updating the display,  handling  interrupts,
monitoring all frames on the channel etc etc.

Since even this approach leads to problems  on  today's  fast  machines,
attempts  were  made  to  streamline and optimise the program code. This
involved rework of many files, removal of redundant code and so on. This
rework also allowed the trace process to run in a separate window all of
it's own. All of this  work  allowed  the  overall  performance  of  the
program  to  be  increased  considerably  as  well as providing a stable
NET/ROM implementation and a net reduction in the size of the executable
by 10 kilobytes.











Parallel to this work, went a  complete  reorganisation  of  the  memory
management  routines.  Borland compiler library routines were used which
allow unused memory to reallocated for use by DOS as  and  when  it  was
needed. These library routines first appeared in Borland C++ 1.01 and so
the program will not run if compiled with Turbo C 2.00.

Despite all of these improvements a word of advice: I  (Michael  Bentrup
DB3FL) make no guarantees and take no responsibilty for, any damage that
WNOS may cause on other systems. Whether intentional or unintentional.


3.  Using WNOS


3.1.  Hardware Requirements

WNOS can run under the MS-DOS or DR-DOS PC  operating  systems.  It  has
been  tested with MS-DOS from versions 3.31 to 5.0 and DR-DOS versions 5
and 6.  Under MS-DOS 3.31 there are some  problems  with  Terminate  and
Stay  Resident  (TSR)  programs  and especially with PC-CACHE version 5.
With PC-CACHE version 6 there  were  no  longer  any  problems  even  if
operating  under  MS-DOS  version  3.31.  All versions of DR-DOS have an
internal problem that means that the File Pointers shown by  the  "stat"
command are not properly displayed. This seems to be a DR-DOS bug.

Disk compression programs such as Stacker  and  DR-DOS's  SuperStor  may
also  be  used  without any problem. Memory managers such as QEMM386.SYS
and EMM386.SYS also work well with WNOS but there is  one  known  slight
problem  in  that  if  the  program  is "exit"ed with outstanding Telnet
connections, some memory corruption may occur. This may  cause  QEMM  to
terminate  with  an  error.  In this case, it is necessary to reboot the
machine from cold so that the ports are properly reset. This is  due  to
WNOS  needing  a well defined port setting before startup and would fail
to attach drivers to ports if a reboot was not carried out.

WNOS has been developed on the following hardware configuration;  386sx,
20MHz  clock,  2Mb  RAM.  Either  MSDOS5  with  Stacker  or  DRDOS6 with
SuperStor was used as the Operating System software. In  both  of  these
configurations,   the   following   resident  software  was  also  used;
QEMM386.SYS,  DOSKEY,  and  K3  (a  keyboard  driver).  QEMM386.SYS  was
configured  with  OPTIMIZE and the "STACKS=0,0" command removed from the
CONFIG.SYS file. With no programs loaded, about 630k of memory was  free
for  DOS.  Later development used much the same configuration but with a
386dx, 40MHz machine with 8Mb of RAM.

Depending on the options configured in the  executable,  WNOS  needs  at
least  500k  of  free memory and a hard disk is recommended. WNOS can be
run using floppy disks as long as the machine  itself  is  fast  enough.
G6DHU  has  no  problems  running a full version of WNOS4 on a 386 16MHz
laptop using just the 1.44Mb floppy as filestore.  The  machine  running
WNOS  is  recommended  to  be  at  least  a  10Mhz 286. Slower machines,
particularly those with floppy drives only, will experience problems  in
busy  environments  when  long  disk  accesses are required. XT machines
equipped with V20 or V30 processors and at least an  8MHz  clock  should
also be able to run WNOS.










Display output is in  text  mode  only  with  the  extended  IBM  ASCIIZ
character  set  supported.  Even Hercules mono cards should be OK. Under
EGA/VGA display adapters it is possible to switch in a 43/50 line mode.


3.2.  WNOS Command Line Options

WNOS accepts command line parameters (options) at startup from  the  DOS
prompt.   Each parameter is identified by a hyphen "-" and a letter. The
value for that parameter should then follow, with no spaces in  between.
The options are;

     -e = WNOS switches into EGA/VGA 43/50 line mode at startup.
          At program exit, the original display mode is reset.
          In "shelling out" from WNOS, no check is made on the
          display mode to use or reset it on exit back to WNOS.

     -b = Instructs WNOS to use BIOS routines to do display
          output rather than the default, which is to write
          directly to display registers. This option is often
          useful when running under some multitaskers.

     -s = Sets the maximum number of sockets that WNOS can
          simultaneously have open. With all servers started,
          10 sockets will be active. The default is 40 sockets
          which should be sufficent in most cases.

     -d = Allows the WNOS file system to reside in a sub-
          directory off the root of the current disk. You are
          not allowed to specify a disk name in this option
          (eg F:).

A typical startup call to WNOS might be

      C:\> wnos -e -d/tcpip /startup/autoexec.wn4

This command line instructs WNOS to look for  its  file  system  in  the
directory  C:\TCPIP,  use  43/50  line  display mode and use the startup
configuration file C:\STARTUP\AUTOEXEC.WN4. If no  startup  filename  is
given  on  the command line, WNOS will look for the file AUTOEXEC.NOS in
the directory specified by the -d option or in the root if the -d option
is  not given. If no startup file can be found, an error message will be
given at program startup.

When WNOS is used for the first time, the routing save  files  will  not
yet  exist  and  the  error messages resulting from this may be ignored.
After a period of operation, these files will be  written  to  disk  and
read in again at the next startup.


3.3.  Operation At Startup

After startup, WNOS waits in command mode in the Command session window.
Input,  followed  by  a carriage Return, is taken to be a command and is
thus executed. Each line of input is saved in  a  buffer  which  can  be
perused  using the Cursor keys. If at the program prompt, a CR is typed,









and nothing else, the program does nothing, not even  a  new  prompt  is
given.  This  line  oriented  input  mode  is  sometimes  replaced  by a
character input mode. This is particularly so when logging into a remote
machine  where  a password must be typed. In this mode, input typed will
not be echoed to the screen. If the "---more---" prompt appears  on  the
screen,  then  character  based  input  is  also in operation. CR is not
needed after something is typed, as it will be read immediately. Hitting
the  Space  bar  normally  scrolls down the screen when the "---more---"
prompt is displayed.


4.  The Windows


4.1.  Window Selection

To switch between sessions, or from a session into the Command or  Trace
windows, the Escape or Function keys are used. This provides for quicker
and easier movement between each window. Peformance issues  necessitated
the  separation  of  the  Trace  and Command windows but the most useful
advantage gained, is that trace output no longer interrupts the  command
window.

The input buffer in each session remembers the last 10 commands or lines
of text typed in.

The following keys are used for session switching;

     F1 to F8      - Switch between sessions

     F9 or ALT-F10 - Switch to trace window, or toggle between
                     the Trace window and the last selected session.

     F10 and ESC   - Switch to Command window.


4.2.  Editing Options

Partially typed commands/input text may be edited  using  the  following
keys;

     Cursor Up   - Move backwards through command history

     Cursor Down - Move forwards through command history

     Control-B   - Recall last input line/command. Fills the
                   current line with the end of the last line
                   if it is longer.

     Control-W   - Delete last word in current line

     Control-U   - Delete the whole current line.













4.3.  Window Structure

After startup, the two status lines remain at the top of the  screen  in
all windows. The lines may be configured for use in colour or monochrome
displays via the "attribute" command.

The status lines in Command and Trace windows;

WNOS4 | Coreleft 50000 | Command |                    | | 17:43
1:DB0DA  2:R:44.131.20.3  3:U:DB0GV-2  4:Chat  5:LocBBS

The fields are as  follows;

WNOS4          - The Program Version

Coreleft 50000 - Free Memory Available

Command        - This is the Command window. "Trace" in that window.

"R"/"U"        - Record or Upload mode

17:43          - The time.

The lower line displays the summary status of each session.

1:DB0DA         - Outgoing AX.25 connect to DB0DA

2:R:44.131.20.3 - Incoming telnet seesion, Record mode in operation.

3:U:DB0GV-2     - Outgoing NET/ROM connection to DB0GV-2,
                  in upload mode.

4:Chat          - Chat session from the mailbox to the console.

5:LocBBS        - Connection to internal mailbox.

The current session is marked in colour on the lower status line  and  a
session  with incoming data still to be read is shown in another colour.
On mono systems, the status line entry flashes when new data arrives.

In the UK version of WNOS4, there  is  an  additional  field  after  the
"Command" or "Trace" icon, which shows either "Attended" or "Unattended"
according  to  the  setting  of  the  "attended"  command.  Should   the
"Coreleft"  value  drop  to a level defined by the "mem thresh" command,
the upper status will blink  and  "WNOS4"  is  replaced  by  "PANIC"  to
indicate impending doom!

On switching into a session, the upper status line changes character  to
display  information  about that session. The "coreleft" icon is removed
too.  The top session line shows infomation as follows  (Right  to  Left
across the line)...














4.3.1.  AX.25 Sessions

Retries = Retry Counter
Unack   = Unacknowledged frames
T1      = AX.25 T1 timer value
RNR     = If an RNR frame has been received
"R"/"U" = Record or Upload Mode active


4.3.2.  NET/ROM Level 4 Sessions

Retries = Retry (Level 4) Counter
Unack   = Unacknowledged (Level 4) frames
T1      = Round Trip Timer value
CHK     = If a Level 4 "choke" frame has been received
"R"/"U" = Record or Upload Mode active


4.3.3.  FTP-DATA Sessions

Rx      = Received Bytes
Tx      = Transmitted Bytes
RTT     = Round Trip Time


4.3.4.  TCP Sessions (FTP Command, Telnet, TTYLink etc)

Backoff = TCP "retry" status
TxQ     = Unacknowledged Bytes in send queue
RTT     = Round Trip Time
"R"/"U" = Record or Upload Mode active

Most windows operate in pseudo-split screen mode.  The  bottom  line  is
used  for text input and editing, while the upper portion shows incoming
and  outgoing  data.   Incoming   data   is   shown   in   a   different
colour/intensity from that sent.


5.  Files and Directories


5.1.  Files

The WNOS configuration files are  listed  below  in  alphabetical  order
together  with  the  pathname.  These  paths  are relative to the option
specified in the "-d" command line startup option. For example,  if  the
current  drive  is  C:   and  no -d option is given, the "alias" file is
expected to be C:\ALIAS.  If the startup option is "-d/tcpip", the  file
is expected to be C:\TCPIP\ALIAS.

Abbreviations below are;

F = File
D = Directory
B = Binary File
A = ASCII (text) file









/alias                   F/A - Mail Alias file
/autoexec.nos            F/A - WNOS Startup file
/arproute.dat            F/B - ARP statements (*)
/axroute.dat             F/B - AX.25 Routes (*)
/convers.cfg             F/A - Convers Cluster Autoconnect file
/domain.txt              F/A - Domain file
/finger/                 D   - Finger information directory
/ftpusers                F/A - FTP and Mailbox user Permissions
/iproute.dat             F/B - IP Routes (autosaved) (*)
/nos.rc                  F/A - FTP Auto Login data
/nrroute.dat             F/A - NET/ROM Saved routes (*)
/popusers                F/A - POP user and password file
/spool/                  D   - Mail and News root directory
     /areas              F/A - List of mail areas to forward
     /forward.bbs        F/A - Mail forwarding instructions
     /help/              D   - Mailbox Help file directory
     /history            F/A - Bulletin ID (BID) history file (*)
     /mail/              D   - User Mail files (eg g6dhu.txt)
     /mail.log           F/A - Mail In/Out logfile (*)
     /mqueue/            D   - Outgoing Mail Queue
     /news/              D   - NNTP (News) root directory
     /news/active        F/A - List of active Newsgroups (*)
     /news/history       F/A - NNTP Message ID history file (*)
     /news/help          F/A - NNTP Server Help File
     /news/junk          D   - Newsgroups for junking
     /news/pointer       F/A - Pointers to news storage directories (*)
     /news/poll          F/A - NNTP poll file (*)
     /news/x/news.rc     F/A - Last read news for each newsgroup (*)
     /news/xinfo         F/A - NNTP XINFO (site information) file
     /node.log           F/A - Mailbox activity log file (*)
     /rewrite            F/A - Mail Address Rewrite file
     /rqueue/            D   - Mail Router Queue
     /signatur/          D   - Mail 'signature' directory


(*) indicates file is automatically created by WNOS

Files such as autoexec.nos etc may use the hash  "#"  character  in  the
first  column of the line to denote a comment. Command parameters can be
separated with TAB or SPACE characters. In  the  domain.txt  file,  TABS
should be used to separate fields.


5.2.  Directory Structure

WNOS needs a defined directory structure in which to operate. This is;

     /FINGER
     /PUBLIC
     /SPOOL
     /SPOOL/HELP
     /SPOOL/MAIL
     /SPOOL/MQUEUE
     /SPOOL/NEWS
     /SPOOL/NEWS/JUNK
     /SPOOL/RQUEUE









     /SPOOL/SIGNATUR

If the  "-d"  command  line  option  is  used  at  startup,  then  these
directories must exist as subdirectories from the directory(s) specified
in  that  option.   For  example,  if  "-d/tcpip"  is  used,  then   the
directories must be /TCPIP/FINGER and so on.

Some files are created automatically by WNOS when running and  as  such,
the  first  startup  will  produce  some  error  messages in the command
window. It is recommended that WNOS be left  to  run  for  at  least  20
minutes so that these files can be created and organised properly.

The files above (not marked with a (*)) must be manually copied into the
directories indicated.


6.  Using WNOS

Here follows a short description as to how the sysop uses WNOS to  start
and use sessions and how a typical mailbox session could look.


6.1.  The Sysop's View

After all the indicated directories have  been  created  and  the  other
files  copied  to their proper places, the program can be started. First
come the copyright messages and then  the  command  prompt.  The  prompt
format  is  dependant  upon  the  setting  of the "hostname" command. If
"autoexec.nos" specified "hostname g6dhu.ampr.org", the  prompt  appears
like

g6dhu.ampr.org>

If no hostname is supplied

net>

will appear. In either case, WNOS is signalling  that  it  is  ready  to
accept  commands.  A  few seconds later, the status lines will appear at
the top of the screen and then probably a  few  error  messages  due  to
failure  of  the  program  in finding the autorouter save files. This is
normal for the  first startup.

Sessions can then be accepted and started. We assume that, for the  sake
of  example,  we have an AX.25 type 2m interface called "144" available.
So, to start a connection to DB0DA, we would type

g6dhu.ampr.org> c 144 db0da

If DB0DA is not within direct range, digipeaters can be specified  after
the destination callsign WITHOUT the word "via" needed. For example

g6dhu.ampr.org> c 144 db0da db0lj db0zdf












would connect to DB0DA using the DB0LJ  and  DB0ZDF  digipeaters.  After
pressing  the  return key, the display changes to the AX.25 type session
window with the appropriate status lines. The first line in  the  window
will show....

Trying DB0DA on 144...

Once the session is connected, the message "AX.25 session 1 connected to
DB0DA"  will  appear.  Commands and/or text can then be typed.  Pressing
Return moves the outgoing text to the top of the screen from the  bottom
'input'  line and the packet is then sent. The top status line will then
show how the session progresses. Incoming text is shown in  a  different
colour or in intensified text to that of outgoing text.

Pressing the ESC key will move  back  to  the  Command  window  and  the
session  continues  to operate without further intervention and any data
waiting to be sent, will be. If  new  data  arrives  in  a  session  not
currently  selected,  the  lower  status line icon for that session will
flash and will continue to do so until that session is selected.

Before a TCP session can be started, we must have an IP and an ARP route
for  the  destination. The IP route is used to determine which interface
the given host is reached over and, if necessary, the address of a  host
which will forward our packets to the destination. Therefore, it doesn't
matter which type of protocol is used to transport the TCP/IP  from  one
host  to  another. In our example, we only have an AX.25 type interface.
This means that we must use  ARP  to  tell  WNOS  which  AX.25  callsign
corresponds  to  the  IP address of the host we wish to reach. Let's say
that we wish to reach  the  host  dg8fbv.ampr.org  and  his  station  is
directly  reachable  over  AX.25 interface 144 and his AX.25 callsign is
DG8FBV-5. First add the IP route

g6dhu.ampr.org> route add dg8fbv 144

and then the ARP route

g6dhu.ampr.org> arp add dg8fbv ax25 dg8fbv-5

Note that Hostnames ARE  NOT  callsigns  and  vice  versa.  However,  in
AMPRNET hostnames are often correspond directly to callsigns.  The point
is that in the above statements, in both cases, "dg8fbv" is  a  hostname
which  gets  looked up to see what it's IP address is (in the domain.txt
file). So, "dg8fbv" is really a mnemonic by which  to  remember  his  IP
address. We could just have easily had typed

g6dhu.ampr.org> route add 44.130.20.3 144
g6dhu.ampr.org> arp   add 44.130.20.3 ax25 dg8fbv-5

instead. The domain file takes away the drudgery of having  to  remember
IP  addresses! the string "dg8fbv-5" is of course a callsign. Anyway, on
with WNOS......

Once IP and ARP routes are set, all we need  type  is  "telnet  dg8fbv".
Again,  the  display  changes  and  switches into a telnet type session.
After the AX.25 connection has been made, the TCP connection  starts  up
and much the same "Trying...." and "...connected to..." messages appear.









In most cases, telnet sessions will be  greeted  on  connection  with  a
welcome message and an invitation to login ie a "login:" prompt appears.
WNOS is no exception but other TCP/IP programs may be. You may also have
to type a password to gain access to the remote host.

To close sessions. you have 2 choices. Obviously, the first is  to  send
the  command  to  the  remote end that closes the connection eg "BYE" on
TheNode. The second is to switch back to the command window and type the
"close"  command.  In  both  cases,  the  session  is disconnected and a
message informing you of this fact will appear in that  session  window.
All  that  remains  to  be done is to press return to acknowledge it and
that is that! If you do not acknowledge the session closed  message,  it
remains in a 'limbo' state and takes up memory and the status line entry
and session window will not be cleared.

Users of the NOS software will already know its main advantage over  all
other  types  of  Packet  software  in  that  it  is  possible  to  have
simultaneous multiple sessions using different protocols.

WNOS also takes pride in being the first version of NOS that takes  real
note of the prevailing channel conditions and adjusts its use of channel
accordingly through its dynamic timers.


6.2.  The View From Outside

For most AX.25 users, their first encounter with WNOS  usually  ends  in
frustration!  On  connecting  to  the  system  using  AX.25,  a  connect
acknowledgement is given and then... nothing happens! Users  first  need
to  send a packet to the mailbox to wake it up (just hitting return will
do).  This comes about since the mailbox can be connected  to  by  three
different  protocols  (TCP, NET/ROM and AX.25) all of which use AX.25 at
the link layer. So, to tell it what protocol  is  being  used,  it  must
receive  a  packet with the PID bit set ie an information frame. This is
only the case in AX.25 connects since once the  link  layer  session  is
established NET/ROM and TCP will immediately send data and WNOS will see
the PID bit!

So, back to our example. An AX.25 user connects,  sends  the  "wake  up"
frame  and  he is then greeted by the WNOS mailbox. Since the mailbox is
also used by other mailboxes aswell as  users,  for  Store  and  Forward
(S&F),  most  of  the  preamble  information  serves  little purpose for
"human" users.

The S&F information is the first  line  ("[WNOS-H$]")  followed  by  the
hostname   "g6dhu.ampr.org   TCP/IP   System".   If   there  is  a  file
/spool/help/host.hlp, the  contents  of  this  file  will  appear  next,
otherwise  the short message "'?' for help." will appear instead so that
the user knows how to get help.  If a "message  of  the  day"  (see  the
"motd"  command)  is set, this will appear. At this point there may be a
short delay whilst the  mailbox  checks   whether  mail  is  waiting  or
present  for  this  user.  New mail for the user will be signalled then,
followed by the mailbox command prompt

(DB3FL) DB3FL de G6DHU>










or in the UK version

(Msg #1: DB3FL) DB3FL de G6DHU>

The mailbox prompt lends itself to the DieBox mailbox style which  shows
the  mail  area,  user  call and mailbox call. The UK version also keeps
track of the current message number. Mailbox informational messages such
as  "***  Connected  to", "*** Busy from" etc match those of the FlexNet
networking software and so this and other packet software (eg "SP")  can
recognise   a  standard  format  and  use  WNOS  nodes  as  autorouters.
Similarly, connections over NET/ROM  conform  to  that  style,  although
connections FROM a WNOS node require the use of the "nconnect" command.

Since we are connected to the mailbox, we can play with a few  commands.
Not  all  commands listed by '?' may be available, since each user has a
permission level defined in the /ftpusers file.

If there are messages to read, just a press of the Return key starts the
message  reader. If a specific message is to be read, the "read" command
is used. Read mail can be deleted from  the  mailbox  using  the  "kill"
command specifying which message to delete.

The list of files available for download can be listed with  the  "what"
command.  Text  files  can be downloaded with the "download" command and
binary files (programs etc) with the "du" command.

Connections to other stations can also be made  from  the  mailbox.  The
list  of  known  AX.25  autorouter paths can be determined by the "path"
command and these stations  can  be  connected  to  using  the  "connect
<call>"  command.   Other connections can be made using "connect <call>"
on the default interface or  with  "connect  <iface>  <call>"  on  other
interfaces.

The sysop can be contacted by using the "c" or "chat" commands.

Connections started using the "connect" command can be  disconnected  at
any  time  by sending the "escape" character (Control-X by default). The
mailbox can be disconnected  through  the  "b",  "bye",  "q"  or  "quit"
commands.


7.  Short Descriptions of the Important Protocols

This is  a  brief  overview  of  the  terminology  and  purpose  of  the
networking protocols that WNOS uses.


7.1.  ARP (The Address Resolution Protocol)

This simple protocol is used  to  determine  which  link  layer  address
corresponds  to  an  IP address. The link layers used by WNOS are either
AX.25 or Ethernet. An AX.25 address is better known  as  a  callsign  eg
G6DHU-3  plus  SSID.  It is not often used in full in WNOS since the ARP
table is there to provide immediately, the lookup between IP address and
link  layer  address.  If however, the desired link layer address is not
found in the ARP table, before the  IP  frame  can  be  sent,  ARP  must









discover the link layer address itself. This it does by  sending  out  a
special  "broadcast" which is listened to by all TCP/IP capable software
(on AX.25 the broadcast address is "QST").  The broadcast basically says
"Hello,  I'm  44.131.20.3  and I live at link layer address G6DHU-5, I'm
looking for 44.131.20.4, tell me your link layer  address".  Any  TCP/IP
system  hearing  this broadcast examines the "I'm looking for <address>"
field and if it matches its IP address, it sends back a reply  broadcast
filling   in the missing information. At that point, the machine sending
the initial request makes a temporary addition to it's ARP table  noting
the information it got. In other words, an internal "arp add" command is
executed. As soon as this procedure is complete,  the  TCP  session  can
start.


7.2.  AX.25 (Amateur X.25 Protocol)

AX.25 is a  basic  version  of  the  more  complicated  commercial  X.25
protocol  cut down for use in the Packet Radio environment. The protocol
supports  point-to-point  connections  in  which  each  sent  frame   is
acknowledged  as arriving OK by the receiving end, thus ensuring that no
data is lost  (in  network  jargon  -  a  reliable  connection  oriented
protocol).   Digipeaters   may   also   be   used   to  forward  packets
unconditionally.

Features implemented by WNOS such as hop-to-hop  acknowlegement  or  the
AX.25  autorouter  are  NOT  an extension of the AX.25 protocol. Rather,
these are ways of implementing the protocol in different ways to provide
certain advantages.


7.3.  IP (The Internet Protocol)

IP is responsible for routing and packet switching functions  for  upper
layer  protocols,  usually TCP. An IP frame header is made up of amongst
other things, the source and destination IP addresses  aswell  as  other
control information.


7.4.  IPCAM (Internet Protocol CAMouflage)

IPCAM is not really a Protocol as such. IPCAM allows  IP  frames  to  be
transported  across  different and mixed protocols. It is only currently
implemented for use upon AX.25 link layers.  Rather  than  send  the  IP
frame  with  an AX.25 PID (Protocol IDentifier) of "IP", it is sent with
an PID of "Text". It is this feature that makes it  particularly  useful
since  some  AX.25  systems  may  not  support,  recognise  or purposely
disallow processing of frames with PID="IP". Using IPCAM  allows  TCP/IP
to be used on such networks.


7.5.  ICMP (The Internet Control Message Protocol)

This protocol is used to  provide  TCP/IP  hosts  with  error  handling,
congestion  control  or  resolution and general diagnostic functions and
services.










7.6.  TCP (The Transmission Control Protocol)

TCP is responsible for the logical connection between two  TCP/IP  hosts
and  uses  IP  for its routing functions. Most importantly it provides a
reliable stream based connection  and  ensures  that  data  reaches  the
remote host without error and for acknowledging receipt of data from the
remote host.

All of the following protocols are applications (services) which use TCP
for the Transport (Level 4) layer and IP at the Network (Level 3) layer.


7.6.1.  Telnet

Is a simple protocol which allows remote login to another  host  running
TCP/IP.  It  can  be  thought  of  as the TCP/IP equivalent of a TNC-TNC
connect using AX.25.


7.6.2.  FTP (The File Transfer Protocol)

FTP allows files (both text and binary) to be transferred from one  host
to  another.  It  is  also responsible for ensuring that the transfer is
succesfully completed.


7.6.3.  SMTP (The Simple Mail Transfer Protocol)

SMTP provides an electronic mail facility  between  hosts.  It  has  the
capability  to  route  mail  from one host to another, for delivery to a
user at the local  host  and  sending  locally  generated  mail  to  its
destination.


7.6.4.  NNTP (The Network News Transfer Protocol)

NNTP provides a service  for  the  posting  and  distribution  of  News.
Whereas  SMTP  is used to handle personal mail, news handles 'broadcast'
messages.  News is divided into newsgroups, each with a  specific  topic
of   interest.   For   interest,  the  Usenet  news  hierarchy  contains
newsgroups;

rec.radio.amateur.misc   - Miscellaneous amatuer radio discussion
rec.radio.amateur.packet - The Packet Radio newsgroup
comp.binaries.ibm.pc     - Latest IBM PC software
rec.humour.funny         - Jokes
etc etc

The hierarchy names represent  the  broad  divisions  of  interest.  For
example  rec.*  newsgroups  are the Recreational newsgroups, comp.*, the
Computer newsgroups etc. There are lots more of these.

NNTP is the analogue of the mailbox Store  and  Forward  network,  where
news articles are referred to as bulletins.











7.6.5.  POP (The Post Office Protocol)

POP allows storage and collection of mail destined for a  host  that  is
not  always  in  operation.  Mail for such hosts is kept on file until a
host comes on line, connects to the POP server and asks  for  its  mail.
It  is  useful  for AMPRNET TCP/IP stations who are not on air 24hours a
day.


7.7.  UDP (The User Datagram Protocol)

This is also a Transport layer (level 4) protocol like TCP but  is  much
simpler  and  does not guarantee a reliable transfer of data from end to
end. Receipt of a UDP frame is not acknowledged as in  TCP.  The  domain
server uses UDP.