The Packet Radio BBS
Version 5.00 (Linux)
English Documentation
For Linux PC

Copyright (c)1990-1996 Joachim Schurig, DL8HBS, Berlin



back to content page

1. Credits

I would like to thank those radio amateurs that helped to develop DPBOX. Without them, their testing, their technical, mental and sometimes psychological help it would not have been possible to create this software.

Beyond many others, I would like to mention:

F6FBB Jean Paul (Toulouse), DL7QG Gerd (Berlin), DG0FT René (Strausberg), DL4YBG Mark (Berlin), DL7AND Michael (Berlin), DL1XAO Odo (Hamburg), DL7APN Chris (Berlin), DL1HAZ Walter (Hamburg), PE1NIB Chris (Wijchen), F6GIA Jean Marie (Le Tholy), DL1GJI Jimy (Mengen), DF2AU Georg (Brunswick), DJ1JV Horst, WB5LMJ Terry (West Palm Beach), DL5DI Hans-Juergen (Koblenz).

And, for her love, Nikoline.

Thank you all!

back to content page

2. Copyright

DPBOX is copyrighted by Joachim Schurig, Berlin, 1990-1996.

DPBOX/Linux is distributed under the terms of the GNU Public License.

DPBOX has reached a high grade of reliability. Nonetheless I have to disclaim that I cannot guarantee for safe and proper work of DPBOX. Therefore, all responsibility for damages that result to hardware and software through the use of DPBOX remain yours.

The authors address:

Joachim Schurig
Bergmannstr. 67
D-10961 Berlin


back to content page

3. System Configuration

DPBOX is a multi protocol and multi user BBS. In the delivered version it handles up to 200 simultaneous users. For stored messages there is a limit of 32767*32767 messages over all. Storing 30.000 messages or more is absolutely usual with DPBOX.

DPBOX supports compressed forward as proposed by f6fbb and his great FBB BBS. Extensions were provided to make forward still more efficient. This includes, among others, binary transparent message delivery in full 8 bit mode and extended CRC checksum protection.

DPBOX/Linux is only a part of a large packet radio environment for Linux. It takes advantage of the connect abilities of the TNT terminal program of DL4YBG, which itself uses different protocols to connect to the outside packet net.

The following pictorial may give you a small impression on what is possible:
(pictorial is only visible in the HTML version of this documentation)

DPBOX/Linux requires a Linux installation with at least 8 MB of true RAM. It still works with 4 MB, but system response time will be lowered dramatically. Swap file size should be set to about 20 or 30 MB. These will not be used by DPBOX under normal circumstances, but it is always nice having a free space for critical system states.

DPBOX does not need a huge amount of disk space. Compared with usual bbs systems it only needs about one third of space. For a typical bbs with an average of 15.000 stored messages and about 700 local users, 120 megabytes of disk space are sufficient. Limiting message lifetimes to some 30 days, even 50 MB may be sufficient.

Beside DPBOX, other services may run on the same computer (running Linux no one expected other). Currently, there are installations running the full tcp/ip protocol suite simultaneous to DPBOX, and much other is possible.

DPBOX mostly is installed with root permissions, however, there is no absolute need to do so. You only have to take care that all files in the box/ - directories are read/write able with the assigned rights of the DPBOX process.

DPBOX is designed for a stand alone remote installation. All configuration parameters may be changed by simple file uploads and on-line commands.

For most critical errors, DPBOX tries to find a solution itself. Sysop maintenance is no must. It may be useful in many cases, but if not available, the program acts itself. This includes rerouting of messages, auto path finding and, as a last effort, returning messages if not routeable in a specific interval.

back to content page

4. Installation

Installation of DPBOX is easy: uncompress and untar the dpbox.tgz archive file (use "tar -xvzf dpbox.tgz"). Edit the dpbox.ini - file. Edit all files in the system/ - directory according to your needs. At least, edit system/config.box !

DPBOX is a Unix daemon. To access to it, you need the TNT terminal, for local access you may also use the DPBOXT terminal (this is a stripped version of TNT).

For automatic startup of TNT and DPBOX, a watchdog and program starter named BOXSTART should be binded in the crond - tab.

For full documentation of BOXSTART and TNT refer to the belonging documentation.

back to content page

5. The Mailbox

The DPBOX is (by its user interface and S&F mechanisms) a synthesis of the in Germany well known TheBox system and the F6FBB system. The user interface of DPBOX is similar to TheBox, but the mail forwarding mechanism also includes the highly improved methods of F6FBB. DPBOX acts as a perfect intermediator between both systems.

back to content page

5.1. Linux

Running Linux, DPBOX uses the TNT terminal program written by Mark, DL4YBG, who also did a lot of the Linux adoptions in the source code of the BBS. Thank you, Mark.

DPBOX first was developed in Turbo Pascal on a Macintosh, using the Atari TOS emulator MagiCMac. The Linux version was automatically created by p2c, the amazing pascal-to-C translator of David Gillespie (thousands of thanks to his address) and the GNU C compiler. I have never seen a better program than the p2c, even my commercial PASCAL compiler had bugs - that were never seen with p2c.

Starting with version 5.00, DPBOX is directly maintained in C code. Primary compiler is Metrowerks Code Warrior on a Macintosh. Same code then is compiled with GNU C for Linux.

back to content page

5.2. Board Oriented System vs. MSG Number Oriented System

The user interface is different to that well known command set of the WA7MBL - oriented systems (as partially also F6FBB is). The reason is simple: in Germany, those BBS systems are not in use. I, the author, was used to the TheBox syntax. Try to habituate yourself to the TheBox syntax, it has its advantages, too.

The main difference is, that the message system is strictly 'board-oriented'. A LIST command will not, as with F6FBB and others, output all new files regardless of their destination but all new files of a board to be specified. The current board selection is always visible, it appears in brackets in the system prompt. If the brackets are empty, no board is selected and all board oriented commands (such as LIST, ERASE, READ) will only work with the explicit specification of a new board.

Another difference is, that the command names are more verbose, such as READ instead of R. But, you can abbreviate them if you like to.

The F6FBB system is message number oriented. In TheBox syntax, this is unknown. Of course, all messages of one board contain message numbers to distinguish them, but they count at every new board from 1. This results in small numbers, the human brain likes them more than high message numbers as #57293.

back to content page

5.3. A Typical Session In DPBOX - Syntax

Lets describe a typical session under DPBOX syntax, this makes the "philosophy" visible.

1) The user logs in.

2) Automatically, the selected board is the users personal mailbox. A LIST command is generated, automatically too. All new messages to the users personal board/mailbox since his last login are displayed. If there are no new ones, the last one is displayed. An example:

DigiPoint Box v3.60.00 operated by DL8HBS
Welcome Joachim!
Last login  : Monday, 15.11.93 21:27
Actual login: Monday, 22.11.93 10:11

Info-File: DL8HBS
Nr.  of     date     UTC  bytes title

1199 F6KVE  17.11.93 15:27 2750 DP3.5 ...
1200 DL7VC  17.11.93 15:27  721 Bin wieder qrv.
1201 DG2GIW 17.11.93 17:35  558 Was ich vergessen hatte...
1202 DK5AD  18.11.93 15:39  950 FRAGEN MAGIC!X
1203 DL1MCX 18.11.93 19:21 1299 Anfrage


Now, I would like to read my messages. This can be performed in three ways. The most simple is typing R. This reads all new messages of the selected board. Look at the above prompt, the selected board is (DL8HBS). As I am connected to my own BBS, the DL8HBS appears two more times hi.

I could also type R 1199- to read all messages starting with 1199. Also, I could type R DL8HBS 1199- , but the board DL8HBS is selected, so this is not necessary. Another possibility would be to type R 1200-1202 , this selects a subset of the new messages.

3) Now I read my mails and would like to erase them. I type E 1199- . The E is the abbreviation for ERASE.

4) I want to know which new bulletins are in the BBS. I type C (this is an abbreviation of CHECK).

The result is a list of the following type:

Check: ()

Nr Call     Area      Nr date     @mbx  bytes #LT title
 1 G7MQD  > DIVERSES...4 22.11.93 WW     2001   2 CHILDREN IN N
 2 G0MTQ  > SAT.......11 22.11.93 WW     1921 365 HELP QUIKTRAK 
 3 DG0FT  > BAYCOM.....1 22.11.93 BB     3847  10 NEU: TFPCX v2
 4 DL7OL  > KEPLER....10 21.11.93 DL     3725  30 NASA 2Line da
 5 DL7ATG > PACTOR....58 21.11.93 DB0BLO 4428 365 PTC und FSK

(the list is shortened in line length to fit in the printing form)

5) Now, I would like to read the bulletin from DL7ATG to PACTOR. I type R PACTOR 58 . This sets the board PACTOR as the current board and tells the system that I want to read the 58th message of that board.

6) I would like to see the older messages for PACTOR, I type L 1- . A list (shortened) appears:

Info-File: PACTOR
 Nr.of      date    UTC  bytes title

  1 DL1BIR 21.02.93 00:19 1956 KAM und Pactor Befehle?
  2 G3ZYP  25.02.93 20:57  973 ** CQ PACTOR & PACTOR MBO's *
  3 DU9BC  27.02.93 21:50 2442 DU-PACTOR STATION!!!
 57 DF7ML  07.11.93 14:43 3584 Mark-info aus LA
 58 DL7ATG 21.11.93 09:08 4428 PTC und FSK


7) I type Q (for QUIT), the connection is terminated.

back to content page

5.4. The Internal Commands Of The BBS

The DPBOX has a fixed set of internal commands. You can add an unlimited number of external commands, this will be described later on.

The command processor requires a file commands.box in the folder box/system/. This file contains the command names, equated to one of the internal command numbers. This means that you can change the command names. I beg you to let the basic set unchanged.

The command processor works with the 'first fit' - method. As said above, commands can be abbreviated. An 'E' will be recognised as 'ERASE' and not as 'EXPORT' because the position of 'ERASE' in the commands.box is first. The commands are not case sensitive.

In the commands.box, a flag determines if a command is only available for sysops. I propose you not to alter this flag.

Several commands require optional parameters to select a subset of the messages within a selected board. The syntax for these selections is as follows:

  1     msg 1 is selected
  1-5   msgs 1 to 5 are selected
  1-    all msgs are selected
  -5    msgs 1 to 5 are selected

The following two are only valid with the READ, LIST, ERASE, EXPORT and CHECK command:

< Search

all msgs having 'Search' in the title or senders field are selected. 'Search' may consist of several words.

1-5 < Search

all msgs from 1 to 5 having 'Search' in the title or senders field are selected. 'Search' may consist of several words.

The LIST command offers the optional use of the parameter "+n" , where n is the count of newest messages to be displayed.

If no selection was made, all new msgs are selected.

back to content page

5.5. Command Description


Ends the connection with the BBS. The logindate is not updated. The same is performed with a simple disconnect.




Sysop only. Displays the last entered command lines of every boxuser. Forward channels are displayed lowercase, with a direction indicator following the call sign.




Sysop only. You can start a batch file. This file contains text lines that will be typed as if you would type them manually. Please take care to use a correct syntax in a batch file, it is not aborted when errors are detected. Example:

BATCH system/cleanup.bat

Batch files are processed in sysop mode


Outputs information about other BBS'. Possible options:


displays information about the BBS db0xyz and shows you the path the mail router of DPBOX would take to send a mail to that station.


displays a list of all BBS having 'DB' as first letters in their call sign.

BBS < Berlin

searches for the BBS that has the string 'Berlin' in its mail header.


outputs all BBS in Florida, USA.


displays all bbs using WinFBB software.

You may use the wild card '*' in any combination.


Sysop only. Starts transmission of a mailbeacon manually. Useful for checking the definition of its parameters (file system/beacon.box).


Sysop only. Recreates the file boxlog.dp (the base of the checklist output). Normally, you won't have to use this command as GARBAGE includes this operation. Might be a useful command if you have the impression that the checklist is disordered.




Sysop only. Starting with v4.00, DPBOX is able to generate a PACSAT BBS Broadcast. Further information are given on other place in this document. With the BROADCAST command, the sysop can immediately switch on or off the BBS transmissions.



Sysop only. You can check the state of the BID pool. Without parameters you get some information about size, maximum size and the seek pointer. If the seek pointer is lower than the size, the pool was completely filled and will be overwritten from the beginning. This is normal. If you add a BID as parameter, the BID is searched and the position in the BID pool is displayed. The added option '-' deletes the BID in the pool, the option '+' appends the BID to the pool.

BULLID 12635_F6ABJ -
BULLID 12635_F6ABJ +

For normal BBS operation you should not delete BIDs.


The CHECK command is similar to L in F6FBB BBS. It shows you either

* all new bulletins in the BBS (C without parameters)

* all bulletins of a special subject (C < search, where 'search' is searched in the title and sender field of all existing mails)

* all new bulletins of a board (C ATARI)

* a subset of all bulletins (C 200-300, this shows you the last 200 to 300 bulletins; or C 50, this shows you the last 50 bulletins).


C 50
C 1000-1200
C < FT-757
C < WP Update

The CHECK command has the optional parameter '+'. If this is added to the command, instead of bulletins only private mails are examined. A nonsysop has access only to mails he wrote or received, a sysop has access to all private mails. Examples:

C +
C < DL8HBS +

Additionally, you may add the parameter '$', this means that instead of the date of the mail you get a display of its bulletin ID. When using the search- and the bulletin-ID in combination, you get an output of the searched Mail(s) having this BID(s). Examples:

C $
C 50 $
C 1000-1200 $
C < $DB0GR
C < $12345_DB0GR

Of course, you are free to combine the options the way you need it, so for example:

C 500 < DL8HBS
C 1000-20000 < $DB0GR
C + 100-300 < $DB0GR

and so on...

The search keyword may include wild cards (*):

C < FT*757

will look for FT-757, FT 757 FT757 etc.

See also: CS


uses the same syntax as CHECK, but the output of the command is sorted by its destination. This makes a long checklist much easier to handle.


Just for compatibility with BaycomBox. Changes the current board selection (the part of the standard prompt that appears in brackets).




is very similar to REPLY, the difference is that no private mail is generated but a message with the same destination and @mbx field as of the read mail.




COMP ON activates the huffman compression of the BBS. It will send a //COMP 1 answer and start compression at that time. COMP OFF switches the compression off, the answer is //COMP 0.


Allows a sysop to configure the config files of DPBOX on-line.



Returns the setting of the parameter REMOTE_ERASE in system/config.box


Sets the parameter REMOTE_ERASE in system/config.box to ON


Same as above. If the file is not found under the given name, DPBOX appends '.box' and '.sf' to the filename to check for existence. Search path for the file is box/, box/system/, box/sf/ (in that order).

CONFIG beacon DUMMY 1234

Appends the parameter DUMMY 1234 to the file system/beacon.box (if a parameter is not found in the given file, it will be appended at the end of the file).


returns a short syntax description of the command.

If you changed system settings with the config command, you have to enter RELOAD to make them effective.


Sysop only. This lets you connect a call via a given TNT interface. Syntax:

CONNECT <Call> [<QRG>] [<Timeout>]



If no interface QRG was added, the interface the user came in will be used. Check for valid interface QRGs with the QRG command.


The BBS offers a built-in converse mode. It is local only, you can not connect it to the Ping-Pong converse of TheNetNode, Wampes or other TCP/IP based network nodes.



starts converse, selected channel is 0.


starts converse, selected channel is 1234.

When in converse mode, try to enter /HELP for further help.

Converse is ended with /Q

Users may use channel numbers from 0 to 100.000, board sysops up to 200.000 and sysops up to ... hum, a real high number, lets say


Sysop only. You can enter a logon text that is displayed to all users. An old CTEXT is displayed and then deleted.


Sysop only. Requests or sets the current debug level of the bbs (until next RELOAD or restart).



Requests actual debug level


sets actual debug level to 5


switches debugging off

On RELOAD or restart the debug level is read out of system/config.box. Default is 0, range is from 0 - 5.


The DIRECTORY command displays a board list of the BBS. It has four different options:


displays the bulletin boards, the number after the name is the maximum lifetime for this board as set in RUBRIKEN.BOX (see below).


also displays the bulletin boards, but the number is the number of the last message in this board (which has, due to erased files, not to be the total amount of messages).


displays the user boards, the number is the number of the last message in the users board.


displays the bulletin boards as 'D' would do it AND all user boards without message count.


displays all user boards whose holders have a MyBBS other than the own BBS.

I is an abbreviation for INFO, U for USER, A for ALL and L for LOST.

Only those boards are displayed that have a lower or same access level as the user who typed the command.


Sysop only. You can disconnect either one or all users of your BBS. The options:


disconnects all users


disconnects DL9XYZ


disconnects the user on box port 6


disconnects all forward connects


disconnects all non-forward connects

A text may be added that will be displayed before disconnecting. Example:

DISC ALL sri, system maintenance works.


Erases the selected files of a board.

Note: the ERASE command of DPBOX does not work immediately. It only sets an erase flag in the file header of the file and makes it invisible. As a sysop, you can un-erase erased files up to the next GARBAGE or, depending on a configuration parameter up to several days. Refer to the commands HIDDEN and GARBAGE and to the setup of system/config.box.

Of course, a non-sysop can only erase files to or from himself.

To find out the corresponding message numbers, you need to use the LIST or CHECK command prior to the ERASE command.


E DL9XYZ 7-10

erases messages 7-10 of DL9XYZ

E 9

erases msg. 9 of the current board


erases message 12 of ATARI


erases all msgs of DL8HBS in DP


erases all msgs with BID from DB0GR in DP

ERASE without parameters erases all new messages of a users board (if it is the selected one). This does not work on bulletin boards, even not for the sysop.

A user may unerase mails to his own board with the UNERASE command. See UNERASE.

A non-sysop erase will create a remote erase message that is then forwarded to the network. Sysop erases need an appended '+' to the command to perform this (not that likely seen).

BBS systems with compatible mechanism (DieBox, BaycomBox) will then erase the marked bulletins, too. Note that due to heavy misuse of this feature by pirates, usually all BBS only accept the erase when performed in the originator-BBS of the original mail. As this doesn't stops all cases of misuse, DPBOX has the additional restriction that if a HOLD-DELAY is defined (in system/config.box), NO remote erase is sent out if the user didn't log in with password. As you may see, the HOLDDELAY in this case indicates, that the sysop of this BBS takes the security problems serious, so why should he allow unregistered users to delete mails in whole Europe.


Sysop only. Exports a specified message (or a number of messages) on disk. Syntax as READ, EXP ATARI 7-10 for example.

You are requested for a output file name. If the command is sent via packet, the output file name is export.box in the folder box/save/ . The .box may be substituted by an up counting number. Additionally, you may extend the command by an output file name:

EXPORT BBS 17 save/test.dat

If the exported file contains binary data (marked with (BIN) in the LIST and CHECK output), only the binary portion of the file is exported. Preceding text lines are cut. Also, the file name is expanded out of that one in the binary header. However, you have to append a file name to the EXPORT command as for ASCII files. Just in case that an original file name was found in the binary header, it is used. Just an example:

EXPORT UPLOAD 4 save/dddd

will be saved as save/dpbox.tgz if the original file name in the binary header was dpbox.tgz.

Note that with Linux, every, yes, EVERY file system oriented remote sysop command will be expanded with the path of the BBS-root-directory. This means, that even a BBS sysop cannot access to non-proprietary files of the Linux file system. In case of that the bbs is running with root permissions, a file access via the BBS software has root permissions, too. As it is possible to run multiple services on the same computer, e.g. FTP servers with Internet access or TCP/IP ham software, including a variety of purposes, it may be that a sysop should only be a sysop for the DPBOX... If you want to get access to parts of the Linux file system through the BBS you have to put symbolic links in the BBS directory.

To gain Linux supervisor rights, the usual way is to log in via the TNT packet driver (assuming that you defined a special SSID for terminal login), privileging with a password and then starting a root shell with the //rootsh command. This is what we do at DB0GR in Berlin.


The FBBMODE command switches between two types of CHECK list output. Setting FBBMODE to ON will produce a list output of F6FBB format, including the overall message numbers of the mail.

While in FBBMODE, you can read the mails with R <message_number>. Normal READ syntax is ok, too: R <BOARD> <Number>.

Note: FBBMODE ON does not change the command syntax of DPBOX (except for the READ command). It is _not_ planned to implement the whole syntax of F6FBB commands. FBBMODE only was implemented for testing message list broadcast functions.




Sysop only. Copies or moves a file in the file system.


FCOPY proto/debug.box save/debug.001
FMOVE save/debug.001 /run/test.dat


Sysop only. Deletes a file or a list of files specified with wild cards.

FDELETE save/test.txt
FDELETE save/test*.*

and so on.


Sysop only. Displays a sorted directory list of the file system.


FDIR proto/
FDIR system/conv*.box

