Packet Radio Mail Forwarding and Routing for BPQ

This is by far the most painful portion of the packet radio journey. As we get more feature specific in the packet radio rabbit hole, there’s less and less useful documentation. At the point of writing, there are almost no definitive BPQ resources for a simple Mail Network Topology or Point A->Z of node-to-node mail forwarding with correct addressing, and explanations of why things the way they are. Just fragmented pieces you have to put together yourself. I made this page to serve as a primer and example for message handling, forwarding, routing, and connection scripts. BPQ is one amazing piece of software, and does A LOT. I just wish the documentation was modern, consistent, and complete. Even after consuming examples, and documentation for hours, I still find myself having to throw stuff at wall to document what sticks.

Short Rant about Packet BBS and Mail Forwarding Knowledge Sharing

I was born in 1995. The glory days of packet radio, BBS, and RF connected networks were unfortunately before my time. I don’t have the assumed knowledge that most of the published or written information assumes I do. The assumed knowledge and conflicting information in packet radio documentation, and even abbreviated terms that haven’t been used since the 80’s have made this portion of the packet radio guide a complete nightmare to piece together.

I make this point because I don’t like to talk about things I simply don’t fully understand. I like to know all of the details about how things work when I present information. If I make mistakes here, kindly correct me in the comments, and give an explanation so we can share it with the rest of the world.

Basic Terminology

These are concepts that you will need to know to get a better idea of how mail works in BPQ, and packet in general. Yes, to those around the scene for a while this stuff may seem obvious. But this is where the major knowledge gap lives.

• BBS Call
  This callsign is your packet nodes “hostname” in modern speak. The BBS Call is used to find your node on a packet network. Yes, it is typically the system operators (your) amateur radio callsign, without any SSID attached to it. It makes up the first portion of nodes hierarchical route, which we will talk about in just a moment.
• SYSOP Call
  This callsign has less technical implications and serves as info to your node users as to where they may direct messages to someone who manages the BBS node. Unless someone else is managing your node, this would be your callsign as the node owner.
• Streams
  A term in BPQ that seems to be a way to limit concurrent connections? I typically set mine to 10.
• Bulletin (Bulls in BPQ)
  Although it may seem obvious, on top of BPQ offering mail between individuals it also hosts bulletins (who would have known). But for those of you my age, the term comes from when public pieces of information were shared on physical bulletin boards for all to see and read. In BPQ, they are called “bulls”,and are part of the mail application. They are sent using the (B) type message code.
• HomeBBS
  This is the complete node address of where a user typically checks their mail and is used for message routing and forwarding purposes. We talk about that more below. Just know that for a message to be routed/forwarded to a different node for that user, they must specify a HomeBBS, or it must be specified for them if the sender doesn’t use the full node address in the “to” line of a message. (More on that in a moment).
• WhitePages (WP in BPQ)
  White pages is the telephone book for users of a BPQ packet radio network. White pages tell you where a user typically checks for mail and resides (Their HomeBBS), as well as other information that user may have shared. You can use the command “i CALLSIGN” in bpq32 mail application to see this information. White pages on a BPQ node are generated by the housekeeping system. On the main configuration page, we can specify destinations to send our white pages to so they can be shared with others in the format “WP@OTHERNODECALL”, and also reject white pages sent from other nodes.
• Message Types (B(ulletin),P(ersonal) and T(National Traffic System))
  You will see 3 message types in BPQ with different codes for each.
  P is for personal and is a message for an individual.
  B is for bulletin, and is addressed to a category to be shared with others. The Category is limited to 6 characters and indicates the nature of the message.
  T(NTS) can be read by any user, and are addressed to a zipcode/state like so: 40475@NTSKY
• Message Status Codes:
  You will encounter several message status codes that indicate the current stage in the messages lifecycle. (N) means the message has not been delivered or read. (Y) means the message has been read. (F) means the message has been forwarded to another BBS. (K) Means the message has been “killed” by housekeeping. (H) means the message has been held (usually an administrative action). (D) means the message has been delivered (for NTS Messages). ($) for a bulletin pending delivery to an addressed BBS.
• RMS(Radio Message Server)
  A term to describe a radio enabled server that connects to a Winlink CMS(Common Message Server) for external email messaging. An RMS is a station that bridges the gap between radio and the winlink cloud server. When “Poll RMS” is checked, it is really polling a CMS, not an RMS for new Winlink Messages.
