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

Text File | 1992-04-04 | 54KB | 1,496 lines

              DB3FL WAMPES NOS (WNOS) Version 3 User Guide


                           Mike Chace (G6DHU)

                   Document Version 1.4 (April 1992)


       WNOS3 is a new "hybrid"  NOS  and  combines  functionality
       from  KA9Q,  G1EMM,  and PA0GRI NOS with a AX.25 front-end
       derived from the German WAMPES system.

       It  features  Data  Compression,  a  more  friendly   User
       Interface  and  Mailbox,  AX.25 Autorouter and a Chat node
       that can  be  used  to  connect  IP  hosts  together  like
       PacketCluster.

       WNOS supports the usual range of TNC drivers (KISS,  DRSI,
       SCC etc) as well as all the well established TCP services;
       Telnet, FTP, POP, SMTP, NNTP, and TTYlink. It has no  need
       for RSPF and RIP since the WAMPES front-end deals with the
       auto-routing.  WNOS   periodically   saves   all   routing
       information  (IP, ARP and AX.25) to all known hosts making
       it a truly dynamic system.

       This manual is a guide to the new features in WNOS  mainly
       designed  for  users  of other NOS versions (G1EMM, PA0GRI
       etc) who might be trying WNOS  for  the  first  time.  You
       should  also  have  received  a  copy of the WNOS3 command
       reference with the UK release package.

       THIS DOCUMENT *MUST* BE INCLUDED IN ANY COPY YOU  MAKE  OF
       WNOS AND GIVE TO SOMEONE ELSE.



























1.  What's New in WNOS3 ?


1.1.  The User Interface


1.1.1.  The Status Line

Perhaps the first thing that you'll notice after loading  WNOS3  is  the
command screen.

The top line of the screen is permanently occupied by the  Status  Line.
The  line  can be configured for either colour or mono displays (see the
"attribute" command).

In use, the status line will look something like this


WNOS3 | 22:02 | CMD | 1:R:U:GB7IMB-2  2:g4wrw  3:R:44.131.17.11  4:Chat

  A       B      C         D             E            F            G

     A) Is the Program Name

     B) Is the current time

     C) Shows the program "mode"

          CMD    = Command mode (at the program prompt)
          TRA    = Trace Screen
          *      = Session mode

     D) Shows session 1 status. Upper case denotes a session  to  either
     an AX.25 station or a NET/ROM host (in this case GB7IMB-2).

     The "R" denotes that the  session  is  in  "record"  mode,  copying
     session input and output to a file.

     The "U" denotes that the session is in "upload" mode and a file  is
     being sent to GB7IMB-2.

     E) Denotes an TCP/IP based connection to a host. TCP/IP  hosts  are
     always displayed in lower case.

     F) Session 3 is connected to TCP/IP host  on  address  44.131.17.11
     and is in "record" mode.

     G) Session 4 is a local Chat session (someone typed "chat" from the
     mailbox).  IP  Stations telnet'ed/ttylink'ed to your Chat port (TCP
     port 87) don't display as "Chat", instead the address  of  that  IP
     station is shown.

Connections to you local bbs (that is, you typed "bbs"  at  the  program
prompt) are shown in the same format and are marked as LocBBS.











1.1.2.  The Program Prompt

Instead of the old net> prompt, WNOS3 displays you hostname eg.

g6dhu.ampr.org>


1.1.3.  Moving Between Sessions