A slash at the end of the path is converted to /*.*

FEXECUTE or OSSHELL or DOS (sorry...)

Sysop only. Executes a file (an external program). If no path is given, it will be looked up in the box/run/ folder.


FEX date
OS df
DOS ps -u
FEXECUTE save/test/ownprog

The command is started as a parallel task. In/Outputs are redirected.

Several environment variables are set to offer information about the calling user. Refer to the description of the External Commands for more information about this.


The FILESERVER command starts the built in file server of DPBOX.

The file server has its own set of commands, and you have to leave it with QUIT or EXIT to use the normal mailbox commands again.

Typing HELP in file server mode gives this command help:

This is a brief listing of the file server commands:
? and HELP           - This help file
DIR and LS and LS -l - Show directory listing
LIST                 - Show directory listing with descriptive labels
CD                   - Change Directory
TYPE                 - Download an ASCII file with paging
READ and WRITE       - Transfer an ASCII file from or to the BBS
GET and PUT          - Transfer an ASCII file from or to the BBS
BGET and BPUT        - Transfer a binary file in AutoBIN protocol
YGET and YPUT        - Transfer a binary file with Yapp protocol
EXIT, BYE and QUIT   - Return to BBS mode

CD /linux/packet     - changes to directory /linux/packet
CD ..                - goes back one directory
DIR *.zip -DATE      - shows a directory listing of *.zip sorted by date
DIR -NAME            - shows a directory listing sorted by name (default)
LS -SIZE             - shows a short directory listing sorted by size
LIST                 - shows a file list with description of file content
YGET test.zip        - downloads test.zip in Yapp mode
BGET 4               - downloads file number 4 in AutoBIN mode
BPUT test.lzh        - uploads a file in AutoBIN, will be stored as test.lzh

Note: Unix distinguishes between UPPER- and lowercase letters in file names!
Directory separator is a '/', not a '\' as with DOS and similar.
Names may be longer than 8+3 chars, e.g. "dpbox-4.17-source.tar.gz"
All server commands may be abbreviated, e.g. YG for YGET, L for LIST.

Sysop commands:
MD and MKDIR         - Make Directory
CP and COPY          - Copy a file
MV and MOVE          - Move/Rename a file
RM and DEL           - Delete a file
RD and RMDIR         - Remove a Directory
INDEX                - Write a new Directory Info

If enabled by the sysop, the file servers /newbin/ folder is filled with collected and decoded 7plus files of normal mailbox store and forward.

Users are allowed to upload files in the /incoming/ directory. Please send a short personal mail to the sysop after an upload so it can be moved to another place.

Note: Using the LIST command instead of DIR or LS gives you extra information about file contents (a short content description, if available).

The file server is local only. Files are not forwarded to other mailboxes.

Whenever you could, you should use the YGET command to download files instead of BGET. YGET selects YAPPC transmission protocol, BGET selects AutoBIN protocol. The great advantage of the YAPPC protocol is its crash recovery (resume) mode, and its block checksum.

YAPPC is _not_ supported by packet programs like GP, DP, SP, TOP, WinGT, but many other programs are supporting it.


Sysop only. MakeF-Mail. Works like the REPLY command, but generates a sysop attention message to F@THEBOX (or another @mbx field, depending on the defined one in system/config.box). Lifetime is set to 14 days.



You are prompted for a comment to be appended to the generated mail.


Sysop only. The FORWARD command allows you to mark manually messages in the forward list (the forward list is held in board X).

Syntax is as with LIST, READ etc.

If for example a new neighbour of yours started operation and it wishes to get all messages of the board ATARI from you, you can type


(where DB0XYZ is your new neighbour). The @mbx field is set to @DB0XYZ, but this is in effect the only change compared with the automatic forwarding.

If you want to avoid this change, add a '+' to the command (but think about what you are doing!, this could cause re-forwarding of old messages if the BID pools of the BBS' in your area are too small). Usually, omit the '+'.

The + option is useful when you have a routing error of private mails. Then, you can forward it manually to one neighbour BBS you decided to be a useful receiver, thus keeping the original hierarchical address.



Routing errors are displayed in the profile.box system file and are usually an indicator for wrong routing setups in your or neighbour systems. Mostly, they appear at loop detection of private mails, another reason may be that you didn't define all hierarchical regions of the world or that a new country appeared on the map and you forgot to put it in your forward definitions.


Sysop only. Reads a file on the file system in AutoBIN mode (#BIN#...). As usual, all path names are expanded in the main box folder.

The command has the options


output is plain ASCII, no BIN


output is with YAPPC protocol instead of AutoBIN


output will be BIN, but compressed with LZH before (compressed forward algorithm, but sent as a #BIN# - file)


fully transparent. output in BIN, but no header sent.

-t nnnn

tail. The last nnnn bytes of the file are sent. Also in conjunction with -a.

-tn nnnn

tail, additionally looking for a line break to start with.


FREAD system/reject.box
FREAD system/commands.box -p
FREAD system/config.box -a
FREAD proto/debug.box -a -t 2000


Sysop only. Writes a file on the file system in autobin mode (#BIN#...). As usual, all path names are expanded in the main box folder.


FWRITE system/config.box

After typing the above command, you get a send request of the BBS. Now, you manually have to start the autobin transmission at your terminal program.


Sysop only. This starts the house keeping routine of the BBS.

All users and mailboxes are disconnected during GARBAGE.

It is a very complex routine that checks all entries in the BBS and deletes physically the erased messages and those where the lifetime expired. Then, the checklist is recreated (the base of the CHECK output). Then the stored BBS route information (file hpath.box in folder box/stat/) is checked, entries with a 'lasttx' of older than half a year are deleted.

Whenever you have an inconsistency in any kind of data's of the BBS, call this routine. (You that you are using Linux may kindly disregard the last phrase, no file error ever occurred in Linux installations...)

The routine is started once a day at a defined time to delete the erased bulletins. You should set this time to local 0300 or 0400 (this is done in box/system/config.box), it takes between 1 and 20 minutes of time.

Of course, if you are using DPBOX as a personal message system, it will not be running 24 hours per day. In that case, call the GARBAGE command manually every some days to clean up the BBS. THIS IS IMPORTANT, SO DO IT!

The command has the option -i, = immediate physical deletion of erased mails.


Header is very similar to READ, but only displays the HEADER of a mail, not the content. This is fine to have a quick look on the forward path or similar.

All options of the READ command are effective.


The HELP command gives online help.


without further parameters gives a brief overview of the bbs commands,

HELP <Command>

gives a detailed help on the desired <Command>.


This is a switch (sysop only). Normally, only undeleted messages are displayed.



all message operations are working with erased messages. The LIST command shows only erased messages, as does the CHECK command and so on.

A [H] in the prompt indicates this mode.

When in hidden mode, you can un-erase erased messages by erasing them (all erase logic is inverted hi).

Note that this only works until the next GARBAGE or maybe some days longer if the belonging parameter in CONFIG.BOX is set to a higher physical erase delay.


switches back to normal mode.


Displays all messages currently in HOLD. Internally, this is a combination of the commands SELECTION SFHOLD OWNHOLD and CHECK 1-



A sysop may release held messages with the RELEASE command.

You may add the same parameters as for CHECK to the command. In that case, the CHECK 1- is replaced with CHECK <parameters>.




Sysop only. Displays the interface names and numbers of each user of the bbs.


Imports a file into the BBS. This could either be a binary file (this is detected automatically) or a text/7plus file. You are requested for the file name, the destination and title. This should be a sysop only command. EXAMPLE:


If entered as a remote command, you have to append a full and valid path name. EXAMPLE:

IMP save/test.txt

Note that the Linux version in case of remote access references all path names starting with the defined box working directory... you have absolutely no access to any file to be found outside.


Sysop only. The same as ERASE, but additionally the Bulletin ID of the erased message is deleted in the BID pool. The BBS will not defer a re-send of that message in S&F. In most cases, this is NOT useful. Use the ERASE command instead.

Additionally, this is your only possibility to get rid of messages whose headers are detected to be corrupted (DPBOX checks all file structures with checksums to prevent itself from file system errors, user manipulations, outdated index versions and so on). Normally, such erroneous files will be deleted at the next GARBAGE, the KILL command is thus the manual possibility to do such.

One word about file systems: we never experienced any file errors on Linux and Mac OS systems. On the Atari, depending on the type of hard disk, they were about to be called usual. Anyway, the check doesn't takes much time and gives you the secure feeling of uncorrupted BBS contents, even on more modern file systems. As I may state of my user correspondence, some tried to re-edit index structures with text editors. Those manipulations (which only led to incorrect lists and a lot of complaints directed to me) are perfectly detected, too, with this check.


Displays all available languages of the BBS.


Sysop only. Sets the user level of a user. Example:


The default user level of every new user is 1. Valid levels are 0 to 127. A level of 0 inhibits this user to log in the BBS.

The levels CAN be used to define special board areas where not everyone has access to. But beware, at least in Germany, this is not legal.

We use it, too, for special boards, e.g. UPLOAD, where we input new BBS system versions in S&F to export them shortly after upload and then installing them.

A maybe more useful application of the level command is to define special BBS commands (as SEND, ERASE) with higher levels than the standard 1, so a new user is unable to SEND and ERASE mails until the sysop gave him a higher user level. This is legal.


Sysop only. You can correct the lifetime of a message. This does not effect the outgoing S&F but only the administration in your own BBS. Example:


sets all messages in board ATARI to lifetime 0 (= infinite)

LT ATARI 5 #365

sets message 5 in board ATARI to lifetime 365 (= 365 days)


Lists the content of a board. Examples:


An option '+' is available. This displays more information about the listed files, such as compression rate, lifetime, @mbx. Example:

L ATARI 1- +

An option ':' is available. This displays even more information about the listed files, such as read counters, readers calls (only sysop), erase source (only sysop and of course only in HIDDEN mode). Example:

L ATARI 1- :

As for the CHECK command, the $ option may be used. Instead of the date, the BID will be displayed or searched for. Example:

L ATARI 50 $
L ATARI 1- $


Displays or sets the last login date/time. An altered date is not saved when leaving the bbs, it's only used while logged in. Examples:

LOG displays last logintime
LOG 1.10. sets last login on the 1.10. of the current year, 00:00 UTC
LOG 1.10.92 sets last login on the 1.10.92 00:00 UTC


Using this command, one can determine if the own call will be displayed in the mail beacon of the DPBOX or not (if new mails arrived).


enables display in the unproto mail beacon


disables display in the unproto mail beacon.


without parameter displays the current setting.

A sysop may set this parameter for other users:



Sysop only. Using this command, you can limit the maximum read account of a user per day.



limits read operations of DL1XYZ to a maximum of 80000 bytes per day.


Sysop only. When a user sent a mail with a wrong @mbx field, you can correct it with this command. The forward list is updated with the new setting. If the new @mbx field is a call sign, the hierarchical definition is looked up and added. Thus, you may add it manually, too. Syntax:



MD2 starts password login with MD2 encryption.

It uses the RSA Data Security, Inc. MD2 Message Digest Algorithm.

Assuming that you entered a password with the PASSWORD command, typing MD2 command results in a random prompt of the DPBOX. Prompt will look alike:

DB0XYZ> [12345abcdef]

Your terminal has to answer with 16 hexadecimal values (32 chars in total) calculated by applying the MD2 algorithm on the 10 prompted random chars and your full password string.

The MD2 password protection is the most secure of the three methods available in DPBOX (PRIV, SYS, MD2), but only very few terminal programs support it.

If in doubt, use the SYS command for password login.


MD2SF command enables MD2 password protection for S&F connections.

It uses the RSA Data Security, Inc. MD2 Message Digest Algorithm.

If a user wants to use MD2 password login in user forward instead of the other methods available, typing


will change to MD2.

A sysop may change the MD2SF flag for every station:


Login prompt of DPBOX in S&F is changed to:

[DP-5.00-AB1D1FHMR$] [12345abcdef]

Algorithm is as discussed in MD2 command description, the logon answer of the connecting forward partner has to be:

[XYZ-1.00-XYZ$] 1a2b3c4d5e6f1a2b3c4d5e6f1a2b3c4d

(the result of the MD2 encryption).


With this command a user enters his home BBS. This information is forwarded to M@THEBOX (THEBOX may be changed in the CONFIG.BOX file to any of your preferred addresses). Additionally, when White Pages exchange is configured, it will be imported in the WP format and sent to your defined WP neighbours. The THEBOXforwarding is up to day used in german speaking countries, the WP format is preferred elsewhere (by good reasons...). Example:


A user is prompted every three month to re enter his HomeBBS.

If the user added the option '-', the information is NOT forwarded to other BBS. This may be of use for some special user forward intentions. Example:


A sysop can set a users MyBBS, at this case, the information is never forwarded but only locally used. Syntax:

MY DL9XYZ DB0XYZ 2 This sets additionally the user level of DL9XYZ to 2 (default 1).


The MSG command transfers a single text line to another user of the BBS. Examples:

MSG DL9XYZ Hi Peter Sends the line 'Hi Peter' to DL9XYZ (if logged on).

MSG 6 Hi Peter Sends the line 'Hi Peter' to the user on port 6 (if connected).

Of course, it is impossible to send a MSG to a forwarding BBS.

If you send a MSG to a user currently writing a message or reading out a huge amount of data's, the prompt of the message command will be "DELAYED MSG OK FOR ...." instead of the usual "MSG OK FOR ..." to indicate you that the user can't answer immediately on your request.

You can send yourself a message, this seems to be necessary for some batch generators of other programs. If the self-sent text starts with a '&', no prompt is echoed, simply the pure text (without '&').

A sysop may send a text to all users, example:

MSG ALL system will shut down in 5 minutes


Required parameter: the users name. Example:

N Joachim

In sysop mode, the sysop can enter data for other users, example:

N DL9XYZ Peter

Length of the name is limited to 80 characters, it may consist of several words.


The NEXT command is used to subsequently read one message of a board after the other.


This command forces the BBS to suppress specific boards in the CHECK output. For example, you may be bored by messages to WINDOWS and SOFTWARE, then you enter


If you want to delete this selection, you type


without parameters.

You can enter several consecutive NOTBOARD - selections until a total of 253 characters is reached.

The current setting is visible using the U command.


shows you all your current user settings.

Important: If you select more than one board to be suppressed, separate them by colons, and do not put a space between.

See WANTBOARD for a positive selection of wanted boards.


You can define a password to be used for the SYSTEM command. A sysop may also set the password of a specific user. The password has to be longer than 20 signs, use long passwords with random signs to avoid logins of hackers.


PASS DJGseut7k4088904fbvvjughrfw6kjjjjhKJHd3jg

A sysop may set the password of another user:

PASS DL8HBS Ljfi8uHJkfhwfhKfjj776Gjhdwtdfgh75jk

Call sign misuses lead to an extended implementation of this command: every user may enter a password for himself to authenticate him when further sending a mail. To prevent making the life of hackers too easy, the generation process may take several steps. Every string following the PASSWORD command is added to a yet existing fragment. So, one can set up his password in several portions at several days or via several digipeaters. Note that the password may not exceed 80 signs and that it starts to be active after reaching 21 signs - even the PASSWORD command (for adding more signs) is no more accessible when not performing a successful SYSTEM login before (relating on the fragment yet received). When activated (after 21 received signs), the PWMODE (see below) is set to 2.


without parameters deletes the actual password and restores the PWMODE (see below) to 0. (PASSWORD <Call> for sysops when deleting user settings).

Please note that if the BBS is provided with a HOLD-DELAY for locally entered bulletins without password protection, the HOLD for a user setting himself a password will end after the defined delay time. In the meantime a sysop can check the accuracy of the setup and prevent self-setting of passwords by pirates. The fact of entering or deleting a password is stated in the profile.box file (you're about to see that this is a really important file where the sysop should regularly have a look on, aren't you?).


Password login command. A password, as generated by PWGEN (1620 random chars) is checked with the 4 letters following the PRIV command. The complete password has to be stored in a file sf/<CALL>.pwd

The appropriate login letters are computed by your user terminal, based on your current login date. This information is extracted of the connect text of the BBS and requires specific terminal programs, scanning the login text. The algorithm to compute the correct answer is the same as for TheBox-BBS, and the terminal programs usable for this feature are the same as developed for usage with TheBox (DP, TNT, GP?, THP, WinGT, SP ...).

After correct login, your further status depends on the setting of your PWMODE.

The command may be applied several times, including false answers to prevent hacking parts of your password.

If you have problems generating this type of password login, you may want to use the SYSTEM command (and the associated password set with PASSWORD). There is no difference in the privilege level between the both modes to log in.

In general, the PRIV login is a little bit easier and faster than the SYS login (as it is not interactive, as the SYS command is), but the SYS login is a little bit more secure (because you can put the correct answer in a random string).

User passwords normally should be generated with the PASSWORD command, as this is much less work for the sysop.


Sysop only. Outputs the proto/profile.box file in ASCII format. profile.box is filled up with important system information and critical error messages. A sysop should read it at least once a day. When running the house keeping routine, the daily profile.box is imported in board Y for further access.

We experienced that the profile.box file is a good media to communicate between multiple sysops checking the BBS. Any text added to the PROFILE statement is written in the profile.box file, expanded with date and call sign of the applier.


PRO I solved the routing problem with db0xyz


You may change your system prompt. The standard prompt looks like this:


To set a new prompt, type

PROMPT Hi Joachim>

and your prompt is changed to

Hi Joachim>

(not that useful).


without parameters deletes the user defined prompt and switches back to the standard system prompt.

Ok, to make this command more than a joke, you may invoke macro definitions in the prompt definition. You have the following choice:

%7 CTRL-G (bell)
%8 TAB
%a actual system load of the BBS
%b active board
%c your own call sign
%d date
%h convert the following two hex chars into one ASCII char
%i logintime
%l last login
%m the BBS call sign
%n your name
%o count of current users
%p used CPU time since login
%r line break (return)
%s box runtime (days, hours, minutes)
%t current time (with seconds)
%u current time (without seconds)
%v software version number
%x box runtime (only days)
%z last command
%% the character %

So, defining the standard prompt would be

PROMPT (%b) %c de %m>

Please, think about that a changed prompt causes conflicts with "mail catching" programs such as DP, TNT and WinGT. Normally, the standard prompt is used to determine the end of a mail. To avoid conflicts, only ADD parameters to the standard setting, for example

PROMPT (%b) %c de %m> (%o/%a)


Sysop only. The proto command opens a protocol file filled with all actions a specified user performed. The file is stored in proto/<call>.pro. It is imported into the BBS (in board Y) while running the house keeping routine.



activates proto file for DL1XYZ


deactivates proto file for DL1XYZ


displays list of protocoled calls


deactivates all proto files.


generates a 1620 characters sized password file for the PRIV command. These kinds of passwords are in Germany broadly used for password protection of forward links. They are also used by sysops to protect access with their call. For user protection, the PASSWORD command offers an easier way (not that much work for sysops hi).



creates a password for DB0XYZ with the path name box/db0xyz.pwd. The file is imported in binary mode into the BBS and forwarded to DB0XYZ. After reception of the file at DB0XYZ, simply move the file box/db0xyz.pwd to box/sf/db0xyz.pwd and from that moment the S&F is password protected. Of course, DB0XYZ had to do the same at his configuration (with the received password). The algorithm follows the one that TheBox and BaycomBox use for protected S&F.

To omit importing and forwarding of the password, type the command without the '+' option:


only creates a file box/db0xyz.pwd.

How does the password calculation work? The BBS prompts the current login date/time after the welcoming SID in S&F. The calling station then has to answer with its SID (as usual), and append a string of 4 characters, computed by a special algorithm.

To use this kind of password login as a user, your terminal program has to be especially designed for this aim (as DP, TNT, THP, WinGT, SP and others are). They scan for the connect text of the mailbox, extract the logindate and send out the computed password when you type PRIV or a special control code.

As DPBOX offers un-configured user-S&F, there exists a second way to start protected S&F. If the user defined a password with the PASSWORD command, a following S&F login gets prompted with the SID and the 5 random numbers as is described under the SYSTEM command. Then, he answers with his SID and the appended correct password response.


Sysop only. This command defines the privilege level a user has after responding to the password request.

Levels are: 0,1,2,8,9,10,11


0 means that the user may connect via the telephone modem port, no write access (this is the default). (special modem driver not yet available for the Linux version)

1 means that the user may connect via the telephone modem port, with write access. Also, this enables write access via a radio port if the global parameter 'SEND/ERASE with PW' is selected.

2 this is as 1, except that the user is always kept to enter the password for write access, independent of the global switch. If a user entered a password by himself using the PASSWORD command, this level is set, too.

8 enables "board sysop mode" - this was invented to maintain large BBS with a lot of mail throughput and users. Board sysops are not literally sysops (in fact they only may execute user commands, but extended to those bulletin boards they were defined to be the local supervisor). A board sysop defined for MAC may for example delete all mails in that board or TRANSFER them to anywhere else, and, as the only non-user command, may set up a new lifetime for mails in "his" board. The boards to be maintained by a "board sysop" are defined in box/system/prvcalls.box (to be described later on).

9 same as 8, additionally, the "board sysop" is protected against call sign misuse by forcing a privileging for every (even non-"board sysop") write/erase operation.

10 enables full sysop mode, either via radio or modem.

11 enables full sysop mode, combined with PWMODE 2, the sysop first has to privilege himself even for non-sysop write/erase operations. Note that the QUIT command is a write operation, too (on the last login time), so it is converted to an ABORT command when entered in unprivileged state (only for pwmodes 9 and 11).

Example: PWM DL9XYZ 9


Sysop only. The QRG command displays all defined TNT interface QRGs. These may be of use for the CONNECT command.


Ends the connection with the BBS. The last login date is updated to the login date of this connection.

Normally, a user should end a connection with QUIT.


Reads the content of a board. Examples:

R 4

An option '+' is available. This displays the full file header (S&F-header) of a file. Example:


Sysops may use the option ':' , this displays all readers call signs in the mail header.


The READLOCK command has three possible options:


All users may read the private mails in the user board of the user applying this command.


Except originator and recipient, users may only read the private mails of the user applying this command after he read his own mails at least one time (and did not delete them)


Only originator and recipient may read the private mails of the user applying this command.


Sysop only. This deletes the BID pool of your BBS. Then, it is refilled with all BID's currently active in your BBS. Normally, the BID pool contains information about messages that have been erased but were received by your BBS once. The effect of the REBUILD command is, that you can receive erased mails. For normal BBS operation this is not useful.


Sysop only. A mail or bulletin that was stopped by the HOLD feature of the BBS will be released for forward. Same is done by the expire timer of the hold feature, but if long hold delays are programmed, it is useful that the sysop checks once a day the actually held messages to release them manually.

The syntax of the command is according to READ.


REL DIGI 12-14

Held messages are displayed with the HOLD command.


Sysop only. RELOAD reloads all configuration files concerning the BBS.

After editing the config files of the BBS, you have to apply this command to make the changes effective.




The REPLY command will create a private mail to the sender of a message that was the last one read with the READ command. Additionally, you may specify the mail you wish to reply to, e.g.


The title of the reply mail is the original title with a leading RE: , the @bbs is first looked up in the internal HomeBBS storage files, only if no definition for the destination was found, the read mail will be scanned and the last found BBS in the mail header is used as @bbs field.


This is a command for advanced users or sysops hi.

SELECTION temporary sets an internal variable of your user setting the way that you get only specific mails displayed when applying the LIST or CHECK command. Available options are:

SFWAIT waits for forward
PROPOSED proposed but not yet acknowledged
SFRX received in forward
SFTX sent in forward
SFERR problem while sending in forward
SFNOFOUND no route found
CUT received by monitor scan
MINE locally created
BROADCAST sent in broadcast
BROADCAST_RX received in broadcast
OWNHOLD local copy held after forward
LOCALHOLD is in HOLD, sent by a local user
SFHOLD is in HOLD, received in forward
REJECTED was rejected by the forward bbs
DOUBLE was marked as yet received by the fwd bbs
OUTDATED older than the max. age of incoming mails
UNDEF designated to an undefined bulletin board
HIDDEN marked as erased


selects only waiting messages in forward to be displayed in CHECK and LIST,


selects waiting messages and such where a forward error appeared

and so on.


without parameters disables the selection feature.


Creates a new file. You are requested for all omitted parameters. The parameters for the SEND command are numerous:

S DL9XYZ @DB0ZZZ <Sender $BID #Lifetime Title

The $BID, #Lifetime, <Sender and @mbx-field is optional. Per default, DPBOX sets the @mbx to your own BBS call (the mail will not be forwarded), the $BID (= Bulletin / Message ID) is generated automatically, the #Lifetime is set to 0 (= infinite) and the <Sender is set to the call sign of the user that typed the SEND command (only sysops and boardsysops may apply that option).

If the destination is a call sign, DPBOX looks up the @mbx field (if omitted) of the forwarded mybbs information or sysop/user set local mybbs info's.

The lifetime determines, after how many days the message shall be automatically deleted. Only supported by DPBOX / TheBox / BaycomBox.

Even if the <Sender field is present, the call sign of that one sending the SEND command is always visible in the mail itself. The first two lines of a mail sent with DPBOX always contain an info as:


The call in the first line is not corruptible. You may ask yourself why this feature is implemented. Well, with the '<' option you can locally re-send msgs with the correct senders call. And, of course, it exists because of the compatibility with TheBox. Starting with v4.04, only Sysops and ăboard sysops'"' can apply the '<Sender' - option.

Note that for usual application there is no different command for private mails and bulletins. The distinction is made by the destination. If it is a call sign, it is a private mail.


S DL8HBS how are you?
S DL8HBS@DB0GR.#BLN.DEU.EU how are you?
S ATARI @ EU problems with hard disk
S ATARI @WW $123456DL9XYZ #30 new comp.

Although normally the distinction between private mail and bulletins is made automatically, from time to time you may want to force DPBOX to override the internal detection. So for example when addressing a server of F6FBB BBS. Those server names mostly are non-call signs, but they have to be addressed with private mails. According to the syntax of F6FBB, DPBOX offers you the two commands SB / SP (Send Bulletin / Send Private), to let you choose yourself the type of mail.

Please note that DPBOX is completely transparent concerning the mail type. In S&F it will even accept a type 'Z' (or anything else) and pass it through unchanged to the next BBS. You, as a terminal user, are limited to the types 'B' and 'P', as all others (except 'T' in NTS messages) are not defined actually.

Please note, too, that TheBox and BaycomBox (at least up to now) are NOT transparent regarding the mail types. This means that they will change forwarded mail types to the standard set 'B' and 'P', and in most cases they will set server requests to type 'B', what results in an incorrect address.


Sysop only (including specific server sysop). DPBOX offers a built-in mailing list server feature. For those not familiar to the Internet: this is about a programmable XEROX for registered users. Every installed server holds a list of addresses, and every mail sent to this specific server is copied and forwarded as a private mail to every subscriber. This is a good mean to keep in touch with a group of OM spread on a wide area. Only registered subscribers may address the server, and no self-subscription is allowed. Except all BBS sysops, one or more "server sysops" may be defined that can maintain the address lists, too.

Basically, the server maintenance commands consist of


<Name> is to be replaced with a selected server name on your BBS. Server names should match call sign conventions, for example at DB0GR we have defined: BB0SYS (sysop server Berlin-Brandenburg-region), BB2DEV (BBS-developer-server), OS2DEV (OS2-developer-server). You may name them in none-call sign style, too, but this may cause problems in networks with BaycomBox and DieBox systems included.


lists all subscribers of server bb0sys


adds subscriber DL8HBS to server bb0sys


adds subscriber DL8HBS with target BBS DB0GR to server bb0sys (if no target is given, the internal white page server is looked up, mostly the better way)


adds subscriber DL8HBS to server bb0sys and makes him a "server sysop", that means that DL8HBS is privileged to alter subscriber information for this specific server


deletes subscriber DL8HBS from server bb0sys

A server is deleted if it has no subscribers, it is automatically generated if it has at least one subscriber.

A mail is sent to the server by his complete address, in the above case with S BB0SYS@DB0GR or SP BB0SYS@DB0GR (the server also does accept incoming mails marked as bulletins, but this is only a trick to prevent problems with TheBox / BaycomBox).


With the SETREPLY command you can mark messages in your own user board as "replied". Normally, this is done automatically when using the REPLY command to answer them, but when using the SEND command instead, the bbs cannot set this mark by itself.

Syntax as with REPLY. Examples:


marks message number 3 to DL1XYZ as replied.


marks the last read message as replied.


Sysop only. The SETSF command manipulates the forward list (that is, by the way, held in the pseudo - board 'X'). The command has three options:

All entries in the forward list of the type 'type' that shall be forwarded to DB0XYZ will be sent to DB0ZZZ.

The entries 3 to 6 of the forward list will be sent to DB0ZZZ.

SETSF type 1- DB0ZZZ
All entries in the forward list of type 'type' will be sent to DB0ZZZ.

Where 'type' is one of the following:

A = all
B = bulletin
P = private
S = system (erase and mybbs)

Note that this command does not change the forwarded mail itself. Only the neighbour BBS used for routing is changed.

There is one special destination call: NIL. When applying this, all selected forwarding entries are erased. Example:


will erase all bulletin entries in the forward list for DB0ZZZ.


Sysop only. Starts manually the S&F to another BBS. Examples:


starts the S&F to db0xyz

This will only work if there is an S&F definition file in the folder box/sf/ for DB0XYZ (db0xyz.sf).

The command has three other options:


stops the S&F timer. No out going S&F connects are established, incoming S&F connections are deferred.


allows automatic S&F operations.


same as SF OFF, additionally disconnecting all S&F connects.

The default is SF ON. This switch is NOT saved. When restarting DPBOX, it is always set to SF ON. The SF OFF case is indicated by a [no S&F] - prompt.


Sysop only. Setting SFLEVEL to 0 results in the verbose user welcome menu of the bbs, setting it to 1 results in the short forward login prompt, but this is the only difference. For defined forward partners, sflevel will be switched automatically to 1.

OK, here are the facts. An SFLEVEL of

-1 disables logging in in forward mode for this user.

0 results in the normal logon screen of the BBS. Note that the SID is sent, but this is the normal (and verbose) user login (and thus every user has by default this "SFLEVEL").

1 SID is sent, directly followed by the S&F prompt in a new line ('>').




Sysop only. Displays all SFPARMS - definitions of all defined forwarding neighbours (this is done in the files of the folder box/sf/). At the last position is marked the UTC when your BBS will start S&F to the neighbour BBS. An asterisk (*) displayed after the last column states that currently a routing to that BBS is in progress.

The command has different options:


shows all SFPARMS.


sets the third parameter of the SFPARMS of DB0XYZ to 1.

SFP DB0XYZ _all_parms_

sets all SFPARMS for DB0XYZ (_all_parms_ has to be replaced with ALL 9 parameters!).


displays information about the forwarded files.


without parameters displays the currently waiting number of files in forward, specified by their type


displays additionally the count of forwarded files since start of the day and start of the month


additionally displays information of the throughput of the BBS since it was installed

At every first of a month, SFS ! is called by the BBS itself during the garbage routine, the output is stored in the board STATISTI (this should imply that you define this board in your rubriken.box file...)


Checks the routing definitions. A user can request the forwarding paths for a specific SEND command. SFTEST accepts all parameters as SEND would do, of course no message is created. The result is a list of BBS' the message would be forwarded to or an error message.



Sysop only. The SHELL and TSHELL command opens a Linux shell.

TSHELL handles all passed datas transparent, in special, no linefeed conversion is done.

The shell is immediately started. user is that one of the running DPBOX process.

If you see security problems, disable the code completely by recompiling the DPBOX with directive -DNO_SHELL.


sets a user language.



SPEAK without parameters shows all languages. In sysop mode, you can set a language for another user, example:


Per default, a users language is defined according to the entries in box/system/whotalks.lan.


You may define one or more startup commands (they will be executed when you connect the BBS). The default startup is a LIST on the users board.


will perform a LIST on the users board, a USAGE and a CHECK for all new mails of the board UNIX.

Subsequent commands are separated with colons, not with semicolons as in normal command input, as this would break the command input, too.


without parameters deletes the setting and restores the standard system startup.

Do not put a CHECK without parameters in the STARTUP sequence. Usually, the generated output is a bit too high to get it returned every time you log in, especially when you had a link failure due to bad radio hi.


Sysop only command. Called without parameters, a list with extended information about every board is displayed. If the parameter is a boards name, only information about the selected board are displayed. Also, the parameters -s , -u, -b are known, they force a 'quick display mode', only summary information are displayed for either user boards (-u), bulletin boards (-b) or both (-s). Examples:



STRIPCR <filename> changes MSDOS - line breaks to Unix - line breaks. DPBOX makes no difference between both, but most Unix editors do.


Starts the password login procedure. If you have a defined password (setup with the PASSWORD command), the BBS prompts you 5 numbers. These numbers are corresponding to the position of characters in your password string. You have to answer the numbers with the 5 corresponding characters. To prevent hacking or pirating of your password, you may repeat the command several times, with incorrect answers. You may also hide the correct answer in a longer random string.

An example:
Your password is abcdefghijklmnopqrstuvwxyz
You type SYSTEM
The BBS prompts you: DB0GR> 1 2 3 4 5
The correct answer would be abcde
Instead you type ghsuwbxgdlf825shfabcdeskfhwnh
You are accepted...

Depending on your personal PWMODE, you now are privileged to write mails, to be a board-sysop or a sysop.


Responses an 'OK' if you are sysop, if not, an error message appears.


Starts a connect to another logged in user. The connect is not fully transparent, binary data transfer will fail. It is text oriented. The connection is ended with a CTRL-Z.



While in TALK mode, a user can enter BBS commands with a prefixed '!', !L ATARI for example. If calling an interactive command, talk mode is ended.


Displays current date and time (in UTC).


Generates a command that is forwarded to another BBS.

The destination BBS executes the command and sends back the resulting answer.

Only TheBox and DPBOX understand that syntax, also some BaycomBBS with a special server utility, it has no effect with others.

As arguments of the TELL command you can add all BBS commands that do not require interactive answers (as NAME, MYBBS do).



where DB0XYZ is the BBS where the command shall be executed.

Sysop information: the TELL command is forwarded in the board 'T'. It is a file generated with 'S T @ DB0XYZ < sender_callsign title', where title is the requested command added with '@ sender_bbs'. If the resulting output of a TELL command is bigger than 300k, it is discarded and an error message is sent to the requester.


Sysop only. The TNTCOMM command allows you to send any TNT terminal command to any channel of any of the connected TNT.



shows all current connections of the selected TNT


disconnects connection on channel 1 of the selected TNT

To find out the <QRG>, use the QRG command.


Sysop only. Starts an input/output tracing of connections of the BBS. This helps in analysing forward problems or supervising "critical" users. Every sysop may trace as many connections as wished, but two sysops cannot trace the same call. The trace setting is not stored after disconnection of the supervising sysop.



starts tracing all connections with db0xyz. While tracing a station, the sysop may continue to enter further commands, the trace output is invoked in his running connection. This may look confusing but remains without side effects.


ends tracing of db0xyz.


ends immediately all open traces of this sysop.


shows list of open traces.


traces ALL connections of the BBS (a little confusing hi).

The output of the traced connection is tagged with time stamps and channel numbers and an internal "action" flag (this one is only a help for the programmer hi). When outputting a text buffer to a traced connection (such as a mail, a help text etc.), the buffer is only indicated by his size, its content is suppressed from tracing.

If you want to get a "full-screen display" of one users actions, try the


command. FULLTRACE is used as TRACE, but no preceding tags are invoked nor buffer suppression nor line breaking. You get an "as is" copy of a users channel. Note that internally, FULLTRACE is the same as TRACE, you only switch a global flag of YOUR user setting ("yes, I wanna get all bytes without limitations"), thus it is not possible to TRACE one user and FULLTRACE another. You see what is meant? Try it, its easier than documenting it in 500 words.


Moves a bulletin from one board to another or copies a user mail from one user board to another. If not in sysop mode, only bulletins directed to or written by the current user are transferred. Examples:

T DL8HBS 12-13 > DL9XYZ (the '>' is not necessary)

If possible, a remark about the transfer action is appended to the mail. This only works if the mail still is in full ASCII mode. After packing or with binary files, this doesn't work.

A Sysop may add a new lifetime to the command, syntax:

T ATARI 7 ALL #7 (new lifetime: 7 days)

Otherwise, the lifetime is adopted to that one of the destination board (if not set lower than that one by the sender of the mail).


The TTL command lets a user choose the format of the lifetime display of messages in LIST and CHECK output.


displays the remaining lifetime of a message


displays the overall lifetime of a message.

If TTL is switched ON, the LIFETIME command (sysop only) is based on the current date, too.


The DPBOX uses a retarded physical erase of mails. The sysop may define a number of days (in system/config.box) whilst logical erased mails are not physically deleted. A user may apply the UNERASE command to make his before erased private mails visible again. This is a necessity since call sign pirates like the game of deleting other users mails.



This behaviour is, by the way, the reason for the on counting mail number in user- and bulletin-boards. Even after deletion of mails 1 to 4, a newly incoming mail gets stored as number 5 because numbers 1 to 4 are physically still existing. I just tell that because users familiar with TheBox BBS are strangely irritated about this fact. Mail count is only reset after real physical deletion.


Sysop only.

With the UNPROTO command, the sysop can enable UNPROTO message list requests for specific users, if not free for all (parameter UNPROTO_ALL in system/config.box).

Unproto requests are used by programs such as TPK and TSTHOST(?) to request a resend of some lines of the unproto message list broadcast.

See the section about unproto lists in this documentation.




Without optional parameters, this command displays all current users of the BBS.

With a call sign as option, all known information about a user (as HomeBBS, name, language) are displayed.

When in sysop mode, more information as level and SF-level are displayed. If the user is currently logged in, the sysop gets a display of received and sent bytes, used CPU time and logintime over all.



displays current on-line users. forward connections are displayed lowercase.


displays all user settings of DL8HBS


shows a list of all users with HomeBBS at @DB0XYZ

U @DB0XYZ -c

only COUNTS the users with a HomeBBS at @DB0XYZ

U @D* -a

sysop only. counts the users of all BBS with the prefix D*


same as U, but the last some lines of the BBS' logfile are sent, too.


same as U, additionally displaying ax.25 from- and to- field of every users connection.


sysop only. Deletes the entry for DL8HBS

U @DB0GR -d

sysop only. Deletes all user entries whose MyBBS is set to DB0GR


sysop only. Displays all local users with password


Displays current connect hiscore


sysop only. Resets the hiscore counter


Displays the version number of the software. Also, the free space in RAM is displayed. The option '+' shows more detailed information about the system setup.




The WANTBOARD command selects boards of the bbs to be displayed in the CHECK output.

For example, you may only want to see messages to WINDOWS and SOFTWARE, then you enter


If you want to delete this selection, you type


without parameters.

You can enter several consecutive WANTBOARD - selections until a total of 253 characters is reached.

The current setting is visible using the U command.


shows you all your current user settings.

Important: If you select more than one board to be selected, separate them by colons, and do not put a space between.

See NOTBOARD for a negative selection of wanted boards.

back to content page

6. The Configuration Files

back to content page

6.1. system/config.box

This is the most important configuration file. You HAVE to edit it. Every keyword is explained in the example file.

This is a copy of the example file:

# This file contains important configuration parameters
# for the mailbox.
# text (max. 30 chars) to be inserted in the ctext of the bbs
CONNECTTEXT  dpbox test
# define your own hierarchical path (DB0GR.#BLN.DEU.EU etc.)
# define a SHORT station info for the routing header. Try not to
# override 16 chars.
FHEADER Nowhere-City
# Undefined boards should be transferred to:
# you may omit this parameter, then, undefined boards guard their name.
# Forward of remote-erase / MyBBS-infos to @:
# Lifetime for s&f fragments (resume):
# Lifetime for system messages in Y
# send once a day an automatic mail to any s&f partner where DPBOX detected
# improper forward settings (rejects on private mails)?
# set it OFF for user-sf, ON for full mailbox operation
# regard received broadcasts as if received in s&f? Usually NO!
# create a logfile of all sysop status operations?
# create a logfile of all user operations?
# create a logfile of all incoming mails in user-sf?
# create a logfile of all READ operations?
# create a logfile of all s&f-commands?
# create a logfile of all status changes forced by CONVTIT.BOX and CONVLT.BOX?
# remote erase enabled (rx and tx)?
# only accept remote erases if sent out by the same bbs that was the
# originator of the original file? Usually ON!
# allow multiple sf sending (via different paths) of private mails? Usually NO!
# keep a backup of mails with console-call = sender-call after forwarding?
# Usually OFF, but useful for a user terminal.
# how should DPBOX react when someone sends S&F without authorisation (CALL.SF)
# AKA User-SF
# 0 = defer all
# 1 = accept only private mails, if sender is the forwarder
# 2 = accept private mails and bulletins, if sender is the forwarder
# 3 = accept all by all
# default is 2, in previous versions of DPBOX it was 3
# disabling caching of the BID-mem in RAM ? Depends on your memory size.
# On Linux and RAM > 8 MB set it ON, on ATARI/Mac and RAM > 2MB too.
# caching = ON
# default after startup of the debugging profiler.
# values between 0 and 5. 0 = OFF. Take care, the higher the value, the
# more verbose is the debug profile (file DEBUG.BOX in BOX\SYSTEM\ )
# how long should the debug.box-file grow before it is renamed to debug.bak and
# a new debug.box is created (in kB)?
# timeout for users
# (default:20 min)
# timeout for s&f
# (default:5 min)
# up to which value should the lifetime of a mail become increased by user
# readouts (every read increases by one day)? 0 = off.
# how many simultaneous connections may a user establish with the bbs?
# (sysops: infinite)
# hide user files (only visible for sender and receiver)?
# (default: OFF)
# create and analyse White Pages message files? (define your WP neighbours in
# wpfor.box)
# scan ALL incoming WP mails (regardless of the sender bbs)? Usually OFF
# in what interval (hours) should WP mails be sent out to your neighbours?
# after how many days should logically erased mails be physically deleted?
# lifetime of undefined boards?
# how many hours of hold-delay for mails defined in reject.box with H or P?
# (if not released earlier by a sysop (command RELEASE))
# define the size of the BID-Buffer of your BBS. 50000 should be a
# good compromise between execution time and mail throughput even in
# high speed networks. Do not lower this value after it is filled up
# to its maximum size (after some weeks of operation). You may increase the
# value whenever you want.
# send the own routing header in outgoing forward? Usually ON!
# analyse incoming routing headers? ON!!! This feeds the auto router and
# the call expansion to hierarchical names.
# start once a day the house keeping routine automatically? ON...
# start the house keeping routine at which time (utc)?
# compress stored mails after how many days? (0 = at once...)
# send/erase GENERALLY only possible after password authentication?
# Lifetime of private mails?
# enable compressed forward if possible? of course ON!
# send a mail beacon as defined by beacon.box-file?
# Insert a line "X-Info: Upload without password authentication" in bulletins
# sent by users without password protection?
# How many milliseconds may one task (user) use the system before the
# next one is scheduled? range: 5 - 2000
# note that low values are less effective, 100 should be a good
# compromise. Anyway, if you use a fast computer, try lower values.
# switches the display of the lifetimes from normal mode to TimeToLive-Mode
# (= remaining lifetime... TTL = Lifetime - (Today-RxDate) )
# if active, the SETLT - command will use this notation, too!
# Add a line with '/EX' after every mail a user reads?
# Create an acknowledgement when detecting /ACK as the last line of a
# private mail addressed to users of your bbs? Normally ON
# Return undeliverable private mails (routing errors, bad links)
# after how many days? Only the first 1500 bytes are returned.
# Try to forward general bulletins for how many days? If you don't
# limit it, your forward list will collapse after some weeks of
# broken link to one of your forward partners.
# How many bytes may users read out at each day? In addition to this
# general setting, you may set a limit for each single user in the bbs
# with the MAXREAD <CALL> <Bytes> - command
MAXPERDAY 999999999
# May users send TELL requests in the user-sf-mode ?
# 0 = No
# 1 = Yes, but only to this mery bbs
# 2 = Yes, to all bbs' (not useful, unless the target bbs is a dpbox)
# Send smaller messages first (outgoing forward sorted by size)
# highly recommended!
# Instead of fixed forward settings (sysop-defined), use auto routing first?
# Results are not too good in networks with different routing software.
# Better you let it switched off unless you really know what you do.
# On restart and RELOAD, start PACSAT broadcast transmission automatically?
# Define the maximum age (in days) of an
# incoming mail (in forward) to be accepted
# Maximalalter (in Tagen) einer im Forward eingehenden Nachricht,
# die noch nicht als OLD markiert wird
# If a local user writes a mail to a bulletin board, request him for a
# lifetime if he forgot to define one?
# Definition of the REDIST server at your bbs:
# ---------------------------------------------
# The REDIST server readdresses (or redistributes) private mails sent to one
# of its four addresses to bulletins that are distributed in a certain area
# around your bbs
# The REDIST server has these four different addresses:
# 1) the LOCBBS server:
#     redists from LOCBBS@CONSOLE_CALL to <redist_defboard>@CONSOLE_CALL
# 2) the LOCAL  server:
#     redists from LOCAL@CONSOLE_CALL  to <redist_defboard>@<redist_local>
# 3) the REGION server:
#     redists from REGION@CONSOLE_CALL to <redist_defboard>@<redist_region>
# 4) the NATION server:
#     redists from NATION@CONSOLE_CALL to <redist_defboard>@<redist_nation>
# short example: at db0gr we use the following settings:
## redist_local  BB  (Berlin-Brandenburg area)
## redist_region OST (the eastern part of Germany)
## redist_nation DL  (whole Germany)
# now define your own ones for your location:
# define the default board for a redistributed message:
# finally, define the lifetime of a redistributed message:
# new with v5.00 (20.9.96):
# if you desire to do so, you can alter the standard system prompt
# refer to the description of the PROMPT command for valid macro definitions.
# A users PROMPT macro will override the standard prompt.
DEFAULTPROMPT (%b) %c de %m>
# better you let this parameter undefined... The callsign defined with
# SFCONNECTCALL is used for outgoing forward connections. Only under very
# special circumstances it is to set to a special callsign. Per default,
# it is (and should be) always the bbs' callsign. 
# the incoming lifetime (counting in days) is used for auto deletion of
# files in the fileservers folders /incoming/, /newbin/ and /temp7pl/.
# A value of 7 days is a good compromise.
# automatically export 7plus bulletins into the file server?
# automatically export autobin bulletins into the file server?
# setting reduceextractlt to ON results in a reduction of lifetime setting
# of an incoming mail that was exported into the file server area. New
# lifetime will be .
# the PACSRV parameter is existing since version v4.10 of dpbox. It was
# never documented cause it seemed to be useless. Anyway: Whenever a sysop
# erases bulletins in the dpbox AND PACSRV is defined with a valid routing
# address, remote erases are issued to the defined address. It was thought
# to be useful for stand alone PACSAT broadcast servers that thiswise could
# be maintained by one master bbs.
# Running different/multiple BBS with the same callsign at one location, you
# have to set the following three parameters. Note that every bbs has to use
# a different SSID.
# Are you running multiple bbs with the same callsign?
# is this bbs the "master" bbs of the multiple bbs^?
# let this parameter switched to "ON" or "TRUE" if you are _not_
# running multiple bbs with the same call but only one bbs.
# But beware: only ONE bbs in a set of multiple bbs^ may be switched to
# If running different bbs with the same callsign, you have to define
# each one of them with a different "sub_bid". Range is from 0 to 6,
# default is 0.
# to enable unproto message list broadcast as defined in system/unproto.box,
# set UNPROTO to ON
# may every user request a resync of the unproto message list or only those
# ones defined with a user setting of UNPROTO ON ?

# last updated 20.9.96 for dpbox v5.00.00 by DL8HBS

back to content page

6.2. system/rubriken.box

The German word 'Rubrik' means the same as the English 'board'. In this file, the fixed boards of the BBS are defined. You can create other (undefined) boards by simply sending a mail to it, but the difference between defined and undefined boards is that the defined usually have a longer lifetime. The lifetime for undefined boards is a general parameter in the box/system/config.box - file. You do not have to define user boards. They have automatically an infinite lifetime (or a limited one, if set up in config.box, what, according to our experiences is highly recommended). But you can define them to provide them with a higher level (or an extraordinary lifetime setting).

The file box/system/rubriken.box may contain board definitions of the following kind:

ATARI 140 1

This defines the board ATARI with a maximum lifetime of 140 days and a minimal required user level of 1 to have access to it.

Boards under DPBOX and TheBox may have up to 8 signs. They are automatically cut to 6 signs when being forwarded to W0RLI/F6FBB systems and re expanded to 8 signs when received in S&F.

Note that two special boards are necessary for the system itself: M and X. The M board contains user information as last login, level, HomeBBS. The X board holds the forward list. You should set the lifetime of X to 0. Board M doesn't "knows" a lifetime. Mail directed to either of these boards is transferred to a generic board.

Boards with only one single letter are sysop only boards. The board T is used for the forward of TELL requests. In Germany, the board F is used for inter-sysop communication (so, a German sysop should define it).

The board Y is used internally for system status information displayed to the sysop. You should define it in rubriken.box !

The board STATISTI is used internally for forward statistic information to the attention of the user and the sysop, too. You should define it in rubriken.box !

The board WP is used internally for the exchange of White Pages information. You should define it to provide it with a higher user level so that it remains invisible for normal users.

You may define as many boards as you want. Note that you should never define boards with only numbers in the name - they will never be readable due to parsing problems (what is a board name, what a message number...).

In box/system/config.box, you may define an optional parameter named UNDEFBOARD. If you set that parameter to, lets say DIV, then every bulletin destined to undefined boards is locally transferred to DIV (of course, then, DIV should be a defined board...).

The total amount of definitions in rubriken.box is unlimited.

back to content page

6.3. system/transfer.box

The board names are not standardised. For example, DX announcements may be found in DXNS, DXNWS, DX-NEWS and other. Let's assume that your BBS has a board DXNEWS. The file box/system/transfer.box should contain the lines:


All incoming mail to these boards is sorted in DXNEWS. Note that this only affects your own BBS. DPBOX NEVER changes any relevant data in outgoing S&F.

The total amount of definitions in transfer.box is unlimited.

back to content page

6.4. system/reject.box

The file box/system/reject.box contains information about types of messages that should be rejected (deferred) or held for sysop attention in your BBS.

The configuration is easily adaptable to your special needs. You can reject mails due to its senders call sign, its length, its board name, its destination, its BID or a combination of all of it.

Every uncommented line in the file uses the following syntax:

action type from @BBS to BID maximum_size(kB)

An asterisk (*) can be used as a wild card. A leading (~) negates the expression.


indicates what the BBS should do if the following criteria in the definition match the incoming mail. Possible values are:

R = reject (do not accept)
H = hold (don't forward until the sysop released the mail)
L = local hold (only hold if locally entered)
P = local -no-password- hold (only hold if locally entered by a user that has no password protection)

P is the most useful appliance for a general local hold.


selects the type of the message. Usually, only B, P and A (bulletin, private and acknowledge) are seen in the packet net. Anyway, there is no limitation in types, and the north American NTS service uses T...


the senders call sign.


the distribution area (@mbx-field)


the board name or receiver call sign


the BID of the message.


matches the message, if the message size is bigger than the value (in kBytes) of this parameter.

Some examples:

P B * * * * 0

will hold all locally entered bulletins by users without password authentication.

R * * * IMAGE* * 0

will reject all messages to the board IMAGE and IMAGES

R P * WW ~SYSOP * 0

will reject all messages with the attribute "private" to the distribution area @WW, except those in board SYSOP. This prevents from mess as: SP DL1XYZ@WW ...

R B * WW MEINUN* * 0

will reject messages in board MEINUN* (discussion area in German language) with world-wide distribution.

R * * * * *_K1MBBS 0

will reject all messages entered in k1mbbs, as this is a CB box.

R * DL1XYZ * * * 0

rejects all messages from DL1XYZ.

R B * WW * * 15

rejects bulletins with a size bigger than 15 kBytes for world-wide distribution.

The format is nearly the same as of reject.sys in F6FBB-bbs, except that only the wild card (*) is accepted and that negations of expressions are possible.

back to content page

6.5. system/badwords.box

This file contains bad words that I even won't quote at this place. It is the data base of the bad word filter of the BBS. Every incoming mail will be scanned for these words, and if one is detected, the mail is transferred into the sysop-only board D (like DIRTY) and stopped from forward. In profile.box the sysop gets a small attention message about this fact, including the incriminated text line. If the sysop decides, that the mail is not to be filtered out, he has to TRANSFER it from D to its original board (the board is noted in the profile message).

This filter is very "sharp", use it with care!!! Usually, only very very bad words should be added to it. And this is how it works:

When putting the word HELLO in badwords.box, all appearances of HELLO are found (in the mail title and body, the forwarding header is not scanned). Due to pirates that broke the common FBB filters, even appearances of ...H..e..ll...o.. are detected, also H e ---l?lo, and hhhh...eeeelll-lloooo.... and so on. Also, the appearance of the word in a longer word is detected: helloall or sayhellotoyou.

This makes the filter really sharp and difficult to handle. Take a good time to think about, which words you put in badwords.box. By adding a space before or after the word, you can determine that the word has to be found as start/end/both of a scanned string.

In general, you should not suppress messages, as this is against the spirit of amateur radio. And I didn't write this program to make you a censor. Unfortunately, from time to time, there are messages in the net that would even catch the attention of a state attorney. So, better filter a little, than loose your license.

back to content page

6.6. system/convtit.box

This file is used to transfer incoming mail according to words appearing in the title. So, for example, the appearance of the word SEARCH could lead to a transfer in board SEARCH. Additionally, you can set a new maximum lifetime for this wise detected mails. See the example.

back to content page

6.7. system/convlt.box

Similar to convtit.box, but if you only want to set a new maximum lifetime and no transfer, use this one. For example, you can detect mail titles with a question mark and set them to maximum lifetime 7 or so. See the example.

back to content page

6.8. system/tcpip.box

If one of the BBS' you are forwarding to is a TCP/IP system, you usually have the problem that this one is waiting for a 'protocol identification frame' to switch to ax.25 and send its CTEXT.

In box/system/tcpip.box you can define those calls. When connecting such a station, DPBOX sends a single <CR> to switch them to ax.25.

Other systems require more verbose login commands. For those, you can use this file, too. All text typed after the call is sent. If a call appears several times, several lines are sent.


DB0XYZ logon

back to content page

6.9. system/wp.for

In conjunction with the White Page settings in config.box, this configures the WP server. In this file, you have to enter call signs of stations (neighbour BBS) to which you want to send WP updates and from which you want to scan received WP updates. Enter each callsign in a separate line.

back to content page

6.10. system/beacon.box

To run a mail beacon, you have to set up this file. If defined, all user board names with new mail are sent as unproto frames in a specified interval. Please, only use this feature if you really install a public BBS. Don't load the HF with useless beacons!

Please refer to the explanations in the file itself.

To enable the beacon, the corresponding switch MAILBEACON in box/system/config.box has to be ON.

This is the distributed example file:

# the mail beacon definition
# the interval. proposed: 30 minutes, maximum: 60 minutes. 0 minutes = OFF
# the 'statustext' appears as a single broadcast. the text is parsed
# by the string convert routine of DPBOX, consult the manual for available
# '%x' - replacements (see the PROMPT command).
# then, if there is mail found, the 'mailtext' is transmitted,
# added with the user callsigns having new mail. (new = unread and
# not older than one week)
MAILTEXT Mail for :
# the unproto-addresses for the mail-beacon:

The QRG setting requires as first parameter the TNT interface name to be used to transmit via the path that is added in the next words. In full words, the above setting starts a mail beacon every 30 minutes at the following unproto addresses:

TNT interface "LINK": to MAIL
TNT interface "LINK": to MAIL via DB0BER DB0BLN
TNT interface "LINK": to MAIL via DB0BER DB0BNO DB0BLO

back to content page

6.11. autobox.dir

The file autobox.dir is responsible for the monitor cut features of TNT/DPBOX. DPBOX can fill up its own BBS by simply monitoring a HF channel. If TNT monitors a message to a board defined in this file, the BBS monitor is started. The file header formats detected by this routine are:

* W0RLI - S&F
* TheBox / DPBOX
* BaycomBox
* WAMPES (dk5sg-bbs)
* F6FBB (this needs your assistance)
* and all others that are compatible to one of the above

Note that monitoring F6FBB type S&F is impossible due to protocol reasons.

Refer to the example of the autobox.dir for the syntax.

You should not use this feature when running DP as an official BBS. In Linux version refer to your TNT documentation, it is part of the terminal features, not of the BBS.

back to content page

6.12. system/f6fbb.box

To monitor files of F6FBB type BBS you have to set up a file f6fbb.box.

The reason is, that every sysop can change the file header. In the distributed f6fbb.box, two different file headers are defined. Note that this file does not contain keywords. The definitions are read in the first 16 uncommented lines of this file. Do not add empty lines...

Read the comments in the file. The best way to configure it is to read out a file of your local F6FBB BBS and save it on disk. So you can easily copy the required parts of the file header in the configuration file. When you did this, restart TNT/DPBOX and try again to read a file of the F6FBB BBS.

This file is without importance when monitoring features are turned off (as an official BBS should do...). It is only useful for user installations. As the monitoring features rely on both, TNT and DPBOX, you have to read the TNT documentation for a full set up of this feature and make sure that TNT will read the system/f6fbb.box - file too to detect the defined fbb file headers while monitoring a radio frequency. If in doubt, disable this file.

back to content page

6.13. The .sf Files

This is a complex matter. First try to imagine, how a message distribution system works:

We get a message (from elsewhere). In the header of the message, we have two relevant routing information:

1) the destination (call sign or board)
2) the @mbx field (BBS call sign or distribution area as @WW)

Another relevant information is the call of the BBS that sent that message.

Now, the router has to decide what to do with the message. There are three cases:

1) don't forward it, it is destined to the own BBS
2) forward it to ONE neighbour, it is a private mail or a bulletin destined to only one BBS.
3) forward it to several neighbours, it is a bulletin with a distribution area (@EU , @WW ...)

Case 1) is very easy to detect. Just find out if the @mbx field is the call of your own BBS or if the @mbx field is empty.

Case 2) is the most difficult. Find out, which of your several neighbours is the next to the target BBS. Not that simple, huh? If you found out, mark the message in a list to be forwarded to that neighbour.

Case 3) is not that difficult, because it only depends on sysop settings. Find out, for which of your neighbours the sysop has defined this @mbx to be forwarded. Mark the message in your forward list to be forwarded to those neighbours.

In reality, the routing is much more complex than described. Many exceptions may occur. What, for example, should happen if a message was forwarded FROM a neighbour to your system that, according to your knowledge about the net, has to be routed BACK via that neighbour...

All OK until now? Well, the problem is, the sysop is YOU. You have to set up the forward definition files very accurate, because many routing problems can be avoided if the definitions are all right. The same is valid for the sysops of your neighbour BBS'. Get in contact to avoid wrong routing. The DPBOX system stops ping-pong mailing immediately, but this does not stop the wrong forward definition either in your system nor your neighbours one nor both.

Every unrouteable mail creates a warning message sent to the sysop.

Now, after that long preliminary, you should take a look at the .SF example distributed with DPBOX. The file db0xyz.sf in the folder box/sf/ is a simple ASCII file, and you have to create a similar one for every one of your forwarding neighbours. The files have to be stored in the folder box/sf/ to be effective.

The file contains several keywords:



The first two control the connect sequence and the timing. The others are responsible for the router.


this keyword may appear several times. It defines connect paths for a specific Interface QRG.

The TNT terminal will set up the routing for you, you only have to define, which TNT to use (there may be several running on your system for multiple TNC connected).


(900 is a time-out for the connect sequence, in seconds, BERLINK is the identification set in TNT.UP for one of its interfaces).

Check the FAQs supplied with this documentation for a more detailed help on configuring TNT and DPBOX for outgoing forward.


this keyword controls the timer that generates an outgoing connect to a neighbour BBS. Also, it defines the maximum size of messages to be forwarded.
It has nine parameters, set them all:

minutes the timer interval in minutes the outgoing forward is to be initialised if mails are waiting.

tnc Put a value of 0 in here - the parameter was used for the atari version. Don't leave it blank!

if defines the case the forward is started:
0 = never
1 = if mails are waiting
2 = if mails are waiting OR if minutes2 expired (reverse forward will be started)

maxuser defines the maximum size of a user mail to be forwarded (in bytes).

maxbulletins defines the maximum size of a bulletin to be forwarded (in bytes).

maxproposals defines the maximum size of all bulletins in one forward step (in bytes).

minutes2 the timer interval in minutes if case 2 of the 'if' definition is valid. More exact it is the interval the reverse forwarding is started if no mails are waiting. Never set this value too low.

startUTC defines the start time any forward action is valid. Example: 0000

endUTC defines the end time any forward action is valid. Example: 2359

Overall example:

SFPARMS 15 0 1 3000 2000 4000 300 0000 2359

By the way, this is what you get displayed when entering the SFPARMS command in the BBS.

Now you must define the routing relevant data's. The following keywords may appear several times in the file.


defines the @mbx field that is to be routed to the neighbour BBS this file is made for.


excludes a @mbx field to be routed to the BBS.


well, this is germish. Excludes boards to be routed to the BBS.


excludes messages received by a specific BBS to be routed to the neighbour BBS.


Rubrik is the German word for board. All messages sent to this wise defined boards are forwarded to the neighbour BBS. This is not a proper forwarding feature, so do use it only with user forward definitions, not in BBS to BBS definitions.

The FOR and NOT keywords accept hierarchical definitions.

Some examples:

FOR *.AS *.NA *.NOAM *.SA *.AF

defines all messages to Asian, American and African BBS to be forwarded to this neighbour.


defines all messages for @DB0XYZ and @DB0XXX to be forwarded to this neighbour.


defines all messages for French BBS to be forwarded to this neighbour, accepting .EU and .EURO suffix...


defines all messages for BBS with the first letter 'F' in the call to be forwarded to this neighbour. Not the best way of defining your routes... please use hierarchical definitions.


defines all bulletins with the @mbx field @EU @WW @SCAN and @DL to be forwarded to this neighbour.


excludes all messages for BBS in the Berlin region to be forwarded to this neighbour.


excludes all messages for @F6KLM to be forwarded to this neighbour.


inhibits the forward of the boards GIF and SALES to this neighbour.


inhibits all messages received FROM DB0ZZZ to be forwarded to this neighbour.


forwards all arriving messages of the board ATARI to this neighbour. This is not a very proper forwarding method... only for very special applications.

back to content page

6.14. Setting Up Outgoing Forward

Please read this FAQ for further help on the subject of installing the forward:

Q: How do I set up S&F?

A: This involves both, dpbox and tnt configuration. First, set up a sf-definition file for each of the bbs you want to forward to. There is a sample file db0xyz.sf in the box directory. Put each of the definition files in the box/sf/ directory. Their name has to be composed of the other bbs callsign and the extension .sf

For most of the parameters in those files, read the dpbox documentation, there is a section "The .SF Files".

For two of the keywords I'll have to give you extra help:

The IFQRG statement:

This means: dpbox will use the interface named BERLINK to force tnt to connect to a station named DB0BLO-8. Connect timeout is set to 900 seconds.

This assumes that you configured two things in tnt: first, you must define the interface name of one of your running tnt as BERLINK (you may name it the way you like it, by the way). Then, you have to create a route in the routes.tnt of that very tnt to tell it how to connect to a station DB0BLO-8.

How do you define an interfaces name in tnt? Add a definition to tnt.up of your tnt: QRG 0 BERLINK
For full documentation of that parameter, refer to the tnt documentation. Best choice for interface names is either a numerical value (the frequency) or an uppercase! name.

Although most installations prefer to use only one single tnt to connect to the outside world, there also exist some with multiple tnt connected to one dpbox. At DB0GR, currently three tnt are serving three TNC2, one used for a 23cm interlink to the next node (DB0BER, so we called the interface BERLINK, you see?), another for the 70cm user port and a third one for the 70cm PACSAT style bbs broadcast.

So far for interfacing. Now about the SFPARMS statement:
EXAMPLE: SFPARMS 2 1 1 200000 200000 200000 90 0000 2359

The second parameter of the statement confuses a little: here, following the documentation, you have to enter the TNC-number to be used for that forward. Simply ignore it, set it to 0 or 1 or whatever (but don't leave it blank). That was used for the Atari version. For all other, refer to the documentation.

Finally, you should set the SFLEVEL of all bbs you defined as forward partners to 1 or 2. To do so, log into dpbox, type SFLEVEL CALL 1 Type HELP SFLEVEL to get a more detailed help. Never set an sflevel 2 for any of your neighbours unless it is a THEBOX bbs. If it IS a THEBOX bbs, never set the sflevel to 1, always use 2! The THEBOX system uses an incompatible way to exchange feature lists in its SID, dpbox (and no other bbs) can't handle that automatically.

Now type RELOAD in dpbox, voilà, the forward is defined.

back to content page

6.15. The Language Files

The BBS is multilingual. The language files are in the folder box/language/ .

To define a language, a file XXX.LAN has to be created, where XXX is replaced with the abbreviation of the language (as 'G' for English, 'DL' for German...). The structure of these files is easy, revise one and you understand all.

It is proposed to create a set of help files for every new language. Help files have the extension .XXX (replace XXX with the language abbreviation). The English help file for NAME has the name NAME.G , for example. Such a file is read if a user types H NAME . Starting with version 4.08, there may be an overall help file, named G.ALL for example. See the examples.

back to content page

6.16. system/unproto.box

Starting with version 5.00, DPBOX supports unproto message list broadcasts, as F6FBB does.

Every time a new bulletin arrives in the bbs, a single-lined unproto message is broadcasted. A user terminal can catch those messages and display the local bbs check/message list offline. The user (with appropriate programs, TPK and TSTHOST(?)) can select messages off this list, they are marked to be requested during the next forward connection with the local bbs (if not yet loaded at the users computer).

DPBOX supports two formats of message list broadcast: the original one, implemented by F6FBB and an extended one, implemented by DL8HBS. The F6FBB format has two disadvantages: it does not contain BIDs, the ID of the file is always its local message number, and it doesn't support message lifetime transmission. Both is resolved with the extended DPBOX format.

A single line broadcast of the message list in F6FBB mode has this format:

12345 B 2053 TEST@ALL F6FBB 920325 This is the subject

This is: message_number, mail_type, size, address, sender, date, subject.

It is forwarded to the unproto address FBB.

A single line broadcast of the message list in DL8HBS/DPBOX mode has this format:

12345 12345_DB0XYZ 7 B 2053 TEST@ALL DL8HBS 920325 This is the subject

This is: message_number, bulletin_id, lifetime(days), mail_type, size, address, sender, date, subject.

It is forwarded to the unproto address DPBOX.

In both formats, gaps in message numbering (due to private mails in the upcount of message numbers) are signalled with a blank message broadcast:

12346 #

This enables the user client to check if it receives all broadcasts continuously. Detecting missing lines, the user can send a resynchronisation command to the bbs to let it repeat the last transmissions.

The syntax of those (unproto) requests is:

? 00002EE00E

For request of a resend of DPBOX style message list broadcast, two ?? must be present as first word of the request line.

If the user is not allowed to request, the bbs broadcasts a line like:

12000 / call

(where 12000 is the requested resync line). User software then MUST stop sending requests.

If the request was accepted, it will be decoded:

The first 8 digits of the second word of the request are the hexadecimal number of the requested start of the list (here 00002EE0 -> 12000) and the last two digits are the sum of the four bytes anded with FF (E0).

The BBS will then start sending lines from the requested number up to the last message number.

If the number requested seems to be too far from the current line, the BBS can reajust the request of "callsign" by sending :

12000 ! CALLSIGN
12001 B 2040 TEST@FRA F6FBB 920325 This is a bulletin
12002 #
12003 B 206 TEST@F6ABJ F6FBB 920325 Hello Remy.

and then starts sending lines from 12001. The remote system must change its base number to 12001.

Note: the bbs always broadcasts to either the address FBB or DPBOX, but the requesting user always broadcasts to the bbs' source call sign.

If the number requested is greater than the last message received in the BBS, the BBS will send a line like :

12300 !!

This indicates that the list in the remote system is up to date. The last received message in the BBS is 12300.

If the users client connects the bbs in forward mode to read some of the messages, the syntax is:

F< #message_number

The message then is transmitted in compressed forward, regardless of the SID of the connecting user client.

Parts of the last paragraphs were taken from F6FBB documentation.

To setup all parameters for the unproto message list feature, a file system/unproto.box should be edited:

# how many lines in message list broadcast may a request scroll back?
# do we want to broadcast in F6FBB mode?
# do we want to broadcast in DPBOX mode?
# broadcast via which path?

Please compare the QRG parameter with that one in system/beacon.box. It has the same syntax.

To enable message list broadcast in general, you have to switch the parameter UNPROTO in system/config.box to ON.

Also, UNPROTO_ALL in system/config.box defines, if all users may request resends or only selected ones, enabled by the sysop with the UNPROTO command (see HELP UNPROTO).
At this time (20.09.96), resynchronisation features are not tested. Can only hope it works. Resynchronisation is only supported with TNT versions > 0.9r.

back to content page

7. The Auto Routing Feature

The BBS has an auto router feature. You cannot switch it off. How does it work?

DPBOX analyses the forward headers of every incoming mail (depending on the switch ANA_HPATH in system/config.box). A file hpath.box in box/stat/ is fed the information. The BBS compares the times in the forwarding header to find out the fastest way to a BBS. The fastest way is overwritten after a specific, dynamically calculated time, so that an enormous time record caused by extraordinary circumstances cannot block a maybe better, newer way for too long.

Depending on the switch SMART_ROUTING in box/system/config.box, auto routing is priorized to the route definitions in the .SF files or vice verse. Only if no definition is found with the priorized method, the other one is tried.

Practice showed that auto routing doesn't works too well in our heterogeneous networks, in general you should rely on hierarchical definitions and switch SMART_ROUTING OFF. If you don't, forward loops, also known as the "ping pong phenomena", may occur if your neighbour bbs's use different routing strategies than DPBOX. This means: the auto router is fine for small gaps in your definitions, but not for a complete routing setup of the BBS.

In case of activated auto routing, outgoing (but still waiting) private mails are re-routed every 4 hours according to the current routing map.

Also in case of disabled auto routing, the auto router will be used for private mails that are waiting longer than half the time of RETURNTIME for forward. This should help correcting erroneous sysop route definitions. RETURNTIME should be set to about 7 days for a good compromise (in box/system/config.box).

back to content page

8. The Bulletin ID System

Bulletin ID's (BID's) are used to prevent double reception of messages. They are a unique signature of a message. The BBS saves every received BID in the file box/stat/msgidlog.dp . The BID remains 'known' even when the file is deleted in your BBS. Of course, the file may not grow endless. If its defined maximum size is reached, the file is overwritten from the beginning.

You can realign the file to the current content of your BBS with the command REBUILD.

BID generation is of the kind : xxxxxx_CALL, where xxxxxx is the UNIX time (count of seconds since 1.1.1970), projected on a character set of 0..9,A..Z. So, your BIDs remain unique up to the year 2040 or so.

back to content page

9. The Return Mailer

DPBOX has an integrated return mailer for undeliverable private mails.

It gets activated in six cases:

1) no forward possible due to bad link
2) no forward possible due to bad route setup
3) no forward possible due to bad destination bbs callsign
4) unknown user on local bbs
5) reject on the mail by a neighbour bbs
6) unread mail, lifetime expired

In case 1 through 4, the mail is returned after the defined RETURNTIME. The RETURNTIME is defined in box/system/config.box, a value of 7 days should be OK. Don't chose a too long delay, the bbs needs the return ability!

In case 5), the mail is returned after approximately three days. This is a fixed internal value.

In case 6), mail is returned after the defined USERLIFETIME (also in box/system/config.box). 90 days seem to be a good value. Don't set it to 0 (= infinite), then, the bbs can't clean up for you...

Depending on the reason for returning the mail, a more or less precise description of what was the problem is preceded to the returned mail.

The returned mail is sent to the originator call @ originating bbs. It is limited in size to 1500 bytes.

back to content page

10. Automatic Batch Jobs

For most automatic jobs, the crond of the Linux system will offer you all you need. However, some actions could better be performed by the bbs itself.

You can place batch files in the box/system/ directory to start specific actions at specific times. The batch files may contain all valid bbs commands and are processed line by line in background to the normal operation of the bbs.

Set them up carefully, no specific error checking is done while execution. Believe the worst that may happen is that a batch job ends in a timeout, but one never knows.

This is the mechanism: every hour, DPBOX looks for a batch file named "hour.bat" in the box/system/ folder. If found, it will be executed with sysop privileges. This file is good for all jobs that should be done in an interval of 60 minutes.

Also, a batch file named "hour_<current hour>.bat" is searched and executed. This should help for jobs that should be done once a day. At 00:00 UTC, DPBOX looks for box/system/hour_0.bat, at 01:00 UTC it looks for box/system/hour_1.bat and so on.

A short example: Your general USERLIFETIME is 90 days. For some users you want to set the lifetime of their private mails to 180 days, because they log in very seldom but are still active users at your bbs. Now you define a file box/system/hour_7.bat with the content:


and every day at 07:00 UTC all existing private mails for the users DL1XYZ, DL2XYZ and DL3XYZ are set to a lifetime of 180 days.

back to content page

11. Message Filtering

DPBOX offers you an interface to investigate every incoming mail before sorting it in the BBS. Your program can copy the mail for special purposes, e.g. 7plus extraction or force DPBOX not to take the mail. A third possibility is to change board name and lifetime. You can even alter the content of the message itself. I do not know why you should do this, but you have all possibilities. For this reason, always reflect on what you are doing if you alter the content of a mail. Normally, a message system should be transparent and NEVER change anything of the mails. You could cause a lot of trouble in the net, and that's not where DPBOX was made for.

How does the interface work?

If you putted a program m_filter.prg in the folder box/run/, this program is called every time a mail is decoded. The program is called with only one parameter in the command line, a full filename (including path) of a file that contains the new mail.

Note that this slows down the execution time of the mail sort routine. Normally, no intermediate file is created on disk when sorting a mail.

In the first seven lines of the file you find some ASCII information, followed by the mail itself. Take care, the mail could be a binary file! DPBOX supports full binary mode in S&F and user in/output. Your program also should...

The first seven lines contain:

* the call sign of the box the mail was received from
* the senders call sign
* the board name (destination field)
* the @mbx field
* the lifetime
* the bulletin id
* the title of the message

You can alter the board name and the lifetime, but note that these changes are only effective for your own BBS, not for outgoing S&F. The other parameters cannot be altered, they are only present for information.

Following the seventh line, you find the complete mail including forward headers.

Your program must return a return value. A value of

0 indicates that nothing was changed
1 indicates that the mail has to be deleted
2 indicates that the mail shall not be forwarded
3 indicates that your program changed either board, lifetime or mail content (or all) and that DPBOX has to accept the altered mail
4 indicates that your program changed either board, lifetime or mail content (or all) and that DPBOX has to accept the altered mail but shall not forward it.

If returning the values 3 or 4, take care that the format of the altered file is exactly the same of the file DPBOX created.

back to content page

12. External Commands

The internal set of commands can be expanded with an unlimited number of external commands. For every new command you have to write a script or program to be placed in the folder box/run/. The program must have the commands name and no extension.

To make the command available, you have to note its name in the commands.box file using the syntax of that file as discussed above. The internal_command_number must be 98 or 99 (98 is most useful, 99 switches the linefeed conversion in in- and output of the command off).

Examples of an entry in commands.box:

RUNTEST 98 0 1

defines the external command runtest, no sysop flag, requires user level 1.

You can define as many external commands as you want.

The external command is started in an own task, it may interact with the user via stdin/stdout.

NOTE: installing a script you have to note the interpreter in the first line, so, for a shell script write:

#! /bin/sh

in its first line.

The Parameter Interface:

When executing an external command, DPBOX defines some environment variables. They can be read with getenv() by the external command.

stdin and stdout of the external command are linked to the users connection.

These environment variables are set by DPBOX:

DPBOXBOARD=(current board)
DPBOXLASTDATE=(last login)
DPBOXIXLASTDATE=(last login in unix time format)
DPBOXSENDERASEOK=(0|1, user may send and erase mails)
DPBOXHIDDEN=(0|1, user is in HIDDEN mode)
DPBOXPWOK=(0|1, user is verified with password)
DPBOXBOARDSYSOP=(0|1, user is a board sysop)
DPBOXSYSOP=(0|1, user is sysop)
DPBOXUSERLEVEL=(0..127, userlevel)
DPBOXBOXCALL=(Callsign of mailbox)
DPBOXSERVERMODE=(0|1, user is currently in file server mode)
DPBOXCONNECTPATH=(full ax.25 header of the users connection)
DPBOXUNPROTOOK=(0|1, user may request unproto list resynchronisation)
DPBOXNOCHECK=(excluded boards for CHECK command (NOTBOARD-command))
DPBOXLASTCMD=(last entered commandline)
DPBOXDEBUGLEVEL=(0..5, debug level of bbs)
DPBOXUSERTIMEOUT=(timeout in minutes)
DPBOXVERSION=(version number)
DPBOXUSERNUMBER=(boxchannel of this user)
DPBOXUSERCOUNT=(actual count of users)
DPBOXTEXTOUT=(Output file name for plain ASCII text)
DPBOXTRANSOUT=(Output file name for transparent binary output (sent without all headers as binary))
DPBOXBINOUT=(Output file name for autobin binary (sent with calculated autobin header as binary))

The three file names may be used by the external command to send data to the user. The files are sent after termination of the external command. All three output files may exist, they are sent consecutively if existing. File size is unlimited.

back to content page

13. Time-Outs

After 20 minutes of no activity, a user is disconnected.

A S&F connect is cancelled after 15 minutes of no activity.

These times can be set up in box/system/config.box.

back to content page

14. Multiple Commands

You can enter multiple BBS commands in one line, separate them with a semicolon (';'). Example:

u;v;r dl8hbs 1;c

This is the reason why no semicolon is accepted in message title input.

back to content page

15. Output Abort

You can abort the output of the BBS at every time by typing a single <RETURN> (an empty line). Note that it may take some lines until output is stopped.

back to content page

16. Erase / MyBBS Forwarding

DPBOX does, as TheBox and BaycomBox, erase and mybbs forwarding.

Whenever a user enters his HomeBBS, a message to M @ THEBOX is generated, with a subject of HomeBBS + UNIX Time, separated by a space.

Whenever a user deletes a message that was written by him and that was forwarded before or received in forward, a message to E @ THEBOX is generated, with a subject of the BID of the deleted message.

The forwarding neighbours that have an entry FOR THEBOX in their .SF definition files will receive those messages.

back to content page

17. The Auto Import Feature

Every minute, the box/newmail/ folder will be checked for files of the type import.*

Also, the folder box/import/ is scanned for any file it contains.

They have to match the expected file format (full status header such as if you read out the mail of the BBS).

The files are imported in the BBS as if they were sent manually.

If found in folder box/newmail/, they are put in the forward if the destination address requires it.

If found in folder box/import/, they are only locally stored, with a remark in the file header that this file was imported.

As for most scriptable programs it is difficult to generate a mail header as is used in DPBOX, a simplified import file format was introduced:

In the simplified import format, the message itself is preceded by six simple text lines, containing the mail header in the following format:

1) Originator Call
2) Destination (board or callsign)
3) @mbx field (may be left blank. Will check for stored home bbs if private mail)
4) lifetime (may be left blank)
5) Bulletin ID (may be left blank, DPBOX will assign an own BID)
6) Subject (preceding word "Subject: " will be deleted)

With the seventh line, the mail itself starts.

Sending a message to DL8HBS@DB0GR could look this way:

<left blank>
<left blank>
Testing IMPORT feature
From: DL1XYZ@DB0XYZ <this is the start of the mail>

This is just a simple Test.
<this is the end of the mail>

One important note: Fill up at least one of the first six lines with at least 70 spaces. If you don't, it may happen that header conversion to internal header representation will fail because the regenerated header will not fit into the file header. This will be stated in the profile.box file.

back to content page

18. The S&F - Resume Mode

Starting with v 3.60, DPBOX supports a crash recovery in S&F (as does F6FBB starting with his version 5.15c). This means, that an aborted S&F transmission (due to link failures etc.) will be resumed the next time at the point the transmission was stopped. So, if you forwarded a 300 kByte file and the link failed after 299 kByte, you will only have to send the missing 1 kByte, not all 300 kByte again. This is a real improvement of the amateur radio forwarding system.

back to content page

19. The Broadcast Mode

The up-to-date most advanced feature of DPBOX is the built-in PACSAT Broadcast Server and the Broadcast Receiver.

The PACSAT Broadcast Mode was developed for satellites, but it works well terrestrial, too. The theory is that usually many users read out the same files of a BBS. It would be much more efficient if the BBS 'broadcasts' the files simultaneously to all interested users, so HF channel load will be lowered dramatically. In practice, this means that a local BBS offers a second HF channel, 9600 baud data speed recommended, where 24 hours a day all incoming mails are 'broadcasted' in a special protocol. The files are repeated, of course, depending on their age. New files are often retransmitted, older ones less often. With today's German mail count, a cycle time of about 30 minutes for the files of the last 24 hours is reachable (in 9k6...). This means, that a user starts reception, for example when coming home, and about half an hour later, he has all new files of the day on his own system. If he stays tuned for longer, he has the chance to catch older files, too, but usually, they were received by him the day before and therefore deferred. Note that the user doesn't needs a transmitter for this mode, so this is fine for SWL's, too. When the user wants to write a mail, he has to leave the broadcast frequency and to connect the BBS on another channel in the usual way.

Take yourself 5 minutes to think about this feature and its implications for the packet radio network. Assuming that about 90 percent of all traffic is the readout of BBS files, the digipeaters will get a lot of free time and bandwidth with this technology.

DPBOX includes both sides of this amazing mode: The Server and the Receiver. DO NEVER USE THE SERVER IF NOT ACTING AS A LOCAL BBS, it will create an incredible amount of QRM! Normally, you only should use the Receiver.

Received files are sorted in your own BBS, according to the selection mechanisms with REJECT.BOX, RUBRIKEN.BOX etc.

One word about satellites and DPBOX: In general, the used protocol at UO-22 or KO-23 is the same as within DPBOX. But, note: Due to small sized antennas I never caught a whole file from those satellites. I cannot promise it works all right. A main problem is the 'request mode', a feature that is not used terrestrial (here, distorted data blocks are resent automatically in the cyclic time slices of the BBS). So better don't use DPBOX interactively on the satellites. But it should be OK for monitoring.

DPBOX/TNT includes one additional Broadcast feature: You can send any file of your file system manually in Broadcast protocol. So, if you have a free frequency, you can try it with some friends. This kind of file transmission works about 20% faster than a direct connect in AX.25 between two stations. With more stations involved, the point-to-multipoint flow makes it incredibly fast compared with usual connects.

Note that with Broadcast mode, a tnc watchdog should be switched off (mostly, there is a simple R-C - time constant, limiting ptt keying time to 20 seconds or so).

Broadcast is most useful with high data rates. Of course, it will also work with 1200 baud, but the advantages start with 9600 baud.

When installing DPBOX as a BBS Broadcast Server, you should shut down the monitor of the terminal program completely to avoid timing problems in hostmode. A server does not react on received frames, so they are not needed.

Refer to the TNT documentation to find out how to receive a PACSAT Broadcast when using TNT/DPBOX at home.

Broadcast transmissions require, for proper decoding at the receiving side (if not received by DP or TNT/DPBOX, they are very tolerant concering this item), the protocol identifier (PID) hex BB instead of the usual hex F0 in packet transmissions. Currently, except the TNC3 firmware of DL1GJI (thank you, Jimi), no common TNC software supports the change of the PID while transmission. DL4YBG and I, DL8HBS, proposed an extended command @P <PID> (<PID> in decimal) to change PID setting for any channel the command was applied for NORD<>LINKs TheFirmware in late 1993. Up till today it's not officially implemented. Nonetheless, you have different possibilities to broadcast with the required PID:

1) use the modified TheFirmware 2.7a available from DL4YBG and DL8HBS
(warning: current version 2.7b by NORDLINK doesn't support the @P command)
2) use TFKISS/Linux as dated from 07.04.96 or later with any KISS TNC.
3) use TFPK, TheFirmware for PK232, ported by DL4YBG, version 2.6a(bc) or later
4) use a TNC3 with a current Firmware.

How to find out if your TNC is ready to support broadcast transmissions:
Simply open a terminal connection to your TNC and type: <ESC> @P <RETURN>
If the response is NOT "invalid extended command @P" or any other error message but a numerical value, then your RIG is ready to transmit in PACSAT Broadcast protocol.

DPBOX supports one special feature concerning Broadcast:

If you have one bbs able to transmit broadcast, you may append an unlimited amount of DPBOXes to receive its broadcast and treat the received files as if they were transmitted directly in S&F to you. This depends on a switch in box/sytem/config.box (BCASTFORWARD).

Just reflect what this could mean: you have one bbs on a prominent hillside in your region, and this one is able to supply all of the bbs in a wide range with the newest bulletins, only occupying one single radio channel for all bbs it forwards to (and the forward takes place at the same time)...

back to content page

19.1. The File system/bcast.box

To configure the DPBOX PACSAT Broadcast, you have to config a file box/system/bcast.box. The file consists of an unlimited number of definition structures, each one starting with a '{' and ending with a '}'. Usually, only one or two definitions are made.

An example:

LEVEL    1
SLICE    300
SLICE    1500
SLICE    5700
SLICE    86400

The QRG parameter defines the TNT interface for this broadcast transmission definition.

The TXPATH appears in the 'via'-field of the unproto transmissions, in this case the frames are sent to 'QST-1 via DB0XYZ'.

The MSGSEL parameter may be either 0, what means that all bulletins in the BBS are transmitted, or a composed bit value, describing the source the mails were coming from with the following code:

MSG_SFRX      		=    4;     { received in S&F        }
MSG_CUT       		=    64;    { the monitor cut mails  }
MSG_MINE     		=    128;   { originated at this BBS }
MSG_BROADCAST_RX 	=    2048;  { received in broadcast  }

So, for example, if you wish to broadcast only mails received in S&F or originated at your own BBS, set MSGSEL to 4+128 = 132.

The LEVEL parameter sets the user level of the "user" broadcast in the bbs. Providing the broadcast with a higher level than the standard 1 would allow it to read boards normal users may not read. This way, you could define that a board PICTURE may not be read out in normal user mode but will be broadcasted...

The FILETYPE parameter defines which PACSAT file type will be used for transmission. Better leave it on 0.

The SLICE parameter opens a time slice for a subset of messages. Up to 20 slices are possible, every slice has the same transmission time over all, they are sent simultaneously. The value following each SLICE entry is the repeat time in seconds of that message block. Let me describe it with an example:

Above, slices of 300, 1500, 5700 and 86400 are defined. This means: in the first slot, all messages are sent that can be sent in 300 seconds. After 300 seconds, the newest message is sent again and so on. In the second slot, all messages are sent that can be sent in 1500 seconds, starting with the first message that was not sent in slot 1. In the third slot...

The result is that the newest messages are sent very often (at least all 5 minutes), older messages have less high cycle times. Note that it seems useful not to define more than four or five slices, because the more slots you open, the less time rests for each one. But anyway, this is an experimental parameter, so, experiment!

Transmission will be started with the BROADCAST ON command (see command description) or per default with SEND_BBSBCAST ON in system/config.box (see above).

back to content page

20. The DPBOX file server

Starting with version 5.00, DPBOX includes a file server area.

What is it: starting the file server mode, a user has access to a file area not that different to an ftp server. Up/Download - protocols are of course limited. Possible are: YAPP/YAPPC, AutoBIN and Text.

Protocols may be expanded by external commands.

The "root" directory of the fileserver is box/fileserv/.

Upload of users is only possible in incoming/ directory.

Check the description of the FILESERVER command for possible user/sysop commands.

The file servers /newbin/ directory can be filled automatically with 7plus and/or autobin extractions, if desired by the sysop. To enable this feature, set AUTO7PLUSEXTRACT and AUTOBINEXTRACT in system/config.box to ON and install 7plus on your system (in any one of the search paths of your linux installation). The 7plus extractor of DPBOX NEVER sends .ERR files to the uploaders of the files. If errors occur, it waits for eventual .COR files, until the INCOMINGLIFETIME (a value in system/config.box) is expired. 7plus extractions in progress are stored in the /temp7pl/ folder of the fileserver. Advice your users not to read out the stuff in that folder, its completely useless. After complete reception the resulting binary is stored in the /newbin/ folder.

Files starting with a dot (.) in file server directories are only visible for sysops. Usually, they contain a short (up to 5 text lines) description of the content of a file with the same name without a leading dot. In auto7plus/autobin extraction, those descriptions are automatically generated by the information of the S&F file title, in case of user uploads, the info is requested by the uploading user. Upload is impossible without a preceeding info. This info is displayed with the LIST command, but not with LS or DIR.

Moving, copying or deleting a file in sysop mode always moves, copies or deletes the description file, too.

A sysop may use the command INDEX in file server to enter a directory description displayed to every user when applying the LS / DIR command on the directory for the first time after a CD (change directory) command. Index files are stored as ".index" in the belonging directory.

The file server NEEDS the directories box/fileserv/, box/fileserv/temp7pl/ and box/fileserv/newbin/. All other directories are mandatory.

To disable user access to the file server, disable the FILESERVER command in system/commands.box. Do NOT simply erase the fileserv/ directory. It MUST exist.

Do not forget to install 7plus on your system!

In analogy to the file server, a second area named the privserver is existing. It is not that useful for remote bbs installations, but when using DPBOX at home and having AUTO7PLUSEXTRACT ON, incoming private mails to the bbs callsign (in this case the callsign of yourself) are extracted and recombined so that you get rid of the manual work with 7plus. Files are stored in the box/privserv/ directory, a box/privserv/temp7pl/ directory MUST exist!, even for remote bbs installations.

If you want to, you can reduce the lifetime of extracted bulletins in the normal bbs file system by setting REDUCEEXTRACTLT ON in system/config.box. Used lifetime is that one of UNDEFBOARDSLT (defined in system/config.box).

Files in file servers folders /incoming/, /temp7pl/ and /newbin/ are deleted after INCOMINGLIFETIME (defined in system/config.box).

back to content page

21. Running Multiple BBS With The Same Callsign

For some installations it seems to be interesting running different bbs softwares with the same callsign. This causes a lot of conflicts with usual error checking mechanisms of modern bbs systems.

Starting with version 5.00, DPBOX supports this kind of multi-bbsing. Three switches in system/config.box are responsible for proper operation:

Excerpt of system/config.box:

# Running different/multiple BBS with the same callsign at one location, you
# have to set the following three parameters. Note that every bbs has to use
# a different SSID.
# Are you running multiple bbs with the same callsign?
# is this bbs the "master" bbs of the multiple bbs^?
# let this parameter switched to "ON" or "TRUE" if you are _not_
# running multiple bbs with the same call but only one bbs.
# But beware: only ONE bbs in a set of multiple bbs^ may be switched to
# If running different bbs with the same callsign, you have to define
# each one of them with a different "sub_bid". Range is from 0 to 6,
# default is 0.

Having set MULTI_BBS ON, you can define a forward definition to a bbs with the same callsign. Do not forget to set a different SUB_BID for every involved bbs with the same BID generation algorithm, otherwise double BIDs may be generated. The MYBBS command in DPBOX was changed to allow a user to set its HomeBBS not only to a bbs call but also to a call+ssid. As network forwarding of HomeBBS settings never allows to append the SSID information, the MASTER_BBS flag is needed to determine if a HomeBBS information entered WITHOUT SSID is meant for this very bbs or one of its colleagues with the same callsign but different SSID. If the bbs receives a private mail for a user with a home bbs of the same callsign but with different SSID or with a HomeBBS without SSID and MULTI_MASTER set to OFF, the bbs tries to forward the file to another bbs of the same call. In praxi this means:

Connecting different bbs with the same callsign is ONLY possible in a kind of token ring connection. Assuming you have three bbs at your location, 1) with DPBOX, 2) with FBB 3) with BaycomBox, internal forward connections HAVE to run in a ring structure, for example: 1) forwards to 2), 2) forwards to 3), 3) forwards to 1).

All other combinations will lead to unsolveable protocol problems, and, being honest, I do not believe that it even works with the above combination, but its worth a try.

It is ABSOLUTELY necessary, that none of the involved bbs in a local "ring" shares the same forward partner outside of the local net. If 2) wants to forward a mail to a forward partner of 1), it has to send the mail to 3), 3) has to send it to 1) and, finally, 1) to his forward partner.

Sounds complicate? It is. All of the above restrictions and complications were avoided if every bbs would use an own callsign. Have fun.

back to content page

22. Importing a TheBox Mail Database

The Linux version of DPBOX offers you the possibility to import a whole TheBox structure (TheBox is a bbs program used in Germany) into the system. This should be done before own proprietary messages are created, but works later, too. But as the import command also changes specific system settings and will override original ones, for upgrading from a TheBox it is always the better way to first install Linux and the DPBOX, then importing the old files and system settings with the IMPORT DIEBOX feature and, in a third step, setting up all new config files of the DPBOX manually and then connecting the BBS to the radio.

We did so with a long time running TheBox installation with 700 local users and 14.000 messages, and it worked perfectly and automatically. Even user settings, including passwords and deferred calls, forward definitions and board conventions were converted, it was a real joy to watch the system updating itself.

All reception dates, all sysop transfers, lifetime settings and other changes will remain effective in the imported messages. Your users will not notice the upgrade (hum, we had the feeling they did, but for other reasons).

This is what you have to do:


Think about how you would mount the MS DOS TheBox database into the Linux file system. We used a removable hard disk and stored a 100% MS DOS copy of the TheBox file system on it. The disk was borrowed for a day, we hope you have similar possibilities as this is the simplest way to upgrade.


Now, install Linux on the computer. At this step we deleted the built in MS DOS hard disk - as we needed the space for Linux.


Install DPBOX and TNT. You only would have to config the dpbox.ini file at this moment of installation. Further configurations will be taken from the TheBox config files.


Mount the hard disk with the MS DOS data base into the Linux file system.


Look up the file config.box of the TheBox installation. At lines 38 through 42 (or so) you find the path definitions pointing to the different system folders of the TheBox system. Mostly, you have to edit these lines. All definitions have to be RELATIVE to the path at which you find the config.box file in the Linux file system. A leading 'C:\' will be ignored, but all that is written after it during import is appended to the path you added to the import command in DP BBS. This means that multiple partitions used by the TheBox installation are not that easy to handle, but with the help of a Linux expert, this is to solve, too. When we did so, we had a single partition system to import, so we had to change nothing.


Start DPBOX. Start a BBS terminal, either dpboxt or TNT (if yet having installed TNCs).


Log in to DPBOX. Make a quick check if the BBS works. Send a mail to any board, verify it, then delete it.


Start the import procedure:

IMPORT DIEBOX /mount/diebox/

or whatever is the path where the TheBox config.box is found.

If you want to delete the imported mails in the TheBox data base, append a minus / slash to the command:

IMPORT DIEBOX /mount/diebox/ -


The import is stopped immediately if the folders were incorrectly specified. If not - you should go out for lunch or have a good cup of tea, smoke a pipe - and be happy about that now the computer has to work and you have a free time.

With 14.000 mails and 25.000 user settings, on a 386DX/33 you may expect an update time of 2-4 hours, depending on the speed of your disk and the amount of RAM of your computer.

The speed is mainly affected by the setting of the PACKDELAY parameter in system/config.box. Per default, it is set to 0 days. This means, every incoming mail is stored in compressed mode immediately. In normal BBS operation, you won't remark a difference to a delayed packing, but when importing 10.000 mails, this is of course noticeable. Anyway we would propose you to let it set to 0 days. If you set it higher, then the first house keeping routine (called GARBAGE in DPBOX) would take a long, long time as most files are packed then.

While importing, you get a progressing info on what is done. You may disregard this, but this may persuade you the system is still living. After import is complete, you find a more or less comprehensive info in the profile/diebox.imp file. You should take a look in it to see if all worked correctly, and to notice which users at your BBS have special settings such as privilege levels.


Welcome to DPBOX. Unmount the MS DOS hard disk. Edit every file in the system/ folder of the BBS. Note that a file badnames.box may exist, but it is no more read in. Instead, set up the deferred boards in reject.box.

Use the command RELOAD to make the BBS accept the edited config files.

That's all.


back to content page

A. Release Notes

Release Notes DPBOX v4.15

Berlin, 3.3.96

Release Notes dpbox v4.15.02 / 3.3.96

Due to a nifty mistake in the date routines of dpbox, all dates following the 29.2.96 were displayed one day in the future.

Internally, the correct date was used, what means that after upgrading to the current version all data bases are handled correctly and dates of messages are displayed again with their real upload date.

So far for errors. Meanwhile, development went on. The forward mechanism was enhanced in many parts, especially speeding up the administration of large forward lists (large is meant in units of 5000 or so) and invoking a longly planned feature, the sort-by-size in outgoing forward. We really learned to love that feature in the
past weeks, it's your only chance to maintain a stable forward line on weak links without stressing your local users with messages like "please do not upload messages bigger than 2000 bytes" - which they don't read anyway.

Sorting outgoing forward by message size means, that a forward link is dynamically adopted to its real bandwidth. You, as a sysop, don't have to care about maximum message sizes, those that are too big simply never would pass the link.

Code optimisation was done at many parts of the source, mostly following the goal of a better parallelisation of the user actions, don't forget that dpbox was first developed on a single tasking OS. There's still enough left to do at this place, and so we will.

If you do not want to use the sort-by-size - feature in outgoing forward, you have to add a new keyword in system/config.box :

Release Notes DPBOX v4.16

Berlin, 30.3.96

Release Notes dpbox v4.16.20 / 30.3.96

Changes since v4.15.02 / 3.3.96

- a defined forward partner now automatically gets the sf login prompt, regardless of its SFLEVEL.

- broadcast streams are reinitialised at a reopen of the TNT interface. Avoids endless wait on acknowledgement of the previously transmitted files.

- SF OFF and SF KILL now reset the routing flags (normally, they are reset after a successful connect or a connect failure by TNT). Avoids endless wait on that reset if an interface error occurred with TNT.

- while processing the standard login command LIST of a user, '>' at the end of line is replaced by ']' - this avoids problems in user sf logins (prompt detection of the users point bbs).

- A RE: on a mailing list server could result in subjects like: (DP8TNT 18) RE:(DP8TNT 17) problem. Fixed.

- Adding parameter REQUEST_LT ON|OFF in config.box. REQUEST_LT ON requests a lifetime setting from the user, if sending to a bulletin board and no lifetime was given in the send command.

- BROADCAST ON was not configurable by default. Fixed. Added parameter SEND_BBSBCAST ON|OFF in config.box.

- Adding counters to display daily forward statistics. Try "SFS +".

- S DL8HBS @ DB0GR #dpbox.p01 lead to a misinterpretation of the subject as an explicit #lifetime setting (0). Fixed (hopefully).

- SB B$LUBB @ ALL in received forward lead to totally corrupted file entries. The $LUBB was at a certain place interpreted as the BID. This did not create erroneous outgoing forward, but the message base looked funny. Fixed. DO NOT USE SUCH BOARDNAMES ANYWAY, except fbb, most bbs systems may have problems.

- If a call was defined as a forward bbs, it still could send files in user send mode (when manually operated by its sysop e.g.). In case of network problems (lost frames while login) this created incorrect forward. Will now be disconnected at a send attempt without prior SID login.

- Error displaying undefined boards with the DIR command. Fixed. (Will appear in lowercase letters)

- Now displaying users name and HomeBBS setting when listing his directory.

- Now displaying users name, HomeBBS and last login when sending a mail.

- Listing the own user directory, the bbs displays if the listed mails are unread, read or replied by the user (* , . or + at the start of the subject)

- Adding command SETREPLY to manually mark a mail as replied for the above feature (Syntax as REPLY).

- Adding command READLOCK 0|1|2 . 0 = everyone may read the users mail, 1 = everyone may read it after the possessor of the mail read it (and let it exist), 2 = no read except for originator and recipient.

- TTL command now permanently stored in a users settings.

- Mails to unknown users were not returned after RETURNTIME. Fixed.

- Now annoying the sysop with daily messages to board Y if the system clock is apparently wrong. Can only detect settings to the past of the true time, not to the future.

- smart routing completely recoded. Works wonderful, but has no use in heterogeneous networks. Your neighbours routers have to use the same or similar algorithm, and unfortunately, they don't in most cases. dpbox uses a strictly time based algorithm (the FASTEST route is the best), other bbs may use other algorithms, looking for the route with the less intermediate hops for example. Have switched that feature OFF in DB0GR, lead to loops as for the above reasons.

- Added switch SMART_ROUTING ON|OFF in config.box. Read the above paragraph. This toggles the priority of the sysop set .sf definitions to the routes the autorouter would propose. If ON, auto routing has priority, if OFF, sysop settings have priority. If the priorized method gives no result, the other one is tried. Never run dpbox with NO sysop route settings.

- changed routing computation from hour-based to minute-based algorithm. This means that the yet collected database is somewhat improper for the new router. Don't worry, after one or two days of operation, all entries are updated.

- now storing the software and version information of every bbs (if available from the forward headers). You can check for bbs with specific software with the BBS or FIND command: BBS < fbb7. displays all WinFBB installations etc.

- now automatic length limitation of the FHEADER entry in the own forward header. Will always leave enough space for appending the $:BID in the forward header.

- changed time zone indicator in forward header from Z to z. Main feature hi.

- in case of activated smart routing, the waiting outgoing user mails are rerouted to the current routing map every four hours or at RELOAD.

- implemented automatic rerouting of user mails in case of previous routing errors. Will be called during GARBAGE (once a day) and will rely on the actual (and maybe changed) routing information of auto router and/or sysop settings.

- Even in case of disabled smart routing and a given (but apparently wrong) sysop route definition, the daily rerouting of user mails will be switched to smart routing, if the time the mail waits for forward is higher than half the time of RETURNTIME (a value of 7 days for RETURNTIME seems to be a good one for European bbs).

- Mails in user boards even had the mostly high USERLIFETIME if they were incorrectly addressed to a flood designator. Will now be set to UNDEFBOARDSLT during garbage and disappear after a few days.

- Non-sysops now may apply the "CHECK +" command too. This gives a checklist on user files. Display is restricted to messages the user is the originator or recipient. Example: "CHECK + 1-" lists all user mails one has written or received. A sysop gets all user mails...

- corrected incorrect caching administration of user infos (lead to incorrect time-outs and wrong byte counts).

- RAM based caching of the last hundred loaded user infos. Real important speedup.

- RAM based indexing of all user entries in M.IDX (misguiding name, M.IDX IS the user info database, not the index to it). Real important speedup.

- Prolonged time-out for user infos: now 365 days, was 182 days.

- dpbox crashed if a user answered with a wrong password string in user sf. Fixed.

- now displaying the erasers call, not only his status, when doing a "LIST :" on erased files.

- now displaying erase time and last read time when doing a "LIST :"

- REDIST server implemented (finally). Receiving a mail to LOCBBS@console_call, LOCAL@console_call, REGION@console_call, NATION@console_call, the mail will be remapped to
Mails to LOCBBS and LOCAL strictly have to be addressed as type P (private), but due to inconveniences in the german packet net, for REGION and NATION any type is allowed.

Define the flood designators in config.box: REDIST_LOCAL, REDIST_REGION, REDIST_NATION. Example: REDIST_NATION DL (for german bbs). Also, define REDIST_LIFETIME (default 30 days), REDIST_DEFBOARD (for other than remapping to the standard board ALL).
The originating user is allowed to add a desired board to its message, it is the first word in the subject line, starting with a '#'. Example: SP REGION @ DB0GR #BBS looking for a bbs in the Berlin area

REDIST servers are also available at many FBB bbs, anyway german users should notify that your mails to REGION or NATION are changed to type 'B' (bulletin) by most of the german bbs, so they remain ineffective at the destination bbs.

- mailing list server now processed in background operation.

- file import now in background operation.

- Expanding all macros (those one valid in the PROMPT command) in language settings.

- setting up two connections in compressed forward if one exceeded the sf-time-out but output buffer still not empty.

- adding a Flag (WWW) in the subject line of LIST and CHECK output if mail content seems to be HTML.

- recoding the very few floating point operations to integer operations.

- dpbox now is linked -static. That should help avoiding problems with erroneous libraries but costs only about 100kBytes.

- many other minor bug fixes nowhere noted. sri.


- adding real NTS support (BTW not used in Europe, so no experience). Just need the following information of any north American sysop: Do you route the NTS messages via the flood designator field (CANTS or what else) or via the ZIP code? If you route it via the ZIP code, who sets up the routing tables? How do you avoid multiple third party delivery in case of routing via flood designators? Silly questions? Remind, we don't use that in Europe.

- adding a HTTP server mode to the bbs. This is a vision, not a running project. Terminal-only based bbs systems in my eyes have a more and more limited lifetime. The mixture of reader application AND file server, as we do it in most amateur radio news and mail servers, limits user actions to those one the author intended to support, surely the better way is to provide an open server/client protocol. After revising all of the used internet protocols, we decided to focus on the HTTP protocol. It is simple, open for extensions, efficient and, well, guess, supporting any kind of source data. Using compression techniques, bandwidth can be limited, what favourites it highly to the NNTP, POP and SMTP protocols. Also, there is no need and no requirement to transport HTTP via tcp/ip connects, still reducing protocol overhead.

Release Notes DPBOX v4.17

Berlin, 14.4.96

Release Notes dpbox v4.17.00 / 14.4.96

Changes since v4.16.20 / 30.3.96

- Installing a hash lookup for the hierarchical bbs definitions and the auto router data base. Nice speedup.

- fixing a problem occurring when a DieBox sent erroneous binary S&F (hopefully).

- correcting erroneous display of time offsets to a bbs when using the BBS/FIND command.

- Disabling detection of "invalid system time" - didn't find out why this was criticised even with completely correct defined system time...

- changed string conversion routine for the system/beacon.box file. Now uses the string conversion as is provided for the PROMPT command (see there).

- added six macros to the string conversion for the PROMPT command:
%7 = CTRL-G (bell)
%8 = TAB
%h = converting the two following hex chars into an ASCII char
%s = box runtime (days, hours, minutes)
%u = current time (without seconds)
%x = box runtime (only days)

- enabled sending of a MSG command to a user currently busy due to writing a message or reading out a huge amount of data's. Prompt will change from "MSG OK FOR ..." to "DELAYED MSG OK FOR ...".

- enabled signalling of incoming new mail to a user that at that moment was busy as for the above reasons.

- and other minor changes.

Release Notes DPBOX v5.00

Berlin, 20.09.96

Release Notes dpbox v5.00.00 / 20.9.96

Changes since v4.17.00 / 14.4.96

  • dpbox now directly maintained on C source code base, no more in Pascal.

  • code should be much faster because of changed calling conventions of subroutines.

  • message list ("Checklist") now in one single database instead of the previous two lists for user mails and bulletins.

  • lots of previously hard coded system status messages now variably defined in language files.

  • added unproto message list output (as FBB does).

  • added TPK-Unproto-Request-Mode (what a word). Is still untested, hope it works. Needs a TNT version > 0.9r to be effective.

  • Added TPK file request mode in user S&F. Still untested, protocol may be erroneous due to the poor documentation available.

  • To support the above TPK request modes, message indexing was completely recoded. When starting dpbox v5.00 for the first time on an older message base, automatic data conversion is done. This takes some time, just up to 5 minutes. Keep patient and wait until the "successfully started" - prompt appears. BEWARE: YOU ARE NOT ABLE TO CHANGE BACK TO OLDER DPBOX VERSIONS!

  • added "FBBMODDE" command: if "ON", checklist output includes FBB style message number output. Just for testing, not a real design decision.

  • now sorting the checklist in background operation when applying the "CS" command. Sorted checklist output therefore no longer is limited to 2000 lines.

  • now displaying the resulting file name of a binary "EXPORT", if differing from the initial user export command.

  • now supporting RSA(c) MD2 password authentication in user login and S&F.

  • SFLEVEL 2 no more implemented (the THEBOX emulation). SF works anyway.

  • german THEBOX system changed passwort prompting in SF login. Now detecting both kinds of prompts, the old and the new one.

  • new path name check to prevent unauthorized file access.

  • all user settable configuration parameters are now available for sysops too. Example: TTL DL8HBS ON

    -MD2 starts MD2 protected password login
    -MD2SF ON or (in user mode) MD2SF ON activates MD2-protection in S&F
    -FBBMODE ON enables FBB message list output for the CHECK command.
    -UNPROTO ON enables unproto request mode of a user. Sysop only.
    -SHELL starts a shell login. sysop only.
    -TSHELL starts a transparent shell login. No linefeed conversion. Sysop only
    -FILESERVER starts file server mode.

  • added a "fileserver" mode (similar to that one implemented in FBB).

  • automatic 7plus collector. WILL NOT CREATE AUTOMATIC .COR REQUESTS :) recombined files are moved into the file server area.

  • automatic AUTOBIN extractor. Files are moved into the file server area.

  • automatic binary to 7plus - converter. If a private mail contains binary data and the forwarding connection is not supporting full binary mail contents, the mail is converted automatically in 7plus.

  • external commands ("run pograms") now started in a separate task. They may interact with the calling user and they are no more limited in execution time. stdin and stdout are redirected to the users connection.

  • parameters for external commands now in environment variables.

  • shell login command SHELL for sysops. If you want to omit this, recompile dpbox with -DNO_SHELL option activated in Makefile.

  • supporting YAPPC in file server mode and in sysop file access.

  • slightly modified auto routing algorithm. Results more reliable paths.

  • trying to restart an activated PACSAT broadcast transmission every 30 minutes in case of interface problems with TNT.

  • New command U PATH gives you the ax.25 from- and to - fields of every user. Only supported with TNT > v0.9r!

  • On a SEND command for a private mail now the date of the last HomeBBS update of the destination user is prompted.

  • To make HomeBBS - pirating a bit more difficult, user and sysop get a warning if the HomeBBS was set from outside. Users mails are NOT redirected to the new address if the following conditions apply:
    - actual HomeBBS is THIS BBS
    - HomeBBS was changed to another BBS via network command
    - user has an activated password
    - READLOCK of this user is > 0
    Note that the HomeBBS IS changed. You are only warned and your yet arrived mails are not redirected. Newly arriving mails will be redirected. If it was a pirate action, you have to reset your HomeBBS with the MYBBS command.

  • changed parameter in U - command: deleting user settings is done with "U -d" and no more "U -". Also "U @ -d". Should help to avoid typing errors.

  • DPBOX now can be mirrored to a bbs of the same callsign. Seems to be interesting for sysops that want to install different bbs systems parallely at their location. Note that every bbs has to use a unique SSID.

  • Fixing a little protocol problem with some NOS BBS. They seem to send the fields of the forward SEND command in lowercase. In user forward mode, this resulted in rejects. Should work now.

  • Forgot in former versions the code fragment inhibiting the proposal of bulletins to forward partners that proposed the same bulletin to us. Was only implemented for fbb forward, now also in w0rli forward.

    dpbox is, BTW, relativly effective in pre-proposal-checks of this kind: it also checks the bbs' the bulletin passed through before and avoids proposals to any of them, not only to the last forwarder.

  • And so many further code changes. DIFF between v4.17 and v5.00 is some 700kB Hope I described the most important changes.

    73 Joachim, DL8HBS@DB0GR.#BLN.DEU.EU

    back to content page

    B. System Identifiers (SID)

    A system identifier for forwarding systems is created with the following syntax:


    The most important field is the <command_set>. The existing characters indicate a protocol feature. They may be followed by a number, this indicates the protocol revision.

    Lets investigate DP's SID:


    A = ACK messages known
    B = huffman compression, only in conjunction with F
    B1 = extended compressed protocol, resume and CRC added.
    D = extended board names (8 chars), improved CRC
    D1 = block crc mode in compressed forward
    F = message exchange in blocks of 5, syntax of F6FBB
    H = hierarchical addresses accepted
    M = Message ID's accepted (BID's of private mails)
    R = extended reject messages as defined by AA4RE
    $ = Bulletin ID's accepted (I am really a BBS)

    back to content page

    C. The Forward Protocols

    DPBOX uses seven different forward protocols

    1) W0RLI
    2) TheBox
    3) F6FBB version 1
    4) DPBOX version 1
    5) F6FBB version 2 (resume mode)
    6) DPBOX version 2 (resume mode)
    7) DPBOX version 3 (as 6, additional block CRCs)

    The complete fbb style forward protocol will be described after this survey.

    The differences between 3) and 4) are some extensions made for proper use in the German network.

    The DPBOX forward protocol compared with F6FBB compressed protocol:

    It is indicated by the presence of the letter 'D' in the SID.

    Proposals are started with FD instead FA / FB.

    The checksum of the proposals is a CRC-16 in hexadecimal notation, sent LSB -> MSB. For computation of the CRC, only the text content of the proposals without <CR> is regarded. The CRC is pre-loaded with 0.


    FD B DL8HBS DL SYSOP 32670BDL8HBS 1508 60
    FD B DL8HBS EU STANDARD 32670CDL8HBS 6987 365
    (... up to five ...)
    F> A7CF

    Boards may count 8 signs. Optionally, a lifetime is added (last parameter of proposals 2 and 3). A lifetime is the count of days after which a message shall be deleted.

    The message exchange is using YAPP, as F6FBB does. The only difference is the end_of_transmission - block: Instead of a 1 byte checksum it contains a 2 byte CRC-16, LSB -> MSB. The CRC is computed over the content of all blocks transmitted before, including the title block. It is pre-loaded with 0.

    The difference between 5) and 6) is the altered proposal protocol for 6) as in 4), additionally, the CRC of 6) is extended via the message title. 5) only CRCs the message body. Note that F6FBB uses a very special CRC calculation method.

    The difference between 6) and 7) is the block CRC appended to each transmitted block, forcing the receiving bbs to disconnect immediately at detection of a transmission error.

    back to content page

    D. Presence of Letter D in SID

    The presence of letter "D" in SID assumes (except of later on described extensions to the f6fbb forward protocols) the following:

    1) Ability of understanding single line messages to boards "M" and "E"
    2) Ability of processing full binary messages
    3) Acceptation of board names with up to 8 signs
    4) Acceptation of lifetimes in proposed forward


    1) Ability of understanding single line messages to boards "M" and "E"

    German net standard requires the exchange of home bbs information in board "M" and remote erase commands in board "E".

    The format of both is simple:

    MyBBS (respectively HomeBBS) information in board "M" are transmitted to M@THEBOX (where @THEBOX may be changed) with this syntax:

    SB M@THEBOX < Sender $BID <HomeBBS> <UNIX Time> CTRL-Z

    Sender is the users call entering a new home bbs, $BID is generically, <HomeBBS> is the new home bbs (may be hierarchical addressed too), <UNIX Time> is the update time in Unix time format plus 4 hours (dunno why).

    Each field is separated by spaces.

    This standard is NOT my choice, I prefer the WP standard. But for supporting the "D" extensions, you have to detect such mails.

    Remote Erase messages in board "E" are transmitted to E@THEBOX (where @THEBOX may be changed) with this syntax:

    SB E@THEBOX < originating_bbs $BID <eraseBID> CTRL-Z

    originating_bbs is the bbs the remote erase was released, $BID is generically, <eraseBID> is the BID that shall be deleted in your bbs.

    Each field is separated by spaces.

    If you want to support the letter "D" in your SID but do not want to support the above features, simply answer to every received line with OK or NO and a ">" in the next line and trash the received line.

    2) Ability of processing full binary messages

    Supporting letter "D" in your SID means that your bbs system is aware of receiving full binary messages in forward. This happens the following way:

    At any position of the forwarded message a binary header may be sent.

    A binary header has at least the following format:


    but mostly has the format


    Except BIN and <Size>, each field may be present or not. <filename> may even consist of a path and a name. The path may contain "/" and "\" and ":" .

    The least your bbs has to do is storing the binary header to the receive file and then storing transparently <size> (decimal) bytes of data following the binary header and then prompting '>' or (if in batch fbb forward) being prepared for the next file.

    As most other "D" - supporting BBS will send a <CRC>, you should check the CRC of the received binary with the sent one. Used CRC calculation is crcthp (see section "Calculating CRCs" in this document) In case of inequality, you should (if in ASCII forward mode, not in fbb batch forward mode) delete the received file and prompt a "|>" instead of ">" - this allows the sending bbs to take the file out of the forward after some erroneous transmissions. If in fbb batch forward mode, crc errors are corrected by the overlaying protocols, if in ascii fbb batch forward mode (who does so?) you have a problem and should disconnect and delete the received file.

    The binary file transfer is an essential of the "D" mode, you cannot override it by any tricks. Compressed fbb forward by its nature has absolutely no problems transferring such files, but due to the fact that no local user nor local ASCII forward bbs of the receiving FBB bbs can read out such a file undistorted (it will be stripped of the eighth BIT), binary files are NEVER sent to bbs not having the "D" in the SID.

    Refer to the description of the AutoBIN protocol later in this document. Note: other than described there (I didn't write it), a BBS never sends an acknowledgement ("#OK#") to a forwarding bbs nor waits for one nor sends a "#NO#". There is only one case your bbs will send an "#OK#" - when a local user starts a binary upload to the bbs sending a binary header after opening an input file with SB or SP.

    Think about the implications of the full binary processing: You will no more need 7PLUS uploads, even not for splitting the message in parts, as FBB and DPBOX support resume mode (recovering crashed forward connects at the point the forward was interrupted, so, big files are no problem at all). You will never see any 7PERR messages, because beside the error protection of the FBB compressed forward, you also have an error protection on those weak ASCII forward links (binary protocol includes a CRC, read above).

    3) Acceptation of board names with up to 8 signs

    Well, this is a simple thing. If you do not want to support board names with 8 signs, simply cut them after the sixth sign in received forward. If you send a board with only 6 signs, lets say "KENWOO" that is known in DPBOX on the receiver side as "KENWOOD", it is expanded automatically while reception.

    This means that for supporting letter "D" in SID, you only have to take care that your bbs does not crash when receiving a proposal with up to 8 signs in the board name.

    4) Acceptation of lifetimes in proposed forward

    Accepting lifetimes in forward means that in ASCII forward your BBS accepts or disregards lifetime settings in the proposal. Lifetimes are no essential for the net, if they are supported its fine, if they aren't, who cares.

    A lifetime setting means that the received mail shall be deleted after the given count of days. This is a proposal by the originator of the message, not a must.

    When forwarding a lifetime setting to another bbs, you have to deduct the days the message waited for forward in your bbs from the received lifetime setting.

    Lifetimes are transmitted the following way:

    SB BBS@EU < DL1XYZ $BID #10

    but also:

    SB BBS@EU < DL1XYZ $BID # 10

    In this case, lifetime of the mail is set to 10 days in the receiving bbs.

    If you want to support the letter "D" in SID, you may evaluate the lifetime setting in the proposal, but you won't have to.

    On the other hand, you may send messages in forward without lifetime field and still presenting the "D" in your SID.

    The lifetime setting is completely optional. It is nice if it is supported (as it helps sysops doing their job by deleting messages prematurely), but it is no must.

    What's left: the minimum standard to support the "D" feature in SID reads as follows:

    1) Accept incoming single line M and E messages, but trash them
    2) Support full binary message exchange in forward and user interface
    3) Accept board names with 8 signs but cut them to 6
    4) Accept additional lifetime settings in proposals but trash them. Send without.

    back to content page

    E. Compressed Forward Protocol Description

    Written January 1993, corrected August 1993, May 1994, extended April 1996.
    Translated to English April 1996.


    This description tries to focus the main essentials of F6FBB type forward. Unfortunately, the requirements for the german bbs network (boards may count up to 8 signs, a lifetime may be added to each mail) lead to a confusing variety of different substandards of the protocol. I can't help it, the system grew in time, and from today's point of view, most standards are obsolete. But this is the whole story:

    Up to today, F6FBB defined three evoluting steps of his protocol:

    1) Mails are proposed and sent in batch forward, 5 at a time (but in ASCII).
    2) as 1), additionally they are compressed with a simple LZH.
    3) as 2), additional CRC and crash recovery (resume), allowing restart of forward transmission at the position the previous connect crashed (even within a mail).

    In DPBOX there is an addition to step 3) of the protocol:

    4) as 3), but includes block CRCs for every transmitted block.

    Required by german bbs net standards, I had to add specific extensions to every protocol step. Each one was extended with the possibility to transfer so called "lifetimes" (a number of days after which the message shall be deleted) and extended board names with up to 8 signs, not only 6 as usual. Additionally, the transfer is locked against transmission errors by CRCs. In step 2), fbb forward had no CRC at all, in step 3) only over the message body, not over BID and subject field.

    Further, I will refer on step 1) / 2) / 3) and the addition "D". "D" means DL or DL8HBS or whatever.

    Step 1)

    Extracts of f6fbb's original documentation:

    APPENDIX -6- 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 or 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 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 (=).

    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 +,-,= 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

    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 :


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

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


    and asks for the disconnection.

    Example :

     F6FBB                          FC1GHV
     Connects FC1GHV
                                    Bienvenue a Poitiers, Jean-Paul.
     [FBB-5.11-FHM$]     (F6FBB has the F flag in the SID)
     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
     Title 3rd message
     Text 3rd message
                                     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
                                     FF (no more message)
     FB B F6FBB TEST FRA 24654_F6FBB 145
     F> HH
                                     FS + (Accepts the message)
     Title message
     Text message
                                     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 !

    End of F6FBB extract

    Step 1D) is only slightly modified compared with step 1). The SID must contain a "D" (for example [DP-3.53-DFHM$]). Proposals then would be:

    FD B DL8HBS DL SYSOP 32670BDL8HBS 1508 60
    FD B DL8HBS EU STANDARD 32670CDL8HBS 6987 365
    (... up to five ...)
    F> A7CF

    The "D" in "FD" signifies a transmission in the 1D) format. The 16-bit hexadecimal value after F> is a CRC over all bytes of the proposal lines except the line break (CR). It may be left out, but if it is present and unequal to the one calculated on the receiver side, the connection will be disconnected. CRC is of type crcthp (as for the autobin protocol, look at the end of this manual), preloaded with 0.

    Obviously, board names may count up to 8 signs. A lifetime may be appended as last field to a proposal line (third proposal, lifetime 365 days).

    A proposal is defined this way:

     FD B DL8HBS ALL ATARI 564323DL8HBS 3456 60 
     ^  ^ ^      ^    ^     ^            ^   ^ 
     I  I I      I    I     I            I   Lifetime (optional)
     I  I I      I    I     Bulletin-ID  Size in Bytes of unpacked 
     I  I I      I    I                                   file
     I  I I      I    board (or callsign)
     I  I I      I
     I  I I       @mbx-field
     I  I  Sender
     I  Type, [B]ulletin or [P]rivate or [A]cknowledge or N[T]S
    Of course, depending on the "H" flag in SID, hierarchical addresses are valid, too.

    Step 2)

    Extracts of F6FBBs documentation

    APPENDIX -7- Extension to the protocol. Compressed forward FBB.

    The protocol utilised 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

    *** remarks by DL8HBS: type FB of transmission is not supported by DPBOX.
    *** DPBOX supports full binary mail transfer in all modes.

    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 utilised 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's 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

    End of F6FBB extract

    Step 2D)

    "F", "D" and "B" must be present in the SID.

    Only change compared with step 2) is the format of the proposals (see step 1D) ) and the locking of the transmitted compressed data's with a CRC. Again, the CRC is of type crcthp (see section "Calculating CRCs" at the end of this manual).

    The CRC is transmitted in the EOT block (see step 2) ).

    <EOT> 1 byte = 04 Hex
    CRC 2 bytes, LSB first, then MSB.

    The CRC counts over all data bytes of all preceding blocks, this includes the content of block 1), the subject with offset and the two zeroes. Only block identifiers and block length bytes are blanked out.

    If the receiver calculates another CRC, it disconnects.

    Step 3)

    Preliminary: As far as I know, there is no released document from F6FBB explaining this protocol step. Use these information with caution, protocol may change.

    Please honour the work of DG0FT. The assertion of the protocol took a complete weekend of work by him (in early 1993). He detected the used CRC algorithm, and this is not as simple as it seems. Thank you for your support, René.

    The SID must contain "B1" and "F".

    Example : [FBB-5.15c-AB1FHMR$]

    Principally, transmission looks like in step 2). The YAPP-encoded file however is leaded by a CRC at the beginning. The CRC only counts over the body of the packed message, it does not cover the subject block.

    The algorithm uses the CCITT CRC table, but a different calculation method:

    CRC = (CRC << 8) ^ CRC_TABLE[(CRC >> 8) ^ DATA]; /* Credits to DG0FT! */

    Except the CRC, no change yet compared with step 2).

    But lets see what happens in case of a link failure while transmission:

    The receiving BBS counts the amount of data's received with the penultimate YAPP block (this one was the last one completely received) and sends, if the interrupted file gets proposed once again, instead of

    FS +

    FS !1250

    (for example). This means that file transmission shall be resumed at offset 1250.

    Receiving a multi-proposal, the answer could look like:

    FS +!1250-

    The transmitting bbs now will send the interrupted file again, with a complete title block, but the OFFSET in this block is not set to 0 but to the demanded resume position (1250 in this example), followed by a short data block containing the first six bytes of the message (this is the CRC and the size of the uncompressed message, as LZH always puts that information in the first four bytes of a compressed file). After these two blocks, the remainder of the message follows in YAPP protocol, starting with the demanded OFFSET.

    Step 3D)

    "B1", "F" and "D" must be present in SID.

    Example: [DP-3.53-AB1DFHMR$]

    Step 3D) unites the advantages of step 2D) and 3).

    It supports boards with a length of 8 signs and lifetimes (as generally with the "D" extension). The format of the proposals is as with 1D) or 2D). Note: CRC over the proposals still is in crcthp format!

    The message itself will be transmitted exactly as with step 3), except for the CRC calculation. The CRC of step 3D) includes the subject, but, different to previous "D" - extensions, only all valid bytes of the subject, NOT the offset (it changes) and not the NULL bytes. The subject is CRCed prior to the message data's. NOTE: 3D) also uses the CRC algorithm of F6FBB, as does step 3). Step 2D) used another CRC algorithm, but that was at a time when fbb did not provide CRCs at all.

    Step 4D)

    As you will remark, this protocol is an extension to protocol 3D). There is no equivalent in F6FBB protocols.

    "B1", "F" and "D1" must be present in SID.

    Example: [DP-4.16-AB1D1FHMR$]

    Uploading big messages, it often happens that the upload runs without interruption but after complete reception is disconnected with a "*** CRC error". This is annoying, at least if you managed to upload say 400k of a new bbs version via a remote HF channel.

    What has happened?

    Due to the unprotected data exchange in wa8ded hostmode, some bits of your upload got corrupted by a receiver overrun of the local bbs computers UART. This even happens with 16550 FIFOs running Linux (but very seldom).

    The CRCing of the complete file avoided storage of the damaged file, but instead it would be better stopping the upload at the YAPP block where the error occurred instead of waiting till the end of file.

    This lead to the implementation of step 4D). The difference compared with step 3D) is very simple: each transmitted YAPP block contains a CRC over its content (crcfbb, as the overall file CRC). The CRC is appended to the data field of the block. If the receiver detects a different result in computing the block CRC, it disconnects the connection and stores its resume offset to the end of the last completely received block.

    No, no one promised that everything in this definition is logical and simple. As you easily can see, it is a protocol system grown by time. With the above information at your hands, it should be possible to implement the whole protocol suite in your own program.

    Some further annotations:

    Implementation problems of f6fbb's protocols usually have two reasons:

    1) The compression method
    2) The checksum of the proposals

    1): The LZH as is used for f6fbb uses (different to the usual implementations of the LZH code) a string buffer size of 2048 bytes instead of 4096 bytes. Sending mails with a size bigger than 2048 bytes to a fbb bbs results in destroyed message contents if the sender used a 4096 bytes buffer for encoding. (DPBOX uses a buffer size of 4096 bytes for decoding, so, don't wonder if your program is able to send mails to a DPBOX but not to an FBB).

    2): checksum computation in FBB proposals. Excerpt of a mail of F6FBB:

    From version 5.14, there is an optional checksum at the end of the proposals. If the checksum exists, then the proposals will be checked.

    It is simply computed :

    Warning, there is no LF character and the CR is included in the checksum computation !

    static char checksum(char *s)
    	char	chck = 0;
    	while (*s)
    		chck += *s;
    	char	chck = 0;
    	int	...
    	for (p=0 ....
    		sprintf(s, "F%c %c %s %s %s %s %ld\r", ...
    		chck += checksum(s);
    	sprintf(s, "F> %02X\r", (-chck) & 0xff) ;

    When receiving, the checksum of the proposals added the received checksum must be equal to zero.

    73 Qro. Jean-Paul, F6FBB @ F6FBB.FMLR.FRA.EU

    CRC computation for proposals in "D" protocol types does NOT include the CRs, as was noted in description of step 1D) !

    Let me express my thanks to Jean-Paul, F6FBB, for the invention of the compressed AND batched forward protocols. I just aligned them for proper use in the german net. And, again, thank you René, DG0FT, for your work spent on these items helping me to implement it correctly.

    back to content page

    F. The Message Base Format

    The DPBOX message base is held in the folders box/indexes/ and box/infofiles/ . Each existing board is represented by one index file (in box/indexes/) and one content file (in box/infofiles/).

    The index file is an array of structures describing each file saved in the content file. The first array in the index represents message 1 in the board and so on. Deleted entries are only marked as deleted, the physical erase and reorganisation of the message base is performed while nightly garbage collection.

    Indexes and contents are locked with checksums. Changing one bit in the files will make them invalid and the garbage collection will try to delete the changed entries.

    In result, you only have read access on the information stored in the message base. You are not allowed to add or change information externally.

    Each index file consists of an array[1..n] of indexstruct, where indexstruct is defined as follows:

    typedef struct indexstruct {
      uchar header_version;      /* is 20 in this version   */
      Char bulletin_id[13];      /* BID                     */
      Char destination[9];       /* board                   */
      Char originator[7];        /* sender                  */
      Char mbx[41];              /* @mbx                    */
      Char subject[81];          /* subject                 */
      long rxdate;               /* locally received at     */
      long txdate;               /* originally created at   */
      unsigned short lifetime;   /* local liftetime         */
      unsigned short txlifetime; /* original lifetime       */
      Char msgtype;              /* A/B/P/T                 */
      uchar r0;                  /* not to be changed       */
      long start;                /* start position in file  */
      long packsize;             /* packed message size     */
      long size;                 /* unpacked message size   */
      long rxqrg;                /* received on qrg (unused)*/
      Char rxfrom[7];            /* received from bbs       */
      boolean deleted;           /* logically deleted       */
      uchar content_type;        /* content encoding        */
      uchar level;               /* access level            */
      uchar fwdct;               /* forward counter         */
      unsigned short msgflags;   /* msgflags (see MSGFLAGS) */
      long erasetime;            /* erased at               */
      long lastread;             /* last read at            */
      unsigned short readcount;  /* readout counter         */
      Char read_by[141];         /* reader field            */
      uchar erased_by;           /* erased by (see EBFLAGS) */
      Char sendbbs[7];           /* originating bbs         */
      uchar reserved;            /* zeroed in this version  */
      long msgnum;               /* message number          */
      unsigned short r1, r2, r3; /* not to be changed       */
    } indexstruct;
    /* MSGFLAGS */
    #define MSG_SFWAIT      1
    #define MSG_PROPOSED    2
    #define MSG_SFRX        4
    #define MSG_SFTX        8
    #define MSG_SFERR       16
    #define MSG_SFNOFOUND   32
    #define MSG_CUT         64
    #define MSG_MINE        128
    #define MSG_REJECTED    256
    #define MSG_DOUBLE      512
    #define MSG_BROADCAST   1024
    #define MSG_BROADCAST_RX 2048
    #define MSG_OWNHOLD     4096
    #define MSG_LOCALHOLD   8192
    #define MSG_SFHOLD      16384
    #define MSG_OUTDATED    32768
    /* bit values for content_type  */
    #define PM_HUFF         4    /* LZH compression         */
    #define TTEXT           0    /* ASCII mail              */
    #define TBIN            32   /* binary mail             */
    #define T7PLUS          64   /* 7PLUS mail              */
    #define THTML           128  /* HTML mail               */
    /* EBFLAGS (erased_by in indexstruct) */
    #define EB_NONE         0
    #define EB_SENDER       1
    #define EB_RECEIVER     2
    #define EB_SYSOP        4
    #define EB_RSYSOP       5
    #define EB_DOUBLESYSOP  6
    #define EB_LIFETIME     8
    #define EB_SF           16
    #define EB_REMOTE       32
    #define EB_SFERR        64
    #define EB_RETMAIL      66
    #define EB_TRANSFER     128

    Note that the gcc aligns the size of the structure to a size dividable by four.

    back to content page

    G. The Check List Format

    DPBOX creates a "check list" while garbage collection: box/stat/msglist.box.

    The file is used for the output of the CHECK command. The content is a subset of the content of the index files. Every relevant change in index files is projected on the check list too.

    The check list is not locked with checksums, as invalid data herein causes no conflicts in forward. However, also the information represented in these files should not be changed, as it makes no sense at all.

    Check lists are an array[1..n] of the following structure:

    typedef struct boxlogstruct {
      long msgnum;               /* message number          */
      long rxdate;               /* rxdate                  */
      unsigned short idxnr;      /* #nr in index/board      */
      unsigned short lifetime;   /* local lifetime          */
      unsigned short msgflags;   /* msgflags (see MSGFLAGS) */
      long size;                 /* unpacked message size   */
      boolean deleted;           /* logically deleted       */
      Char msgtype;              /* A/B/P/T                 */
      uchar content_type;        /* content encoding        */
      uchar level;               /* access level            */
      Char destination[9];       /* board                   */
      Char obrett[9];            /* original board          */
      Char bulletin_id[13];      /* BID                     */
      Char originator[7];        /* sender                  */
      Char mbx[7];               /* @mbx (shortened)        */
      Char subject[41];          /* subject (shortened)     */
    } boxlogstruct;
    /* MSGFLAGS */
    #define MSG_SFWAIT      1
    #define MSG_PROPOSED    2
    #define MSG_SFRX        4
    #define MSG_SFTX        8
    #define MSG_SFERR       16
    #define MSG_SFNOFOUND   32
    #define MSG_CUT         64
    #define MSG_MINE        128
    #define MSG_REJECTED    256
    #define MSG_DOUBLE      512
    #define MSG_BROADCAST   1024
    #define MSG_BROADCAST_RX 2048
    #define MSG_OWNHOLD     4096
    #define MSG_LOCALHOLD   8192
    #define MSG_SFHOLD      16384
    #define MSG_OUTDATED    32768
    /* bit values for content_type  */
    #define PM_HUFF         4    /* LZH compression         */
    #define TTEXT           0    /* ASCII mail              */
    #define TBIN            32   /* binary mail             */
    #define T7PLUS          64   /* 7PLUS mail              */
    #define THTML           128  /* HTML mail               */

    back to content page

    H. The Auto Router Data Base

    The auto router database is fed with information by the header analysis of each incoming mail. It is used for smart routing capabilities of DPBOX and for automatic expansion of hierarchical bbs calls. You can check its content with the BBS command.

    The database is stored in box/stat/hpath.box.

    Its content is not locked with checksums, however, don't change its content while runtime of DPBOX as the data base is indexed by an automatic hashing algorithm.

    There is one exception: you may delete one entry by overriding the call field of the structure with '******' to delete it, if you think a bbs should be deleted from the table. Normally, this is performed whilst garbage collection after 12 month of inactivity from that bbs.

    Do not touch the other fields. Do not edit the content with text editors. Crashes are on your side.

    The database in hpath.box is an array[1..n] of the following structure:

    typedef struct hboxtyp {
      Char call[7];              /* BBS-Call                */
      Char hpath[41];            /* hierarchical path       */
      Char bestvia[7];           /* best rx via             */
      Char rxfrom[7];            /* best path received from */
      Char desc[41];             /* BBS info                */
      long lasttx;               /* last TX date            */
      long msgct;                /* count of messages       */
      long best;                 /* fastest runtime of msg  */
      long average;              /* average runtime of msgs */
      long bytect;               /* count of received bytes */
      long change_date;          /* best path changed at    */
    } hboxtyp;

    back to content page

    I. The HomeBBS Data Base

    The home bbs information of users is stored in the file box/stat/mybbs.box.

    It is updated by local usage of the MYBBS command, by incoming M-Mails (german standard) and by incoming WP update messages of type /U (user set). Guessed entries of WP messages are not used for updating.

    The file is not locked by checksums. However, don't change its content while DPBOX is running. DPBOX uses different caching mechanisms to speed lookup in this file, and any change whilst runtime will confuse the caching completely.

    Additionally, home bbs information for local users (those one that connected your bbs at least once in the past year) is held in the box/indexes/M.IDX database, too. Information held therein overrides the setting in box/stat/mybbs.box (but is, if you didn't patch in mybbs.box, the same).

    Better you open that file read only.

    The database in mybbs.box is an array[1..n] of the following structure:

    typedef struct mybbstyp {
      Char call[7];              /* Call                    */
      Char bbs[7];               /* MyBBS                   */
      long updatetime;           /* last updated at         */
    } mybbstyp;

    back to content page

    J. The DPBOX Socket Interface Specification

    As is described more detailed in the TNT documentation, for connection to the outside world, DPBOX uses a Unix Socket Interface.

    All communication with the DPBOX daemon is handled via this interface. Multiple interfaces may be opened at the same time. Except general file system access by DPBOX, no other input/output is done by the BBS. This is the vital interface.

    You might be interested in the full layout of this interface if you want to write an own driver for DPBOX, e.g. a PACTOR driver or similar.

    Erroneous implementation of the protocol WILL lead to crashes, there is no syntax check in the receiving code of DPBOX.

    The interface was developed by Mark, DL4YBG. Its layout covers a general purpose of connecting terminal programs to data processing applications via socket interfaces. The use by DPBOX is only one possible implementation.

    For this reason, data direction indicators in the below definition vary between the names "PR", "Program" and DPBox". In general, "PR" is the program DPBOX is connected to (usually supporting the access to the packet radio network), "Program" and "DPBox" siginify the part of DPBOX.

    Definition of the protocol was made from the point of view of TNT. If in doubt what happens at specific actions, investigate the TNT source code and make your own program behave the way TNT does.

    Description of Socket-Interface-Protocol Rev.2
    Mark Wahl, DL4YBG Created: 26.11.94 Last Update: 13.04.96 0. General Layout
    Indicator (1 Byte) Channel (2 Byte) Usernr (2 Byte) Length (2 Byte) Data (Length Bytes) 1. Commands
    1.1 Activate Program
    (PR->Program) On the specified channel the linked program (defined by used socket) shall be activated (the interface will be opened). If channel is 0, the activation is started from the operator console instead of a packet channel. Indicator (1 Byte) IF_COMMAND Channel (2 Byte) channel Usernr (2 Byte) NO_USERNR Length (2 Byte) LEN_SIMPLE + (strlen(callsign) + 1) Command (4 Byte) CMD_ACTIVATE Callsign ((strlen(callsign) + 1) Byte) char callsign[] 1.2 Deactivate Program
    (PR->Program) On the specified channel the linked program (defined by used socket) shall be deactivated (the interface will be closed). Indicator (1 Byte) IF_COMMAND Channel (2 Byte) channel Usernr (2 Byte) usernr Length (2 Byte) LEN_SIMPLE Command (4 Byte) CMD_DEACTIVATE 1.3 Connect
    (Program->PR) A free channel shall be used to build up a connection. QRG, Source call, Destination call and a connection-build-up-time-out must be specified. The connection will be build up using xconnect-feature, therefore no digipeaterpath is allowed. The user 'usernr' will be informed about the result of the connect, successful or not. Indicator (1 Byte) IF_COMMAND Channel (2 Byte) NO_CHANNEL Usernr (2 Byte) usernr Length (2 Byte) LEN_CONNECT + (strlen(sourcecall) + 1) + (strlen(destcall) + 1) Command (4 Byte) CMD_CONNECT Timeout (4 Byte) int timeout Qrg (20 Byte) char qrg[20] Sourcecall (strlen(sourcecall) + 1) char sourcecall[] Destcall (strlen(destcall) + 1) char destcall[] 1.4 Disconnect
    (Program->PR) The connection on the specified channel shall be disconnected. Indicator (2 Byte) IF_COMMAND Channel (2 Byte) channel Usernr (2 Byte) usernr Length (2 Byte) LEN_SIMPLE Command (4 Byte) CMD_DISCONNECT 1.5 Finish Program
    (Program->PR) If the program was started directly (using special SSID), the connection will be disconnected. Otherwise a reconnection to the last used command processor will occur (reconnect to terminal/node-software). Indicator (1 Byte) IF_COMMAND Channel (2 Byte) channel Usernr (2 Byte) usernr Length (2 Byte) LEN_SIMPLE Command (4 Byte) CMD_FINISH 1.6 Channel Status
    (PR->Program) If the number of frames in the TX-buffer (Program and TNC) has changed on a channel linked to a program, a channel status message with the new number of frames in TX-buffer will be sent. Indicator (1 Byte) IF_COMMAND Channel (2 Byte) channel Usernr (2 Byte) usernr Length (2 Byte) LEN_CSTATUS Command (4 Byte) CMD_CSTATUS Number of frames in TX-buffer (4 Bytes) int snd_frames 1.7 Blocking
    (Program->PR, PR->Program) If blocking is received, the sending side has reached maximum byte count and is waiting for an unblocking message. Otherwise no data will be transmitted. This is a simple handshake to avoid an overrun of the socket. Indicator (1 Byte) IF_COMMAND Channel (2 Byte) NO_CHANNEL Usernr (2 Byte) NO_USERNR Length (2 Byte) LEN_SIMPLE Command (4 Byte) CMD_BLOCK 1.8 Unblocking
    (Program->PR, PR->Program) unblock restarts the transmitter on the other side of the interface. Indicator (1 Byte) IF_COMMAND Channel (2 Byte) NO_CHANNEL Usernr (2 Byte) NO_USERNR Length (2 Byte) LEN_SIMPLE Command (1 Byte) CMD_UNBLOCK 1.9 Sort new mail
    (PR->DPBox) A mail was collected from monitor or during connect with a mailbox. Pattern is the filename of the used file, Rcall is the callsign of the mailbox where this file was fetched (or an empty string). Not used for S&F connects, only for monitoring features. Indicator (1 Byte) IF_COMMAND Channel (2 Byte) NO_CHANNEL Usernr (2 Byte) usernr Length (2 Byte) LEN_SIMPLE + (strlen(pattern_) + 1) + (strlen(rcall) + 1) Command (4 Byte) CMD_SORT_NEW_MAIL Pattern ((strlen(pattern_) + 1) Bytes) char pattern_[] Rcall ((strlen(rcall) + 1) Bytes) char rcall[] 1.10 SF Rx EMT
    (PR->DPBox) A mail for folder 'E', 'M' or 'T' was received. These mails consist only of one line. This line will be sent directly in Eingabe. Not used for S&F connects, only for monitoring features. Indicator (1 Byte) IF_COMMAND Channel (2 Byte) NO_CHANNEL Usernr (2 Byte) usernr Length (2 Byte) LEN_SIMPLE + (strlen(eingabe_) + 1) Command (4 Byte) CMD_SF_RX_EMT Eingabe ((strlen(eingabe_) + 1) Bytes) char eingabe_[] 1.11 Connect for Store and Forward
    (DPBox->PR) A free channel shall be used to build up a connection for Store and Forward. Sourcecall, Destinationcall and a connection-build-up-timeout must be specified. Indicator (1 Byte) IF_COMMAND Channel (2 Byte) NO_CHANNEL Usernr (2 Byte) NO_USERNR Length (2 Byte) LEN_BOXPBOXSF + (strlen(sourcecall) + 1) + (strlen(destcall) + 1) Command (4 Byte) CMD_BOXPBOXSF Timeout (4 Byte) int timeout Sourcecall (strlen(sourcecall) + 1) char sourcecall[] Destcall (strlen(destcall) + 1) char destcall[] 1.12 Disconnect
    (DPBox->PR) The connection on the specified channel shall be disconnected. Indicator (1 Byte) IF_COMMAND Channel (2 Byte) channel Usernr (2 Byte) usernr Length (2 Byte) LEN_SIMPLE Command (4 Byte) CMD_BOXPRDISC 1.13 Abort Store and Forward
    (DPBox->PR) Store and Forward shall be cancelled. If Immediate is not 0, outstanding TX-Packet must be cancelled, too. Indicator (1 Byte) IF_COMMAND Channel (2 Byte) channel Usernr (2 Byte) usernr Length (4 Byte) LEN_BOXPABORTSF Command (4 Byte) CMD_BOXPABORTSF Immediate (4 Byte) int immediate 1.14 Abort Routing
    (PR->DPBox) A Connect command for Store and Forward sent by DPBox (CMD_BOXPBOXSF) was not successful. Indicator (1 Byte) IF_COMMAND Channel (2 Byte) NO_CHANNEL Usernr (2 Byte) NO_USERNR Length (2 Byte) LEN_SIMPLE + (strlen(callsign) + 1) Command (4 Byte) CMD_ABORT_ROUTING Callsign ((strlen(callsign) + 1) Byte) char callsign[] 1.15 Start Store and Forward
    (PR->DPBox) A Connect command for Store and Forward sent by DPBox (CMD_BOXPBOXSF) was successful and S&F can begin. Indicator (1 Byte) IF_COMMAND Channel (2 Byte) channel Usernr (2 Byte) NO_USERNR Length (2 Byte) LEN_SIMPLE + (strlen(callsign) + 1) Command (4 Byte) CMD_START_SF Callsign ((strlen(callsign) + 1) Byte) char callsign[] 1.16 Finish Program
    (PR->Program) The Program connected to the socket shall terminate the execution. This is used to kill daemon-processes. Indicator (1 Byte) IF_COMMAND Channel (2 Byte) NO_CHANNEL Usernr (2 Byte) NO_USERNR Length (2 Byte) LEN_SIMPLE Command (4 Byte) CMD_FINISH_PRG 1.17 Activation Response
    (Program->PR) If a program was activated via CMD_ACTIVATE or CMD_START_SF, the resulting usernr will be returned in this message. If the usernumber is equal 0, then the activation was not successful. In the response string additional information about the activation can be transferred. Indicator (1 Byte) IF_COMMAND Channel (2 Byte) channel Usernr (2 Byte) usernr Length (2 Byte) LEN_SIMPLE + (strlen(response) + 1) Command (4 Byte) CMD_FINISH_PRG Response ((strlen(response) + 1) Byte) char response[] 1.18 AutoBIN-File to Box
    (PR->Program) On the current channel a file was received with AutoBIN-protocol. Erase defines if the file shall be deleted afterwards, error indicates a wrong CRC-checksum and buffer contains the filename of the file. No more supported by DPBOX, DPBOX handles AutoBIN itself. Indicator (1 Byte) IF_COMMAND Channel (2 Byte) channel Usernr (2 Byte) usernr Length (2 Byte) LEN_ABINFILETOBOX + (strlen(buffer) + 1) Command (4 Byte) CMD_ABINFILETOBOX Erase (4 Byte) int erase Error (4 Byte) int error Buffer ((strlen(buffer) + 1) Byte) char buffer[] 1.19 Huffman Status
    (PR->Program) (Program->PR) If huffman coding is enabled or disabled this message will inform the other side about the new status. 1 means huffman coding is active, 0 means inactive. Huffman encoding/decoding has to be done by PR. Indicator (1 Byte) IF_COMMAND Channel (2 Byte) channel Usernr (2 Byte) usernr Length (2 Byte) LEN_HUFFSTAT Command (4 Byte) CMD_HUFFSTAT Huffstat (4 Byte) int huffstat 1.20 Frequency Information
    (PR->Program) With this message all frequencies handled by the PR-program are sent to the program. This information is used to find the right interface for S&F by DPBox. Indicator (1 Byte) IF_COMMAND Channel (2 Byte) channel Usernr (2 Byte) usernr Length (2 Byte) LEN_QRGINFO Command (4 Byte) CMD_QRGINFO Frequency (220 Byte) char qrg[MAXQRGS+1][20] (MAXQRGS = 10) 1.21 Bulletin-ID query and answer
    (PR->DPBox)(DPBox->PR) With this message the program can query if a mail is already available in the DPBox by checking the bulletin ID. DPBox will answer in 'Found' (0: not found, 1: found) and will return the bullid, too. Not used for S&F connects, only for monitoring features and similar. Indicator (1 Byte) IF_COMMAND Channel (2 Byte) channel Usernr (2 Byte) usernr Length (2 Byte) LEN_BULLID Command (4 Byte) CMD_BULLID Found (4 Byte) int found Bullid (13 Byte) char bullid[BULLIDLEN+1] (BULLIDLEN = 12) 1.22 Start AutoBIN-receive
    (DPBox->PR) This message instructs TNT to prepare AutoBIN reception on the current channel. The filename of the file to open will be given as parameter (null-terminated string in buffer). No more supported by DPBOX, DPBOX handles AutoBIN itself. Indicator (1 Byte) IF_COMMAND Channel (2 Byte) channel Usernr (2 Byte) usernr Length (2 Byte) LEN_SIMPLE + (strlen(buffer) + 1) Command (4 Byte) CMD_STARTABIN Buffer ((strlen(buffer) + 1) Byte) char buffer[] 1.23 Update Box-timeout
    (PR->DPBox) During AutoBIN-receive TNT informs DPBox by this message that the user is still active. No more supported by DPBOX. Indicator (1 Byte) IF_COMMAND Channel (2 Byte) channel Usernr (2 Byte) usernr Length (2 Byte) LEN_SIMPLE Command (4 Byte) CMD_BOXTOUCH 1.24 Set Read/write Mode
    (DPBox->PR) This message informs TNT if during a boxconnect the AutoBIN-header shall be analysed (rwmode = 0) or not (rwmode = 1). No more supported by DPBOX, DPBOX handles AutoBIN itself. Indicator (1 Byte) IF_COMMAND Channel (2 Byte) channel Usernr (2 Byte) usernr Length (2 Byte) LEN_SETRWMODE Command (4 Byte) CMD_SETRWMODE Rwmode (4 Byte) int rwmode 1.25 Box Is Busy
    (DPBox->PR) This message informs TNT if DPBox is busy and connects shall be rejected. (boxisbusy = 0, connects allowed; boxisbusy = 1, no connects allowed) Indicator (1 Byte) IF_COMMAND Channel (2 Byte) NO_CHANNEL Usernr (2 Byte) NO_USERNR Length (2 Byte) LEN_BOXISBUSY Command (4 Byte) CMD_BOXISBUSY Boxisbusy (4 Byte) int boxisbusy 1.26 Start Box Broadcast
    (DPBox->PR) This message instructs TNT to start a broadcast transmission of a file. The broadcast-header is contained in a file, the filename of this file is stored in buffer. Indicator (1 Byte) IF_COMMAND Channel (2 Byte) NO_CHANNEL Usernr (2 Byte) NO_USERNR Length (2 Byte) LEN_SIMPLE + (strlen(buffer) + 1) Command (4 Byte) CMD_STARTBOXBC Buffer ((strlen(buffer) + 1) Byte) char buffer[] 1.27 Broadcast Callback
    (PR->DPBox) If the broadcast transmission of a file is finished, DPBox will be informed by this message. The file is identified by the file_id contained in the message. Indicator (1 Byte) IF_COMMAND Channel (2 Byte) NO_CHANNEL Usernr (2 Byte) NO_USERNR Length (2 Byte) LEN_BCCALLBACK Command (4 Byte) CMD_BCCALLBACK File_id (4 Byte) long file_id 1.28 Set Unproto Destination
    (DPBox->PR) This message sets the unproto destination for the following unproto data. The destination is stored independently for every interface. Indicator (1 Byte) IF_COMMAND Channel (2 Byte) NO_CHANNEL Usernr (2 Byte) NO_USERNR Length (2 Byte) LEN_SETUNPROTO + (strlen(buffer) + 1) Command (4 Byte) CMD_SETUNPROTO Qrg (20 Byte) char qrg[20] Address ((strlen(address) + 1) Byte) char address[] 1.29 Connect Not Successful
    (PR->Program) A connect, initiated by user 'usernr' was not successful. Indicator (1 Byte) IF_COMMAND Channel (2 Byte) NO_CHANNEL Usernr (2 Byte) usernr Length (2 Byte) LEN_SIMPLE Command (4 Byte) CMD_NOSUCCESSCON 1.30 Connect Successful
    (PR->Program) A connect, initiated by user 'usernr' was successful and the link between the two connects shall be established. The channel of the new connection is contained in channel. Indicator (1 Byte) IF_COMMAND Channel (2 Byte) channel Usernr (2 Byte) usernr Length (2 Byte) LEN_SIMPLE + (strlen(callsign) + 1) Command (4 Byte) CMD_SUCCESSCON Callsign ((strlen(callsign) + 1) Byte) char callsign[] 1.31 TNT-Command
    (Program->PR) This command contains a command string, which shall be parsed and executed by the TNT command processor. 'channel' is used as channel used for the command. 'usernr' is the user, which must be informed about the result. Only used in DPBOX for the TNTCOMM command. Indicator (1 Byte) IF_COMMAND Channel (2 Byte) channel Usernr (2 Byte) usernr Length (2 Byte) LEN_SIMPLE + (strlen(buffer) + 1) Command (4 Byte) CMD_TNTCOMMAND Buffer ((strlen(buffer) + 1) Byte) char buffer[] 1.32 TNT-Response
    (PR->Program) This message contains the response to the command given by CMD_TNTCOMMAND (1.31 TNT-Command). 'follows' indicates, if other responses to the command will follow, 'follows' == 0 indicates the last response. 'channel' is the given channel for the command and 'usernr' is the user, who requested the command. Only used in DPBOX for the TNTCOMM command. Indicator (1 Byte) IF_COMMAND Channel (2 Byte) channel Usernr (2 Byte) usernr Length (2 Byte) LEN_SIMPLE + (strlen(buffer) + 1) Command (4 Byte) CMD_TNTRESPONSE Follows (4 Byte) follows Buffer ((strlen(buffer) + 1) Byte) char buffer[] 1.33 Abort Connect
    (Program->PR) A connect request started by 'usernr' shall be aborted. Indicator (1 Byte) IF_COMMAND Channel (2 Byte) NO_CHANNEL Usernr (2 Byte) usernr Length (2 Byte) LEN_SIMPLE Command (4 Byte) CMD_ABORTCON 2. Data
    Indicator (1 Byte) IF_DATA Channel (2 Byte) channel Usernr (2 Byte) usernr Length (2 Byte) 1 - 256 Data (Length Bytes) char data[] 3. Unproto
    The data will be sent to the destination last defined by CMD_SETUNPROTO. Indicator (1 Byte) IF_UNPROTO Channel (2 Byte) NO_CHANNEL Usernr (2 Byte) NO_USERNR Length (2 Byte) 1 - 256 Data (Length Bytes) char data[]

    Following are the const definitions for the interface:

    #define MAXQRGS 10
    #define BULLIDLEN 12
    #define LEN_SIMPLE sizeof(int)
    #define LEN_CSTATUS (LEN_SIMPLE + sizeof(int))
    #define LEN_BOXPBOXSF (LEN_SIMPLE + sizeof(int))
    #define LEN_BOXPABORTSF (LEN_SIMPLE + sizeof(int))
    #define LEN_HUFFSTAT (LEN_SIMPLE + sizeof(int))
    #define LEN_ABINFILETOBOX (LEN_SIMPLE + sizeof(int) + sizeof(int))
    #define DAT_QRGINFO (20 * (MAXQRGS + 1))
    #define LEN_BULLID (LEN_SIMPLE + sizeof(int) + BULLIDLEN + 1)
    #define LEN_SETRWMODE (LEN_SIMPLE + sizeof(int))
    #define LEN_BOXISBUSY (LEN_SIMPLE + sizeof(int))
    #define LEN_BCCALLBACK (LEN_SIMPLE + sizeof(long))
    #define LEN_SETUNPROTO (LEN_SIMPLE + 20)
    #define LEN_CONNECT (LEN_SIMPLE + sizeof(int) + 20)
    #define LEN_TNTRESPONSE (LEN_SIMPLE + sizeof(int))
    /* special definitions */
    #define NO_CHANNEL -1
    #define NO_USERNR -1
    /* states for iface_list.active (0 = inactive) */
    #define IF_NOTACTIVE 0
    #define IF_ACTIVE 1
    #define IF_TRYING 2
    /* states of iface_list.indicator and first byte of iface-packet */
    #define IF_COMMAND 1
    #define IF_DATA 2
    #define IF_UNPROTO 3
    /* commands if IF_COMMAND */
    #define CMD_ACTIVATE 1
    #define CMD_DEACTIVATE 2
    #define CMD_CONNECT 3
    #define CMD_DISCONNECT 4
    #define CMD_FINISH 5
    #define CMD_CSTATUS 6
    #define CMD_BLOCK 7
    #define CMD_UNBLOCK 8
    #define CMD_SORT_NEW_MAIL 9
    #define CMD_SF_RX_EMT 10
    #define CMD_BOXPBOXSF 11
    #define CMD_BOXPRDISC 12
    #define CMD_BOXPABORTSF 13
    #define CMD_ABORT_ROUTING 14
    #define CMD_START_SF 15
    #define CMD_FINISH_PRG 16
    #define CMD_ACT_RESP 17
    #define CMD_ABINFILETOBOX 18
    #define CMD_HUFFSTAT 19
    #define CMD_QRGINFO 20
    #define CMD_BULLID 21
    #define CMD_STARTABIN 22
    #define CMD_BOXTOUCH 23
    #define CMD_SETRWMODE 24
    #define CMD_BOXISBUSY 25
    #define CMD_STARTBOXBC 26
    #define CMD_BCCALLBACK 27
    #define CMD_SETUNPROTO 28
    #define CMD_NOSUCCESSCON 29
    #define CMD_SUCCESSCON 30
    #define CMD_TNTCOMMAND 31
    #define CMD_TNTRESPONSE 32
    #define CMD_ABORTCON 33

    back to content page

    K. The AutoBIN Protocol

    DPBOX uses a binary mode for receiving and transmitting binary messages called the "AutoBIN protocol". It first was defined in the mid-80s by DL1BHO and is broadly used in german packet programs.

    The below text is a packet message of DK4NB explaining the implementation of the protocol. Please note that I disagree in some minor points with the author, so for the importance of the YAPP protocol.

    ### Start of copied text ###

    From: DK4NB @ DB0AAB.#BAY.DEU.EU
    To : SOFTWARE @ WW

    This is the documentation for the so-called #BIN# protocol, a procedure
    for transferring binary and other data files without undue overhead.


    31 May 94 First published.

    1) HISTORY

    The original #BIN# protocol was probably devised by DL1BHO for use with his TurboPacket program. The protocol underwent a number of changes and improvements at the hands of ex-DL1MEN who is now DK4NB. The #BIN# protocol is implemented in most packet terminal programs utilizing the WA8DED host mode, such as TurboPacket, TOP, GP, SP and others, as well as the F6FBB and TheBox BBS software.

    As of today (June 1994), the most recent version of the #BIN# protocol is only available in SP version 9. It is hoped that this version is adopted by other packet terminal programs. Due to its very low overhead, it is a natural for replacing the obsolete YAPP protocol.


    2.1) BASIC

    The basic #BIN# protocol consists of three elements:

    The station transmitting the file (from now on called STATION A) transmits
    and the station receiving the file (from now on called STATION B) transmits
    in positive response, or
    in negative response.

    "nnnnn" = the length of the file in decimal bytes
    "\r" = a RETURN character
    "..." = any explanatory text as to why the file transfer is rejected.

    STATION B is to ignore any data not beginning with #OK# or #NO#.

    All Elements are to start at the beginning of a frame and be contained entirely within one frame. The frame immediately preceding an element is to end with a return ("\r").

    A transfer is aborted in midstream by one of the stations transmitting

    2.2) EXTENDED

    The extended #BIN# protocol has last been changed in January 1994 and is described as follows:

    STATION A transmits:

         -----  -----  --------  ----
           !      !       !      file name without path
           !      !       file date and time in 'struct ftime' format (BCC 3.x)
           !      !       in hexadecimal notation (32 bits)
           !      The CRC of the whole file in decimal. Standard CCITT
           !      polynomial.
           file length in decimal bytes.
    The negative response by STATION B is defined as above. The positive response may be
    #OK#\r (1)
    #OK#ssss\r (2)
    #OK#ssss#$nnnnn#ccccc\r (3)
        ----  ----- -----
         !      !   CRC of received file fragment
         !      number of bytes in received fragment
         file name without path
    Case (1) and case (2) are treated identically. Currently, the #OK# file name is transmitted for information to the operator only, since the receiving side is free to choose any file name.

    Case (3) is the response used if it had previously been attempted to transfer the file, and the transfer has failed due to a manual abort or a broken link, or a disconnect. Note that when aborting, it is the responsibility of the receiving station not to allow any extraneous information, such as digipeater status messages or the #ABORT# command or TNC status messages or any other data not belonging to the received file to be stored. If the receiving station cannot guarantee this, it should delete the file fragment.

    When STATION A re-transmits the same file, STATION B should check for existence of a previously stored file fragment. If there is a fragment, then the data according to (3) should be determined and the appropriate #OK# message should be transmitted.

    The method of identifying a file fragment is up to the protocol implementation. In the case of SP, the file extension contains a "$" in place of the first character, e.g. "TEST.LZH" generates a fragment called "TEST.$ZH". Better operating systems than MS-DOS allow long file names which could be used to better denote a fragment.

    STATION A, upon receiving the #OK# according to (1) or (2), should commence transmission of the file. The logical conclusion of the file transfer is achieved with the transmission of the last byte of the file. Upon receiving #OK# according to (3), STATION A should determine the CRC of the fragment and compare it with the CRC reported. Appropriate measures must be taken if the CRCs do not match.


    While STATION A is in binary transfer mode (i.e. not all bytes of the file have been committed to the TNC yet), the user is allowed to transmit textual data not related to the binary transfer. All frames of such data must be preceded by the string
    SP\- and STATION B must not regard frames starting with this string as parts of the binary file transfer. This allows the operators to chat while transferring the file. STATION B, when transmitting data, need not take any precautions. STATION A must not cause an abort when receiving any data from STATION B that does not consist of the special abort element described above.


    If STATION A is unable to resume an aborted binary transfer, it should signal this to STATION B at the start of the transfer by not transmitting the question mark ("?") shown in the #BIN# element above. If this question mark is missing, STATION B is to take whatever measures required to either reject the transfer or to quietly overwrite the fragment.

    If STATION B is unable to resume an aborted binary transfer, it should delete aborted file fragments or take whatever steps necessary to not cause an error message should STATION A repeat the transfer attempt.

    2.5) CRC ERRORS

    If, at the end of a transfer, STATION B detects a CRC error, it should report this to STATION A and take whatever steps required (e.g. delete the damaged file). The format of this report may be of any kind, since it is not used by the protocol.

    2.6) SUCCESS

    STATION B should, at the end of a successful transfer, transmit a success message to STATION A. It is recommended that STATION A send one to STATION B as well. Neither message will be part of the protocol specification. Provisions should be made to transmit success messages on a per CALL SIGN basis, so as to not send such messages to BBS systems, which might be confused and report invalid commands. Success messages only make sense when transmitted to a human operator.


    ld react to the #BIN# element even if it has not been placed in binary mode. An example would be the reception of a binary file from a TheBox BBS, which simply sends the #BIN# element immediately followed by data. Normal procedure, however, calls for some other means of initiation.

    A second use for automatic #BIN# would be consecutive transmission of multiple files. The list of files is to be controlled by STATION A, and STATION B must be in a mode which allows automatic responses to #BIN#. The protocol does not allow auto resume with automatic #BIN#.


    A binary transfer may be initiated at the programmer's discretion. Usually, this will be a command issued by one of the two stations involved.

    A typical constellation is a packet user controlling an unattended station. That unattended station should place the appropriate commands at the remote user's disposal. Implementation of such remote commands depends on factors such as the programmer's fancy or the general purpose of the station to be controlled and their description is beyond the scope of this document.


    All communication regarding the Extended #BIN# Protocol is to be directed to the author, DK4NB @ DB0AAB.DEU.EU or Compuserve 100346,2236 (Internet 100346.2236@composerve.com).

    This specification is subject to change without prior notice. Any changes will be published. Anyone making changes to this protocol specification does so at their own risk.


    The following C code consists of the standard CRC table and a macro used to access the table.

     *      crctab calculated by Mark G. Mendel, Network Systems Corporation
    unsigned short crctab[256] = {
     * updcrc macro derived from article Copyright (C) 1986 Stephen Satchell.
     *  NOTE: First argument must be in range 0 to 255.
     *        Second argument is referenced twice.
     * Programmers may incorporate any or all code into their programs,
     * giving proper credit within the source. Publication of the
     * source routines is permitted so long as proper credit is given
     * to Stephen Satchell, Satchell Evaluations and Chuck Forsberg,
     * Omen Technology.
    #define updcrc(cp,crc) (crctab[((crc >> 8) & 255)] ^ (crc << 8) ^ cp)
    ### End of copied text ###

    back to content page

    L. Calculating CRCs

    This is no theoretic explication on how CRCs are computed. I just give you the CRC calculation routines as used by DPBOX. Credits belong to DG0FT for spending two days (and a night hi) hunting for the CRCing of FBB in compressed forward.

    ### File crc.h ###

    /* four different methods of CRCing:
        crc_16 is the CRC16 as used for SMACK KISS (init crc with 0),
        crcfcs is the FCS of AX.25 (init crc with 0xFFFF),
        crcthp is the AutoBIN-CRC (init crc with 0),
          (thp represents TurboHostPacket, the forefather of all german hostmode
           programs, written by DL1BHO in mid-80s)
        crcfbb is the f6fbb-forward-CRC (init crc with 0).
    extern void crc_16(uchar Data, unsigned short *crc);
    extern void crcfcs(uchar Data, unsigned short *crc);
    extern void crcthp(uchar Data, unsigned short *crc);
    extern void crcfbb(uchar Data, unsigned short *crc);

    ### End of file crc.h ###

    ### File crc.c ###

    #include "crc.h"
    typedef unsigned short crctabtype[256];
    Static crctabtype crc16_table = {
      0, 0xc0c1, 0xc181, 0x140, 0xc301, 0x3c0, 0x280, 0xc241, 0xc601, 0x6c0,
      0x780, 0xc741, 0x500, 0xc5c1, 0xc481, 0x440, 0xcc01, 0xcc0, 0xd80,
      0xcd41, 0xf00, 0xcfc1, 0xce81, 0xe40, 0xa00, 0xcac1, 0xcb81, 0xb40,
      0xc901, 0x9c0, 0x880, 0xc841, 0xd801, 0x18c0, 0x1980, 0xd941, 0x1b00,
      0xdbc1, 0xda81, 0x1a40, 0x1e00, 0xdec1, 0xdf81, 0x1f40, 0xdd01, 0x1dc0,
      0x1c80, 0xdc41, 0x1400, 0xd4c1, 0xd581, 0x1540, 0xd701, 0x17c0, 0x1680,
      0xd641, 0xd201, 0x12c0, 0x1380, 0xd341, 0x1100, 0xd1c1, 0xd081, 0x1040,
      0xf001, 0x30c0, 0x3180, 0xf141, 0x3300, 0xf3c1, 0xf281, 0x3240, 0x3600,
      0xf6c1, 0xf781, 0x3740, 0xf501, 0x35c0, 0x3480, 0xf441, 0x3c00, 0xfcc1,
      0xfd81, 0x3d40, 0xff01, 0x3fc0, 0x3e80, 0xfe41, 0xfa01, 0x3ac0, 0x3b80,
      0xfb41, 0x3900, 0xf9c1, 0xf881, 0x3840, 0x2800, 0xe8c1, 0xe981, 0x2940,
      0xeb01, 0x2bc0, 0x2a80, 0xea41, 0xee01, 0x2ec0, 0x2f80, 0xef41, 0x2d00,
      0xedc1, 0xec81, 0x2c40, 0xe401, 0x24c0, 0x2580, 0xe541, 0x2700, 0xe7c1,
      0xe681, 0x2640, 0x2200, 0xe2c1, 0xe381, 0x2340, 0xe101, 0x21c0, 0x2080,
      0xe041, 0xa001, 0x60c0, 0x6180, 0xa141, 0x6300, 0xa3c1, 0xa281, 0x6240,
      0x6600, 0xa6c1, 0xa781, 0x6740, 0xa501, 0x65c0, 0x6480, 0xa441, 0x6c00,
      0xacc1, 0xad81, 0x6d40, 0xaf01, 0x6fc0, 0x6e80, 0xae41, 0xaa01, 0x6ac0,
      0x6b80, 0xab41, 0x6900, 0xa9c1, 0xa881, 0x6840, 0x7800, 0xb8c1, 0xb981,
      0x7940, 0xbb01, 0x7bc0, 0x7a80, 0xba41, 0xbe01, 0x7ec0, 0x7f80, 0xbf41,
      0x7d00, 0xbdc1, 0xbc81, 0x7c40, 0xb401, 0x74c0, 0x7580, 0xb541, 0x7700,
      0xb7c1, 0xb681, 0x7640, 0x7200, 0xb2c1, 0xb381, 0x7340, 0xb101, 0x71c0,
      0x7080, 0xb041, 0x5000, 0x90c1, 0x9181, 0x5140, 0x9301, 0x53c0, 0x5280,
      0x9241, 0x9601, 0x56c0, 0x5780, 0x9741, 0x5500, 0x95c1, 0x9481, 0x5440,
      0x9c01, 0x5cc0, 0x5d80, 0x9d41, 0x5f00, 0x9fc1, 0x9e81, 0x5e40, 0x5a00,
      0x9ac1, 0x9b81, 0x5b40, 0x9901, 0x59c0, 0x5880, 0x9841, 0x8801, 0x48c0,
      0x4980, 0x8941, 0x4b00, 0x8bc1, 0x8a81, 0x4a40, 0x4e00, 0x8ec1, 0x8f81,
      0x4f40, 0x8d01, 0x4dc0, 0x4c80, 0x8c41, 0x4400, 0x84c1, 0x8581, 0x4540,
      0x8701, 0x47c0, 0x4680, 0x8641, 0x8201, 0x42c0, 0x4380, 0x8341, 0x4100,
      0x81c1, 0x8081, 0x4040
    Static crctabtype ccitt_table = {
      0, 0x1021, 0x2042, 0x3063, 0x4084, 0x50a5, 0x60c6, 0x70e7, 0x8108, 0x9129,
      0xa14a, 0xb16b, 0xc18c, 0xd1ad, 0xe1ce, 0xf1ef, 0x1231, 0x210, 0x3273,
      0x2252, 0x52b5, 0x4294, 0x72f7, 0x62d6, 0x9339, 0x8318, 0xb37b, 0xa35a,
      0xd3bd, 0xc39c, 0xf3ff, 0xe3de, 0x2462, 0x3443, 0x420, 0x1401, 0x64e6,
      0x74c7, 0x44a4, 0x5485, 0xa56a, 0xb54b, 0x8528, 0x9509, 0xe5ee,
      0xf5cf, 0xc5ac, 0xd58d, 0x3653, 0x2672, 0x1611, 0x630, 0x76d7, 0x66f6,
      0x5695, 0x46b4, 0xb75b, 0xa77a, 0x9719, 0x8738, 0xf7df, 0xe7fe,
      0xd79d, 0xc7bc, 0x48c4, 0x58e5, 0x6886, 0x78a7, 0x840, 0x1861, 0x2802,
      0x3823, 0xc9cc, 0xd9ed, 0xe98e, 0xf9af, 0x8948, 0x9969, 0xa90a,
      0xb92b, 0x5af5, 0x4ad4, 0x7ab7, 0x6a96, 0x1a71, 0xa50, 0x3a33, 0x2a12,
      0xdbfd, 0xcbdc, 0xfbbf, 0xeb9e, 0x9b79, 0x8b58, 0xbb3b, 0xab1a,
      0x6ca6, 0x7c87, 0x4ce4, 0x5cc5, 0x2c22, 0x3c03, 0xc60, 0x1c41, 0xedae,
      0xfd8f, 0xcdec, 0xddcd, 0xad2a, 0xbd0b, 0x8d68, 0x9d49, 0x7e97,
      0x6eb6, 0x5ed5, 0x4ef4, 0x3e13, 0x2e32, 0x1e51, 0xe70, 0xff9f, 0xefbe,
      0xdfdd, 0xcffc, 0xbf1b, 0xaf3a, 0x9f59, 0x8f78, 0x9188, 0x81a9,
      0xb1ca, 0xa1eb, 0xd10c, 0xc12d, 0xf14e, 0xe16f, 0x1080, 0xa1, 0x30c2,
      0x20e3, 0x5004, 0x4025, 0x7046, 0x6067, 0x83b9, 0x9398, 0xa3fb, 0xb3da,
      0xc33d, 0xd31c, 0xe37f, 0xf35e, 0x2b1, 0x1290, 0x22f3, 0x32d2, 0x4235,
      0x5214, 0x6277, 0x7256, 0xb5ea, 0xa5cb, 0x95a8, 0x8589, 0xf56e,
      0xe54f, 0xd52c, 0xc50d, 0x34e2, 0x24c3, 0x14a0, 0x481, 0x7466, 0x6447,
      0x5424, 0x4405, 0xa7db, 0xb7fa, 0x8799, 0x97b8, 0xe75f, 0xf77e,
      0xc71d, 0xd73c, 0x26d3, 0x36f2, 0x691, 0x16b0, 0x6657, 0x7676, 0x4615,
      0x5634, 0xd94c, 0xc96d, 0xf90e, 0xe92f, 0x99c8, 0x89e9, 0xb98a,
      0xa9ab, 0x5844, 0x4865, 0x7806, 0x6827, 0x18c0, 0x8e1, 0x3882, 0x28a3,
      0xcb7d, 0xdb5c, 0xeb3f, 0xfb1e, 0x8bf9, 0x9bd8, 0xabbb, 0xbb9a,
      0x4a75, 0x5a54, 0x6a37, 0x7a16, 0xaf1, 0x1ad0, 0x2ab3, 0x3a92, 0xfd2e,
      0xed0f, 0xdd6c, 0xcd4d, 0xbdaa, 0xad8b, 0x9de8, 0x8dc9, 0x7c26,
      0x6c07, 0x5c64, 0x4c45, 0x3ca2, 0x2c83, 0x1ce0, 0xcc1, 0xef1f, 0xff3e,
      0xcf5d, 0xdf7c, 0xaf9b, 0xbfba, 0x8fd9, 0x9ff8, 0x6e17, 0x7e36,
      0x4e55, 0x5e74, 0x2e93, 0x3eb2, 0xed1, 0x1ef0
    void crc_16(uchar Data, unsigned short *crc)
      *crc = ((*crc) >> 8) ^ crc16_table[((*crc) ^ Data) & 0xff];
    void crcfcs(uchar Data, unsigned short *crc)
      *crc = ((*crc) >> 8) ^ ccitt_table[((*crc) ^ Data) & 0xff];
    void crcthp(uchar Data, unsigned short *crc)
      *crc = ((*crc) << 8) ^ Data ^ ccitt_table[(*crc) >> 8];
    void crcfbb(uchar Data, unsigned short *crc)
      *crc = ((*crc) << 8) ^ ccitt_table[((*crc) >> 8) ^ Data];

    ### End of file crc.c ###

    back to content page

    M. LZHuf Compression

    This is the LZHuf compression algorithm as used in DPBOX and F6FBB.

        written by Haruyasu Yoshizaki 11/20/1988
        some minor changes 4/6/1989
        comments translated by Haruhiko Okumura 4/7/1989
    #include <stdio.h>
    #include <stdlib.h>
    #include <string.h>
    #include <ctype.h>
    FILE  *infile, *outfile;
    unsigned long int  textsize = 0, codesize = 0, printcount = 0;
    char wterr[] = "Can't write.";
    void Error(char *message)
        printf("\n%s\n", message);
    /********** LZSS compression **********/
    #define N       4096    /* buffer size */
    /* Attention: When using this file for f6fbb-type compressed data exchange,
       set N to 2048 ! (DL8HBS) */
    #define F       60  /* lookahead buffer size */
    #define THRESHOLD   2
    #define NIL     N   /* leaf of tree */
    unsigned char
            text_buf[N + F - 1];
    int     match_position, match_length,
            lson[N + 1], rson[N + 257], dad[N + 1];
    void InitTree(void)  /* initialize trees */
        int  i;
        for (i = N + 1; i <= N + 256; i++)
            rson[i] = NIL;          /* root */
        for (i = 0; i < N; i++)
            dad[i] = NIL;           /* node */
    void InsertNode(int r)  /* insert to tree */
        int  i, p, cmp;
        unsigned char  *key;
        unsigned c;
        cmp = 1;
        key = &text_buf[r];
        p = N + 1 + key[0];
        rson[r] = lson[r] = NIL;
        match_length = 0;
        for ( ; ; ) {
            if (cmp >= 0) {
                if (rson[p] != NIL)
                    p = rson[p];
                else {
                    rson[p] = r;
                    dad[r] = p;
            } else {
                if (lson[p] != NIL)
                    p = lson[p];
                else {
                    lson[p] = r;
                    dad[r] = p;
            for (i = 1; i < F; i++)
                if ((cmp = key[i] - text_buf[p + i]) != 0)
            if (i > THRESHOLD) {
                if (i > match_length) {
                    match_position = ((r - p) & (N - 1)) - 1;
                    if ((match_length = i) >= F)
                if (i == match_length) {
                    if ((c = ((r - p) & (N - 1)) - 1) < match_position) {
                        match_position = c;
        dad[r] = dad[p];
        lson[r] = lson[p];
        rson[r] = rson[p];
        dad[lson[p]] = r;
        dad[rson[p]] = r;
        if (rson[dad[p]] == p)
            rson[dad[p]] = r;
            lson[dad[p]] = r;
        dad[p] = NIL;  /* remove p */
    void DeleteNode(int p)  /* remove from tree */
        int  q;
        if (dad[p] == NIL)
            return;         /* not registered */
        if (rson[p] == NIL)
            q = lson[p];
        if (lson[p] == NIL)
            q = rson[p];
        else {
            q = lson[p];
            if (rson[q] != NIL) {
                do {
                    q = rson[q];
                } while (rson[q] != NIL);
                rson[dad[q]] = lson[q];
                dad[lson[q]] = dad[q];
                lson[q] = lson[p];
                dad[lson[p]] = q;
            rson[q] = rson[p];
            dad[rson[p]] = q;
        dad[q] = dad[p];
        if (rson[dad[p]] == p)
            rson[dad[p]] = q;
            lson[dad[p]] = q;
        dad[p] = NIL;
    /* Huffman coding */
    #define N_CHAR      (256 - THRESHOLD + F)
                    /* kinds of characters (character code = 0..N_CHAR-1) */
    #define T       (N_CHAR * 2 - 1)    /* size of table */
    #define R       (T - 1)         /* position of root */
    #define MAX_FREQ    0x8000      /* updates tree when the */
                        /* root frequency comes to this value. */
    typedef unsigned char uchar;
    /* table for encoding and decoding the upper 6 bits of position */
    /* for encoding */
    uchar p_len[64] = {
        0x03, 0x04, 0x04, 0x04, 0x05, 0x05, 0x05, 0x05,
        0x05, 0x05, 0x05, 0x05, 0x06, 0x06, 0x06, 0x06,
        0x06, 0x06, 0x06, 0x06, 0x06, 0x06, 0x06, 0x06,
        0x07, 0x07, 0x07, 0x07, 0x07, 0x07, 0x07, 0x07,
        0x07, 0x07, 0x07, 0x07, 0x07, 0x07, 0x07, 0x07,
        0x07, 0x07, 0x07, 0x07, 0x07, 0x07, 0x07, 0x07,
        0x08, 0x08, 0x08, 0x08, 0x08, 0x08, 0x08, 0x08,
        0x08, 0x08, 0x08, 0x08, 0x08, 0x08, 0x08, 0x08
    uchar p_code[64] = {
        0x00, 0x20, 0x30, 0x40, 0x50, 0x58, 0x60, 0x68,
        0x70, 0x78, 0x80, 0x88, 0x90, 0x94, 0x98, 0x9C,
        0xA0, 0xA4, 0xA8, 0xAC, 0xB0, 0xB4, 0xB8, 0xBC,
        0xC0, 0xC2, 0xC4, 0xC6, 0xC8, 0xCA, 0xCC, 0xCE,
        0xD0, 0xD2, 0xD4, 0xD6, 0xD8, 0xDA, 0xDC, 0xDE,
        0xE0, 0xE2, 0xE4, 0xE6, 0xE8, 0xEA, 0xEC, 0xEE,
        0xF0, 0xF1, 0xF2, 0xF3, 0xF4, 0xF5, 0xF6, 0xF7,
        0xF8, 0xF9, 0xFA, 0xFB, 0xFC, 0xFD, 0xFE, 0xFF
    /* for decoding */
    uchar d_code[256] = {
        0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
        0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
        0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
        0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
        0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01,
        0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01,
        0x02, 0x02, 0x02, 0x02, 0x02, 0x02, 0x02, 0x02,
        0x02, 0x02, 0x02, 0x02, 0x02, 0x02, 0x02, 0x02,
        0x03, 0x03, 0x03, 0x03, 0x03, 0x03, 0x03, 0x03,
        0x03, 0x03, 0x03, 0x03, 0x03, 0x03, 0x03, 0x03,
        0x04, 0x04, 0x04, 0x04, 0x04, 0x04, 0x04, 0x04,
        0x05, 0x05, 0x05, 0x05, 0x05, 0x05, 0x05, 0x05,
        0x06, 0x06, 0x06, 0x06, 0x06, 0x06, 0x06, 0x06,
        0x07, 0x07, 0x07, 0x07, 0x07, 0x07, 0x07, 0x07,
        0x08, 0x08, 0x08, 0x08, 0x08, 0x08, 0x08, 0x08,
        0x09, 0x09, 0x09, 0x09, 0x09, 0x09, 0x09, 0x09,
        0x0A, 0x0A, 0x0A, 0x0A, 0x0A, 0x0A, 0x0A, 0x0A,
        0x0B, 0x0B, 0x0B, 0x0B, 0x0B, 0x0B, 0x0B, 0x0B,
        0x0C, 0x0C, 0x0C, 0x0C, 0x0D, 0x0D, 0x0D, 0x0D,
        0x0E, 0x0E, 0x0E, 0x0E, 0x0F, 0x0F, 0x0F, 0x0F,
        0x10, 0x10, 0x10, 0x10, 0x11, 0x11, 0x11, 0x11,
        0x12, 0x12, 0x12, 0x12, 0x13, 0x13, 0x13, 0x13,
        0x14, 0x14, 0x14, 0x14, 0x15, 0x15, 0x15, 0x15,
        0x16, 0x16, 0x16, 0x16, 0x17, 0x17, 0x17, 0x17,
        0x18, 0x18, 0x19, 0x19, 0x1A, 0x1A, 0x1B, 0x1B,
        0x1C, 0x1C, 0x1D, 0x1D, 0x1E, 0x1E, 0x1F, 0x1F,
        0x20, 0x20, 0x21, 0x21, 0x22, 0x22, 0x23, 0x23,
        0x24, 0x24, 0x25, 0x25, 0x26, 0x26, 0x27, 0x27,
        0x28, 0x28, 0x29, 0x29, 0x2A, 0x2A, 0x2B, 0x2B,
        0x2C, 0x2C, 0x2D, 0x2D, 0x2E, 0x2E, 0x2F, 0x2F,
        0x30, 0x31, 0x32, 0x33, 0x34, 0x35, 0x36, 0x37,
        0x38, 0x39, 0x3A, 0x3B, 0x3C, 0x3D, 0x3E, 0x3F,
    uchar d_len[256] = {
        0x03, 0x03, 0x03, 0x03, 0x03, 0x03, 0x03, 0x03,
        0x03, 0x03, 0x03, 0x03, 0x03, 0x03, 0x03, 0x03,
        0x03, 0x03, 0x03, 0x03, 0x03, 0x03, 0x03, 0x03,
        0x03, 0x03, 0x03, 0x03, 0x03, 0x03, 0x03, 0x03,
        0x04, 0x04, 0x04, 0x04, 0x04, 0x04, 0x04, 0x04,
        0x04, 0x04, 0x04, 0x04, 0x04, 0x04, 0x04, 0x04,
        0x04, 0x04, 0x04, 0x04, 0x04, 0x04, 0x04, 0x04,
        0x04, 0x04, 0x04, 0x04, 0x04, 0x04, 0x04, 0x04,
        0x04, 0x04, 0x04, 0x04, 0x04, 0x04, 0x04, 0x04,
        0x04, 0x04, 0x04, 0x04, 0x04, 0x04, 0x04, 0x04,
        0x05, 0x05, 0x05, 0x05, 0x05, 0x05, 0x05, 0x05,
        0x05, 0x05, 0x05, 0x05, 0x05, 0x05, 0x05, 0x05,
        0x05, 0x05, 0x05, 0x05, 0x05, 0x05, 0x05, 0x05,
        0x05, 0x05, 0x05, 0x05, 0x05, 0x05, 0x05, 0x05,
        0x05, 0x05, 0x05, 0x05, 0x05, 0x05, 0x05, 0x05,
        0x05, 0x05, 0x05, 0x05, 0x05, 0x05, 0x05, 0x05,
        0x05, 0x05, 0x05, 0x05, 0x05, 0x05, 0x05, 0x05,
        0x05, 0x05, 0x05, 0x05, 0x05, 0x05, 0x05, 0x05,
        0x06, 0x06, 0x06, 0x06, 0x06, 0x06, 0x06, 0x06,
        0x06, 0x06, 0x06, 0x06, 0x06, 0x06, 0x06, 0x06,
        0x06, 0x06, 0x06, 0x06, 0x06, 0x06, 0x06, 0x06,
        0x06, 0x06, 0x06, 0x06, 0x06, 0x06, 0x06, 0x06,
        0x06, 0x06, 0x06, 0x06, 0x06, 0x06, 0x06, 0x06,
        0x06, 0x06, 0x06, 0x06, 0x06, 0x06, 0x06, 0x06,
        0x07, 0x07, 0x07, 0x07, 0x07, 0x07, 0x07, 0x07,
        0x07, 0x07, 0x07, 0x07, 0x07, 0x07, 0x07, 0x07,
        0x07, 0x07, 0x07, 0x07, 0x07, 0x07, 0x07, 0x07,
        0x07, 0x07, 0x07, 0x07, 0x07, 0x07, 0x07, 0x07,
        0x07, 0x07, 0x07, 0x07, 0x07, 0x07, 0x07, 0x07,
        0x07, 0x07, 0x07, 0x07, 0x07, 0x07, 0x07, 0x07,
        0x08, 0x08, 0x08, 0x08, 0x08, 0x08, 0x08, 0x08,
        0x08, 0x08, 0x08, 0x08, 0x08, 0x08, 0x08, 0x08,
    unsigned freq[T + 1];   /* frequency table */
    int prnt[T + N_CHAR];   /* pointers to parent nodes, except for the */
                /* elements [T..T + N_CHAR - 1] which are used to get */
                /* the positions of leaves corresponding to the codes. */
    int son[T];     /* pointers to child nodes (son[], son[] + 1) */
    unsigned getbuf = 0;
    uchar getlen = 0;
    int GetBit(void)    /* get one bit */
        int i;
        while (getlen <= 8) {
            if ((i = getc(infile)) < 0) i = 0;
            getbuf |= i << (8 - getlen);
            getlen += 8;
        i = getbuf;
        getbuf <<= 1;
        return (i < 0);
    int GetByte(void)   /* get one byte */
        unsigned i;
        while (getlen <= 8) {
            if ((i = getc(infile)) < 0) i = 0;
            getbuf |= i << (8 - getlen);
            getlen += 8;
        i = getbuf;
        getbuf <<= 8;
        getlen -= 8;
        return i >> 8;
    unsigned putbuf = 0;
    uchar putlen = 0;
    void Putcode(int l, unsigned c)     /* output c bits of code */
        putbuf |= c >> putlen;
        if ((putlen += l) >= 8) {
            if (putc(putbuf >> 8, outfile) == EOF) {
            if ((putlen -= 8) >= 8) {
                if (putc(putbuf, outfile) == EOF) {
                codesize += 2;
                putlen -= 8;
                putbuf = c << (l - putlen);
            } else {
                putbuf <<= 8;
    /* initialization of tree */
    void StartHuff(void)
        int i, j;
        for (i = 0; i < N_CHAR; i++) {
            freq[i] = 1;
            son[i] = i + T;
            prnt[i + T] = i;
        i = 0; j = N_CHAR;
        while (j <= R) {
            freq[j] = freq[i] + freq[i + 1];
            son[j] = i;
            prnt[i] = prnt[i + 1] = j;
            i += 2; j++;
        freq[T] = 0xffff;
        prnt[R] = 0;
    /* reconstruction of tree */
    void reconst(void)
        int i, j, k;
        unsigned f, l;
        /* collect leaf nodes in the first half of the table */
        /* and replace the freq by (freq + 1) / 2. */
        j = 0;
        for (i = 0; i < T; i++) {
            if (son[i] >= T) {
                freq[j] = (freq[i] + 1) / 2;
                son[j] = son[i];
        /* begin constructing tree by connecting sons */
        for (i = 0, j = N_CHAR; j < T; i += 2, j++) {
            k = i + 1;
            f = freq[j] = freq[i] + freq[k];
            for (k = j - 1; f < freq[k]; k--);
            l = (j - k) * 2;
            memmove(&freq[k + 1], &freq[k], l);
            freq[k] = f;
            memmove(&son[k + 1], &son[k], l);
            son[k] = i;
        /* connect prnt */
        for (i = 0; i < T; i++) {
            if ((k = son[i]) >= T) {
                prnt[k] = i;
            } else {
                prnt[k] = prnt[k + 1] = i;
    /* increment frequency of given code by one, and update tree */
    void update(int c)
        int i, j, k, l;
        if (freq[R] == MAX_FREQ) {
        c = prnt[c + T];
        do {
            k = ++freq[c];
            /* if the order is disturbed, exchange nodes */
            if (k > freq[l = c + 1]) {
                while (k > freq[++l]);
                freq[c] = freq[l];
                freq[l] = k;
                i = son[c];
                prnt[i] = l;
                if (i < T) prnt[i + 1] = l;
                j = son[l];
                son[l] = i;
                prnt[j] = c;
                if (j < T) prnt[j + 1] = c;
                son[c] = j;
                c = l;
        } while ((c = prnt[c]) != 0);   /* repeat up to root */
    unsigned code, len;
    void EncodeChar(unsigned c)
        unsigned i;
        int j, k;
        i = 0;
        j = 0;
        k = prnt[c + T];
        /* travel from leaf to root */
        do {
            i >>= 1;
            /* if node's address is odd-numbered, choose bigger brother node */
            if (k & 1) i += 0x8000;
        } while ((k = prnt[k]) != R);
        Putcode(j, i);
        code = i;
        len = j;
    void EncodePosition(unsigned c)
        unsigned i;
        /* output upper 6 bits by table lookup */
        i = c >> 6;
        Putcode(p_len[i], (unsigned)p_code[i] << 8);
        /* output lower 6 bits verbatim */
        Putcode(6, (c & 0x3f) << 10);
    void EncodeEnd(void)
        if (putlen) {
            if (putc(putbuf >> 8, outfile) == EOF) {
    int DecodeChar(void)
        unsigned c;
        c = son[R];
        /* travel from root to leaf, */
        /* choosing the smaller child node (son[]) if the read bit is 0, */
        /* the bigger (son[]+1} if 1 */
        while (c < T) {
            c += GetBit();
            c = son[c];
        c -= T;
        return c;
    int DecodePosition(void)
        unsigned i, j, c;
        /* recover upper 6 bits from table */
        i = GetByte();
        c = (unsigned)d_code[i] << 6;
        j = d_len[i];
        /* read lower 6 bits verbatim */
        j -= 2;
        while (j--) {
            i = (i << 1) + GetBit();
        return c | (i & 0x3f);
    /* compression */
    void Encode(void)  /* compression */
        int  i, c, len, r, s, last_match_length;
        fseek(infile, 0L, 2);
        textsize = ftell(infile);
        if (fwrite(&textsize, sizeof textsize, 1, outfile) < 1)
            Error(wterr);   /* output size of text */
        if (textsize == 0)
        textsize = 0;           /* rewind and re-read */
        s = 0;
        r = N - F;
        for (i = s; i < r; i++)
            text_buf[i] = ' ';
        for (len = 0; len < F && (c = getc(infile)) != EOF; len++)
            text_buf[r + len] = c;
        textsize = len;
        for (i = 1; i <= F; i++)
            InsertNode(r - i);
        do {
            if (match_length > len)
                match_length = len;
            if (match_length <= THRESHOLD) {
                match_length = 1;
            } else {
                EncodeChar(255 - THRESHOLD + match_length);
            last_match_length = match_length;
            for (i = 0; i < last_match_length &&
                    (c = getc(infile)) != EOF; i++) {
                text_buf[s] = c;
                if (s < F - 1)
                    text_buf[s + N] = c;
                s = (s + 1) & (N - 1);
                r = (r + 1) & (N - 1);
            if ((textsize += i) > printcount) {
                printf("%12ld\r", textsize);
                printcount += 1024;
            while (i++ < last_match_length) {
                s = (s + 1) & (N - 1);
                r = (r + 1) & (N - 1);
                if (--len) InsertNode(r);
        } while (len > 0);
        printf("In : %ld bytes\n", textsize);
        printf("Out: %ld bytes\n", codesize);
        printf("Out/In: %.3f\n", (double)codesize / textsize);
    void Decode(void)  /* recover */
        int  i, j, k, r, c;
        unsigned long int  count;
        if (fread(&textsize, sizeof textsize, 1, infile) < 1)
            Error("Can't read");  /* read size of text */
        if (textsize == 0)
        for (i = 0; i < N - F; i++)
            text_buf[i] = ' ';
        r = N - F;
        for (count = 0; count < textsize; ) {
            c = DecodeChar();
            if (c < 256) {
                if (putc(c, outfile) == EOF) {
                text_buf[r++] = c;
                r &= (N - 1);
            } else {
                i = (r - DecodePosition() - 1) & (N - 1);
                j = c - 255 + THRESHOLD;
                for (k = 0; k < j; k++) {
                    c = text_buf[(i + k) & (N - 1)];
                    if (putc(c, outfile) == EOF) {
                    text_buf[r++] = c;
                    r &= (N - 1);
            if (count > printcount) {
                printf("%12ld\r", count);
                printcount += 1024;
        printf("%12ld\n", count);
    int main(int argc, char *argv[])
        char  *s;
        if (argc != 4) {
            printf("'lzhuf e file1 file2' encodes file1 into file2.\n"
                   "'lzhuf d file2 file1' decodes file2 into file1.\n");
            return EXIT_FAILURE;
        if ((s = argv[1], s[1] || strpbrk(s, "DEde") == NULL)
         || (s = argv[2], (infile  = fopen(s, "rb")) == NULL)
         || (s = argv[3], (outfile = fopen(s, "wb")) == NULL)) {
            printf("??? %s\n", s);
            return EXIT_FAILURE;
        if (toupper(*argv[1]) == 'E')
        return EXIT_SUCCESS;

    back to content page

    N. RSA Data Security, Inc. MD2 Message Digest Algorithm

    This is the RSA Data Security, Inc. MD2 Message Digest Algorithm

    /* ------- start of RSA copyrighted code --------- */
    /* some changes were made by Joachim Schurig 28/04/96 to encapsulate
       the code in PASCAL */
    /*  Copyright (C) 1990-2, RSA Data Security, Inc. Created 1990. All
        rights reserved.
        License to copy and use this software is granted for
        non-commercial Internet Privacy-Enhanced Mail provided that it is
        identified as the "RSA Data Security, Inc. MD2 Message Digest
        Algorithm" in all material mentioning or referencing this software
        or this function.
        RSA Data Security, Inc. makes no representations concerning either
        the merchantability of this software or the suitability of this
        software for any particular purpose. It is provided "as is"
        without express or implied warranty of any kind.
        These notices must be retained in any copies of any part of this
        documentation and/or software.
    typedef uchar MD2barr16[16];
    typedef struct MD2_CTX {
      MD2barr16 state, checksum;
      long count;
      MD2barr16 buffer;
    } MD2_CTX;
     *  Permutation of 0..255 constructed from the digits of pi. It gives a
     *  "random" nonlinear byte substitution operation.
    typedef uchar PI_SUBSTTYPE[256];
    typedef MD2barr16 PADDINGTYPE[17];
      41, 46, 67, 201, 162, 216, 124, 1, 61, 54, 84, 161, 236, 240, 6, 19, 98,
      167, 5, 243, 192, 199, 115, 140, 152, 147, 43, 217, 188, 76, 130, 202, 30,
      155, 87, 60, 253, 212, 224, 22, 103, 66, 111, 24, 138, 23, 229, 18, 190, 78,
      196, 214, 218, 158, 222, 73, 160, 251, 245, 142, 187, 47, 238, 122, 169,
      104, 121, 145, 21, 178, 7, 63, 148, 194, 16, 137, 11, 34, 95, 33, 128, 127,
      93, 154, 90, 144, 50, 39, 53, 62, 204, 231, 191, 247, 151, 3, 255, 25, 48,
      179, 72, 165, 181, 209, 215, 94, 146, 42, 172, 86, 170, 198, 79, 184, 56,
      210, 150, 164, 125, 182, 118, 252, 107, 226, 156, 116, 4, 241, 69, 157, 112,
      89, 100, 113, 135, 32, 134, 91, 207, 101, 230, 45, 168, 2, 27, 96, 37, 173,
      174, 176, 185, 246, 28, 70, 97, 105, 52, 64, 126, 15, 85, 71, 163, 35, 221,
      81, 175, 58, 195, 92, 249, 206, 186, 197, 234, 38, 44, 83, 13, 110, 133, 40,
      132, 9, 211, 223, 205, 244, 65, 129, 77, 82, 106, 220, 55, 200, 108, 193,
      171, 250, 36, 225, 123, 8, 12, 189, 177, 74, 120, 136, 149, 139, 227, 99,
      232, 109, 233, 203, 213, 254, 59, 0, 29, 57, 242, 239, 183, 14, 102, 88,
      208, 228, 166, 119, 114, 248, 235, 117, 75, 10, 49, 68, 80, 180, 143, 237,
      31, 26, 219, 153, 141, 51, 159, 17, 131, 20
    Static boolean PADDINGOK;
    /* must be initialized with FALSE at program startup (Joachim Schurig) */
     *  initializes the padding tab, cannot be assigned directly in PASCAL code
     *  added by Joachim Schurig
    Static void init_padding(void)
      short x, y;
      PADDING[0][0] = 0;
      for (x = 1; x <= 16; x++) {
        for (y = 0; y < x; y++)
          PADDING[x][y] = x;
      PADDINGOK = true;
    /* MD2 initialization. Begins an MD2 operation, writing a new context. */
    Static void MD2Init(MD2_CTX *context)
      if (!PADDINGOK)   /* added for PASCAL */
      context->count = 0;
      memset(context->state, 0, sizeof(MD2barr16));
      memset(context->checksum, 0, sizeof(MD2barr16));
    /* MD2 basic transformation. Transforms state and updates checksum based on block. */
    Static void MD2Transform(uchar *state, uchar *checksum, uchar *block)
      long i, j, t;
      uchar x[48];
      /* Form encryption block from state, block, state ^ block. */
      memcpy(x, state, 16);
      memcpy(&x[16], block, 16);
      for (i = 0; i <= 15; i++)
        x[i + 32] = state[i] ^ block[i];
      /* Encrypt block (18 rounds). */
      t = 0;
      for (i = 0; i <= 17; i++) {
        for (j = 0; j <= 47; j++) {
          t = x[j] ^ PI_SUBST[t];
          x[j] = t;
        t = (t + i) & 0xff;
      /* Save new state */
      memcpy(state, x, 16);
      /* Update checksum. */
      t = checksum[15];
      for (i = 0; i <= 15; i++) {
        t = checksum[i] ^ PI_SUBST[block[i] ^ t];
        checksum[i] = t;
      /* Zeroize sensitive information. */
      memset(x, 0, sizeof(uchar) * 48);
     *  MD2 block update operation. Continues an MD2 message-digest
     *  operation, processing another message block, and updating the
     *  context.
    Static void MD2Update(MD2_CTX *context, uchar *input, long inputLen)
      long i, index, partLen;
      /* Update number of bytes mod 16 */
      index = context->count;
      context->count = (index + inputLen) & 0xf;
      partLen = 16 - index;
      /* Transform as many times as possible. */
      if (inputLen >= partLen) {
        memcpy(&context->buffer[index], input, partLen);
        MD2Transform(context->state, context->checksum, context->buffer);
        i = partLen;
        while (i + 15 < inputLen) {
          MD2Transform(context->state, context->checksum, (uchar *)(&input[i]));
          i += 16;
        index = 0;
      } else
        i = 0;
      /* Buffer remaining input */
      memcpy(&context->buffer[index], (uchar *)(&input[i]), inputLen - i);
     *  MD2 finalization. Ends an MD2 message-digest operation, writing the
     *  message digest and zeroizing the context.
    Static void MD2Final(uchar *digest, MD2_CTX *context)
      long index, padLen;
      /* Pad out to multiple of 16 */
      index = context->count;
      padLen = 16 - index;
      MD2Update(context, PADDING[padLen], padLen);
      /* Extend with checksum */
      MD2Update(context, context->checksum, 16);
      /* Store state in digest */
      memcpy(digest, context->state, 16);
      /* Zeroize sensitive information */
      memset((uchar *)context, 0, sizeof(MD2_CTX));
    /* ------- end of RSA copyrighted code ------- */
    void calc_MD2_pw(Char *MD2prompt, Char *MD2pw, Char *MD2result)
      MD2_CTX context;
      MD2barr16 digest;
      short i, n, len;
      long bc;
      Char c1, c2;
      uchar *buffp;
      Char buff[256];
      short FORLIM;
      buffp = buff;
      bc = 0;
      FORLIM = strlen(MD2prompt);
      for (i = 0; i < FORLIM; i++) {
        buffp[bc] = MD2prompt[i];
      FORLIM = strlen(MD2pw);
      for (i = 0; i < FORLIM; i++) {
        buffp[bc] = MD2pw[i];
      buffp[bc] = 0;
      len = bc;
      i = 0;
      while (i < len) {
        if (len - i > 16)
          n = 16;
          n = len - i;
        MD2Update(&context, (uchar *)(&buffp[i]), n);
        i += 16;
      MD2Final(digest, &context);
      MD2result[0] = '\0';
      for (i = 0; i <= 15; i++) {
        int2hchar(digest[i], &c1, &c2);
        sprintf(MD2result + strlen(MD2result), "%c%c", c1, c2);
    void calc_MD2_prompt(Char *MD2prompt)
      short x;
      Char c;
      MD2prompt[0] = '\0';
      for (x = 1; x <= 10; x++) {
        do {
          c = dp_randomize(48, 122);
        } while (!isalnum(c));
        sprintf(MD2prompt + strlen(MD2prompt), "%c", c);