home    builders    Search

builders ➜ Bulletin Board System

BBS on your PI

Every Raspberry PI in the network includes G8BPQ BBS software called LINMAIL. Every node should have this turned on. If you are commissioning a new node, see below for Configure the BBS.

The bulletin board system (BBS) lets you enter messages to and receive messages from other stations in the packet network. Messages are sent and delivered as text but can include binary messages encoded with uuencode. More on uuencode later.

The BBS devices enable email-type messages to be automatically moved from one's own station to the destination station and for broadcast messages to be moved from one's own station to a selection of other destinations. The destinations must be in the packet network but messages can be moved over links which are only transiently available. This is very handy for power-loss or power stingy operations, when network links are only selectively available.

The knowledge of how to configure and operate the BBS software could be of great value if we had to deploy a network in support of some emergency operation.

While you are entering messages to be sent, the connection is entirely within your LAN and your Raspberry PI, so responsiveness is quick. When you read a message on your Raspberry PI, received from another station, you are again seeing the message from the Raspberry PI to your display without over-the-air delays. Messages can be 10K in length if needed, though that will take 5 minutes of network time to transfer. Individual messages are addressed by callsign.

We have the ability to send global messages such that every packeteer in our network receives the message. Global messages are called Bulletins in this system.

Each BBS in the network is hand maintained to know how to move messages toward their destination. This isn't Internet, but it is workable. TARPN-HOME users connected with a full-service web browser (i.e. not a cell-phone browser) will receive notification via an audible alert and an icon on the upper right of the display.

TARPN-HOME operates the BBS for the most common user functions from the BBS tab and can view the message list, send or read messages. A ham can also connect to their own or another node's BBS by connecting to the node command processor, where NODES and C OTHER commands would work, and typing BBS. The BBS will respond with some text and then a > prompt. The user can now type one of several different commands.

For textual UI access to the BBS, go to TARPN-HOME or BPQtermTCP. In TARPN-HOME, click on the Node tab and then make sure the switch is in the green position. In BPQtermTCP connect using the Connect menu. Type BBS return. bbs_from_tarpn_home

Using the BBS via Text Interface

HELP is a good first command.
Here are the common commands:

sp callsign send-personal. This will start an email to go to some other station on the packet network. If things are configured correctly, the file will be saved locally and will then be forwarded across the network to the BBS operated by the callsign. sb name@cncnc send-bulletin of topic name to everybody in the Central North Carolina Network. This is like SP but instead of going to the destination and being deleted locally, this will leave a copy locally and will attempt to leave a copy on every BBS in the region CNCNC. The region is specified by which neighbors get a copy and that is set in the Forwarding web page of each BBS. If things are configured correctly, the file will be saved locally and will then be forwarded across the network to every BBS within the region. We can have different regions as agreed upon by the group.
lm list mine will lists your messages.
ll 100 lists the last 100 messages.
r # reads message whose number is #.
k # marks a message for deletion. This actually just marks the message as status K. The automated housekeeping will come along on schedule and delete the message.
files requests a list of the files stored on the BBS by the owner. This does a directory of the files in the /home/pi/bpq/Files folder. Note the capital F in the filename.
read filename requests a file from the /home/pi/bpq/Files folder.

Forwarding Routes

LINMAIL has a process which watches the clock and watches what messages are put into the BBS. When the time is right or a message with the appropriate addressee and status shows up, the BBS will do a forwarding process. This is the operation which causes messages to be copied from the BBS to some other BBS. In the TARPN network, all stations with a unique callsign are potentially BBSs. Ideally all of them are but in reality some of the stations are unsupervised. Some stations don't have a unique callsign. Right now, every node builder in the network has only one BBS. So if a node builder has two nodes, only one of them will have the BBS.

For every BBS on the network, there are a selection of stations which are neighbors. A neighbor would ordinarily be the first BBS your connection would pass on the way to some destination. One of the configuration steps is to specify forwarding configs, each of which specifies forwarding routes to a neighbor BBS. Each BBS has the ability to have a user entry for each node operator in the network. Initially, though, the BBS will only have an entry for the neighbor nodes (i.e. one hop away over the network) and that entry will enable forwarding of personal messages, bulletins, and traffic messages. MSGTYPES PBT9999
With experience, the operator will add personal message forwarding and traffic message forwarding to every BBS they can keep track of. MSGTYPES PT9999
Bulletins will get forwarded in a flood going from each BBS to each of the neighbors, across every link from a node. Then those stations continue to propagate the bulletins. There's no really good reason to forward a bulletin past a working neighbor BBS since that neighbor will also flood out its ports. The idea is that no message should travel over the same link twice. Bulletins are replicated and often a copy will remain at every station that handles them, for 3 months or more, and this is good as they may be read by each operator along the way, at their convenience. Personal messages, on the other hand, will not be replicated. Usually a personal message is automatically deleted at the end of the day, by the BBSs that handle them, except for the destination BBS which will hold it until the operator kills it or some long (month or months?) timeout.