WNOS3 differs from all previous version of NOS in  that  moving  between
sessions is now accomplished through use of the Function keys....

     F1 to F8 : Select sessions 1 through to 8
     F9       : Toggles between the "Trace" screen
                and the last selected screen (session or command)
     F10      : Return to Command Mode
     ESCAPE   : Return to Command Mode (See the "escape" command
     ALT+F10  : Select the Trace screen - No Toggling.

The use of the return key is two fold depending on whether  you  are  in
the Trace or the Command screen.

     ENTER    : From Command Mode     - Switches into the last  selected
     session
     ENTER    : From the Trace Screen - Switches into the last  selected
     session

Please note that in command mode,  with  no  active  sessions,  pressing
ENTER  will have NO EFFECT. It's a bit disconcerting at first but you'll
get used to it.

All trace output goes into the Trace Screen  (selected  by  F9).  It  no
longer scribbles over sessions or the command display.


1.1.4.  Editing Characters

The following special keys can be used to edit or redisplay input either
to a session or at the prompt.

     Control-B  : Fill rest of command line upto end
                  of last input (see below)
     Control-R  : Recalls the previous (complete) line
     Control-U  : Kills the current line
     Control-W  : Deletes the previous word in the current line
     Up-Arrow   : Scrolls backwards through past input
     Down-Arrow : Scrolls forwards through past input

Control-B needs an example. Say the last (valid) command you  typed  was
'tcp  status'. If you then begin to type a new line and press Control-B,
the rest of the previous line is added to the new one.

     g6dhu.ampr.org> tcp status
     <output from command>
     g6dhu.ampr.org> ax2 <type Control-B>










     gives the input line

     g6dhu.ampr.org>ax2 status

Input history is kept separate for each session and the command window.


1.1.5.  Session Notification

The status line session summary (eg 2:g4wrw) will blink if that  session
receives  incoming data and will continue to do so until you select that
session. Once you close session, the status line summary will be deleted
and all other summaries move one to the left.

Sessions closed by the remote end will of course  remain  (blinking)  on
the  status  line  until  you  look  at  them. This is a useful feature,
allowing someone to drop you a quick message, which you won't lose!

Incoming connections to your 'Chat' port will ring a "bell" to alert you
to  the  fact that someone wishes to chat to you. This happens according
to the setting of  the  "bell"  command  and  whether  or  not  you  are
"attended" (see below).

Input to sessions of type Telnet, Chat, Convers, AX.25 and NET/ROM is in
a  pseudo  "split  screen" mode. The text you type ALWAYS appears at the
bottom of the screen and allows the other persons text to appear as  you
are preparing that line. Your text is shown in "normal" (light) text and
that from the remote end in "intensified" (bright) text. You can use the
cursor  (up and down arrow keys) to recall past input and scroll through
it whilst preparing outgoing text.

On selecting a session, you  are  taken  into  that  session's  "window"
(which  holds its own, separate input history) and the Status Line entry
for the current session is shown in "normal" text (white on black).  The
other,  unselected  Status Line session entries remain in "inverse" text
(Black on white)


1.1.5.1.  Colour Displays

The above discussion holds on Mono displays (set "attribute mono").   On
Colour displays (set "attribute col") Status line columns A, B and C are
shown in Red.

Further columns (session indicators) are shown in Blue. The  arrival  of
new  data  to an unselected session is indicated by it having an inverse
Grey bar.

The current session is in yellow text upon a Blue background, all  other
sessions are shown in Grey text upon a Blue background.

Another feature unique to WNOS3 is that automatic wrapping  of  outgoing
text  is  enabled  in sessions. You can specify a line length limit (see
the "wrap" command), if you type beyond this limit, the next space  will
force  the  line  to be transmitted and the rest of your input line over
the line length limit is put at the start of the next line.  This  means









that you don't have to think about pressing return all the time  as  you
near  the  end  of a line. WNOS detects when you have reached the end of
the  line  and  sends  that  text  out  without  intervention.  It  also
eliminates  a  messy screen at the remote end of the link where lines go
over the 80th column.


1.2.  The Auto-Router

One of the other major changes to WNOS3 is that the NOS AX.25  front-end
has  been  replaced  by  that  from the German WAMPES system. The WAMPES
front-end allows full AX.25  auto-routing  as  well  as  saving  of  all
routing  information  (IP,  ARP  and  AX.25  routes)  to disk at regular
intervals.

Unfortunately, the AX.25 auto-router is only of real use in IP  networks
where  nodes  are directly connected. By this is I mean that other hosts
are reachable through a direct AX.25 connection (VC or datagram mode) or
using  AX.25 across a digipeated path. This is because the WAMPES system
was primarily designed to work with  FlexNet,  a  networking  system  in
widespread  use throughout Europe (but not in the UK hihi). FlexNet is a
fast system with 1200bps and  9600bps  user  access  ports  and  9600bps
backbone  links and works on the principle of fixed routes between nodes
using hop-to-hop acknowledgements (looks like normal digipeating to  end
users).

The auto-router is however still useful over here in  the  UK.  See  the
"ax25  route"  commands  in  the  Command  Summary  for  details  of the
autorouter.


1.2.1.  Using the Auto router

I should also note that the  AX.25  auto  router  can  also  auto  route
digipeated  packets thereby allowing very effective crossband operation.
For example, let's imagine that a  WNOS3  node  local  to  you  has  two
interfaces  one  on 70cm and the other on 2m. That system will of course
get to know the AX.25 paths to stations on both interfaces. You can then
set  up  connections via the local node which enter on one frequency and
get digipeated on the other. For instance, I have a  local  WNOS3  node,
G4OTJ-2 which has a 70cm and 2m interface. G4OTJ-2 knows that there is a
path to the KA-node G1WQU-8 on 70cm. If I am on 2m, I can reach  G1WQU-8
without knowing how the crossband connection (and if there are any digis
involved) is made simply by using the connect command

g6dhu.ampr.org> connect 144 g1wqu-8 g4otj-2

So I send a connect request to G1WQU-8 via G4OTJ-2 and the autorouter at
G4OTJ-2  works  out  how  to  get  to  G1WQU-8! And, of course, since my
autorouter will now have stored the path to G1WQU-8,  the  next  time  I
want to connect to that station, all I need type is

g6dhu.ampr.org> connect g1wqu-8












WNOS3 does away with the need for you to remember how to get  to  places
and lets the software do it all automatically.

As you can see, it makes for a very powerful and flexible  system.   For
further details see the "ax25 digipeat" command.


1.3.  Dynamic Route Save

Each time an IP frame is processed  by  an  WNOS3  system,  the  machine
records the following information in it's various routing tables

1) An IP route entry
2) An ARP entry
3) An AX.25 Path entry (if the IP frame arrived via AX.25)

The system therefore dynamically alters  its  knowledge  of  routing  to
other IP hosts and records ALL information necessary to reach that host.
For instance, if a node normally reaching you  via  NET/ROM  manages  to
deliver  a  frame via direct AX.25 and say over your UHF rather than VHF
interface, your system has saved all this information and can alter  its
return path in response. Other NOS systems will not be able to do so!

