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.

FBB inittnc(x).sys

INITTNCx.SYS (\FBB\SYSTEM).

 This file is also in the SYSTEM-directory. When the BBS starts, it sends
some standard parametres to the TNC, like PACLEN, MAXFRAME etc. These
parametres are in PORT.SYS. But in addition to this we may send some more
parametres to each TNC. We send parametres to TNC 1 with the INITTNC1.SYS, to
TNC 2 with INITTNC2.SYS etc. Here is just one example from LA1B BBS : (you do
not need to use the same parametres)

 C MAIL v LA7QR
 U 0
 N 10
 M IU
 P 64
 T 40

 C MAIL V LA7QR means that unproto mail-beacon will be sent to MAIL via the
digipeater with callsign LA7QR. You may use just C MAIL if you do not want to
send via digipeaters. U 0 means that the TNC will not send any TNC-message to
user when he connects to the BBS. You should use this parametre.

 N 10 means that RETRY will be set to 10.

 M IU means that that all I and UI frames will be shown in monitor-windows. P
64 means a p-persistence value of 64. This is normal.

 T 40 sets a TXDELAY of 40. This value depends on Transceiver in use. So, you
can use any suitable parametres in this file. You need one file for each TNC.

 The commands sent to the TNC, are the commands described in the
documentation for the firmware you use, or in the documentation for PK*-232,
DRSI, BPQ etc.

FBB BPQ Port

G8BPQ-node (uses TNCs in KISS-mode, DRSI cards, etc...).

If you plan to use BPQ-node with this software, you must make some changes.
Before you start FBB, you must load the BPQ-program.

From version 4.05 of BPQcode, separate ports can be declared. Level 2
connections issue to the MultCh in the same order as PORTs declared in the
BPQCFG.TXT (G8BPQ distribution) file. First port corresponds to MultCh 0.
Level 4 connections (from the network) always issue to MultCh 0.

In <a href="https://packet-radio.net/fbb-port-sys/">PORT.SYS</a> you must use 2 in INTERFACE, and Q in type host mode. Version
4.05 or up is recommended. COM can be from 1 to 8, but will exclude existing
COMs. Choosing 8 is a good solution to keep existing COMs. We recommend
that you use COM 8.

Only the <a href="https://packet-radio.net/fbb-inittncx-sys/">INITTNCx.SYS</a> for the 1st port must exist. You must check that there
is only one INITTNCx.SYS file for all BPQ-ports, otherwise you will have
big problems! The parameters for other ports will be taken by default, and then
no conflict should happen between ports. If you want to define the streams
differently on each port, you can do it with the INITTNCx.SYS file, but be sure
to give the right configuration. INITTNCx.SYS will look like this:
A1
R0
UMAIL
M1
N1

If paclen is equal to 0, then the default BPQ paclen of the port will be
taken, otherwise the specified paclen will overwrite the default BPQ paclen.

If you have validated the gateway, you must configure ENABLE_LINKED=A in
BPQCFG.TXT to give to the stream the callsign of the user.

Here is an example of PORT.SYS with BPQ-node and 2 TNCs:

#
#Ports TNCs
1 2
#
#
#Com Interface Address (Hex) Baud
8 2 0 4800
#
#
#TNC NbCh Com MultCh Pacl Maxfr NbFwd MxBloc M/P-Fwd Mode Freq
1 8 8 0 230 4 1 10 30/60 UQYW VHF
2 1 8 1 80 1 1 5 30/60 UQYW HF
#

Example of INITTNCx.SYS for BPQ 4.05 (Only ONE INITTNCx.SYS) :

A1 Number of application
R0 Returns to node (0=No,1=Yes)
UMAIL Unproto MAIL
M1 Monitor (0=No,1=YES)
N1 Number of first stream

The parameters for other ports will be taken by default, For instance, as the
first stream of the first port is 1, the first stream of the second port will
be 9. (8 channels defined in PORT.SYS for port 1). This will be done
automatically, and the second INITTNCx.SYS should not exist.

In FORWARD.SYS there are a few changes, here is a short example:

A LA2D
#
P B
#
C C SWITCH Connect first BPQ switch.
C C 2 LA2D Connect LA2D on port 2 of BPQ.
#
B LA2D
F LA2D
#
---------

For WinFBB:

If you are using WinFBB together with BPQ-code you have to copy the files

BPQCODE.386
BPQDLL.DLL

to the \WINDOWS\SYSTEM directory. These files are normally included in the
BPQ programpack.
After this you starts BPQ in the same way as with DOSFBB, but before starting
WINDOWS. The best is to start BPQCODE from AUTOEXEC.BAT.

For LinFBB:

BPQ cannot be used with LinFBB....