
Work started on 30 Jan 1995, as it appeared no one else was going to do it.

The majority of the code within this archive is my work, this has not been
based on any existing code, just on the existing protocol (standards) for
BBS forwarding which are about.  There is no warranty whatso ever with
this software and you use entirely at your own risk.


I am interested in feedback, also what tools are needed to help manage the
system (including remotely).

At this moment in time the bbs consists of forwarding binaries and incoming
processing bins.  Next to work on is outgoing processing.  Then I shall
move on to rem_sysop/user commands.

============================================================================


INSTALL:
   Read the file README.Setup (if from scratch) and README.Upgrade
   (if upgrading).  Then come back here and read through.

   Next read the ./Credits file to see who has put into this package.


When running WAMPES/LNET you just make the login shell of the BBS uid in
/etc/passwd (with the 'usermod -s /usr/lbbs/bin/bbsrx <user>' command).
You can run 'bbsd' on bootup and this will scan the queue every XXX seconds
(as setup in the Config file).  If you wish to reverse forward from users
you can setup crond to run 'bbstx' when you wish to do this.  Invoking bbstx
with a '-s <system> -f' option will force a connection even if nothing is in
the systems queue file.

When using the Kernel AX.25 layer please examine the ./bin/kax.25 dir and
the README in here.


PARTS OF THIS ARE/MAYBE BROKEN, PLEASE LIST THEM BACK TO ME AS YOU FIND THEM,
ALSO HOW YOU THINK IT SHOULD BE DONE.

Feedback needed:

   bbsrx, bbstx, bbsd, bbs-inject

Work In Progress:

   bbs-spool


73s for now, Darryl L. Miles, G7LED.

----------------------------------------------------------------------------


This should handle FBB FA and FB messages within compression.  I am not sure
at this time with the plan for compressed FB messages, it is supported to
the extent the code won't reject it and pass it up to the bbs-inject to
handle.  Many aspects of the above are not fully tested.



Some general notes:
===================

The whole /usr/lbbs tree has to be on one device.

!
!The algo used in bbs[tr]x to decide which one of the jobs to offer next is
!such that is would be possible to preserve the date of submision of the job
!into the network in the queuefile.  This has the effect of forwarding OLDER
!items first (even though it may only just have been spooled out for the
!BBS, and the queue file has a few hundred items already in it at the same
!priority).  The net effect it that as items get further away from where they
!originated (which implies they are getting older), they get offered first. 
!Thus averaging out the propogation time for the item(s) to reach every
!system on the network.  (It will also make the original article always
!appear before the followup!)
!
!! Que file now has an optional prioirity field don't believe the above for
!!  the time being.


It could do with a fail trap in the dialer, and some enhancements!

The MBL forwarding mech is based purely on presumption and experiments with
the protocol.


I found a few problems while adding FBB compression, mainly ambigiouity
within the specs, I should claify these:

The two byte hex checksum with 'F>' is worked out as it's all the chars
in 'FA' and 'FB' lines including the '\r' at the end of the line, but not
including the 'F>' line itself or the SID block (if the start of the
forwarding) modulo 256


The dialer program only flushs input to the next '\r' after the last item
has been found, also it does not flush input to the next '\r' between
finding items.  It *must* have quotes round the items and it *is* case
sensitive.  If any of the above is a problem please let me know and I'll
move the dialer re-vamp up the TODO.

Byte order is as per Intel, as there is no port of this to any other arch
(yet) it's not a problem.  This afects things like Information in the WP
database, if you intend sharing it between systems.

R: line dates for the local system are added at the time of spooling out,
not when it arrives.  So the Date in them will reflect this (if you use
batch spooling), the date they arrived it preserved by not used at this time.

If the NTS ID length is ever increased it could cause problems, the jobs are
stored as per their ID.  Linux with ext2fs has plenty of room left in the
filename length, but many other unices don't.  The system would still work
providing the ID was truncated to file the filesystem namelen.  The REAL ID
is always readout from inside the spooled file anyway.



ToDo: Lay lock down in the spool/incoming dir, from bbs[tr]x when creating a
      new file in there.