In some areas of the network, there will be a number of choices for setting up outbound forwarding. To get started, consult the neighbors and see what they recommend. If you are enthusiastic about managing BBS traffic for maximum efficiency, you will develop systems of your own, and that's great. Work with your neighbors on a plan.

Beyond the immediate neighbors, the user table must include every BBS which would be forwarded to or from which forwarding may be received. For the sake of keeping it simple, you can start with just the neighbor nodes, and then add additional users if requested by other operators.

You need to specify every node-op callsign in your geographic region in the TO field for some BBS, possibly just a neighbor. That way every message that comes into your BBS can be made to continue on its way to reach its destination. If you left somebody out, messages could get stuck on your BBS. This isn't really a massive concern until you are a multi-port node and will have BBS traffic passing through your system. If you are a new node with only one link neighbor, the neighbor can come up with a list of all of the callsigns they are dealing with, and you can paste that list into the TO field for the forwarding screen addressing your link neighbor. That way, every message you need to send from your BBS will be forwarded to your neighbor, then on to that BBS's neighbor, and so on. Any time a new node op in your geographic area comes on-line, you'll add that station's callsign (without a -ssid) to the TO field of the forward table addressing your neighbor.

In the long term we'll use a hierarchical forwarding system where an operator may send a message to a BBS in another geographic region without having the specific BBS configured as a forwarding target. There are some systems we don't have documented, but which are part of LINMAIL, and which would allow us to do hierarchical addressing and automated support for new BBSs outside of our geographic area.

On the Forwarding page you will have a place to specify the node connect script which your BBS will use to connect to each of your neighbors. The collected sequence of scripts which take traffic to each distant neighbor would be called a forwarding route. In this example my BBS is asked to connect to the neighbor node.

Configure the BBS - :7777 web page

Bring up a web browser and dial in your Raspberry PI's IP address followed by :7777

The page you bring up with be the BPQ32 Node page which has several useful links. What we're concerned with right now is the Mail Server Pages. So click there.

Mail Server Pages will bring you to a log-in prompt. Fill in your callsign and then the letter p for your password.


Main Configuration page

Click on Configuration Page link. get to configuration page

There are many things on this page that we might play with in the future.
The critical things to adjust are:
Leave the reset of the settings blank.
The BBS program will not start until the configuration page has been finished. Do the changes here to set up your BBS, and then do a tarpn kill to restart the node and BBS.

Set things on configuration page

User Pages

Click to the User page link so we can set up your forward partners.

A user page must be created for every link neighbor and possibly some additional network participants. This is so you can configure them to be BBSs, allowed to forward mail to your BBS and to automate forwarding mail to theirs.

Go down to the bottom of the user page and enter each callsign next to the Add button, and then click Add. add-user-example

A list of the users you have added, plus your own callsign, will be built on the left in a single column. For a brand-new single-port TARPN node, you might have only one user along with yourself. The BBS will have automatically created your own entry in the User list. Once you have all of your neighbor callsigns entered, click on the left on each user(neighbor), except yourself, and sequentially do these steps:

bbs_user_otherThis image represents the page for every neighbor BBS.

For your own user, go back and checkbox

The other boxes are unchecked. We're going to use the EXPERT flag to select a special Welcome Message for your connects. At one point I thought filling-in the password field would help in some way, but I haven't seen a need for it yet. Similarly the QTH and ZIP fields don't seem necessary, so far.

bbs_user_meThis image represents the page for your callsign.

Set up Forwarding

Note: The list of all callsigns on the NCPACKET network is available on the WIKI here:

Forwarding is the process where mail is moved from one BBS to another. If you type a message into your BBS addressed to some callsign, the BBS can take action to forward it to the next BBS down the chain toward the BBS and node operated by that callsign. Your BBS will receive messages both to your callsign, and for which you are the next BBS in the chain toward the destination.

What we're going to do is set up forwarding from your BBS to each of your neighbor BBSs. For some nodes this will only be one neighbor. Others might have four or five that must be set up. You can only forward to BBSs which have you set as a BBS. To keep things simple, we can limit this to just neighbors. But do as you will and have fun. It is worth experimenting to learn the system.

The BBS software creates a web page for forwarding, for each station which you have marked as a BBS. There is even a page for your own callsign. Don't mess with that one. It is left blank.

Important note: Before configuring forwarding to another BBS, make sure they have your callsign configured with the BBS check-box.

Test another BBS to see if you can forward to it

Use the Node pane of TARPN-HOME or BPQtermTCP or other UI, and connect over the network to your BBS forwarding target and check. The clue that they have you properly configured is that if you connect to their BBS by keyboard, and do the following process, you will get the > response at the end, only if they have you set up as a BBS.
My tx:c node
expect*** Connected
My tx:C BBS
expect} Connected to BBS
My tx:[BPQ-$]
My tx:; MSGTYPES  P9999 Use two spaces between MSGTYPES and P9999
expect>If you are not set up as a BBS, you won't get the > here
My tx:sp w1aw < YOURCALLUse your callsign here
expect** < can only be used by a BBSIf your callsign is not known as a BBS, you could see this.
If you do forwarding to a BBS that does not have you set up properly, it can end up in an endless loop, tying up the network links from your node to the target BBS. If you do get into that infinite loop, the way to kick it is to restart your node with tarpn kill issued at a Linux prompt.
For each neighbor BBS you will want to list all of the callsigns of the network participants which are, from your perspective, in that direction. If you are a Terminal node, i.e. only one link, and if your one neighbor has a BBS, then you will add every callsign in the network, except your own, to the TO field of that neighbor. Here is a for instance from my BBS (note: where the image differs from the text. use the text):


