Or “What I have learnt on my journey”…

1. What s the relationship between NODESINTERVAL within the port config and SIMPLE in the config header?
2. Found a new command to temporarily stop ports (needs SYSOP access) <STOPPORT n> & <STARTPORT n>
3. Writeup Node Help: Create a NodeHelp.txt file in /opt/oarc/bpq. This can contain anything you like. The command <help> from node level will present the contents of this file to the user.
4. Mine is

****************************
*         Ask Tom!         *
* Always the best route :) *
****************************

First you will need to edit your Config File either on the UI or within a terminal to enable LinMail, add a mail user name and password and allocate an application, shown in red text below:

• Enable LinMail by inserting ‘LINMAIL’ either before the first port, or after the last port but before 'APPLICATIONS'
• Add the BBS ‘APPLICATION’. This takes the form;
  • APPLICATION n,CMD,New Command,Call,Alias,Quality,L2Alias
    • See https://www.cantab.net/users/john.wiseman/Documents/BPQCFGFile.html
• Add a BBS username and password
  • <example required>

Once done, save your edit and restart BPQ

<sudo systemctl restart bpq>

You should now see an extended top menu on the main page. Including links for ‘MailMgmt’ and ‘WebMail’

The status page does not really show much. Here you can monitor live use of your node, see who is logged in to each (virtual) stream. You can also see a count of messages in the system.
NOTE:- Message count needs verification.

Many boxes to complete and lots of checks to get right. Let's try to take these one at a time.

• BBS Call: Your node callsign
• SYSOP Call: Your callsign.
• H Route: Your node's 'address'; the # indicates the county, followed by country and continent codes a.. separated by a dot.
• Redirect msgs to BBS Call to SYSOP Call: Self explanatory (I think)
• BBS APPL No: The SSID of your BBS; by convention usually 1
• Streams: Maximum number of simultaneous contacts. 32 is good enough

Mostly self explanatory but beware of the double negatives.

• Send System Msgs to SYSOP Call
• Refuse Bulls
• Enable FBB UI System
• Send Mail For Beacons every 30 Minutes
• Don't Hold Messages From New Users
• Set Don't add WINLINK.ORG flag on new users
• Don't Request Name
• Don't Request Home BBS
• Dont Check From Call
• Allow users to kill T messages
• Forward Messages to BBS Call
• Don't allow unknown users
• Enable Event Reporting

