CBBS V6.1c for the AMIGA (Kickstart V1.2 and V1.3)
17-Jul-1989
This program is basically a CBBS 6.1 version of the W0RLI
BBS. It was originally put together for the IBM-XT by K3RLI,
AG3F and others. It is written in the 'C' programming language
which made it fairly easy for me to port to the AMIGA because I
have been using C since 1974. However, it has had to be
modified somewhat to make it work on the AMIGA. It has been
used extensively on an AMIGA with the V1.2 Kickstart. It starts
up and appears to work OK with Kickstart V1.3 but has not been
tested extensively. It will work on a system with 512K of
memory. I have run it on a single floppy drive, although that
required limiting the number of files on the BBS. With such
limited disk space you will only be able to handle transfer of
mail rather than running as a full-blown BBS. But if you have a
hard drive you can run a full-blast BBS with this program. If
you are already familiar with the CBBS or W0RLI (or even MBL)
systems you should have little trouble getting this thing to
go.
You MUST be able to use the CLI and an editor in order to
set the BBS up properly.
I have only used the BBS with a KAM and an old TAPR TNC1
with the upgrade to TNC2 V1.1.6, but there should be no problem
running this BBS with others such as GLB, PK232, PACCOMM etc.
provided that they are TNC-2 compatible (if you are running one
of these, read the info below about the problems with the TAPR
V1.1.6 just in case they apply to you). The program will permit
KAM users to run one HF and one VHF port. It will only allow
connects from one side at a time but forwarding and logins to HF
and VHF can be accomplished. For other TNCs you are stuck with
running either VHF or HF at any one time.
I have done very little to customize the program for the
amiga ... no menus etc. There are two reasons for this. First,
it's a lot of work and I don't feel like doing it. The source is
here and compiles with MANX 3.6a, help yourself! Second, there
are other CBBS and W0RLI systems around which run on IBM and
other disgusting machines. They all use the same command
structure so if you can run the amiga BBS, you can run IBM etc..
But if the commands are all buried in menus you won't be able to
switch to other machines. Not a big deal but another
justification for me to leave well alone.
The only concession to the amiga environment was to provide
a window title when the BBS comes up. Clicking on the top-left
'close' gadget will make the BBS shut itself down in the same
way as the 'Q' command except that it does not ask you if you
are sure you want to terminate the program. The two numbers in
the title separated by a slash are the highest message number
and the number of active messages. In earlier versions the
number of active messages was exactly that, the number of
messages you would see if you asked the BBS to list every mail
message it had. But in V6 this number also includes the number
of messages created and deleted since the last 'GM' command. So
if the number of messages listed is way less than the number in
the title bar, it's time to do a 'GM' command to clean up.
I have not explicitly modified the program to take
advantage of available ram:. But look at the tnc.on file. When
the program starts it dumps the tnc.on file into your TNC to
initialize its parameters. It also allows you to put CLI
commands in that same file and you can, for example, set up your
config.mb file so that help.mb, info.mb, user.dat, mail.dat and
other files are specified as being in a ram: directory. CLI
commands are then put into 'tnc.on' to actually copy the files
into ram: as the program starts up. Thus, you don't need to
load the files into ram: as a separate operation before the BBS
starts up. Your forwarding files can also be modified so that
after a regular forwarding operation or after the regular
console 'forward', the system copies mail.dat and user.dat back
to disk. (help.mb and info.mb are not modified by CBBS so they
do not have to be saved back to disk). If you do this, you will
also have to modify tnc.off so that it saves the files when the
bbs is shutdown and you should also be cautious that shutting
the bbs down before the ram: files are saved could leave the bbs
files in an indeterminate state. Putting the files in ram:
really speeds up the operation of the bbs especially if you are
only using floppy drives. It also significantly speeds up other
operations such as untangling the mail file and user files (GM
and GU commands). It is safest to specify that the backup files
mail.bak and user.bak are still on disk. Just in case.
BEFORE YOU START UP THE PROGRAM READ THIS PROCEDURE.
** Make a few backups of this disk!!!!!
** Print out this readme file, the manual.bbs file and the
config.mb file which is in the 'cbbs' directory. If you
aren't familiar with BBS systems at all then read manual.bbs
first very carefully. As you read through it, it will help to
have the copy of the config.mb file with you. But remember
as you read it that it was intended for users of IBM machines
so some references to things like DESQVIEW and windows etc.
are irrelevant to you. (The IBM concept of window mentioned
in the manual is not the same as an AMIGA window and should
be ignored). You should then read through the rest of this
file.
** If you are going to use just this disk as the BBS then you
will have to clean up the space on it. Further, if you have
only one disk drive then you are going to have to change this
disk so that it can be booted. I haven't tried that at all
but it can be done. Make a few backups, and then you can
delete vt100.doc, manual.bbs, the readme files, all the C
source if you don't want it online, and if there are commands
in the c directory you won't use then remove them too.
** The TNC MUST be wired up for HARDWARE HANDSHAKING. If your
TNC is not currently wired for hardware handshaking then do
it NOW. My KAM is wired as follows:
KAM Pin AMIGA
2 2
3 3
4 4
5 5
7 7
6-8-20 (all jumpered AMIGA side only)
** Before you start up the BBS the TNC PARITY MUST be set to
NONE (or SPACE). On my KAM no parity is "PAR 4" (and space is
"PAR 3"). Any other parity setting will not work. You can use
the vt100 program on this disk to talk to the TNC to set the
parity before you start up the BBS. (Thanks are due to
Frank, DF3UM, who suffered through this problem and brought
it to light for me).
There is a nasty problem with TNC1s that have the TAPR
V1.1.5/6 upgrade. The manual states that setting PAR to 0 or
2 means parity is set to none, but it actually forces the
parity to a one all the time. The BBS expects parity to be
forced to zero. To get around this you can specify the '-t'
flag when you start up the BBS and the BBS software will
strip the high order bit off every character that it receives
from the TNC. This means you cannot use transparent mode even
if I get it working in a future release.
** Your TNC must have the commands:
streamdb on
users 1 (and on the KAM users 1/1)
so that the BBS software will process stream switch
characters properly and will only permit one user at a time
to connect to the BBS. The BBS does a 'conok off' whenever
someone connects but it is safest to make sure that nobody
else can get in. Your TNC can also have the command:
autolf off
This command is not essential but it does make the screen
output clearer. All of these commands can be put into the
tnc.on file.
** The manual refers to use of transparent mode. I haven't
implemented the necessary stuff yet. DON'T USE IT.
** You MUST edit the configuration file config.mb. There are two
places in it (obviously marked) where you must put your
callsign and one where you must put your QTH. NOTE also that
there is one place where a line generates the time in a
message that is being forwarded. Currently the timezone
printed out is CST. If you are not using CST on your amiga
you'll have to find the line and change CST to your timezone
(or Z if you run your beast on UTC). The line looks like
this:
R:$J/$KCST $M@$O [$Q]
^^^ Change this if necessary.
The structure of this disk corresponds to the config.mb file
but you can change it if you wish. If you have a hard drive
you will certainly want to have CBBS use that instead of a
floppy. You can also set the config file up so that it will
use two (or three) floppies instead of one (i.e. you can
spread the BBS directories across two or more drives to
spread out the load).
I have changed the remote sysop password scheme in the
amiga version. It is described later, but you should change
the existing example password, which is at the end of the
config.mb file, or replace it with one line containing a
single zero if you don't want to permit remote sysop.
** DON'T change the port designators for the TNC and console
terminal in the config.mb file. They MUST be 'A' (the TNC)
and 'L' (console) respectively. Any other port designators
are ignored and so are a waste of space.
** When the program starts up it looks for the file fwd.mb to
define what it does for forwarding files. This file will have
to be edited. I have left parts of my forwarding files here
for you to look at as examples. As distributed, fwd.mb
contains just enough to forward to VE5OP which is our local
BBS on vhf. NOTE that there is a |a as part of the connection
string. This is only required if you have a KAM to force the
forwarding onto VHF. Similarly, there are a few files
(20m.fwd etc.) that do forwarding on HF and have a ~a in
them. If you aren't running a KAM you must edit these out of
the files as you'll only have one port to use anyway, in
which case delete the two characters |a or ~a as
appropriate. Notice also that some of the TNC commands have
a '/' in them. These are specific to the KAM since many of
its commands apply to the HF and VHF ports. Such commands are
specified as, for example, 'retry 10/5', which sets the retry
parameter to 10 for HF and to 5 for VHF. Similarly, the
command 'retry 10/' sets the HF retry to 10 but leaves the
VHF retry as it is.
You can make CBBS use a forwarding file other than
fwd.mb after the BBS comes up by using the 'YF filename'
command. I often use 'YF 20m.fwd' to change from VHF-only
forwarding to HF and VHF forwarding. The HF forwarding is
here as an example ONLY. It won't work on the air for you
unless KC0TA has entered you in his user file as a BBS. Note
that the 20m.fwd file refers to several other files, and
these sometimes refer onwards to yet others. The reason for
this is to keep the forwarding info easy to manage (really!).
Also, the file ve5op.via contains an example of passing
traffic by connecting to an intermediate KA-NODE. Near the
end of this file I have added a couple of examples of how to
work out what should be in a forwarding file.
** When the program starts up it looks for the file 'tnc.on'
which need not exist but if it doesn't your TNC had better be
configured properly. You MUST edit this file to make it
conform to your configuration or delete it if necessary. The
tnc.on file can contain comment lines (lines beginning with
#) which are ignored, and CLI commands (lines beginning with
!). All other lines are assumed to be commands to the TNC and
are sent out the serial port. The tnc.on file contained on
this disk contains a lot of comments about what it can do.
Some commands that could be in here are those to force on
hardware handshaking and any other TNC parameters useful to
the BBS. Even if you only use the TNC with the BBS (and
therefore you never change the parameters) it can help to
have them 'softwired' into this file 'just in case'. You
could, for example, put EVERY command your TNC understands in
here so that if the TNC ever gets scrambled, just restarting
the BBS will restore it's sanity.
I have commented out those commands specific to the KAM.
If you have a KAM, edit them back in by removing the comment
symbol at the beginning of each TNC command line.
For TAPR upgraded TNC1s you MUST have the two commands:
newmode off
nomode off
in the tnc.on file because this is the ONLY combination of
these two commands that will work properly. This is not
exactly what the BBS needs but is as close as the TNC can
get. It works fine for the BBS. The only place it might
cause you problems is if you use the 'TA' command and connect
to a station. On the disconnect the TNC stays in convers mode
so you MUST remember to type '^C' (CTRL-C) to force the TNC
back into command mode before you type '^E' to get back to
the SYSOP prompt.
In the KAM these commands are set to:
newmode on
nomode off
For other TNCs these commands should be set to whatever will
cause the TNC to return to command mode on a disconnect and
to go to convers mode when a connection has been established.
If your TNC won't do this then it is almost certain that the
BBS won't work properly.
** For TAPR TNC1s and upgrades it is best to be sure of forcing
the TNC into hardware handshake mode by specifying all of the
following commands in the tnc.on file:
start 0
stop 0
trflow off
txflow off
** When you terminate CBBS, the last thing it does just before
it closes the serial port and the window is to send the
content of the file 'tnc.off' to the TNC if the file exists.
The structure of this file is the same as for tnc.on and may
also contain comments, CLI commands and/or TNC commands. You
MUST edit this file to make it conform to your configuration
or delete it if you don't want anything done at shutdown.
If, for example, you have set up the bbs to keep user.dat
and mail.dat in ram:, then this file should contain the
commands necessary to write them back to disk before the
program exits. You can also add TNC commands such as the
'btext' command with a text saying that the BBS is off the
air.
** The AMIGA has only one serial port (or at least my A-1000
does) and so the gateway commands have been removed from the
program. They are only useful if you have multiple serial
ports, each with a TNC. If you have a KAM, it'll gateway for
you anyway!
** The A, AH, AI and user C commands have all been removed from
the amiga version.
** The 'J' commands have been modified to print out the date
that each call was seen as well as the time.
** I have made a change to the way that this BBS handles
bulletins which is NOT in the standard CBBS. In order for
this BBS to ACCEPT a bulletin from another system there MUST
first exist a file in the msgs directory (Note that the name
'msgs' is specified in the config.mb file and can be changed
if you wish). If for example you want to receive ALLUS
bulletins then there MUST be an ALLUS.dis file in the msgs
directory. If no such file exists then the program doesn't
even check the BID, it just says "NO - Don't want it". This
can save you from being inundated with bulletins you don't
want from another BBS. This has happened to me, and with my
limited disk space it doesn't take too many ALLUS bulletins
before all my disk space is gone! The content of the .dis
file is a list of the callsigns (one per line) of those
systems that you will forward that type of bulletin to. It
does not have to contain the name of the system you receive
the bulletin from. If you only receive bulletins and don't
forward them, just put the name 'hold' in the file, as is
shown in the example .dis files on this disk.
** Another change I have made is that if there are messages to
ALL on your BBS and they are addressed TO your BBS (i.e.
either the @BBS field is empty or it contains the callsign of
your BBS), the beacon does not just say ALL as most other
systems do. It also includes the highest message number
addressed to ALL, e.g. ALL(489) to show that the highest
message for all is numbered 489. This allows users to see
when a new message to ALL has arrived at the BBS without them
having to log in, they just monitor the beacon.
** There is also a change to the way the BBS handles mail. If
the BBS receives mail addressed to someone who is in the
USER.DAT file then the BBS OVERRIDES the @BBS field in the
message with the @BBS field from the user file. This will
occur whether the message is one you typed in yourself or
from a logged in user, or even in mail forwarded from another
system. The assumption here is that if the user is in your
user list then the @BBS field is more likely to be correct
than any mail from outside. If the mail is addressed to a
user who is not in the user file then the @BBS is not
changed.
** There are a few messages already in this BBS as distributed.
They are a few AMSAT bulletins which will be out of date by
the time you get this disk. You can delete them when the BBS
first starts up. Do a 'll 10' command first to list them and
then use the 'K' command to kill them e.g. K 1 will kill
message number 1 and so on. Then do a 'GM' command to clean
out the files. You must periodically execute the 'GM'
command anyway to clean out old files. This can be done
automatically or manually as described in the manual. It
cleans up the space used by the mail files and deletes old
ones.
In CBBS V6 a new feature has been added such that
deleted files can, if you wish, be archived instead of being
deleted. If, for example, you want to archive AMSAT
bulletins, then you must create a directory called AMSAT
immediately under the CBBS directory. Then instead of
deleting amsat bulletins when they get old, the program will
store them in the amsat directory. NOTE, I think it is
dangerous to have a bulletin board directory name the same as
a bulletin name. For example, if you store files about
satellites in a directory called AMSAT, then the 'GM' command
will archive AMSAT bulletins in there as well. I have not had
much experience with V6.1 yet but I suspect that this would
be a bad thing because the structure of a mail file is NOT
plain text. It has a header containing arbitrary binary
rubbish in it and if a user tries to download it strange
things may happen. So, when you pick names for the bulletin
board directories, DON'T make them the same as the names that
occur in the @BBS field of incoming bulletins.
** This distributed version also has a few BBS file areas. You
can add more or remove some as you wish. But remember to
create corresponding directories for the new ones. The reason
I have a specific 'upload' directory that is write-only and
all others are read-only is that a user might upload a file
containing arbitrary binary characters and then download this
same file to themselves. It is possible that the bad
characters in the file will mangle your TNC. Alternatively,
a user might upload a file that contains obscenity or is
commercial in nature and you would not want to be held
responsible for distributing it any further. So to avoid
this, users can upload a file into the specific area and then
send you mail telling you that it is there. You can then
move the file to its intended area after you are sure it is
safe to do so. Thus, users can't write into the normal file
areas and can't read from the upload area.
** The content of the file 'files/info.mb' is sent to any user
who issues the 'I' command. It currently has two lines in it
briefly describing that this is the CBBS program. If you want
to, you can edit the file and add to it your name, qth and
the type of TNC, Rig etc. that you are using.
** The ! SYSOP command that allows you to execute CLI commands
works except that the output of a CLI command goes to the
window in which the CBBS was started, NOT to the CBBS window
itself. This is annoying but I can't find a way around it
yet. On the other hand, this is a multitasking machine and
you can always have a separate CLI window open to execute CLI
commands anyway. So I'm not gonna bust a gut to sort it out.
** In my version of CBBS the remote sysop password does NOT work
as described in manual.bbs. I felt that the password
mechanism used there is very weak and it wouldn't take a
determined snooper very long to be able to break into your
system remotely if remote sysops use it very often (NOTE that
in order for someone to successfully be a remote sysop, you
must first set that privilege for them in the user file AND
set the 'R' privilege for port 'A' in the config.mb file AND
set up a proper password as described below).
Instead of using a line containing 64 characters, the
password scheme now uses a line (or lines) containing up to
64 positive non-zero numbers. If a remote user tries to get
in, the system still sends them four numbers as a challenge
but instead of sending the corresponding letters of the
password, the remote sysop must send the SUM of the
corresponding NUMBERS.
Since you can't easily fit 64 numbers on a line, you can
put the numbers on several lines with all but the last line
terminated with a backslash character. For example:
17 42 93 81 90 3 27 82 103 35 72 64 13\
76 7 25\
23 47 56 62 18 11 95 79 126
Using this example password, if a user tries to be a remote
sysop and receives the challenge
10 21 7 16
then they must answer with 105 (the sum of the 10th, 21st,
7th, and 16th numbers in the list). There MUST be at least
20 numbers and no more than 64 in the list AND they must all
be positive and non-zero or the remote sysop function will be
disabled. Thus, if you don't want to permit the remote sysop
function at all just put a single zero on this line. The
numbers should all be different and in random order to
strengthen the password scheme.
***###*** OK .. Let's try it ***###***
You MUST first be connected to the directory that contains
the mb program and the config.mb file, which on this disk is the
'cbbs' directory. This is because the config.mb file in this
distributed version has all the directories specified as being
relative to the 'cbbs' directory. You can change this as you see
fit. Then execute a command of the form:
mb [-bN] [-t] [[config-file] debug]
The default baudrate between the TNC and AMIGA is 9600 baud. If
you use any other speed then you MUST specify the -bN switch to
tell the program what baudrate to use .. e.g. -b1200 (NOTE that
there's no space between the b and the number!)
The '-t' option (which can be specified before or after the
'-bN' if it is also present) specifies that the BBS software
must strip off the high order bit of every character received
from the TNC. This allows the BBS to be used with TNCs that set
the parity bit to a one when in 'no parity' mode, such as the
TNC1 with the TAPR upgrade to TNC2 V1.1.5.
The program can be told to use a different config file than
the default name of config.mb by specifying the name as the
config-file argument.
If another argument is specified after the config-file name
(e.g. debug ... but the program doesn't really care what it is
as long as it is there) it turns on debugging. This won't be
much use to you unless you have read the source code.
It takes a few seconds of disk churning to load the program
but then the first thing that should happen is that it opens a
new window for the BBS and the title should appear. It then
prints a line containing the words Window and Port .. ignore
this. Now it tries to send three commands to the TNC: 'm off',
'cono off' and 'echo off'. If you have forgotten to connect the
TNC to the amiga serial port or have set it to the wrong baud
rate or wrong parity, then after about 30 seconds the program
will timeout and exit because it can't get a reasonable response
from the TNC. Connect it up properly and start again. It then
sends out 'TXD' and looks for the 'TXD' reply from the TNC. The
program then sends a PASS command to the TNC to find out what
the pass character is. If it finds one it also sends a STREAMSW
command to the TNC to find out what the stream switch
character(s) is(are). On the KAM there are two, one for VHF and
one for HF. The program then prints the results of what it
found.
If you have included CLI commands at the front of the
tnc.on file then the process may pause a bit here. Then the
program should show some data from the TNC as it dumps the
tnc.on file into the TNC. It then prints out how many calls are
in the calls.mb file (initially zero) and don't worry when it
reports that the file is full. It then should print a line
saying how many users are in the USERS file. First time through
it should say zero AND you had better have set your call in
config.mb already because the program automatically adds you to
the user file as a sysop (of course). It then prints out how
much free chip and fast memory it can find and it always says it
will use 16K. It then prints:
BT mail for:
and after a couple more lines it should just go quiet.
It is now waiting for someone to call into it on the TNC or
for you to wake it up as SYSOP from the keyboard. As SYSOP you
type a Control-E character (default in config.mb and can be
changed) at which point it should send the commands 'm off' and
'conok off' to the TNC. It then grinds the disk a second or so
and then it should print the sysop prompt which the distributed
config.mb file has set to 'SYSOP>' (you can change it). From
there on you can issue the commands described in manual.bbs. As
an example, just type the command DU at the prompt. It should
display just your callsign first time through because you are
the only user it has seen so far. A useful exercise at this
point is to use the 'EU' command to edit your entry to add your
name. As users log in and give the BBS their name and zipcode,
the file will begin to grow. You can add new users yourself if
you wish by using the EU command with their callsign. E.g. to
add me:
eu ve5va
and then set the other parameters (such as name, zipcode etc.)
as shown in the manual. Another command to try is:
LL 10
which asks the BBS to list the 10 most recent messages in the
mail file.
One thing you must keep an eye on, especially if you are
only using floppy disks, is that if you have allowed logging of
events (in config.mb) the log file, log.mb, will grow without
bound as the BBS is used. So you must occasionally delete this
file. If you are required by law to keep a record, print the
file out or archive it on another disk and then delete it from
the bbs disk. Try out the 'PRTLOG' program which prints a
summary of the file.
To exit from sysop mode just type the 'B' command. It will
then wait for a user to call in.
The safest way to terminate the program is by clicking the
close program gadget in the window title bar or use the Q
command on the keyboard. This is so that the program will update
the user and possibly the mail files properly. Just removing the
disks might leave them in an indeterminate state whether or not
you have stored them in ram:. Also, if you have CLI commands in
the tnc.off file to do some tidying up, the only way they can be
executed is to quit properly.
Here are a few pointers, based on experience.
** If the BBS opens the window but then closes it and generates
the "Timeout - .." message it can be for one of the three
reasons listed or others I haven't though of or run into yet.
Make sure that the TNC is plugged into the serial port. Also
make sure that the cable is wired up properly. If neither of
those help then try running the BBS with "run mb -t" to tell
it to ignore parity.
** If you call another BBS but it won't accept mail from you, or
it won't send you the [BBS-TYPE-CODES$] message, then you
must log into that BBS as a normal user and send mail to the
SYSOP asking him/her to set you up as a BBS in his/her user
file. It also helps to have them also set you up as an expert
user (although you can do that yourself) because this usually
reduces the size of the login message.
** If you want to send bulletins, you and your users must use
the 'SB' command. If they use an 'S' command such as 'S ALL @
AMSAT' then it generates Private mail, NOT a bulletin. So no
matter how your bulletin distribution files are set up, it
won't forward them. If you already have some mail like this
on your system then you can change it from type 'P' or ' ' to
type 'B' by using the 'E msg#' command and changing the
message tYpe. (i.e. type the command 'y b' when you are in
the 'E' command).
** If your BBS still won't forward bulletins make sure that you
have a proper .dis file for the bulletin in the msgs
directory.
** If your BBS won't accept bulletins from another BBS (i.e.
your BBS says 'No - Don't want it') then you do not have a
proper .dis file. There must be a .dis file for that
bulletin type even if you don't forward the bulletins to
anyone else.
** If your BBS won't forward mail for a user then either they
are not listed in your forwarding file for their BBS or their
user record does not specify the correct Home bbs.
Some Forwarding Examples
The best way to work out a forwarding file is to log in
manually to the system that you are trying to forward to and
record everything that occurs. Then work out the forward file
from that.
First, a simple example. I wish to forward to VE5OP who is
here in Saskatoon. If I connect to VE5OP manually I see this
(with my comments added on the right):
c ve5op [ I type this command
cmd:*** CONNECTED to VE5OP [ and the TNC says I'm connected
[CBBS-6.0-H$] [ Here's the BBS login message
EU> [ from VE5OP and its prompt.
Now let's add the corresponding forwarding commands on the right
hand side.
c ve5op [ CC VE5OP
cmd:*** CONNECTED to VE5OP [ <NOTHING HERE
[CBBS-6.0-H$] [ HA0023C VE5OP
EU> [
The 'CC' command not only sends the first connect message,
but it also looks for the '*** CONNECTED' message from the TNC.
So you must NOT use the 'R' command to read the '*** CONN'
message. Remember that once you get to the [BBS-TYPE-CODES$]
message you are in to the BBS and now you just use an 'F', 'H'
or whatever list and you simply add in the list of calls whose
mail is forwarded to VE5OP. So the complete script could look
like this:
CC VE5OP
HA0023C VE5OP
ve5op [ you can put lots more calls in
ve5pf [ here as well as
ntssk [ nts codes
97* [ or wildcards
*** EOF
KAM users should remember to add the streamswitch characters
into the initial connect command (e.g. 'C|aC ve5op' for VHF).
If I had to go through the VE5USR digipeater to get to
VE5OP, the only change in the script would be:
CC ve5op via ve5usr
because the digipeater would not generate any more text during
the connection.
A more complex example is if I want to connect to the
VE5AGA BBS in Regina, which is 165 miles from Saskatoon. I have
to go through two KA-NODES (VE5BAR and VE5ABO) and one
digipeater (VE5GF) to get to VE5AGA. The path is in this order:
VE5VA <-> VE5BAR-3 <-> VE5ABO-3 <-> VE5GF <-> VE5AGA
bbs ka-node ka-node digi bbs
Here's what I would see if I logged in manually with my comments
on the right hand side:
cmd:c ve5bar-3 [ I send the connect
cmd:*** CONNECTED to VE5BAR-3 [ and my TNC responds.
###CONNECTED TO NODE VE5BAR-3(VE5BAR) CHANNEL A [ Now KA-NODE responds
WELCOME TO SASKATOON...VE5OP LOCAL BBS... [ with its own messages
ENTER COMMAND: B,C,J,N,X, or Help [ until it prints the
?c ve5abo-3 [ prompt without a CR.
###LINK MADE [ Connected to ABO
###CONNECTED TO NODE VE5ABO-3(VE5ABO) CHANNEL A [ and ABO now prints
Welcome to the Ituna Node [ its own messages
ENTER COMMAND: B,C,J,N, or Help [ up to the prompt
?c ve5aga v ve5gf [ now connect via digi
###LINK MADE [ The KA-NODE says OK
[MBL-5.12-C$] [ Now the BBS responds
Welcome to the Regina BBS [ with all its own
de Perry VE5AGA [ login messages
[ which can be anything
for latest information 'D INFO.TXT' [ up to the prompt
VE5AGA> [ with the '>'
And here's the script with the corresponding forwarding
commands.
cmd:c ve5bar-3 [ CC VE5BAR-3
cmd:*** CONNECTED to VE5BAR-3
###CONNECTED TO NODE VE5BAR-3(VE5BAR) CHANNEL A [ R###CONN
WELCOME TO SASKATOON...VE5OP LOCAL BBS... [ R!
ENTER COMMAND: B,C,J,N,X, or Help [ R!
?c ve5abo-3 [ SC VE5ABO-3
###LINK MADE [ R###LINK
###CONNECTED TO NODE VE5ABO-3(VE5ABO) CHANNEL A [ R###CONN
Welcome to the Ituna Node [ R!
ENTER COMMAND: B,C,J,N, or Help [ R!
?c ve5aga v ve5gf [ SC VE5AGA VIA VE5GF
###LINK MADE [ R###LINK
[MBL-5.12-C$] [ HA0023C VE5AGA
Welcome to the Regina BBS
de Perry VE5AGA
for latest information 'D INFO.TXT'
VE5AGA>
Note that the '?' prompt from the KA-NODEs does not have a
carriage return after it and so there is just a corresponding
'S' command here. The 'R' command must not be used here because
it is looking for a line ending with a carriage return and the
BBS will just hang and eventually timeout here if you use 'R'.
IF the KA-NODE sent a prompt with a carriage return after it
(i.e. '?<CR>' instead of just '?') then you would need a 'R'
command to read the '?<CR>' and then an 'S' command to send the
next command to the KA-NODE. You can easily tell the difference
because if there's no <CR> then you will see:
?c ve5abo-3 [ only requires SC ve5abo-3
such that both the prompt and your next command are on the same
line, whereas if there were also a CR there you would see:
? [ would require R! (or R?)
c ve5abo-3 [ SC ve5abo-3
When you use the 'R' command you can specify some context
expected on the line such as the 'R###LINK' I have used here. It
is useful to do this rather than 'R!' for the 'LINK' or
'CONNECTED' messages because if the link fails then the ka-node
will send a message such as '###RETRIED OUT AT NODE VE5ABO-3'.
This does not match the specified '###LINK' and so the 'R'
command will fail and your BBS will disconnect the forward
attempt. If you had specified 'R!' instead of 'R###LINK' then
'R!' will also accept '###RETRIED OUT' and then your script will
hang until the process times out. However, you don't need to
specify a context for all the lines so that some of them are
just read with 'R!'. The 'R' command will search for its given
string anywhere on the line so that you could check for '###LINK
MADE' by specifying 'RMADE' as well as 'R###LINK' or even
'R###LINK MADE'. Just how much context you give is up to you as
long as it is sufficient to correctly distinguish the line from
any other expected response.
Note also that VE5AGA has a much longer login message than
does VE5OP, but that doesn't matter. Once your BBS sees
[BBS-TYPE-CODES$] it will look for the prompt with the '>'
symbol in it and then start forwarding.
If the VE5GF digipeater were between the ka-nodes rather
than at the end, then the script would not be any more
difficult. For example, if the order of the connections were:
VE5VA <-> VE5BAR-3 <-> VE5GF <-> VE5ABO-3 <-> VE5AGA
bbs ka-node digi ka-node bbs
The connection process would then be:
c ve5bar-3
c ve5abo-3 via ve5gf
c ve5aga
so the basic script would look like this (with some of the
extraneous stuff removed):
CC ve5bar-3
R###LINK
etc.
SC ve5abo-3 via ve5gf
R###LINK
etc
SC ve5aga
R###LINK
HA0023.....
etc.
This procedure for working out a script can also be used
for working through NET/ROM nodes and other types of networking
or gatewaying nodes.
The BBS commands
The BBS commands (as opposed to commands used for storing
and forwarding mail) are fairly easy to use. The primary use of
these commands is to store information of local interest that
you would not want to mail to everyone. Rather, you can store
the information in a file area and let users read the
information if they are interested. For example, on this BBS I
have put a file area for QRP related information. Other file
areas could be for AMSAT information, and another for a swap'n
shop file. If someone is interested in QRP stuff but not in
AMSAT info then they can look through the QRP area and not have
to read a lot of mail or bulletins that don't interest them.
I'm going to use my local BBS VE5OP as an example here to
show how the commands work.
The first command to give to the BBS is the 'w' command
which asks what are the major areas in the BBS. If I type 'w' on
the VE5OP BBS I receive this info:
Use W and directory ID:
WA --> Amsat / Oscar WB --> General information
WC ---> ARRL/ Newsletters WD --> Hamfests and Related EVENTS
WE --> Packet Meetings-Minutes,ect. WF --> Packet LISTS
WG --> Swap 'n Shop WH --> Local Users - Equipment
WI --> NEW Uploads To Here Please
If I want to see what is in the 'General information' area then
I type the 'WB' command as shown beside the name of the area.
The 'WB' command will print out:
AA4RE 4k | Q.BAS 3k | README.R95 16k
CONFIG.MB 4k | README.DOC 12k | WOOD1.INF 2k
41k of 31834k used, 27348k free.
Now let's look at the AMSAT area by typing the 'WA'
command:
AO-13.SKD 2k | MIR.QSL 1k | O13.OCT 3k
MIR.BCN 1k | MIR89.FEB 4k | O13.SEP 5k
MIR.MAR 8k | MISC.021 2k | WEATHER.021 5k
MIR.OPR 4k | O13-1.OCT 4k | WOOD1.INF 2k
41k of 31834k used, 27348k free.
And also let's see what's in the swap'n shop area with the
'WG' command:
890416.SWP 7k | SWAP04.DEC 7k | SWAP20.FEB 7k
890523.SWP 7k | SWAP12.MAR 8k | SWAP29.JAN 6k
SWAP0122.89 6k | SWAP2.NOV 8k | VE5BBL.SEL 1k
57k of 31834k used, 27348k free.
Now, I decide that I want to look at what is in the file
mir.qsl in the amsat area. To do this I must Download the file
and tell the BBS which area it is in ('a') and it's name. So I
type the command:
da mir.qsl
and receive the following info:
ARRL BULLETIN 140 ARLB140
MIR SPACE STATION COSMONAUTS U1MIR AND U2MIR ARE NOW REPORTED TO BE
OPERATING ON 145.400 MHZ. QSL CARDS SHOULD BE SENT VIA USSR, MOSCOW,
107207, P.O. BOX 679, B. STEPANOV.
WA2ILB @ NN2Z>
In this case the file contains an ARRL bulletin but it
could be anything.
If a user wants to send a file to the BBS then the file
must be Uploaded into the 'I' area and a filename must be
specified for it. For example:
ui qrp.info
The BBS will respond by telling the user to upload the file
and then terminate it either with '^Z' or with '/ex'. The user
should also send mail to the SYSOP to tell them that the file
has been uploaded and what is in it.
The 'W' commands can also by used by the sysop so you can
try them on the distribution disk. But the SYSOP cannot use the
upload and download commands. They mean something different when
the SYSOP uses them.
Good Luck.
If you have problems getting CBBS to work either because my
instructions aren't clear or I've left out something important,
please let me know. If you want help or have questions I'll be
glad to help IF I can but you must take note of two things.
- I will not answer mailed queries unless you also send me a
proper SASE. U.S. hams PLEASE note that putting a U.S.
stamp on your envelope won't do me any good. Canada Post
expects me to use Canadian stamps. However, I will take a
LOOSE U.S. stamp (30 cents) in exchange (NO IRCs please - I
have plenty right now). If you send me a disk and expect
it back, that will require correspondingly more stamps or a
money order.
- I have been ill since Sept 1984 with Chronic Fatigue
Syndrome (Myalgic Encephalomyelitis to you Brits ... I'm
one myself) and am always tired. I put this BBS together
over many months (it took me six months to find a simple
bug in my amiga code!) . So if I'm having a bad spell I may
not get around to answering for a while. Be patient.
Just to save you sending "I wish that ..." letters, here
are a few things I'd like to do for the next release if I get
the time.
** Allow the sysop to specify TNC type in the config.mb port
description. Mainly so a sysop can specify that a KAM is
being used but also useful for other quirky TNCs as well.
** perhaps add code to take mail out of your TNC if it has a
mailbox in it. When my CBBS is down, people sometimes leave
mail for me or others in my KAM mailbox and if I don't
explicitly look for it and manually forward it into CBBS,
it's stuck there forever. This is why there's a 'PBL' command
in my tnc.on file, to remind me if there's stuff there. But
it doesn't actually transfer the mail into CBBS.
For your info, a KAM mailbox can accept mail FROM a CBBS
(I believe that some other TNCs can too). It accepts mail
just like a regular BBS. But a KAM can't SEND mail to a CBBS.
So if you have 'clients' out there who use a KAM, you can set
up a forward file which automatically sends their mail into
their KAM. The only thing that you can't control is the
amount of mail. If it overruns the available ram in the KAM
(or other TNC) then they could lose some of their mail. Let
them decide if they want to risk it.
** add some menus? Don't count on it.
** Allow sysop to choose which of my non-standard modifications
should be active.
Pete Hardie VE5VA
338 113th St.
SASKATOON
SASK S7N 2L2
CANADA
or packet
@KC0TA, @VE3IWJ or @VE2ED (all on 14.107 Mhz)
or BITNET
hardie@dvinci.usask.ca