Welcome Msgs & Prompts

This page sets the messages and prompts an incoming user (including yourself) will see. Our plan is to use the EXPERT messages for your connects. Normal users are the remote BBSs. New Users will be any random station which connects.
These messages are presented as typed, but the dollar figures are replaced with numerical or text values as described at the bottom of the web page.

There are a few subtle changes to be made here.
The Expert User Welcome and Expert User Prompt are used by TARPN-HOME and that text will automatically be set when your node starts up. This must have the text
$x unread>>>>  new-msgs=$x   Hello Boss
You, the BBS owner operator, are the only person who will see this text. The reason for the exact text is that scripting on your Raspberry PI will use that text and the number which gets filled into the $x to set or clear alerts including on TARPN-HOME.
You can put whatever you want in the New User Welcome and Normal User Welcome except that the message must end in a carriage return and must not contain a left or right square bracket, or a >
You can put whatever you want in the New User Prompt and Normal User Prompt except that the message must not contain square brackets, and it must end with a >
All three prompts must end in a >
The sign off message can also be anything you want but keep it short.

Visiting stations may come looking for your Files. Don't be too offensive. Your neighbors are all BBSs and will see the messages for "Normal Users". New Users are the visitors from elsewhere in the network.

Set up Housekeeping

Click on the Housekeeping link.

Housekeeping runs once a day and cleans up messages which are no longer needed on your BBS. Messages which are Killed from the command prompt of your BBS are not actually deleted immediately, they are just marked with a K status. Housekeeping can then go and delete those K messages when Housekeeping runs. In addition you can have housekeeping take care of out-of-date messages of various kinds. Change the Unread number to 180. Change the Personals Forwarded number to 1.

Notice on the left of the screen there is a checkbox that says Suppress Mailing of Housekeeping Results. Housekeeping can send you (the BBS operator) a message every time Housekeeping runs to tell you what it did. This might be a good thing for the first month or so of BBS operation but eventually it is a pain. So leave this checked until you see it go a few times and then when you want to, check the box next to Suppress Mailing of Housekeeping Results.

Don't forget to click Save.


background features

The TARPN scripts leave a couple of files available for further development. In the /usr/local/etc directory on the Raspberry PI are a couple of BBS status files which may be interesting. These are the bbshasmail.txt file and the bbsunreadmessagecount.txt file.

bbshasmail.txt has the value NO_MAIL_FOR_YOU or BBS_HAS_MAIL. You can use a BASH script to check on this and report via GPIO or some other artifice. Here is an example script:

echo "21" > /sys/class/gpio/export              ### this establishes that gpio-21 is going to be active
echo "out" > /sys/class/gpio/gpio21/direction   ### drive a high 3.3v OR a low of 0v to this pin.
echo "0" > /sys/class/gpio/gpio21/value         ### This starts us out with a low
while[ 1 ];                                     ### loop forever, or until you ^C out of this script.
   if grep -q "BBS_HAS_MAIL" /usr/local/etc/bbshasmail.txt; then  #### see if the file says there is mail
       echo "1" > /sys/class/gpio/gpio21/value                    #### there is mail. Set GPIO21 high
       echo "0" > /sys/class/gpio/gpio21/value                    #### no mail.  GPIO21 goes low
sleep(1);   ### don't forget the sleep, else the script will try to use all of the CPU
Save this script by copying it from this page, then in your terminal program at the Linux prompt type:
cat > bbsgpio.sh <enter>
Then paste the script in, and finally do control-D to close out the CAT. Now set the permissions to "executable" by
chmod +x bbsgpio.sh <enter>
and finally, execute it by
./bbsgpio.sh <enter>
Now use a volt meter between a ground pin and gpio 21 to see if there is mail. You can hook an LED up to the pin through a resistor, or find a relay to let your big 12v supply drive some 12V lights. That circuit is left to another conversation.
By the way.. the background feature that sets the you-have-mail or not only checks every 30 seconds or so, and the BBS program doesn't record that there is mail until the sending station disconnects. So, if you are sending yourself a SP message to test this, make sure you disconnect before panicking.

Links to More Info

The author of the BBS program we're using, G8BPQ, published this note about setting up forwarding

Hank W0RLI (?-2013) was the author of the first successful packet radio BBS system.
Here is the W0RLI BBS SPEC 12-Oct-1998.pdf (tarpn mirror) W0RLI wrote about the BBS to BBS forwarding operation.

Northern Oregon Packet Radio Association has much W0RLI info

Commands from W0RLI BBS are close to what G8BPQ's BBS looks like.

© Tadd Torborg, 2017↝2022 -- all rights reserved