• FBB (Mail Config Option: Enable FBB UI System)
  (Thanks for a commenter Stephan for this one)
  FBB is another BBS software from F6FBB. It allowed for sending lists of messages to other nodes or users in an unproto(unconnected) state. This is useful for letting users know that they may have messages waiting at your BBS without actually connecting to it. I don’t use this function, and not many people do anymore unless they are running older BBS software or FBB supported BBS systems. When configuring this option, “MailFor” is for sending an alert for a PM(Personal Message). “Headers” is for a bulletin list, and “Empty Mail For” is for sending an alert to state “No Personal Mail”

Hierarchical Route (H Route in BPQ)

This is the “domain” where your node lives. The BBS packet network uses these addresses for routing, forwarding and addressing in general. Every node has an address on the packet network in a “Hierarchical” format based on region. The region is broadest on the right side of the route and gets more specific as you move to the left side until you end up with your NODE Call. Think of your nodes full address as an internet URL that you would use to get to a specific website. The reason that we use regions is because without DNS, we must rely on mail forwarding of other nodes, and the region on the message address to determine the best place to forward a message to so that it reaches a destination. Those who have worked with windows active directory might find the concept similar to domain forests.

Examples:

The most common format for a hierarchical address in the USA is like the following:
#REGION.STATE.COUNTRY.CONTINENT
An example of my own nodes hierarchical address that is located in eastern Kentucky, is the following:
#EKY.KY.USA.NOAM
My nodes full address then, is the NODE Call + the Hierarchical Route (much like referring to a computer on a domain)
KN4MKB.#EKY.KY.USA.NOAM
And this full address makes up the “domain” (right portion) of a node users “email address” (modern speak).

