FBB Connections filtering

 software allows filtering on connection. Filtering is not done by the
BBS software but by external programs developed by users.

 When the BBS starts, the C_FILTER does not really need to be there.  But at
the first connect it must exist.  If it does not exist at THAT time, it will
not be checked again.  So if a C_FILTER is added after that, the BBS must be
rebooted for the filter to take effect.

 Connection filter may be interactive and allows to incorporate some features
like dedicated information for predefined callsigns, password filtering,
etc...

 The C_FILTER program must be found by the PATH of MsDos. Its extension can
be COM or EXE, and it must be little and fast as multitasking is stopped
during the activity of this program. If this program is not found, it will
not be called until the BBS is rebooted.

 The C_FILTER may also be created as a DLL.  Both for WinFBB and DosFBB (!!).
The filter must be installed in the path (\FBB\BIN) of Dos.

 When receiving the connection, the C_FILTER program (if found) is called
with some arguments including a level number. This number is incremented each
time the program is called in the same connection session. The first time the
level number will be 0.

 The line arguments given to the C_FILTER program are :

- Callsign (format as F6FBB-8).
- Level number (0 is the first time, up to 99).
- Flags of the user (binary number as user`s mask of INIT.SRV).
- New : Flag indicating if the user is unknown in the BBS database.
- Record number of the user in INF.SYS.
- New: one more parameter before the optional text. It indicates the
  port where was connected the user.
- Received data (in one argument).


 The C_FILTER program ends with an exit value. This value is very important
and tells the BBS what to do :

 Return value (for C_FILTER):
 0 : Connection is accepted
 1 : C_FILTER will called again, level is incremented
 2 : Connection is refused, user is disconnected
 3 : Connection is accepted, but in read-only mode
 4 : Connection is accepted, but messages will be hold.
 100 and up
   : C_FILTER will called again, next level is equal to the return value.




Example of C_FILTERs.  First C_FILTER.EXE, next C_FILTER.DLL:

Example C_FILTER.EXE:

/*
 * C_FILTER.C
 *
 * Connection filter for FBB BBS software. (C) F6FBB 1991.
 *
 */

#include <stdio.h>

/*
 * Connexion filter called for each connection.
 * All datas sent to stdout will be sent to the user.
 *
 * Filter is called with some arguments on the command line :
 * C_FILTER CallSign Level Flags New Record ReceivedData....
 *
 * The return value tells the BBS if C_FILTER must be called again or not
 * 0 if the BBS can go on,
 * 1 if the C_FILTER must be called again
 * 2 if the user must be disconnected.
 *
 * Callsign is in the FORM CALLSIGN-SSID (F6FBB-0).
 *
 * The first time C_FILTER is called Level=0, and then will be incremented
 * each time it is called for the same connection.
 *
 * Flags give the flags of the user (MGPBSXLE) in a bit field. as defined
 * in the INIT.SRV user's mask. (0x80=Modem, 0x40=Guest, etc...)
 *
 * If New=1, then this is the first connection of the user on the BBS.
 * Record is the record number in the INF.SYS file.
 *
 * All other arguments are the words sent by the user
 * (password for instance).
 *
 * The number of arguments is variable and depends of the number of words
 * in the answer of the user.
 *
 */


/*
 * This is only a little example to test the system. It will be called
 * four times and will give the list of arguments.
 *
 * The fourth time, the hand will be given back to the BBS.
 */

main(int ac, char **av)
{
  int i;
  int level = atoi(av[2]);            /* Get level from argument list  */
                                      /* and transform it to integer   */

  if (level == 0) {                   /* Is level equal to 0 ?         */
    printf("Connection line :\n");    /* This is the first call        */
    for (i = 0 ; i < ac ; i++)        /* List line arguments           */
    printf("%s ", av[i]);
    putchar('\n');
    return(1);                        /* C_FILTER must be called again */
  }
  else {
    printf("Following line  :\n");    /* These are other lines         */
    for (i = 0 ; i < ac ; i++)        /* List line arguments           */
      printf("%s ", av[i]);
    putchar('\n');
    if (level == 4)                   /* Is it the last time ?         */
      return(0);                      /* Yes, go on BBS                */
    else
      return(1);                      /* No, call once more C_FILTER   */
  }
}


Next example, C_FILTER.DLL:

#define STRICT
#include <stdio.h>
#include <windows.h>

/*
 *    Code (C) F6FBB 1995-1996
 *
 *  C_FILTER example
 *
 *  svc_main is the only exported function. It must exist as WFBB will
 *  look for it. All filters are in the same format. If not NULL,
 *  r_buf allow to give a direct text back to the BBS
 * The size of the buffer is given by the parameter len.
 *
 *  Answers may also go to stdout (slower...).
 *
 *  This code is only an example and was not fully tested. It could
 *  give problems as I am not an expert !
 *
 * The used compiler is a Borland C++ 4.5
 *
 *  The DLL is not linked with the code, but checked and loaded when
 *  needed by WFBB.
 *
 * This is an example of the C_FILTER.DEF file :
 *
 *  LIBRARY        C_FILTER
 *  DESCRIPTION    'C_FILTER DLL for FBB'
 *  EXETYPE        WINDOWS
 *  CODE           PRELOAD MOVEABLE DISCARDABLE
 *  DATA           PRELOAD MOVEABLE SINGLE
 *  HEAPSIZE       1024
 *
 *
 * Parameters are (for C_FILTER):
 * ac[0] : The name of the filter (C_FILTER)
 * ac[1] : The callsign and SSID
 * ac[2] : Level number (from 0)
 * ac[3] : Flags
 * ac[4] : Boolean for new user
 * ac[5] : Recordnumber in INF.SYS
 * ac[6] : Port number
 * ac[7] : Optionnal Command received
 * r_buf : The buffer to put an answer
 * len   : The size of the answer buffer
 *
 * Return value (for C_FILTER):
 * 0 : Connection is accepted
 * 1 : C_FILTER will called again, level is incremented
 * 2 : Connection is refused, user is disconnected
 * 3 : Connection is accepted, but in read-only mode
 * 4 : Connection is accepted, but messages will be hold.
 * 100 and up
 *   : C_FILTER will called again, next level is equal to the return value.
 *
 */

int _export FAR PASCAL svc_main (int ac, char FAR ** av, char FAR * r_buf, int len)
{
	if (len > 20)
	{
		sprintf (r_buf, "Inside the C_FILTER\r");
	}
	return (0);
}

FBB Programming servers

Programming technics for servers.

 The servers are exec programs (.COM or .EXE). They are compact and fast.
They will work as the function of the messages which are addressed to them.

 They should be compact because the available memory to run their application
is limited (check the information Ok:nnnn in the status window). They should
be fast because they are executed in the MsDos environment which is not
multi-task.

 The programming language can be of any kind provided that it could be
compiled and that it is able to read parameters which are given appended in
the command line.

 I wrote three servers in TurboC but I have no equivalent in TurboPascal or
in TurboBasic, since I usually don't write in these languages. The working
principle remains always the same whatever language is utilized.

 The program is called with the following manner from the MsDos (Example for
the REQDIR.COM command) :

 C> REQDIR.COM TEMP.$$$

 TEMP.$$$ is the name of the file in which the message addressed to REQDIR is
located. It is necessary to read the name of this file in the command line,
as the one can change from one call to another.

 The file TEMP.$$$ contains the message with the following format :

 SP REQDIR < F6FBB
 Title of message
 Text of message line 1
 Text of message line 2
 ...
 Text of message last line.
 /EX

 The server should then eventually work as a function of the contents of this
message.

 The server can read and make use of the configuration file of the BBS
software (in particular INIT.SRV) to execute its process.

 If the server generates a return message, it should be APPENDED to the
incoming mail file to the BBS. The name of this file can be found in
INIT.SRV. Take care : it is necessary to open the incoming mail file in
APPEND as to add the answer at the end of the file. If it is not done this
way, the messages which could be waiting in this file are destroyed.

 The incoming mail file is tested each and every minute, except in the case
of the usage of a service, where it is tested right after.

 The format of the messages in the incoming mail file is identical to the
format of the file given to the server. Several messages can be written
sequentially in the file. There should not be blank lines or separations
between the messages. The routing fields (@ field), and the originator (<
field) should mandatory be specified. The originator field is the callsign of
the BBS which is taken from the INIT.SRV file.


 Example of server REQFIL written in C language.

/*
 * REQFIL.C Server example.
 *
 * This server is called with a command line like this :
 *
 * REQFIL.COM FILE
 *
 * FILE is the filename of the message to be answered.
 *
 *
 * This server answers to a message like this :
 *
 * SP REQFIL < FC1EBN
 * TEST.TXT @ F6ABJ
 * Text is not necessary
 * /EX
 *
 * by a message like this
 *
 * # <- This is a local message
 * SP FC1EBN @ F6ABJ < F6FBB <- command line
 * Req File : TEST.TXT <- subject
 * Contents of the file <- text
 * etc.....
 * /EX <- end of text (must be in 1st column)
 *
 * Appent to mail in bbs file.
 *
 *
 * The server receives from FBB software 1 argument :
 *
 * argv[1] = Name of the file including the message received from
 * FBB software.
 *
 * ============================================
 * The server must APPEND its answer to MAIL.IN
 * file to avoid destroying existing mail.
 * ============================================
 *
 * As this server opens the INIT.SRV file, it must be in the same
 * directory.
 *
 */

 #include <stdio.h>
 #include <fcntl.h>
 #include <sys/stat.h>

 /* Offsets of parameters from INIT.SRV */

 #define BBS_CALL 1
 #define USER_DIR 8
 #define MAIL_IN 14

 main(int argc, char **argv)
 {
 #define LINE 80
   int end = 0;
   int index = 0;
   FILE *fptr;
   char buffer[LINE];
   char sender[LINE];
   char route[LINE];
   char file[LINE];
   char bbs_call[LINE];
   char base_dir[LINE];
   char mail_in[LINE];

   if (argc != 2) exit(1);            /* Check the number of arguments */

   /* The first task is to open and then read the message */

   fptr = fopen(argv[1], "rt") ;      /* Open the received message */
   if (fptr == NULL) exit(1);

   fgets(buffer, LINE, fptr);         /* Read the command line */
   sscanf(buffer, "%*s %*s %*s %s\n", sender);

   *file = *route = '\0';
   fgets(buffer, LINE, fptr);         /* Read the subject */
   strupr(buffer);                    /* Capitalize */

   /* Scan dir and route */
   sscanf(buffer, "%[^@\n]%[^\n]", file, route);

   fclose(fptr);                   /* All needed is read in the message */

   /* We must get some informations from the INIT.SRV file */

   fptr = fopen("INIT.SRV", "rt"); /* Open the file */
   if (fptr == NULL) exit(1);

   /* Scan the file to get the requested lines. */
   while (!end) {
     fgets(buffer, LINE, fptr) ;
     if (*buffer == '#') continue; /* Comments ignored */

     switch (++index) {

     case BBS_CALL:
       sscanf(buffer,"%[0-9A-Za-z]", bbs_call);
       break; /* Callsign */

     case USER_DIR:
       sscanf(buffer,"%s\n", base_dir);
       break; /* Users directory */

     case MAIL_IN :
       sscanf(buffer,"%s\n", mail_in);
       end = 1; /* Mail in file */
       break;

     }
   }

   fclose(fptr);

   /* Append the answer to mail in file */
   /* Mail in file is opened in appent text mode */

   if (fptr = fopen(mail_in, "at")) {

     /* Tell that this is a message from this BBS */

     fprintf(fptr, "#\n");

     /* Send command line */
     fprintf(fptr, "SP %s %s < %s\n",
     sender, route, bbs_call);

     /* Send subject and requested file */
     send_file(fptr, base_dir, file);

     /* Send end of message */
     fprintf(fptr, "/EX\n");

     /* That's all ! */
     fclose(fptr);
   }
   exit(0);                                /* Tell BBS all is correct */
 }

 int points(char *ptr)   /* Looks for a ".." sequence in the path */
 {
   while (*ptr) {
     if ((*ptr == '.') && (*(ptr+1) == '.')) return(1);
     ++ptr;
   }
   return(0);          /* ".." not fond ! */
 }

 send_file(FILE *fptr, char *base_dir, char *filename)
 {
 #define BUF_SIZE 1000
   int fd;
   int nb;
   char path[256];
   char buffer[BUF_SIZE];
   char last_char;

   sprintf(path, "%s%s", base_dir, filename);       /* Complete path */

   fprintf(fptr, "ReqFil 1.1 : %s\n", filename);       /* Subject */

   if ((!points(path)) && ((fd = open(path, O_RDONLY | O_TEXT)) != -1)) {
     while (nb = read(fd, buffer, BUF_SIZE)) {
       fwrite(buffer, nb, 1, fptr);
       last_char = buffer[nb-1];
     }
     close(fd);

     /* Be sure /EX will be in first column */
     if (last_char != '\n') fputc('\n', fptr);

   }
   else fprintf(fptr, "File not found !\n");
 }

FBB Wildcards

Replacement characters or wildcards.

Most of the search commands or list commands and some configuration files
as well, accept replacement characters or wildcards.

 Character Replaces
 -----------------------------------------------------------------
 @         a letter
 ?         an alphanum character (letter or number)
 =         a printable character
 #         a numeral character or the # character
 *         a string of printable characters.
 &         a dot followed by printable characters. (equiv to .* )
 -----------------------------------------------------------------

FBB Format of ACK-messages

The ACK messages on receiving have a simple and compact format. The aim is
to have a message as short as possible in order to avoid an unnecessary usage
of the network.

 The title of the message is the title of the original message with a leading
"ACK:". Example :

 ACK:Title of the original message.

 These ACK messages are true messages strictly speaking. They carry the
origin, the destination, the route and the MID but they are of a particular
type, the type A (private are of type P, bulletins of type B, etc...). This
difference allows the routing of these messages without the lines "R:". This
is done again with the aim of avoiding an excessive load by data which are of
no use in this case.

 To keep the compatibility with the existing forwarding protocol, the type of
these messages is changed to P (private) if the receiving BBS of the
forwarding does not know the type of ACK messages (specified in the SID [FBB-
5.12-ABFHM$] by the letter A). In this case, the ack message will continue on
its route as a private message.

 The ACK messages are of the following form :
 ACK:Message test. <-- Title of message
 Msg FD1CDC@F6FBB - 22-dec 17:28z <-- Text of message

 It tells that the message that you had sent to FD1CDC at F6FBB and whose
title is "Message test" has been received in the BBS F6FBB on 22 dec at 12:28
GMT.

FBB Compressed forward

Extension to the protocol. Compressed forward FBB.


The protocol utilized for the transfer of ascii files compressed is an
extension to the existing protocol. The compressed forward is validated by
the presence of the letter B in the SID [FBB-5.12-BFHM$]. The transfer of
compressed files can only take place under FBB protocol. The presence of the
letter B in the SID without the F letter will remain without effect.

The only difference as regard to the standard protocol is the submit line.
It can specify the type of data contained in the compressed message. FA means
that the transfer will be an ascii compressed message. FB means that the
message will be a binary compressed file (this last possibility is not yet
implemented in the version 5.12).

The submission of an ascii message will be in the form :
FA P FC1CDC F6ABJ F6AXV 24754_F6FBB 345

The submission of a binary file will be in the form :
FB P FC1CDC F6ABJ F6AXV 24754_F6FBB 345

The transferred data are of a specific format. The transfer will be done in
binary mode. This last one is derived of the YAPP protocol which is very
reliable. All transfer is made of a header, a block of data, an end of
message and a checksum. Each transfer is equivalent to the transfer of one
message of the standard protocol and shall not be followed by a control Z,
the end of file specifier is defined in another way.

Format of header for an ascii compressed message (submission FA) :

<SOH> 1 byte = 01 hex
Length of the header 1 byte = Length from the title,
                               including the two <NUL> characters.
Title of the message 1 to 80 bytes
<NUL> 1 byte = 00 hex
Offset 1 to 6 bytes
<NUL> 1 byte = 00 hex

Format of header for a binary compressed file (submission FB) :

<SOH> 1 byte = 01 hex
Length of the header 1 byte = Length from the filename,
                               including the two <NUL> characters.
Name of the file 1 to 80 bytes
<NUL> 1 byte = 00 hex
Offset 1 to 6 bytes
<NUL> 1 byte = 00 hex

As to follow the french regulation, the title of the message or the file
name are transmitted in ascii, not compressed.

The offset is also transmitted in ascii and specifies the offset at which
the data should be inserted in the file (in case of a fragmented file). In
the version 5.12, this parameter is not utilized and is always equal to zero.

A data block contains from one to 256 bytes. It begins by two bytes which
specify the format.

Data block format :

<STX> 1 byte = 02 hex
Number of data 1 byte = 00 to ff hex. (00 if length = 256 bytes).

  Data bytes 1 to 256 bytes

The last data block is followed by the end of file specifier and the
checksum.

End of file specifier format :

<EOT> 1 byte = 04 hex
Checksum 1 byte = 00 a ff hex

The checksum is equal to the sum of all the data bytes of the transmitted
file, modulo 256 (8 bits) and then two's complemented.

The checking of the checksum is very simple :

The sum of the data from the file and the checksum received modulo 256
anded with FF) shall be equal to zero.

In case of a checksum error, the message or the file is not taken to account
and the system issues a disconnect request after having sent the comment :

 *** Checksum error

Extension to the protocol. XFWD compressed forward.

 X forwarding Protocol is implemented.  
 XForwarding now supports re-routing and swapping.
 Binary forwarding via telephone modem (FBB or XFWD)

FBB forward protocol

FBB software includes two forward protocols. The first one is standard with
MBL/RLI  protocol.  The  second  one  was  developed  to  allow 
efficiency, particularly on long links where propagation time of data are
long. The exchange of commands is reduced to a minimum, and not acknowledged
to get time. The data transfer direction is changed every block of data, a
block of data holding up to five messages. This uses the "pipeline" effect of
long links (Nodes and digipeaters), and gain some time over short links
(HF...).

FBB protocol is very simple in its principle. It is based on MID/BID usage.
The identification is made by the F letter in the SID (system type identifier
contained in square brackets). All command lines must start in first column
with the 'F' character. All command lines are ended by a return (CR)
character.

Suppose I call another BBS to forward some mail. When I connect another BBS
using FBB protocol, I will receive the SID followed by a text and the prompt
(">"). If the SID contains the F flag, I will send immediately my SID and the
first proposal.

 Proposals looks like :

 FB P F6FBB FC1GHV FC1MVP 24657_F6FBB 1345
 F> HH

 FB : Identifies the type of the command (proposal)
 P : Type of message (P = Private, B = Bulletin).
 F6FBB : Sender (from field).
 FC1GHV : BBS of recipient (@field).
 FC1MVP : Recipient (to field).
 24657_F6FBB : BID ou MID.
 1345 : Size of message in bytes.
 F> : End of proposal.
 HH is optional. It is the checksum of the whole proposal in hexadecimal.

 ALL the fields are necessary. This kind of command must hold seven fields.
If a field is missing upon receiving, an error message will be send
immediately followed by a disconnection.

A proposal can handle up to five FB command lines. If the total size of
messages seems to be too important, the proposal can handle less lines. In
FBB software, a parameter is defined in INIT.SRV file to tell the maximum
size of the message block. It is set by default to 10KB.

 Example of proposal :

 FB P F6FBB FC1GHV.FFPC.FRA.EU FC1MVP 24657_F6FBB 1345
 FB P FC1CDC F6ABJ F6AXV 24643_F6FBB 5346
 FB B F6FBB FRA FBB 22_456_F6FBB 8548
 F> HH

This proposal is limited to three FB lines, as the amount of messages
overran the 10KB limit.

When receiving the proposal, the other BBS will reject, accept or defer the
message. This command is made by a FS line :

 FS -+=

 This means :

 - I don't want the first message (-).
 - I need the second message (+).
 - I defer the third message, as I'm still receiving it.

 In the new version 1 of FBB protocol there are 3 more responses:
 R, E or H:

 "FS +R++" means that the second message is rejected. Only works with new 
 version of the protocol.
 The information is also written in the LOG like :
 MJ B:Message_Bid V:Callsign_Rejecting
 A warning message may be sent to the sending sysop when his message is 
 rejected (see INIT.SRV for more info on warning messages).
 The message is not marked as 'F', and still can be forwarded to another BBS

 "FS +H++" means that the second message is held. Only works with new 
 version of the protocol.
 The information is also written in the LOG like :
 MH B:Message_Bid V:Callsign_Rejecting
 A warning message may be sent to the sending sysop when his message is 
 held (see INIT.SRV for more info on warning messages).

 "FS +E++" means that the second message has a format error. Only works 
 with new version of the protocol. 
 A warning message may be sent to the sending sysop when his message  
 proposal is wrong (see INIT.SRV for more info on warning messages).

 It should interesting to defer a message if you are still receiving it on a
other channel, or if you think that the size is to big, or for another
reason. The message should be proposed again at the next connection.

 FS line MUST have as many +,-,=, R, E, H signs as lines in the proposal.

When receiving the FS lines, I can send the block of messages. Each message
is made with the title on the first line, the text, and a Ctrl Z in the last
line. The is no blank line between the messages.

 Title of 2nd message
 Text of 2nd message
 .....
 ^Z

When the other BBS has received all the asked messages, it acknowledges by
sending its proposal, and the system is reversed.

 If it has no message to send, it only sends a line :

 FF

 This line must not to be followed by a F>.

 If the other hand has no message, it sends a line :

 FQ

 and asks for the disconnection.


 Example :
 ---------

 F6FBB                          FC1GHV
 ----------------------------------------------------------------

 Connects FC1GHV

                                Connected

                                [FBB-5.11-FHM$]
                                Bienvenue a Poitiers, Jean-Paul.
                                >

 [FBB-5.11-FHM$]     (F6FBB has the F flag in the SID)
 FB P F6FBB FC1GHV.FFPC.FRA.EU FC1MVP 24657_F6FBB 1345
 FB P FC1CDC F6ABJ F6AXV 24643_F6FBB 5346
 FB B F6FBB FRA FBB 22_456_F6FBB 8548
 F> HH

                                FS +-+ (accepts the 1st and the 3rd).

 Title 1st message
 Text 1st message
 ......
 ^Z
 Title 3rd message
 Text 3rd message
 ......
 ^Z

                                 FB P FC1GHV F6FBB F6FBB 2734_FC1GHV 234
                                 FB B FC1GHV F6FBB FC1CDC 2745_FC1GHV 3524
                                 F> HH

 FS -- (Don't need them, and send immediately the proposal).
 FB P FC1CDC F6ABJ F6AXV 24754_F6FBB 345
 F> HH

                                 FS + (Accepts the message)

 Title message
 Text message
 ......
 ^Z

                                 FF (no more message)

 FB B F6FBB TEST FRA 24654_F6FBB 145
 F> HH

                                 FS + (Accepts the message)

 Title message
 Text message
 ......
 ^Z

                                 FF (still no message)

 FQ (No more message)

 Disconnection of the link.


In this example, FBB protocol is used as the two BBS were identified by the
F flag in the SID. If F6FBB had sent the SID [FBB-5.11-MH$] when answering
FC1GHV, the protocol should be the standard MBL/RLI.

 All callsigns are only examples !

 

FBB Tricks and tips

 This rubric is yours, more than mine. I'll try to insert there all tricks
you will tell me.


Only for DosFBB:
Using DesqView (c).
-------------------
 There is no particular problem when using DesqView. The minimum window size
is 500 KB. You MUST use communication drivers, like ESS, COMBIOS or MBBIOS,
as the software does not dispose of the whole process time.


Communication errors displaying.
 -------------------------------
An error counter can be displayed 
in WinFBB: after the word "Resync" on the screen
in DosFBB: just right of the date, on the first line of the screen.
If you are using TNC2 with WA8DED software, these errors can be minor, but
with PK232, error recovery is more difficult, and the system may reboot.

 With a correct operation of your system, this counter will not appear, or
exceptionally. If errors are displayed, they can result from :

 - Using DOS 4.0 or 5.0 : The keyboard driver of these versions is very slow.
You must use the ESS driver for RS232 (or COMBIOS).

 - A too hight baudrate, or RS232 defective cables. The baudrate can be
selected down to 4800 Bds. It is not a good idea to go down 4800 Bds, as the
performance of the software should be lower.

 - Change the LM324 fitting out some TNC RS232 line drivers by a TL074 or
TL084.

 - HF detection in the TNC. Errors and resynchronizations will appear when
the transmitter is running. There is no real cure, you must investigate.

 You can also use communication drivers like ESS, COMBIOS or MBBIOS if you
are not still using them.


Repeat the last message number.
--------------------------------
 The last message number displayed, read, killed, etc... can be utilized
again with the # (pound) character. This short-cut allows as for an example
to read a message after a list or to suppress it just after its reading.

 Example :

 F6FBB BBS ; R 12351
 The message is displayed ...
 F6FBB BBS ; K #
 Message #12351 killed.
 F6FBB BBS ;



									

FBB Recording a message

A message can be left by a user or within a forwarding connection. The
recording mechanism is always the same.

 The recording command is always like :

 Sx desti @ bbs < exped $ ident + filename

 Only recipient field is mandatory, all other fields are optional.

 Appending a filename is a possibility reserved to the sysop. The name must
be complete, including logic unit and complete path (C:\FBB\SYSTEM\TEST.TXT).

 When receiving the command line, a first test checks if a route exists when
a route has been specified, or if the message must be automatically routed
when no route was specified.

 The title of the message is then asked to the user.

 If the title is a missing, the message is canceled and the user returns to
the main menu.

 The text of the message is then asked to the user.

 The software checks possible preamble lines. These lines give information
on the previous BBS having routed this message. They all begin by R: on first
column. The BBS callsign is given behind the @ character within the preamble
line. All adjacent BBS mentioned in this preamble will be included in the
"already forwarded" list, and will not be concerned by this message. This
list specific to each message can be displayed with the $ or FN command
followed by the message number.

 When receiving a /EX in first column, or a Ctrl Z, a message number is then
assigned, The BID (or MID if private) and the list of adjacent BBS concerned
by this message are created. All these information are sent to the user when
acknowledging the message.

 In case of disconnection before the /EX or Ctrl Z, the whole message will be
lost, and the texts already stored are deleted.

 All information about the message (sender, recipient, route, MID, title,
etc...) are stored in the DIRMES.SYS file. The text of the message is stored
in a sub-directory of the MAIL directory. The sub-directory is MAILn where n
is the last digit of the message number. The name of the file corresponds to
the message number 123 is M_000123.MES, the number is 6 digits wide, in this
case it is in the sub-directory MAIL3.

 The message number uses a long integer (32 bits), the number boundary is
very far (more than 4 billions !).

FBB Process numbers and help

Process number and on-line help identification.

 The various processing functions contained in the software are identified by
three numbers displayed in the status banner. The first of those three
numbers  is  the  main  process  system  (BBS,  FBBDOS,  Satellite
Computation, etc...), the second number is the process function (in the BBS,
list, message sending, etc..) and the third number is a sub-function (record
of the message title, message, etc..)

 A complete description of these numbers would be useless and time consuming.
They are mainly used for debugging purpose. The first number is also used to
identify the help block out of the x.HLP file. Upon receipt of the "?" or the
"H", the  software  searches  the  x.HLP  file  for  a  line  of  
corresponding to the language in use, and of the format @@ number word in
which "number" stands for the current processing level, and "word" stands for
the word following the command "?" or "H".

 Example : you are inside FBBDOS, and you type in the command "? EDIT", the
help block searched for must begin with the line:

 @@ 9 EDIT

 It may happen that a block matches several search keywords. It is enough to
specify the various words separated by the character "|" (vertical bar), WITH
NO SPACE.

 @@ 9 EDIT|EDITEUR

 List of the processing levels :

 0 Connection.
 2 Qra-Locator.
 3 Statistics.
 4 Information.
 5 Nomenclature.
 6 Satellite Orbital Computation.
 9 FbbDos.
 11 Telephone Modem
 14 BBS.
 15 Forward.
 16 Gateway Sysop page.
 17 YAPP.
 18 Conference.

FBB DRSI-card

 

 If you plan to use DRSI-card with this software, you must make some changes.
Before you start FBB, you must load the DRSI-driver that comes with the DRSI-
card. This must be TNCTSR-R or TNCTSR-L with a version-number higher or equal
to 2.1.

 The first DRSI-card (MultCh 0 and 1) must be at address 300.
 The second DRSI-card (MultCh 2 and 3) must be at address 310.
 The third DRSI-card (MultCh 4 and 5) must be at address 308.
 The fourth DRSI-card (MultCh 6 and 7) must be at address 318.

 Before installing cards in the PC, use the program CHKADDR to verify that
the addresses corresponding to the cards have a value of FF. If there is a
problem, check your configuration to find what peripheral is already using
this address. Install just one card at the time, and verify each cards
presence with CHKADDR.

 When all cards are ok, configure the driver by means of the TAILORnn program
(depending of the version). TNCTSR-S will be ok if you use only a few
channels, while TNCTSR-L should be used for big configurations, up to 32
channels.

 One problem: What DRSI calls DRSI-PORT, is what we call MultCh in FBB ! What
DRSI calls PORT, is what FBB calls port or TNC ! We always use FBB-names
here...

 Each DRSI-card works like 2 radio-ports. The first DRSI-card is always
MultCh 0 and 1, and the forth card is MultCh 6 and 7. If one radio-port is
used on HF, that port must be the second port on the card.

 All the DRSI-cards together, work like only one COM. And this COM-port does
not need to exist in the PC. You may call that port COM 7 or COM 8 and keep
free the already existing COMS.

 Baud-rate does not matter, but should be set to a standard value, to avoid
error-messages.

 Here is an example of PORT.SYS with 2 DRSI-cards (4 radios) :

 #
 #Ports TNCs
 1      4
 #

 #
 #Com Interface Address (Hex) Baud
 7    4         0            4800
 #

 #
 #TNC NbCh Com MultCh Pacl Maxfr NbFwd MxBloc M/P-Fwd Mode Freq
 1    8    7   0      230  4     1     10     30/60   UDYW 433.650
 2    1    7   1      80   2     1     5      12/30   GDW  15/20m
 3    8    7   2      230  4     1     10     36/60   UDYW 433.650
 4    8    7   3      230  4     1     5      10/30   GDW  145.300
 #

 If you are using DRSI-card, you also must change the INITTNC1.SYS. You will
need only ONE file for all the ports.

 Example of INITTNC1.SYS that initializes 4 ports:
 MUIS
 U0
 p0 1 64 10 4 4 10 100 18000 30 2 0
 p1 1 64 10 4 1 16 100 18000 30 1 0
 p2 1 64 10 4 4 10 100 18000 30 2 0
 p3 1 64 10 4 4 10 100 18000 30 2 0




 The same goes for MAINT1.SYS, only 1 file is needed for all 4 ports, like
this:


 Y 1
 U 1 BBS ($c) was shut down for service $d $T.


 In FORWARD.SYS there is no changes. Use standard syntax.