WP Destinations is where you would list stations you wish to receive any WP Updates generated by your node Housekeeping (more of which later) You have the option to reject WP bulletins and to sent yours either as bulletins or personals.
NOTE:- Further research needed here :(

Here you can define rules to filter messages accepted by your node. You can filter by message From, To or AT fields to accept, reject or hold (for other users). TBH - not really sure of these. We need an edit…

Illustrated are my node settings for GB7IOW, is it fully correct? Not sure: Does it work? Yes! We are only concerned, at present, about packet mail routing but not email via winlink.

The meaning of the fields are:

• BBS: A BBS system. Allows the BBS to queue messages for forwarding to it, to use compressed (B/B1/B2) forwarding protocols and to accept messages sent on behalf of other users..
• PMS: Personal Message System. Allows use of software such as Winpack, to use FBB compressed forwarding, even though it isn't a BBS.
• Expert: Changes the BBS prompt, normally to just >, but can be configured.
• Excluded: Prevents the user from connecting.
• Hold Messages: Prevents messages being seen by other users or forwarded until released by the sysop. This allows the sysop to review messages, as required by some licensing authorities
• NTS MPS: Message pickup station. Allows stations to retrieve NTS messages that would normally be forwarded to them on a “first come first served” basis.
• Redirect to RMS: Messages for this user will be forwarded to call@winlink.org.
• Send Mail For to APRS: Whan a message arrives for this user send an APRS message to User-SSID.
• Permit Email: Allows users to use the ISP Gateway. Any user can send via RMS, so long as the RMS gateway is configured.
• Poll RMS for SSID's: This allows the BBS to download messages for the user from the Winlink system, for local storage or onward forwarding. You can specify up to 3 SSIDs to poll, as Winlink. unlike the packet system, treats for example G8BPQ and G8BPQ-2 as separate accounts.
• RMS Express User: This allow a user (who is not also a BBS) to connect to the BBS using RMS Express. Specifically it includes B2 in the SID, which RMS needs. It isn't needed for Airmail, which doesn't require any special SID.
• Don't Add @winlink,org: If an RMS Express user addresses a message to g8bpq@winlink.org, RMS Express removes the winlink.org and only sends the callsign. Normally BPQ adds the winlink.org back if it receives just a callsign in the TO address. as that is what most RMS Express users would expect. However in some cases (eg a system without an interface to Winlink) this isn't appropriate, so can be disabled.
• Allow Sending Bulls: Enables the user to send B type messages.
• CMS Pass: This field holds the password required for Secure logon to Winlink servers.
• RMS Express can be used as a client to the BBS, but there are some issues to watch.

Here you can view messages received and their forwarding status. top of the frame is the Message number which can be selected from the list of links to the left; there is also a filter if required. most of the fram is given over to displaying message fields. The most useful aspect is the coloured frames which indicate the state of each message as selected.

• White: No forwarding set
• Yellow: Message queued for this user
• Green: Message sent
• You can click on the field to cycle through status selections. Useful if you need to resend.

The complex bit - lots of work here
The only problem to be solved in forwarding is where you should forward a message to next. If the message goes to the next-best BBS then it is assumed that BBS will pass it on correctly. Each BBS doing it's part correctly forms the network magic. All you need to do is work out one step.

Mostly self explanatory

\

A whole hierarical address (HA) would be something like MM0UHR@MM0UHR.#77.gbr.euro.ww

The part before the @ is the TO. The part after the @ is the AT. TO@AT.

In the AT part of the HA, the parts go from the most general at the right to the most specific at the left, separated by dots.

“WW” stands for World Wide. This will become important if we colonise Mars, but for the time being mail addresses usually leave it off and the software assumes it. It is still used when setting up routing rules in your BBS though.

“Euro” is the continent.

“GBR” is the country.

“#77” is the region.

Different parts of the world agree on the continent codes and within that they agree their own country codes. Each country organises their own region codes.

When a message needs to be forwarded, every BBS you can forward a message to is scored to see how specifically it matches the HA of the message.

For a personal message, the message is forwareded on the single node that best matches the address. If more than one node is equally good, the one first alphabetically is used.

For a bulletin, the message is forwareded to all the nodes that best match the address. If more than one node is equally good, they all get a copy.

An HA for a message has to match all the parts that are specified in the forwarding rules. Rules that match more parts score more highly than rules that match fewer parts, but rules that specify something that isn't in the HA score nothing at all.

Here is an example for a personal message to MM0UHR@MM0UHR.#77.gbr.euro

In this case the message would be passed to GM7RYR because it matches the most parts of the HA address.

A message to GM0CQV@GM0CQV.#75.gbr.euro would fail to match GM7RYR because #77 does not equal #75. In this case the message would fall back to MM3NDH as matching the implied WW.

The software has some rules baked into it. This is mostly only important for bulletins, but they count everywhere.

A message to MM0UHR@MM0UHR.#77.gbr.euro is assumed to be MM0UHR@MM0UHR.#77.gbr.euro.ww to help match BBS forwarding rules to WW.

A message to @EURO is assumed to be @EURO.WW.

A message to @GBR is assumed to be @GBR.EURO.WW.

A message to @#77 is too specific. The software only has implied rules for countries and continents and won't assume GBR on the end of a bare #77 route.

Most messages are sent with HA addresses because they don't need you to know everything, you just have to send the message to the next-best BBS you know about yourself and everyone doing that will get the message where it needs to go, but there are other options.

If the forwarding BBS has a value in the TO field, any message with that whole value before the @ in an address will go to that BBS. There is no special intelligence here. Any string that matches will do. Put “Bob” in the to field for a BBS and a message to bob@not-a-real-node will forward to that BBS. It might not get processed correctly from there, but that is network magic.

In the same way, if the part after the @ matches the whole line of an AT rule the message will go that way.

In Scotland this is used to provide an @SCOT bulliten service. Every node in Scotland puts SCOT in the AT box of every neighbour within Scotland and bullitens to ALL@SCOT will be forwared to every node in Scotland. (this may be a work in progress)

SCOT is not a valid HA destination so this is entirely done with non-HA addresses and works well.

The problem of @#77 being too specific for the software to understand could be fixed by creating a #77 AT rule for your forwarding partners, but they would then have the same problem of not recognising it. Every node in your region would need to agree to make the short rule work. That's not to say it can't be done, but it requires more coordinatation than relying on the existing HA rules.

There are several scenarios that could be true. Pick the one that best matches your install right now and it should tell you how to set up forwarding rules.

You are the only BBS you can see. There may be other packet stations around but you are in a little network island of your own.

Set yourself up as a user in mail and configure the account as a BBS. Everyone else will create and read mail on your node. It won't go anywhere so no forwarding rules are required.

This scenario is missing from the table below because no mail is forwarded.

Most likely if you have just set up. You can see one BBS that's already running and doing network magic, you just want in. This is also the case if there are several BBSs but you only care about one Big BBS that can do all the collation and distribution.

In the network map, this could be MM3NDH or 2M0IIG.

Create a user for the other BBS. Set them up as a BBS in their settings. In the forwarding table set “WW” as the only rule for floods and personals.

They do the same for you and all mail specifically for you is delivered via an implicit AT match.

Several people have set up in your region. There may be a gateway to the wider network, but that's not you.

In the network map this would be MM0UHR.

Create a user for every BBS you can see directly. Set them up as a BBS in their settings.

Set WW as the only rule for floods for all your neighbour BBSs. Mail to any one of them specifically will be picked up as an implicit AT rule for that BBS and go there directly.

If there is a hidden BBS you can't see but you know exists, add the full HA for that BBS to the personals rules for next best BBS you can see. This means knowing the BBSs in your area and how best to reach them.

If there is a gateway node, set them up with a WW rule in personals. Anything not explicitly or implicitly handled above means it goes to the wider world. If you can't see the gateway, add the WW rule to the next-best BBS you can see.

Your region is self contained except for one node that can see out of your region and that node is you.

In the network map this is meant to me GM0BKS.

The node outside your region gets WW in floods and personal.

The nodes inside your region get set up with your region address [e.g. #77.gbr.euro] in floods. Personals are handled by implicit or explicit rules as in the section above.

You can only see nodes inside your region but you can see a node others can't. You also divide the network in two but don't have the convenience of it being on a region boundary.

In the network map this would be GM7RYR.

The same situation of making BBS users for each BBS you can see and adding explicit rules for personals in case there are nodes you can't see behind nodes you can.

Flood rules work region wide automatically because whichever side they come in on, they should go out the other.

Your region has two or more links to other regions and they are managed by different nodes.

Set yourself up as the next best scenario above. Then add the other known regions to the next-best node you can see. This can be tricky because it might be the next city over or it might be the next continent over. This is expert level stuff and may be expanded on later.