For example, if K2FTS (a user) has declared my node (KN4MKB.#EKY.KY.USA.NOAM) their HomeBBS, and typically checks for mail there, they would have users on other nodes elsewhere use the address “K2FTS@KN4MKB.#EKY.KY.USA.NOAM” to send them mail, so that it can be forwarded to, and checked on the KN4MKB node.

Implied Portions

Even when unspecified, all Hierarchical Routes have “.WW” on the end of them, which stands for Worldwide. As most of us are here on earth, this only matters when you intend of sending messages globally. A message to @NOAM is assumed to be @NOAM.WW. This point is more relevant when we talk about bulletin forwarding.

There is no “right” answer on what a hierarchical route should look like in a private packet network, though you should follow the above standard for your best chance of success when working with other users. I say that so you don’t get upset if you don’t see exactly online what the region for your state may look like. It just may be that you are the only one out there, so follow the standards and others will follow.

Forwarding Example between Two Nodes

In order for a user of one BBS node to get messages from the user of another BBS, (a simple message forwarding example) using full addresses, a few things must be true.

Users Tab

The BPQ node which is being used to send the message (the sender is using and logged into) must have a “User” record with the other nodes node call as a username, as well as the “BBS” option checked in its user settings.

Forwarding Tab

In the “Forwarding” section of BPQ within the sending node(again the one sender is using to send the message), the entry of the user from the point above must have the “BBS HA” field filled out with the full address of the destination node (NODECALL.#HIERARCHICAL.ROUTE). An Example for a Node, K2FTS located in central Texas might be “K2FTS.#CENTX.TX.USA.NOAM” .

The “Enable Forwarding” option in the record should be enabled, and “Request Reverse” option should optionally be checked, so that the user on the destination end can potentially reply with the senders full address. Checking the option “Send new messages without waiting on the poll timer” will make it so that the time period in seconds for the intervals does not have to go by before the message is forwarded to the other node.

For a simple two node system, you can place “WW” in the Personals and Directed Bulls to have all personal messages and directed bulletins forwarded between the two nodes correctly. In a system with more than 2 nodes, your forward rules under “Personals and Directed Bulls” should start to narrow down the address to increase the chance of a message going to the right region. For example, if K2FTS is the only node I have linked in Texas, I should probably have something like “TX.USA.NOAM” in it’s “Personals and Directed Bulls” rules. That will forward all mail destined for Texas to the node that I have a link with down there. From there, that node may or may not be able to get the message to the end destination. The point is, we did our job in getting it to the next best spot.

A “Connect Script” should be entered in the Forwarding section of BPQ for the user record created above (again within the sending node) that will connect to the receiving nodes BBS SSID . The node you intend on connecting with to forward messages must be in your ROUTES.
If I have AXIP on port 2, and have a node to node link on that port with the destination node, K2FTS, and K2FTS is running a BBS on K2FTS-11 for example, my connect script can be:
C 2 K2FTS-11
Optionally, if you can only reach the destination node call, and not the BBS CALL SSID, your Connect Script could be something like
C 2 K2FTS-7
BBS
The point is, you can use your imagination on what it may take to connect to another BBS node. We will expand on this in the script section below, but bear with me here now.

Sending a Message to a User on another Node

The sender should address the message to the destination user with the following format:
DEST_USER@FULL.DESTINATION.NODE.ADDRESS. If I wanted to send a message from my node in Kentucky that has a Node to Node link with another node, K2FTS (which is set up to forward mail to) as above, in Central Texas to a user KD2UCJ, I would send the message to:
KD2UCJ@K2FTS.#CENTX.TX.USA.NOAM

Ideally, those same settings would be setup in reverse for the other node (K2FTS) to forward back to my own (KN4MKB).

If the user you are sending a message to has an account on the sending node, and also has a “HomeBBS” set, messages sent to that user callsign will automatically get their @HomeBBS added after the callsign, so that the messages is forwarded for them.

Going Forward with Advanced Message Handling

This was an example of how routing and forwarding works in practice between two nodes. If you want to build on this, Hierarchical addresses can be used to decide what node in your routes should handle what messages you receive. With this topology, we can work together to get messages where they need to go globally.

Let’s say I have 3 nodes in my routes.
I live in Kentucky, and my node is NODE1.#EKY.KY.USA.NOAM.
I have a node I can communicate on VHF in Central Kentucky at NODE2.#CKY.KY.USA.NOAM.
I have another node I can communicate with on HF in Florida at NODE3.#NFL.FL.USA.NOAM.

I should forward all messages that aren’t destined to my node, but still have KY in their address to NODE2.#CKY.KY.USA.NOAM. Perhaps that node can hopefully get the message to it’s destination. It’s the best chance given that’s the only other node in KY I can get them to when they aren’t addressed to my own. I can do that by adding KY.USA.NOAM in the personal and directed bulls block for that nodes forwarding entry. If I am the only node in Eastern Kentucky that they have a link with, they should have an entry to forward all #EKY.KY.USA.NOAM messages to myself.
If I am the only node they have a link with, they should have “WW” as an entry for me, so that ALL messages they get (not destined for their own node) go to me, in the hopes I can get them closer.

I should do something similar for the node in Florida that I have a link with. There’s a good chance that’s the only Florida node I have an entry in my routes table for, so I will have a forward entry for this node to send all messages that have FL.USA.NOAM in their address to NODE3.#NFL.FL.USA.NOAM. Lets assume that NODE3.#NFL.FL.USA.NOAM has a link in Central Florida as well NODE4.#CFL.FL.USA.NOAM (But we don’t know that), just for the below example.

So whats the end result?

A user logs into NODE2.#CKY.KY.USA.NOAM in central Kentucky, and wants to send a message to a friend who lives in central Florida. This friend has set his HomeBBS to a node, NODE4.#CFL.FL.USA.NOAM, and it has propagated through the white pages form node to node. So the sender checks the whitepages for his friends HomeBBS by issuing the command “i FRIENDSCALL”, and sees his home BBS is NODE4.#CFL.FL.USA.NOAM.

He sends a message to FRIENDSCALL@NODE4.#CFL.FL.USA.NOAM in hopes it will make it to it’s destination at the node in central Florida. The node he is using, NODE2.#CKY.KY.USA.NOAM has one forwarding partner, so it’s WW entry for NODE1.#EKY.KY.USA.NOAM, causes it to forward the message there, as it’s the only place it could go. (It’s best Hope).

NODE1.#EKY.KY.USA.NOAM gets the message, and due to it’s forwarding rules, determines the best match would be to send the message to NODE3.#NFL.FL.USA.NOAM over HF, as that’s it’s only forward rule for messages with FL (Florida) in the address.

NODE3.#NFL.FL.USA.NOAM gets the message, and sees it’s destination NODE4.#CFL.FL.USA.NOAM is actually in it’s forwarding rules directly, so it forwards the message to the final node. The user logs into NODE4.#CFL.FL.USA.NOAM over VHF in central Florida, and can read the message from his/her friend.

General Rules of Thumb and Tips

It’s generally good to have at least one forwarding partner with “WW” under “HR (Personal and Directed Bulls)” in a single node forward. Although this is implied in BPQ if an HA is given, by putting “WW” by itself, you are designating a “default route” if no messages matches any other rule. This makes sure messages don’t get held up with nowhere to go. You are passing it to someone in hopes they can get it closer to the destination.

If more than one forwarding rule/partner exist for a message. (More than 1 rule matches the HA), the message will be forwarded to the node that has a rule that meets the most specific parts of the HA in the message destination. For example, If I have two forward partners, one with the rule “USA.NOAM” and the other with “KY.USA.NOAM” under the HA field, if a user sends a message to “#CALL.#WKY.KY.USA.NOAM”, the message will forward to the station with “KY.USA.NOAM” in it’s rules, not the one with “USA.NOAM”. If a user sends a message with HA: “#CALL.#NVA.VA.USA.NOAM”, and those are the only two forwarding partners I have, the message will go to the node with “USA.NOAM” in it’s HR rule field.

If you intend on forwarding a message to another node, the other node (forwarding partner) should have a user entry for your nodes callsign, with the “BBS” option checked, and your nodes HA filled in both the user screen home BBS, as well as filled in the forwarding screen for that user entry. The other node should ideally have the “Enable Forwarding” option checked as well.

If you find that a message needs to be forwarded, and is held for some reason, or hasn’t gone to the correct place, you can open that message in the Mail Management page,and click a forwarding partner to change the block to yellow and que that message to be forwarded next time it meets a rule

Changing Frequencies to Forward, Scripts, RigControl and Fallback

If your head isn’t spinning enough already, you can also use the “Connect Script” block to change frequencies, modify TNC parameters, set times of the day you would like to start forwarding and even have “fallback” methods to forward if one path fails.

For this portion, I heavily recommend you take a look at the official documentation here to supplement what I’m about to get into.

For this to work, you must have some type of RIG Control setup on your BPQ32 instance. You can also reference the official documentation on this subject here. Although I will give a small example of what my FT-891 looks like when using FLRIG.

Small Example of Rig Control in BPQ

BPQ has a system for controlling radios via CAT through different means. The details for supported modes and radios are outlined on the official documentation here. The first step is to build a “Radio Port”, which lives in the main portion of the bpq32 configuration file. I use FLRIG for cat control, and so my Radio port is simple, as it only needs to point to my FLRIG instance over the network. My radio also doesn’t change modes/bandwidth when changing frequency, so the only thing I must worry about is setting a frequency in my radio port. Normally, this port can be used to scan, and hop frequencies for different portions of the day, but this is only about setting a frequency our radio will jump back to after a forwarding script changes it. The frequencies in BPQ only use a single decimal point after the Mhz. Thus, for my FT-891 connected to FLRIG, I have this for my radio port:

RADIO 1
  FLRIG 10.85.94.99:12345
  15,7.1027
****

Now, we must move on to the port configuration that actually uses our radio. I like to use VARA for forwarding, so I will go there. Within my VARA port in BPQ, I have a parameter (outside of the CONFIG section) called “DefaultRXFreq” that tells BPQ what to put my radio back to after a frequency change. My home frequency for my BBS is 14.1027. My VARA port also has it’s own “RIGCONTROL” portion that points to FLRIG, and my ADDR line is just telling BPQ where on the network VARA is running, and what PTT method to use. Another option I have here is “INTERLOCK=1” which is on all of my ports that use the same HF radio. This makes sure no two ports can toggle PTT at the same time on the same radio. Thus, my VARA port looks like this:

PORT
   PORTNUM=6
   INTERLOCK=1
   ID=VARA HF 7.102.7 N/W
   DRIVER=VARA
   NOKEEPALIVES=1
   DefaultRXFreq 14.1027
   CONFIG
   ADDR 10.85.94.99 8400 PTT FLRIG
   RIGCONTROL
   FLRIG 10.85.94.99:12345
   BW2300
   ****
ENDPORT

The Forwarding Script

Now that we have some form of rig control setup, we can now use that in our Connect Script in a forward rule on the BPQ32 Mail configuration page, amongst other things. Reference the official documentation for these scripts here. We will be using a few tools in this script to create a VARA connection to a node on another frequency during a specific time of day, fallback to AX25 if it fails, and hop back to our own home frequency.

TIMES for Time Restrictions
Time bands or “TIMES” is used to filter forwarding to a specific time window in a day. Just remember you can’t cross 2400 as a rule. If you can’t to forward into the next day, it must be two TIMES sections, 2300-2359, and 0000-0100 for example.
IDLETIME for Timeout
IDLETIME can be used in the script to close a link if no traffic occurs in a specific time. Good rule to have this in a forward script so that sessions will close if something is held up.
ATT to attach to a Port
ATT , followed by a port number is used to attach to a specific port. My VARA port is 6, and that is what I will be using for forwarding, so I need ATT 6 in my script.
RADIO FREQ MODE
When hopping a frequency in a script, a specific format is used to tell your radio what to do. Using FLRIG, my FT-891 only needs to have “RADIO 7.1013 DATA” to hop to 7.1013 with the correct mode and bandwidth. This probably needs experimentation to see what works on your own. Some configuratiosn may need USB/LSB instead of DATA for example. Reference the RIGCONTROL documentation here for instructions on changing the mode, filtering, bandwidth and more as needed by your radio.
BW500
This is just a VARA specific setting that tells VARA that I want to connect using 500 bandwidth. This can be changed for any other TNC parameter you might need for that port. For example, AX25 over HF, you may have “PACLEN 60” in your connect script.
C CALL-1
This is how yo actually start the connection to the remote forward partner. The callsign needs to be the callsign+SSID of the BBS system you are forwarding to/from. You can also have C CALL-2, follwoed by BBS, if CALL-2 is the node.
ELSE
Else can be used to do an action if the first action isn’t successful. So if my connection line wasn’t able to connect, everything under ELSE will run. This can be used to connect via a fallback plan and connect via a different method.
PAUSE
PAUSE is useful after a radio command to allow things to “stabilize” a bit before initiating a connection. This seems useful in several other ways when you want to wait a moment before proceeding.

Given all of this, the following is an example of a connect script that I use to attempt to connect to a forward partner, K5DFAT on his BBS at K5DAT-1 between the hours of 0000-0159 and 1100-1200. I change to his frequency at 7.1013, and attempt a VARA connection on port 6. If it fails, I connect via AXIP port(2) to an internet linked partners node, K7EK-7, and then use his AXIP port(3) to connect to K5DAT-1 using his AXIP link with him. My interval is set to 1800, which is every 30 minutes, which means it will try about once in each of those hour windows.

TIMES 0000-0159
IDLETIME 60
ATT 6
RADIO 7.1013 DATA
BW500
C K5DAT-1
ELSE
PAUSE 35
IDLETIME 60
C 2 K7EK-7
C 3 K5DAT-1
TIMES 1100-1200
IDLETIME 60
ATT 6
RADIO 7.1013 DATA
BW500
C K5DAT-1
ELSE
PAUSE 35
IDLETIME 60
C 2 K7EK-7
C 3 K5DAT-1

A Request for Explanation

These are concepts that I can’t find straightforward answers to online. They are terms thrown around in software and forums, that I can’t seem to get a grasp on how it works or why. I may know what effect they have when turned on, but that doesn’t lead to understanding. If anyone can offer a decent explanation of these concepts that understands them past the surface, comment below and I will credit you here on this post.

NTS MPS
This option is within a user’s BBS settings “NTS MPS” or a National Traffic System Message Pickup Station”. It seems to allow users to retrieve NTS messages that would normally be forwarded to them. I have no idea why this is an option, or what use case it may serve.

FBB Binary Protocols
These are options you may enable in the mail forwarding configuration of BPQ. You have the option of checking B1 or B2 or both. The BPQ documentation recommends to use B1 when possible as it “supports restarts and gives additional checks against corruption”. I have no idea what is restarting in this context, or what is in danger of corruption, or what it really is in general. I think this option is only relevant for forwarding mail between FBB enabled BBS systems?

FBB Blocked
This is an option in the BPQ mail forwarding, that has a number for the max size of the forwarding block. I have no idea what this could mean, and the BPQ documentation doesn’t really talk about it besides stating it’s there. I think this option is only relevant for forwarding mail between FBB enabled BBS systems?

Please leave this field empty

Consider Subscribing!

Signup for our once a month newsletter!

We don’t spam! Read our privacy policy for more info.

Check your inbox or spam folder to confirm your subscription.