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 neighbor BBS.|
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 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.Important note: Before setting up forwarding to another BBS, 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.
The most important is the text for the Expert User Welcome.
This must have the text unread=%x .
That's unread equals percent lower-case x and four spaces, followed by whatever text you like.
You, the BBS owner operator, are the only person who will see this text.
The reason for the exact unread equals percent lower-case x is that one part of the scripting on your Raspberry PI will use that text and the number which gets filled into the percent x to set or clear alerts including on TARPN-HOME.
You can put whatever you want in the Welcome messages except that the message must end in a carriage return and must not contain a left or right square bracket, or a greater than. The prompts must end in a greater than. 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.|
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.
#!/bin/bash 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. do 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 else echo "0" > /sys/class/gpio/gpio21/value #### no mail. GPIO21 goes low fi sleep(1); ### don't forget the sleep, else the script will try to use all of the CPU doneSave this script by copying it from this page, then in your terminal program at the Linux prompt type:
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.