Differences

This shows you the differences between two versions of the page.

--- member-projects:m0jqq_-_bpq_for_beginners [2024/02/09 20:12] – [Templates and scenarios] more scenarios mm0uhr
+++ member-projects:m0jqq_-_bpq_for_beginners [2024/03/27 10:31] (current) – [Things to check...] m0jqq
@@ Line 9: / Line 9: @@
 Or "What I have learnt on my journey"...
+==== Things to check... ====
+  - What s the relationship between NODESINTERVAL within the port config and SIMPLE in the config header?
+  - Found a new command to temporarily stop ports (needs SYSOP access) <STOPPORT n> & <STARTPORT n>
+  - 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.
+  - Mine is
+<code>
+****************************
+*         Ask Tom!         *
+* Always the best route :) *
+****************************
+</code>
 ==== Configuring your node for mail ====
@@ Line 34: / Line 46: @@
 === Status ===
-{{ :member-projects:mail_mgmt-status.jpg?600 |}}
+{{ :member-projects:mail_mgmt-status.jpg?600|}}
+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.
+\\
+\\
+\\
+\\
+\\
+\\
+\\
+\\
+\\
+\\
+\\
+\\
+\\
+\\
+\\
+\\
 === Main configuration ===
@@ Line 44: / Line 80: @@
 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
+  * **BBS Call:** Your node callsign
-  * SYSOP Call: Your 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.
+  * **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)
+  * **Redirect msgs to BBS Call to SYSOP Call:** Self explanatory (I think)
-  * BBS APPL No: The SSID of your BBS; by convention usually 1
+  * **BBS APPL No:** The SSID of your BBS; by convention usually 1
-  * Streams: Maximum number of simultaneous contacts. 32 is good enough
+  * **Streams:** Maximum number of simultaneous contacts. 32 is good enough
@@ Line 55: / Line 91: @@
 == Now the check boxes ==
-Mostly self explnanatory but beware of the double negatives
+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
 == Ignore the rest until you get to **WP Params** ==
 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 :(
+\\
+\\
+\\
 == Message Filters ==
+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...
+\\
+\\
+\\
+\\
+\\
+\\
+\\
+\\
+\\
+\\
+\\
+\\
+\\
+\\
-Initial description which can be fully completed at a later date
 === Users ===
+{{ :member-projects:users2.jpg?600|}}
-Example of a node and a BBS - descriptions as required
+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.
+ \\
 === Messages ===
+{{ :member-projects:messages.jpg?600|}}
+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.
+\\
+\\
+\\
+\\
+\\
+\\
+=== Forwarding ===
+{{ :member-projects:forwarding.jpg?600|}}
+\\
+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.
+\\
+\\
+\\
+\\
+\\
+\\
+\\
+\\
+\\
+\\
+\\
+\\
+\\
+\\
+\\
+\\
+\\
+\\
+\\
+\\
+=== Welcome Messages & Prompts ===
+{{ :member-projects:welcome_prompts.jpg?600|}}
+\\
+\\
+Mostly self explanatory
+\\
+\\
+\\
+\\
+\\
+\\
+\\
+\\
+\\
+\\
+\\
+\\
+\\
+\\
+\\
+\\
+\\
+\\
+=== Housekeeping ===
+{{ :member-projects:housekeeping.jpg?600|}}
+\\
+\\
+\\
+\\
+\\
+\\
+\\
+\\
+\\
+\\
+\\
+\\\
-Screensnip & description
+\\
+\\
+\\
+\\
+\\
+\\
+\\
+\\
+\\
+\\
+\\
-=== Forwarding ===
+=== WP menu ===
+{{ :member-projects:wp_updates.jpg?600|}}
+\\
+\\
+\\
+\\
+\\
+\\
+\\
+\\
+\\
+\\
+\\
+\\
+\\
-The complex bit - lots of work here
+\\
+\\
+\\
+\\
+\\
+\\
+\\
+\\
+\\
+\\
+\\
+==== Hierarchical addressing ====
+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
+^Node^HA Personal Rule^score^
+|GM7RYR|#77.gbr.euro|matches #77.gbr.euro in the HA|
+|MM3NDH|ww|matches the implied WW in the HA|
+|GM0BKS|#77|doesn't match anything because it matches from left to right|
+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.
+==== Implied parts ====
+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.
+==== Non-HA Addresses ====
+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.
+{{:member-projects:network_map.png?nolink&400 |}}
 ==== Templates ====
@@ Line 97: / Line 356: @@
 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.
-Create a user for that BBS. Set them up as a BBS in their settings. In the forwarding table set "WW" as the only rule for floods and personals.
+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.
@@ Line 103: / Line 364: @@
 ==== Just your region ====
 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.
@@ Line 111: / Line 374: @@
 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.
 ==== Gateway to the world ====
-You're region is self contained except for one node that can see out of your region and that node is you.
+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.
+==== To a hidden node ====
+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 gets through traffic ====
@@ Line 125: / Line 400: @@
 ==== Templates and scenarios ====
-| |One other BBS|Just your region | Gateway to the world | Through Traffic|
+^ ^One other BBS^Just your region^Gateway to the world^Through Traffic^
 |A personal is sent to you|The Big BBS delivers it to you|One of your neighbours passes it to you|One of your neighbours passes it to you| One of your neighbours passes it to you.|
 |You send a personal mail within your region|It goes to the only other BBS you know about. WW matches every HA rule|If you can see the BBS, an implicit AT rule will forward it that way. If you can't see it, then explicit HA rules will forward it to the next-best BBS you can see|You pass it into your region because those implicit or explicit rules match more specifically than the WW rule for outside the region|Forwarded by implicit or explicit rules|
@@ Line 134: / Line 409: @@
-=== Welcome Messages & Prompts ===
-Mostly self explanatory
-=== Housekeeping ===
-=== WP menu ===
-=== Return via Node Menu ===