Each of the routing tables dynamically written to are  saved to disk  at
regular  intervals  (see  the  'route  save', 'ax25 route save' and 'arp
save' commands). These files are then read from disk the next  time  you
start up and so you never lose this routing information.


1.4.  Compression

WNOS3 is unique in that it is the first NOS variant to make use of a NOS
feature  that  has  long  existed,  but  never  been  used before - data
compression.

In the present release, both e-mail and telnet based sessions (eg  chat)
have the ability to send and receive compressed data using a method that
is completely transparent to the users. It is also  backward  comaptible
with non-compressed systems so if you're the only one using WNOS3 you'll
still be able to everything you did before.

WNOS3 uses the LZW (Lempel-Ziv) data compression method which is used to
"squash"  text data using LZW coding before it is sent out over the air.
Since text contains a lot of  redundant  infomation  such  as  tabs  and
spaces LZW can often compress data to upto 40% of its original size. The
basic advantages are obvious - you send less real  data  which  improves
performance where it's most felt (across a slow RF link) and you're also
thereby doing the network a favour by reducing traffic. Obviously, there
is  a  slight penalty in performace at each end of the link in unpacking
the data and converting it back into human-readable  text  but  that  is
small in comparison with the time it takes to send the data out over the
air.

Line-by-line protocols such as telnet are compressed when you press  the
return  key  at the end of the line and then sent out to the remote end.
Message (file) based protocols such as SMTP negotiate with the other end









of the link to see if it will accept compressed mail. If you "trace"  an
outgoing  SMTP  session, you will see that the machines greet each other
in the usual way but a sending WNOS node  will  then  send  the  command
"XLZW".  If the other end is also a WNOS3 node it responds with "250 Ok"
and the mail (and any subsequent commands  eg  QUIT)  are  sent  out  in
compressed  form.   On completing the mail transfer, the remote end will
then uncompress the mail before writing it to the  appropriate  mailbox.
Should  the  remote end not be a WNOS3 node, it will respond to the XLZW
command with "550 Command Unrecognised" and the sending end will forward
mail as normal.

LZW compression is a mainly experimental feature in WNOS3 and  may  well
be extended to NNTP, POP and convers for example if it found useful.  If
you find it so please drop me or Mike, DB3FL, a line. I think  it  is  a
great  step forward and should prove useful on marginal links, of which,
there are (let's face it) plenty in the UK.


1.5.  Convers Node and Cluster Mode


1.5.1.  What Is a Convers Node ?

The convers (pronounced like converse)  node  is  much  like  the  G8BPQ
"CHAT" system or TheNet Mini-Convers and allows round-table QSOs between
a number of users connected to it. If you've  never  used  a  Chat  node
before, it's best imagined in the following way.

You and your fellow hams all connect to the convers node. On connecting,
you  are asked to login so that the system knows your name (or callsign)
and can then send messages to you. The convers  node  has  a  number  of
"channels" to which 1, 2 or more people can be connected, talking either
to each other as a group or sending private messages to each  other.  So
you  can  think of it as a multi-user "conferencing" system. You can QSY
to other channels if you want a simple private conversation with another
person and other users can invite you into the "net" on their channel.

The convers node software handles all the conversations on each  channel
independently and sends the conversation(s) out to each user connected.


1.5.2.  The WNOS Convers System

WNOS3 supports two distinct convers modes which I'll refer to  from  now
on  as "local" and "cluster" mode. I'll cover basic use of the system in
the section on local access below. The behaviour  under  Cluster  access
being exactly the same.

To enable your convers server you must put the line

                             start convers

somewhere in your autoexec.nos file.












1.5.2.1.  Local Mode

Any WNOS3 system can enable it's own internal convers node  (or  server)
(see  the "start convers" command). The convers server lives on TCP port
number 3600.

Your local convers server can be accessed in two ways...

     1) Remote users telnet to your port  3600  (ie  they  type  'telnet
     g6dhu 3600')
     2) Remote users (including AX.25 users) can type 'convers' at  your
     mailbox
        prompt.

You can of course login to your local server by typing (for example)
        g4otj.ampr.org> telnet g4otj 3600

Users connecting from the mailbox get told to login  using  the  convers
"/N <name>" command but if you login locally by telnet you'll need to do
this before the server will respond and you will then  get  the  convers
login banner.

Once logged in, you can use the / commands (see /HELP or /H) for help to
inquire about the state of the system, who is logged in etc.

Private messages to a named user are  sent  using  the  /MSG  or  /WRITE
commands (for example)...

/M john Hi there John, Just noticed you login!

Anything that you type without a / command will be  sent  to  all  users
logged  into   your  channel  (change  channels  with the /CHANNEL or /C
command).

Chatter from your channel is sent to you like this

<john>: Did you see that there is a new TCP/IP user in the area ?
<dave>: No, What's his callsign ?
<mike>: I think it's G6DHU
<dave>: No it isn't, it's G4WRW
<*pete*>: Who cares ?

          etc

Notice that text directed to everybody on your channel has the ID of the
person who sent it eg <mike> (So that user logged in with (/n mike).

See also that user "pete" (the cynical one!) sent me a private   message
(not  seen by anyone else on the channel) indicated by the asterisks "*"
surrounding his user name.


1.5.2.2.  Convers Cluster Mode












That last discussion took as its example convers users ALL  logged  into
the  convers  server  running  on  YOUR  machine. As I mentioned before,
TCP/IP users can do this either by telnetting  to  your  port  3600  and
AX.25  Level  2 users can connect by typing the "convers" command whilst
logged into your mailbox.

WNOS3 has another very useful feature in  which  convers  servers  on  a
number  of  WNOS3 nodes can be connected together. This brings about the
possibility of  a  distributed  conference  system  much  like  TALK  or
CONFERENCE as found in the PacketCluster system. This then enables users
logged in on one machine to  transparently  join  in  conversation  with
other  convers  users  who  are  logged  on  at a different machine. The
convers servers on each WNOS3  node  talk  to  each  other  passing  the
various messages back and forth.

To enable cluster mode, each WNOS3 node must set up a file in  the  WNOS
root  directory  (ie  in the same place as the FTPUSERS file). This file
called "convers.cfg" identifies the name  of  your  convers  server  and
defines  the other convers servers you which to connect in cluster with.
PLEASE note that cluster servers **MUST** connect  in  a  "daisy  chain"
otherwise  messages  just  "ping-pong" back and forth, growing each time
and probably resulting in network collapse. By  "daisy  chain",  I  mean
that  if,  for  instance,  you wish to interconnect 4 machines, the most
sensible configuration would be

                    g4wrw -> g4otj -> g0lxc -> g6dhu

so each machine connects to the next down the chain. All you need to  do
is decide the network and AVOID ROUTING LOOPS AT ALL COST!

The format of convers.cfg is as follows

          <your_host_name>
          <remote_host_name> telnet|ax25|netrom
          <remote_host_name> telnet|ax25|netrom
          etc

<your_host_name> is the name of your machine eg  g6dhu.  You  can  enter
names of any length but only the first 8 characters are used.

<remote_host_name> is the name of the  machine  to  connect  to.  Again,
typically you would use the domain name of a remote machine eg g4wrw.

With each remote host you must specify the protocol used to  communicate
with  that  machine's  convers  server, either telnet, AX.25 or NET/ROM.
**Please note*** that only telnet method is currently  supported,  AX.25
and  NET/ROM  are  likely  to  be added later. Please note that "telnet"
means the protocol to be used and that telnet connection can  of  course
be carried by AX.25 datagrams, virtual circuits or NET/ROM just the same
as any other telnet connection. AX.25 and NET/ROM connect  methods  will
use  those protocols to send the convers messages (and therefore not use
TCP).

Example convers.cfg files for the above example cluster would be

At g6dhu  -  None needed (end node)









At g4otj  -  g4otj
             g0lxc telnet

Obviously more complicated networks  will  require  more  "remote  host"
entries. Imagine a star network for example.

On starting WNOS, the machine will read the  convers  startup  file  and
auto-connect  to  the remote machines specified in the file. No operator
intervention is needed. Once the connections are set up down  the  chain
all users can talk to each other. For instance, an AX.25 user could have
connected to g6dhu's mailbox, typed "convers" and be talking to  someone
logged on all the way down the chain at g4wrw.

You can inquire on the state of  cluster  links  to  other  machines  by
logging  into  your  local  convers  server and using the /LINKS (/L for
short) command.


1.6.  A New Mailbox Interface

WNOS has a re-arranged mailbox interface. The most notable  changes  are
that  the prompts are more informative and the "psuedo" NET/ROM node has
also been remodelled.

On logging into the mailbox, users will see the following...

[WNOS3-XH$]
g6dhu.ampr.org TCP/IP system.
Welcome to the G6DHU TCP/IP Mailbox!

The Escape Character is Control-X

Type C to Chat, ? for Command List, and 'S mike' to mail me

You have 1 message

(G6DHU) G6DHU de G6DHU>

Note first of all that the mailbox SID banner [WNOS3-XH$] now sports the
X flag to denote that it is capable of forwarding BBS mail in compressed
format (to compatible boxes).

The second line (fixed in the program) just announces your  hostname  to
others.  The  third,  fourth  and  fifth  lines  are the contents of the
following command strings or files

motd (Message Of The Day)  =  Welcome to the G6DHU TCP/IP Mailbox!

host.hlp                   =  The Escape Character is Control-X

mbox motd                  =  Type C to Chat,... etc

The first and third of those above are standard (derived from the  G1EMM
version of NOS) commands to set the "Messages of the day". The second is
a new feature whereby special messages for the mailbox can be  specified
in  file called "host.hlp" (see the Command Summary). If host.hlp is not









present, the program just sends the short string

     ? for Help

The final two lines of mailbox login text are of, a mail flag to show if
you  have  any  mail  waiting for you to read and of course, the mailbox
prompt. The prompt shows the following information

        (G6XYZ) G6XYZ de G6DHU>
           |      |        |
           |      |        Mailbox Callsign
           |      User Callsign
           Current Mail "area"

As expected, if the user changes mail area with the "area"  command  (eg
"area tcpip"), the prompt is updated to show (TCPIP) in the first prompt
field.


1.6.1.  Mailbox Commands

This is the output from a ? request to the mailbox (short for HELP!!!).

(G6DHU) G6DHU de G6DHU> ?

Available commands:
               area           bye            connect        chat
convers        download       escape         finger         help
info           kill           list           mheard         nodes
nconnect       path           quit           read           send
telnet         user           upload         what           ?

(G6DHU) G6DHU de G6DHU>

As I mentioned before, perhaps the  most  obvious  change  is  that  the
NET/ROM  node  is  now  longer  a  separate part of the mailbox. All its
commands are available directly at  the  mailbox  command  line.  Typing
"nodes"  will  show  you  a  list  of  NET/ROM nodes known locally and a
NET/ROM connection can be made by typing "nconnect <nodecall>".

Other new things are the "path" command which displays a list  of  known
autorouter  paths,  or  if  a  callsign  is  given too, the path to that
destination. As you might expect, users can just type  "connect  <call>"
to  reach  an  autorouted destination. Digipeaters and interfaces are no
longer needed. A minor change is the  "mheard"  command  which,  as  you
would expect shows the monitor heard list from your system.

Users returning from outbound connections are  always  returned  to  the
node on disconnection and are informed of this. For example

(G6DHU) G6DHU de G6DHU>convers
*** connected to 44.131.20.3:convers
conversd @ g6dhu $WNOS_Rev: A.2.17 $  Type /HELP for help.
/q

*** reconnected to G6DHU









(G6DHU) G6DHU de G6DHU>

In that case a user connected to the cluster and then quitted  from  it.
The  same  TNC-like  connect  message  is  sent  when  an  AX.25 (raw or
autorouted) or NET/ROM connect is made. It should  at  least  make  non-
TCP/IP users a little less frightened of the technology!

The usual help scheme as found in other NOS  version  is  included.  "?"
will  give the command list (as demonstrated above) and detailed help is
available by typing "h <command>" where <command> would  be  "path"  for
instance. These help files live in the usual place (spool/help/*.hlp).


1.6.1.1.  Mailbox Timers

The WNOS3 mailbox will disconnect a user after a  period  of  inactivity
equal to the value you set for the ax25 t3 timer. For instance, "ax25 t3
180" sets the link inactivity timeout to 3 minutes (180 seconds) and  on
logging in, users will see the extra message

Inactivity Timeout is 3 mins

(G6XYZ) G6XYZ de G6DHU>

The timeout is also dependent as to whether or not  the  link  timer  is
active  (see  the "ax25 t3disc" command). Users connected to the mailbox
via telnet (TCP port 23) do not receive this treatment.


1.6.1.2.  Remote Sysop Mode

This has changed substantially in WNOS3. Remote sysop is useful if WNOS3
is running on a remote computer say on a hill-top site.

A password number key is entered (by  the  autoexec.nos  file)  via  the
"sysop"  command.  A  mailbox user wishing to login as remote sysop must
firstly have the correct FTPUSERs  "sysop"  permission  bit  set  before
using the mailbox "@" command.

Entry is gained in the following manner (the  pass  number  key  is  say
"sysop 12345").

1. Type @ at the mailbox prompt

2. The mailbox responds with 3 groups of 5 numbers in the prompt

89076, 77613, 11680>

3. The intended remote sysop must then calculate the password
   according to the following formula.

   Pass number = (Any number in first column  * 1st number in key) +
                 (Any number in second column * 2nd number in key) +
                 (Any number in third column  * 3rd number in key) +
                 (Any number in fourth column * 4th number in key) +
                 (Any number in fifth column  * 5th number in key)









   Eg (8 * 1) + (9 * 2) + (6 * 3) + (1 * 4) + (0 * 5) = 48

4. Type the password and you should be logged in

89076, 77613, 11680> 48
Net>


Successful login as sysop give you the  remote  sysop  prompt  as  shown
above.  Yes,  yes,  I  know  it's  complicated but it's also *extremely*
difficult to break the key.


1.6.1.3.  Mailbox Message Scrolling

By setting the "mbox more" command to "yes" you can  enable  a  function
which  passes  mail messages to users on a page by page basis, prompting
for more (or a quit) and the end of each  screenful.  This  function  is
only  active for users connecting to the mailbox via TCP (telnet to port
23).


1.6.1.4.  Mail Signature

It is common Internet style that most mail messages  end  with  a  short
'signature' which gives details such as the senders home address, e-mail
address etc. WNOS can automatically add this signature to  mail  entered
into the system from the local bbs (the "bbs" command).

The signature  lives  in  a  file  called  <call>.sig  situated  in  the
spool\signatur\  directory.  The  file  SETUP.EXE  contains  an  example
signature file (G6DHU.SIG) - the one I use here on my  system.  Remember
to  keep  it  short  and free of fancy graphics! Fancy graphics may look
great when viewed on the same type  of  machine  from  which  they  were
entered but display as meaningless crud on other systems!

Please note that the signature is only added to the end of messages that
are  entered  interactively  into  the  bbs  and not if an external mail
program (eg PCElm) is used. These programs add a signature file of their
own which usually is called something else and lives in another place!


1.7.  The Not-So-Obvious Improvements

In this section I'll outline some of  the  improvements  in  WNOS3  over
other NOS versions or WNOS2 and any consequent changes in syntax. Please
refer to the Command Summary chapter for details of command syntax etc.


1.7.1.  New AX.25 Features

Since the old NOS AX.25 front-end has been stripped out and replaced  by
the WAMPES autorouter there have been some changes to ax25 parameters.












The AX.25 retransmission timer (ax25  t1)  is  now  dynamically  set  by
measuring the round trip time of the connection. WNOS3 measures the time
it takes to get an ACKnowledgement (RR) packet  back  after  sending  an
information  (I)  frame,  this time is known as the RTT. If this time is
recorded for a few sucessive packets, the value  can  be  smoothed  over
time  to  produce the SRTT (Smoothed Round Trip Time) of the connection.
WNOS3 sets the T1 timer to this  value  and  adjusts  it  as  conditions
change  and  a  new SRTT emerges.  The result should be a more efficient
connection.

MAXFRAME (ax25 maxframe) is now also dynamically set. The initial  value
is  set  to  the  value  specified  in  the "ax25 maxframe" command. The
connection starts with this value and adjusts it by watching the  number
of  frames  that are ACKnowledged by the remote end. For example, if you
set a maxframe of 6 and your node has enough  traffic  queued,  it  will
send  out  a  string  of  6  sucessive  I-frames.  Your  node  now has 6
outstanding (that means unacknowledged) frames. If, on  hearing  the  RR
(ACK)  from  the  remote  end, it only acknowledges 3 packets, WNOS will
drop the maxframe to this value since it guesses (it's a sensible  guess
too) that 3 of the 6 frames sent were lost. As you can probably see from
this, if you kept a maxframe  of  6  you  would  be  wasting  time  with
retransmitting  3  out  of  every  6  I  frames which is inefficient and
needlessly hogs the channel with data that is wasted.

WNOS  actually  implements  dynamic  maxframe  by  firstly  setting  the
maxframe  to  that  specified  by the "ax25 maxframe" command. After the
AX.25 T1 timer times out, maxframe is set to 1 and increased every  time
if sent frames are ACK'ed within the lifetime of T1.

WNOS can resequence out of sequence packets. It quite often happens that
stations  can  send  you  data  packets  that  are  out of sequence. For
example, you were expecting frames 1, 2 and 3 but you got 1,  3  and  4.
Normally,  most  software  will  dump  all  but  the  first  packet  and
acknowledge it even if number 4 arrives quickly after. WNOS will hold 1,
3  and  4  for a time determined by the reassembly timer (ax25 t5) so if
packet number 2 arrives before T5 times out, it can reassemble them  all
(1, 2, 3 and 4) and acknowledge all 4. Again, this increases efficiency.

WNOS can do hop-to-hop acknowledgement.  On  a  marginal  link  using  a
digipeater,  it  is often more efficient to have both halves (or all) of
the link operating in hop-to-hop acknowledgement mode. This  means  that
if,  for  example, someone digipeats via you, instead of digipeating the
packets on, your node opens a connection to the desired  destination  to
pass the packets on. Packets are therefore being passed using hop-to-hop
acknowledgement  rather  than  digipeating.  Again,  this  can  increase
effeciency  and  throughput  on marginal links (see that "ax25 digipeat"
command)

WNOS concatenates short frames. If, for instance, you type 3 short lines
(ie they total less than "ax25 paclen" in length), WNOS will concatenate
these packets and send them as one packet. A useful idea on a good link.














1.7.2.  Memory Management

The old 'NOS provided' memory management routines have been replaced  by
those  provided  by  the  Borland BCC (C++) compiler. The result is that
memory doesn't suffer from the sort of downward spiral  always  seen  in
previous NOS versions.

If your system suffers heavy useage, the  memory  will  of  course  drop
since  each new connection opened requires memory to hold various pieces
of information needed (the Control Blocks). After these connections  are
closed  (and/or  at  regular intervals) the system will check the memory
for "holes" where memory has been freed but is  too  small  to  be  used
usefully  by  something else. All these holes are then gathered together
and turned into one large chunk that can be used again. A process called
garbage collection and compaction.

If you run the "memory status" command at  regular  intervals  during  a
busy period, you should see the available free memory counter (coreleft)
drop. After connections close, you should, after a few minutes, see  the
memory  coreleft  total  creep  up again. The result is that the machine
makes better use of memory and since  it  recovers  as  much  memory  as
possible, should last longer!


1.7.3.  Setping

Setping is a small utility that allows WNOS to announce itself as an end
node in an TCP/IP network that uses the RSPF (Radio Shortest Path First)
routing system. It allows 'pings' (ICMP Echo Requests) to be sent to any
host  at  a  regular interval. Note that the function is not exclusively
used for communicating with RSPF machines, you  can  use  it  to  anyone
running  TCP/IP software. WNOS keeps a table of how many replies it gets
to pings sent to each host and assigns a 'link  quality'  to  that  host
based on the percentage of replies that came back.

Typing the "setping" command will display all the hosts  with  whom  you
have  setping  sessions  active  and the link quality of each. Hosts are
marked as "Bad" (host  is  most  certainly  down),  "Suspect"  (host  is
probably  down) or "Good" (the host is up). Setping sessions are stopped
with the "resetping" command.


1.7.4.  Mode

The "mode"  command  has  been  extended  to  allow  you  to  specify  a
connection  mode  to  any host individually. You no longer need to set a
default (and global) mode to reach all your direct hosts (eg mode 144 vc
-  use  AX.25  Virtual  Circuits).  Instead  the  mode  to  each host is
specified separately by its own "mode" statement. For example

     mode g4otj 144 datagram g4otj-2
     mode g4wrw 144 vc
     mode g6den 432 datagram
     mode [44.131.20.11] vc g4wrw-4











Note that the sytax of the command also allows a path  to  be  specified
with the mode to each host.


1.7.5.  Route Saving

WNOS will save to disk its routing information at intervals specified by
you (I use the defaults which are 10 minutes). Routing information saved
(and the corresponding files) is :-

IP Routing Table      (route)             - iproute.dat
AX.25 Routing Table   (ax25 route)        - axroute.dat
ARP Statements        (arp)               - arprout.dat
NET/ROM Routing Table (netrom route)      - netrom.dat

This feature is very useful in that the complete system state  is  saved
when  the  program exits. Since you may have had connects from users for
which you had  no  route  entered  before  (especially  if  a  new  user
appears),  these  will not be lost at the next startup. WNOS records ALL
pertinent information when a  new  connection  to  it  is  made  (ie  IP
address,  interface,  ax25  path or NET/ROM call and ARP entry if it was
used to reach you). This feature makes WNOS a truly dynamic system.

Note that all .dat files are *binaries*  and  so  cannot  be  viewed  or
edited.


1.7.6.  Chat

The KA9Q/G1EMM/PA0GRI "ttylink" command has  been  replaced  by  "chat".
This sets up a session to a remote host's TTYlink (on TCP port 87). It's
just a shorthand for "telnet  <host>  87"  which  would  have  the  same
effect.


1.7.7.  Mail and Node Activity Log

In WNOS you can selectively  log  activity  on  your  mailbox  and  mail
server.  Details of times and stations connecting to the mailbox will be
logged to the spool\node.log. Details of  mail  sent  to  and  from  the
system  are  logged  in  the file spool\mail.log. See the commands "mbox
log" for further details.


1.7.8.  Socket Writes

You can send text out to any connection (known internally to WNOS by its
socket  number)  by using the "socket" command to find the socket number
eg 152. From the command window you can then type, for example

write 152 Hello John, This is Mike testing a socket write

the text specified will then be sent out on the connection which  'owns'
that  socket.  It  is  also  very  useful when logged in remotely to the
mailbox as sysop (See the Mailbox "@" command). When logged on as  sysop
you  cannot  use  any commands that start sessions (after all, how could









you send the screen updates and new window out to  you  ?).  The  socket
command  is  then  useful for sending out a message to someone logged in
without starting a session.

Note that you cannot do socket writes to stations  who  are  just  using
your station as a digipeater.

You can also send messages to multiple users in the  same  way  just  by
adding  the  socket  numbers you want to send to. For example (it's late
and you want to switch off and go to bed)...

write 152 144 163 176 Message from  Sysop:  System  switches  off  in  3
minutes!

obviously much quicker than changing to all 4 sessions  and  typing  the
same line into each one!


1.7.9.  FTP Auto Login

WNOS3 takes the  drudgery  out  of  having  to  remember  usernames  and
passwords for use when logging in as an FTP user at a remote machine. In
the NOS root directory, you can create a file "nos.rc" which holds  your
username  and  password  used  to  login  over  FTP.  Users  of the Unix
operating systems will recognise the similarity with the  ".netrc"  file
used for the same purpose.

The format of the "nos.rc" file is....

<hostname> <username> <password>
<hostname> <username> <password>
etc

For example, if you use g0lxc as an FTP host, you might have an entry in
your "nos.rc" file with the line

g0lxc g6dhu mikechace

When you FTP to g0lxc, WNOS  will  login  for  you,  sending  the  "user
<username"  and  "pass <password>" strings automatically. Once logged in
at the FTP host, you will see the ftp> prompt appear.


1.7.10.  Domain Features


1.7.10.1.  Domain Server

WNOS now has a built in domain server. This  means,  for  example,  that
other  users,  with  no  or small domain.txt files can query your domain
server for the IP address corresponding to the given domain name.

Say you use g4wrw as a domain server (ie you have domain  add  g4wrw...)
in  your  autoexec.nos  startup  file. You now type "telnet sys2.g6den".
Obviously, the first thing that happens is that your machine will search
the  local  domain.txt  file  for  the  IP  address  of  the domain name









sys2.g6den.ampr.org.  If it is not found, your machine will send  out  a
special  "domain  query"  packet  to g4wrw's domain server. It will then
search its domain file for the details specified.  The  results  of  the
query  (success  or failure) then get sent back to your machine. You can
then either procede (since you will have been told  the  IP  address  to
use) or, in the case of failure, the connection will be closed.


1.7.10.2.  domain dfile

This command allows you to set a path other than the default (domain.txt
- in the 'root' directory) to an alternative domain file. For example

domain dfile d:/spool/domfiles/mydom.txt


1.7.10.3.  BOOTP Server

This is really an extension of the "domain  server"  concept  introduced
above.  The  BOOTP  server  is  much  like  the  domain  server with the
difference in that it can supply  any  querying  machine  with  ALL  the
information  it  knows  about  routing and the domain. This means that a
querying machine can startup  with little or no of its own IP or  domain
information  but  have  it  supplied  by  interrogating the remote BOOTP
server.

On receiving a query, the BOOTP server  supplies  the  querying  machine
with  a copy of its own IP route and ARP tables as well as a copy of its
domain.txt file.

Perhaps you can now see the reason for the name "BOOTP" since the server
supplies the "boot parameters" for the querying machine.


2.  New NNTP Services

For those of you that use NNTP (Network News Transfer Protocol) to  send
and  receive news articles, WNOS3 provides both client and server with a
fully auto-configuring news system  as  well  as  a  gateway  that  will
transfer  bulletins  handled  by the SMTP server into the NNTP system as
news articles.


2.1.  Auto Configuring NNTP System

The NNTP system within WNOS3 is now fully auto configuring. All you need
to  do  is  supply  the  various  NNTP  parameters  (see  the "nntp ..."
commands).

News system sub-directories are automatically created if a new newsgroup
is  handled  and all NNTP system files (eg the active and history files)
are updated automatically.

Both server and client routines are included and you can therefore  send
articles  to  others as well as collect new ones from your list of known
news servers.









The NNTP system files are also created (if necessary) on startup.  These
are  detailed  in  the  "Files  and  Directory Structure" section below.
Obviously, if you are converting  to  WNOS3  from  another  NOS  version
supporting  NNTP you can just transfer all of your NNTP system files and
articles (after creating the appropriate article  directories)  and  you
will be able to carry on as normal.

WNOS3 contains a simple, internal news posting program  for  you  to  be
able  to  compose  and  send  news  articles  and transfer them into the
system. (See the 'nntp profile' and 'nntp post' commands)


2.2.  SMTP -> NNTP Gateway

WNOS3 adds a new feature to  the  NNTP  implementation.  Mail  messages,
usually  but  not  necessarily, bulletins can be automatically sent into
the NNTP system by the SMTP server. For  example,  if  another  IP  node
mails  you  all  the AX.25 BBS bulletins sent to TCPIP@GBR, TCPIP@EU and
SYSOP@GBR  via  SMTP,  you  can  transfer  them  into  newsgroups,   say
ampr.tcpip and gbr.sysop.

The SMTP server recognises a bulletin 'group' for transfer to NNTP by  a
special  notation  in the Alias file (/alias). Alias entries are made as
normal but the name to expand to contains the newsgroup name preceded by
an exclamation mark (!).

Taking my example above, the alias file entries needed would be

tcpip   !ampr.tcpip
sysop   !gbr.sysop

The normal operation of the alias file isn't changed in any  other  way.
The bulletins are converted to NNTP news articles by the gateway and can
then be distributed to others using NNTP.


2.3.  UK Version Notes

I have added the following features to DB3FL's standard  release  source
code for executables distributed by me to the UK.


2.3.1.  NET/ROM Route Saving

Each time the 'netrom obsotimer' kicks, the program will save all netrom
routes  to  a file, "NRROUTE.DAT" in the WNOS root. The routes are saved
in plain text and maintain the status of  the  route  (eg  Permanent  or
Recorded).

When WNOS3 is restarted, it will read the saved  routes  file  and  load
each  route  back into the internal netrom routing table. At present, no
check is made to age routes since they were last saved,  each  route  is
initialised  with  an obsolesence count of 6. Obviously, any routes that
have since aged, will be slowly dropped in the normal way. All I  wanted
to  avoid by implementing this feature, was to stop having to wait for a
NODES broadcast from a local node to reload my netrom routes if I had to









take the system down for a short while.

I should also note, that this does not affect any netrom routes you  may
set at startup either - they will still be read in too.


2.3.2.  Forward Commands

I have also integrated G6PHF's code which  adds  the  commands  "forward
info"  and  "forward  nic".  These  are  used to set fields in a locally
generated Mailbox  standard  R:  header  which  is  added  to  all  mail
(bulletins  and  personal)  forwarded  by the system onto AX.25. See the
Command Reference for details and an example of how to set the fields.


2.3.3.  SMTP Header Stripping

Also integrated is G3UVQ's code to strip  all  SMTP  headers  from  mail
forwarded  from  SMTP  to AX.25. This is a useful addition to reduce the
size of messages sent into the BBS network  or  to  PMSes,  PBBSes  etc.
Obviously,  SMTP  headers  are  retained  on  messages  relayed, sent or
received via SMTP.


3.  WNOS DOS Environment Variables

WNOS3 reads the following DOS environment variables


3.1.  TZ

Timezone. Note  the  CAPITAL  TZ!  Sets  the  timezone  to  be  used  in
timestamping  outgoing mail messages and for adjusting the machine clock
time to a local time. For example

     set TZ=GMT+0UTC

GMT is the "official" inital  timezone  name.  By  official,  I  mean  a
recognised name eg PST, UTC, CET etc.

+0 is the difference from the initial timezone.

UTC is the real (local) timezone name.

For a UK example...

     set TZ=GMT+1BST

Meaning BST is GMT plus one hour.

The timezone string itself (UTC, BST, GMT etc) that you set is  used  to
stamp mail messages with the time when they were processed.













3.2.  MAILER

Set the name and location of the  mail  program  called  by  the  "mail"
command

     set MAILER=c:\tcpip\pcelm30.exe


4.  Files and Directory Structure

The default files and directories used are...

alias                   # Mail Alias file
autoexec.nos            # WNOS Startup file
arproute.dat            # ARP statements (autosaved)
axroute.dat             # AX.25 Routes (autosaved)
convers.cfg             # Cluster Autoconnect file
domain.txt              # Domain file
finger\                 # Finger information directory
ftpusers                # FTP and Mailbox user Permissions
iproute.dat             # IP Routes (autosaved)
nos.rc                  # FTP Auto Login data
popusers                # POP user and password file
spool\
     \areas             # List of mail areas
     \forward.bbs       # Mail forwarding instructions
     \help\             # Mailbox Help file directory
     \history           # Bulletin ID (BID) history file
     \mail\            # User Mail files (eg g6dhu.txt)
     \mqueue\           # Outgoing Mail Queue
     \news\             # NNTP root directory
     \news\active       # List of active Newsgroups
     \news\history      # NNTP Message ID history file
     \news\junk         # Newsgroups for junking
     \news\pointer      # Pointers to newsgroup storage directories
     \news\poll         # NNTP poll file
     \news\xinfo        # NNTP XINFO (site information) file
     \rewrite           # Mail Address Rewrite file
     \rqueue\           # Mail Router Queue
     \signatur\         # Mail signature directory

Directories are shown with a trailing slash, ordinary files without.


5.  Source Code

Source code for WNOS3 will be available from  me.  You  are  in  no  way
restricted  in passing the source code on to others. I would however ask
users passing source code to others the mail me with a message informing
me  of  who the code was given to. This is just so that I can keep track
of who has source code and pass on these details to Mike, DB3FL.














6.  Bug Reports

As with all good software, it's hard to  test  100%  and  so  there  are
likely to be a few bugs about.

If you find a bug please contact me with the details and I  will  do  my
best  to pass them onto Mike (DB3FL). WNOS has had a good reputation for
a fast response to bug reports and subsequent fixes.

Send me a good explanation of  the  bug  and  as  good  a  grip  on  the
environment  (both  machine  and the outside world) and circumstances in
which it takes place. Example autoexec.nos and any DOS batch  files  are
often useful too.

Please note that neither I nor Mike (DB3FL) will entertain  bug  reports
on  executables  that  have  been  built  from  anything  other than the
official release sources. Some users will have  the  source  code  -  to
"roll  their  own"  and  if  they  change  it and give you a copy of the
program built from those sources then direct your bug reports to them  -
OK ?!

I can be reached in the following ways.

     NTS Mailbox - G6DHU @ GB7IMB
     Internet    - [e-mail]
     AMPRNet    - [e-mail] [44.131.20.3]
     Snail Mail  - Mike Chace,
               84 Frankland Close
               Bath,  Avon
               BA1 4EL

73 and enjoy WNOS3!

Mike - G6DHU


7.  Change Log

v1.1 30th November 1991 (WNOS3alpha10)

First Issue.

v1.2 4th Jan 1992 (WNOS3a9)

Added sections on NNTP system and SMTP/NNTP Gateway.

Second Issue

v1.3 31st Jan 1992 (WNOS3a9_1)

Cleanup a few point following comments from DB3FL.

v1.4 4th April 1992 (WNOS3b1_2)












Added bit about mail signature file.