The bulletin board system 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, or 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. Messages from your Raspberry PI to another Raspberry PI are fully delivered and verified to have been fully received before they are marked as sent on the originator end. 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. Eventually we'll have some sort of notification that messages have been received. It would be pretty easy to light a light with a GPIO on the Raspberry PI, or have an icon on TARPN-HOME to indicate messages waiting.
A user connects to their own BBS by connecting to the node command processor, where NODES and C OTHER commands would work. The user then types BBS. The BBS will respond with some text and then a > prompt. The user can now type one of several different commands.
From TARPN-HOME, go to the Node pane. Just type K return and then BBS return.
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.
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. For the time being, every node operator in the network is listed as a user of every BBS in the network. That being the case, every node operator in the network could potentially be a forwarding destination for every BBS in the network. For the sake of keeping it simple, we're only requiring that every BBS op have some destination for the personal mail of every station in the network. They don't have to specify a forwarding route for every station. In addition, if you specify a forward route which does not work, you could be in the unenviable position of locking up somebody's personal mail, by accident of not keeping up with changes in the network. It's probably better to send mail toward the destination, and not all the way there, if you are in any doubt of keeping up with network changes and network status out side of your immediate 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.
|This image represents the page for every callsign in the network except for your callsign.|
For your own user, go back and checkbox
|This image represents the page for your callsign.|
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 actually forward to every BBS in the network if you wish but the amount of detail starts growning. Ideally you will have more than just your neighbors.Important note: Before setting up forwarding to your neighbor, make sure they have your callsign configured with the BBS check-box. 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 your packet link to that neighbor. The clue that they have you properly configured is that if you connect to their BBS by keyboard, you should see a message that looks like this:
There are a few subtle changes to be made here.
Delete the Expert User Welcome.
That should be totally blank.
Change the Expert User Prompt to $U de yourcallsign. That way if somebody observes BBS forwarding going on across their node in BPQtermTCP, they can tell what is happening.
The Normal User Welcome needs to include the text $x unread messages for because the TARPN-HOME application will depend on it.
|Visiting stations (all of whom are automated) get a very short prompt and no welcome message.|
Housekeeping runs once a day and cleans up messages which are no longer needed on your BBS. This mostly only affects your system. Messages which are Killed from the command prompt of your BBS are not actually deleted, they are just marked with a K status. Housekeeping can then go and delete those messages every day 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.
Hank W0RLI (?-2013) was the author of the first successful packet radio BBS system. Northern Oregon Packet Radio Association has much W0RLI info including this specification he wrote about the BBS to BBS forwarding operation.
Commands from W0RLI BBS are close to what G8BPQ's BBS looks like.