I've run into this issue before, but never figured out a resolution.
I'm running SBBS 3.19, SBBSecho v3.15-win32. I received a netmail from a point in zone 2. I replied to it, and see a .cut file in what looks like the proper place - %binkdir%\outbox.002\00dd0001.pnt\0000003a.cut. The contents of the .cut file is the netmail reply I wrote. So far, so good.
If I poll the boss node, nothing gets transferred. If I poll the point, nothing happens, as expected.
Is there a setting I've missed in echocfg to properly route any point mail I receive to the boss node?
Which means that the boss node must be configured in EchoCfg->Linked Nodes for this boss-routing to occur. Is the boss node in question configured in
Re: routing to points
By: Digital Man to poindexter FORTRAN on Tue Feb 14 2023 05:06 pm
Which means that the boss node must be configured in EchoCfg->Linked Nodes for this boss-routing to occur. Is the boss node in question configured in
No. I tried configuring the boss node and that didn't work either. I'll see if I can reproduce that.
It seems cumbersome to have to configure a boss node on an individual basis. I'd need to receive mail, then create an entry for the boss node. If an end-user receives a netmail and replies, I might not even know to create the entry. It might be nice if, when packing mail for a point, you check to see if there's a points list, and if not, automatically address point-bound mail to the boss, where any default rules could handle routing mail to the boss.
Apparently boss-routing feature was added to SBBSecho just for you: https://gitlab.synchro.net/main/sbbs/-/commit/45ced2a3b39d30cbb8c909e66e063 ceeff05e636
Apparently boss-routing feature was added to SBBSecho just for you: https://gitlab.synchro.net/main/sbbs/-/commit/45ced2a3b39d30cbb8c909e66e063 ceef f05e636
Re: routing to points
By: Digital Man to poindexter FORTRAN on Wed Feb 15 2023 09:58 am
Apparently boss-routing feature was added to SBBSecho just for you: http s://gitlab.synchro.net/main/sbbs/-/commit/45ced2a3b39d30cbb8c909e66e063 ceeff05e636
Looking at the commit, it looks like it was some time ago, in sbbsecho 3.13. My sbbsecho reports version 3.15?
Re: routing to points
By: Digital Man to poindexter FORTRAN on Wed Feb 15 2023 09:58 am
Apparently boss-routing feature was added to SBBSecho just for you: http s://gitlab.synchro.net/main/sbbs/-/commit/45ced2a3b39d30cbb8c909e66e063 ceef f05e636
Since I typed my last response, I've upgraded to 3.20, Created an email to a point node and am seeing the following behavior:
1. Try to poll the point address - not found (as is expected)
2. Try to poll the boss (not defined in sbbsecho.cfg) - doesn't transfer point mail.
3. Try to poll the boss (defined in sbbsecho.cfg) - doesn't transfer point mail.
It's be great if there was a way that the logic could automatically boss-route any point mail, regardless of whether or not the boss is defined in sbbsecho.cfg.
Digital Man wrote to poindexter FORTRAN <=-
It's be great if there was a way that the logic could automatically boss-route any point mail, regardless of whether or not the boss is defined in sbbsecho.cfg.
Hm. I'll consider doing that. I'm not sure why it wasn't done that way initially. I understand for echomail why you couldn't/wouldn't, but I suppose NetMail should be possible in that scenario. I'll give it more thought. --
Digital Man wrote to poindexter FORTRAN <=-
Looking at the commit, it looks like it was some time ago, in sbbsecho 3.13. My sbbsecho reports version 3.15?
Yes. I'm not sure of your point.
Does sbbsecho support a point list?
Digital Man wrote to poindexter FORTRAN <=-
Looking at the commit, it looks like it was some time ago, in sbbsecho 3.13. My sbbsecho reports version 3.15?
Yes. I'm not sure of your point.
Thanks again for looking into this.
I wanted to send you my logs and notes from my experiments with point netmail. If I understand the logic, a point that has a boss node defined
in sbbsecho.ini should have mail host-routed to the boss.
I'm running
sbbsecho 3.20, recently updated from the nightly archives.
It appears that point mail isn't being host-routed, which the commit you referenced appears to suggest.
I did the following:
1. I defined the boss node, 2:221/1 in sbbsecho.ini. I created a netmail to 2:221/1:58 in SBBS. When I run SBBSECHO, I see the netmail being packed.
C:\Users\kweiske>sbbsecho
SBBSecho v3.20-Win32 (master/aa33f300f) - Synchronet FidoNet
EchoMail Tosser
Loading configuration files from c:\sbbs\ctrl\ SBBSecho
3.20-Win32 master/aa33f300f Feb 15 2023 MSC 1929 (PID 5580)
invoked with options: Configured: 6 archivers, 84 linked-nodes,
8 echolists NetMail directory: c:\sbbs\binkit\netmail\ Secure
Inbound directory: c:\sbbs\binkit\inbox\ Non-secure Inbound
directory: c:\sbbs\binkit\inbox\ Outbound (BSO root) directory:
c:\sbbs\binkit\outbox\ Reading ../data/AREAS.BBS Exporting
Outbound NetMail from c:\sbbs\data\mail to
c:\sbbs\binkit\netmail\*.msg ... NetMail msg #13487 from
poindexter FORTRAN to 1:103/1 (1:103/1): already sent NetMail
msg #29046 from Kurt Weiske to August Abolins (2:221/1.58):
Exporting NetMail message #29046 from Kurt Weiske to
August Abolins (2:221/1.58) Created NetMail (4.msg) from Kurt
Weiske (1:218/700) to August Abolins (2:221/1.58), attr: 0183,
subject: Another
Packing Outbound NetMail from c:\sbbs\binkit\netmail\*.msg ...
Node (2:221/1.58) successfully locked via:
../binkit/outbox.002\00dd0001.pnt\0000003a.bsy Adding NetMail
(4.msg) to new packet for 2:221/1.58:
../binkit/outbox.002\00dd0001.pnt\0000003a.cut Deleting
c:\sbbs\binkit\netmail\4.msg (from line 5344)
Touching outgoing semfile: ../data/binkout.now Writing 33 areas
to ../data/badareas.lst Deleting
../binkit/outbox.002\00dd0001.pnt\0000003a.bsy (from line 2963)
Deleting c:\sbbs\ctrl\sbbsecho.bsy (from line 2969) SBBSecho
(PID 5580) exiting with error level 0, NetMail(0 imported, 1
exported, 1 packed)
My guess is that you have 2:221/1.58 explicitly listed as a linked node in echofg?
Re: Re: routing to points
By: Digital Man to Kurt Weiske on Thu Feb 16 2023 01:20 pm
My guess is that you have 2:221/1.58 explicitly listed as a linked node in echofg?
No, only 2:221/1.
I saved the log files and commentary to https://realitycheckbbs.org/sbbsecho.txt, that should be easier to read.
Re: Re: routing to points
By: Kurt Weiske to Digital Man on Thu Feb 16 2023 01:39 pm
Re: Re: routing to points
By: Digital Man to Kurt Weiske on Thu Feb 16 2023 01:20 pm
My guess is that you have 2:221/1.58 explicitly listed as a linked node in echofg?
No, only 2:221/1.
I saved the log files and commentary to https://realitycheckbbs.org/sbbsecho.txt, that should be easier to read.
$ wget https://realitycheckbbs.org/sbbsecho.txt
--2023-02-16 17:34:01-- https://realitycheckbbs.org/sbbsecho.txt
Resolving realitycheckbbs.org (realitycheckbbs.org)... failed: Name or service not known.
wget: unable to resolve host address
Re: Re: routing to points
By: Kurt Weiske to Digital Man on Thu Feb 16 2023 01:39 pm
Re: Re: routing to points
By: Digital Man to Kurt Weiske on Thu Feb 16 2023 01:20 pm
My guess is that you have 2:221/1.58 explicitly listed as a linked node in echofg?
No, only 2:221/1.
I saved the log files and commentary to https://realitycheckbbs.org/sbbsecho.txt, that should be easier to read.
$ wget https://realitycheckbbs.org/sbbsecho.txt
--2023-02-16 17:34:01-- https://realitycheckbbs.org/sbbsecho.txt
Resolving realitycheckbbs.org (realitycheckbbs.org)... failed: Name or service not known.
wget: unable to resolve host address
Re: Re: routing to points
By: Kurt Weiske to Digital Man on Thu Feb 16 2023 01:39 pm
Re: Re: routing to points
By: Digital Man to Kurt Weiske on Thu Feb 16 2023 01:20 pm
My guess is that you have 2:221/1.58 explicitly listed as a linked node in echofg?
No, only 2:221/1.
Re: Re: routing to points
By: Digital Man to Kurt Weiske on Thu Feb 16 2023 05:34 pm
Re: Re: routing to points
By: Kurt Weiske to Digital Man on Thu Feb 16 2023 01:39 pm
Re: Re: routing to points
By: Digital Man to Kurt Weiske on Thu Feb 16 2023 01:20 pm
My guess is that you have 2:221/1.58 explicitly listed as a linked node in echofg?
No, only 2:221/1.
I saved the log files and commentary to https://realitycheckbbs.org/sbbsecho.txt, that should be easier to read.
$ wget https://realitycheckbbs.org/sbbsecho.txt
--2023-02-16 17:34:01-- https://realitycheckbbs.org/sbbsecho.txt Resolving realitycheckbbs.org (realitycheckbbs.org)... failed: Name or service not known.
wget: unable to resolve host address
Also, the detail we're looking for would be in your sbbsecho.log file, yet you seem to be copying/pasting from the console output of sbbsecho.
The sbbsecho.log file is the relevant log to be looking at in this
case. --
Digital Man wrote to Kurt Weiske <=-
Digital Man wrote to Kurt Weiske <=-
Compiling answers to a handful of messages:
Not sure why https://realitycheckbbs.org/sbbsecho.txt wouldn't resolve
for you - I was able to ssh into dreamhost, my web host on the outside
and see it OK using Lynx. Maybe it was a transient issue?
I was able to get through to https://reality.synchro.net and saw the
error on the cert mismatch. Is there a way to pass a secondary hostname
to letsyncrypt.js?
Odd, since one of my subdomains hosted on the bbs,
radio.realitycheckbbs.org works with my LE cert.
I did have an entry for 2:ALL in my sbbsecho.log,
but I removed it and still saw the same behavior.
I didn't see anything in my sbbsecho.log corresponding to that snippet
from the event log, I'll crank up the log level and see what I can see.
Digital Man wrote to Kurt Weiske <=-
I also tried reality.synchro.net with HTTPS, but you don't have your
TLS cert set correctly:
$ wget https://reality.synchro.net/sbbsecho.txt
--2023-02-16 17:46:48-- https://reality.synchro.net/sbbsecho.txt Resolving reality.synchro.net (reality.synchro.net)... 98.210.238.44 Connecting to reality.synchro.net (reality.synchro.net)|98.210.238.44|:443... connected.
The certificate's owner does not match hostname
I tried reality.synchro.net:8000 via HTTP, but it downloads a SHOUTcast error message file instead. --
Re: Re: routing to points
By: Digital Man to Kurt Weiske on Thu Feb 16 2023 06:32 pm
I took out the 2:ALL statement in sbbsecho.ini, changed the log level to debugging, created a netmail for 2:221/1.58, and saw this in my log file:
Routing NetMail (4.msg) to boss-node 2:221/1
Node (2:221/1) successfully locked via: ../binkit/outbox.002\00dd0001.bsy Adding NetMail (4.msg) to new packet for 2:221/1: ../binkit/outbox.002\00dd0001.cut
Deleting c:\sbbs\binkit\netmail\4.msg (from line 5344)
Which looks like the expected behavior - 2:221/1 is listed in my linked nodes list.
Digital Man wrote to Kurt Weiske <=-
I also tried reality.synchro.net with HTTPS, but you don't have your TLS cert set correctly:
$ wget https://reality.synchro.net/sbbsecho.txt
--2023-02-16 17:46:48-- https://reality.synchro.net/sbbsecho.txt Resolving reality.synchro.net (reality.synchro.net)... 98.210.238.44 Connecting to reality.synchro.net (reality.synchro.net)|98.210.238.44|:443... connected.
The certificate's owner does not match hostname
I tried reality.synchro.net:8000 via HTTP, but it downloads a SHOUTcast error message file instead. --
Which looks like the expected behavior - 2:221/1 is listed in my linked
nodes list.
Cool. So do we now want to change the expected behavior?
Re: Re: routing to points
By: Digital Man to Kurt Weiske on Fri Feb 17 2023 10:59 am
Which looks like the expected behavior - 2:221/1 is listed in my linked >> nodes list.
Cool. So do we now want to change the expected behavior?
Would it be correct to assume that my 2:ALL "linked node" entry in echocfg was being applied to my point netmail, and because no routing was specified in the 2:ALL entry, that sbbsecho packet the point netmail according to the wildcard entry? It seems like when I removed the 2:ALL entry that sbbsecho packed point mail for the boss (that *was* defined in sbbsecho.ini.)
If that's the case, that would fit the behavior I was seeing.
Since Synchronet doesn't know how to route to a point, I'd think it would make to sense to first pack all point netmail for the Boss node and then let explicit linked node entries or catch-all entries handle mail routing/flavor to the boss.
Then, if you had a specific routing arrangement with a node, you could specify them in the linked node section. If not, a zone:ALL rule could route/flavor the mail to the boss however you choose.
This would simplify sending replies to point netmail, in my opinion.
Or, am I missing something?
I'm not sure what you mean by "Synchronet doesn't konw how to route to a point". You can tell SBBSecho (not Synchronet) how to route to points both explicity and with wildcards and there's the boss-node fall-back if the boss-node is explicity configured.
Re: Re: routing to points
By: Digital Man to Kurt Weiske on Fri Feb 17 2023 12:58 pm
I'm not sure what you mean by "Synchronet doesn't konw how to route to a point". You can tell SBBSecho (not Synchronet) how to route to points both explicity and with wildcards and there's the boss-node fall-back if the boss-node is explicity configured.
I'm mis-using some of the terminology.
SBBSecho, unless told otherwise by specifying the boss node in sbbsecho.ini, will create an outbound packet for the full point address, and binkit is unable to deliver the mail.
If you define the boss node, SBBSecho will create a packet containing the point's netmail for the boss node, which makes sense.
Since points are not in the network's nodelist and are dependent on the boss node to receive and deliver files on its behalf, why not automatically route all point mail to their respective boss nodes by default?
I think SBBSecho changed to do that. Do you mind creating a feature request at https://gitlab.synchro.net/main/sbbs/-/issues and providing this detail?
The code we're discussing now was added 3 years ago (at your request) and a request for test results was made by me at the time (in the commit message), but I don't think ever got those results/feedback. I'd like to better track the change request/rationale and the results this time.
With this change (apparently as the result of a suggestion or request by Alterego), if the destination address is 1:2/3.1, but our local system has an AKA of 1:2/3.2, no routing would occur (to a boss node or based on explicit routing configured in echocfg->Linked Nodes) and that seems like a bug to me. But still unrelated to your observations.
Re: Re: routing to points
By: Digital Man to Kurt Weiske on Fri Feb 17 2023 10:59 am
With this change (apparently as the result of a suggestion or request by Alterego), if the destination address is 1:2/3.1, but our local system has an AKA of 1:2/3.2, no routing would occur (to a boss node or based on explicit routing configured in echocfg->Linked Nodes) and that seems like a bug to me. But still unrelated to your observations.
Why does that seem to be a bug?
Why does that seem to be a bug?
I would think if my system had an AKA of 1:2/3.2 and I wanted to send a netmail to 1:2/3.1, it should still be auto-routed to the boss note (1:2/3.0) by default. No?
So you cant have a direct link to 1:2/3.1?
I would think if my system had an AKA of 1:2/3.2 and I wanted to send a netmai
to 1:2/3.1, it should still be auto-routed to the boss note (1:2/3.0) by defau
. No?
deon wrote to Digital Man <=-
So you cant have a direct link to 1:2/3.1?
Re: Re: routing to points
By: Digital Man to deon on Fri Feb 17 2023 04:18 pm
Why does that seem to be a bug?
I would think if my system had an AKA of 1:2/3.2 and I wanted to send a netmail to 1:2/3.1, it should still be auto-routed to the boss note (1:2/3.0) by default. No?
So you cant have a direct link to 1:2/3.1?
not unless you have a point list with 1:2/3.1fni noitcennoc s'
connection info in it.
John H. Guillory
call sign KF5QEO
URL: kf5qeo.servebbs.net
KF5QEO's Shack BBS
Why does that seem to be a bug?
I would think if my system had an AKA of 1:2/3.2 and I wanted to send a netmail to 1:2/3.1, it should still be auto-routed to the boss note (1:2/3.0) by default. No?
So you cant have a direct link to 1:2/3.1?
Sure, but I also might not. The way this requested-enhancement was implemented, it wouldn't make any difference: the mail would not be routed to the boss.
Re: Re: routing to points
By: Digital Man to deon on Sat Feb 18 2023 11:38 am
Why does that seem to be a bug?
I would think if my system had an AKA of 1:2/3.2 and I wanted to send a netmail to 1:2/3.1, it should still be auto-routed to the boss note (1:2/3.0) by default. No?
So you cant have a direct link to 1:2/3.1?
Sure, but I also might not. The way this requested-enhancement was implemented, it wouldn't make any difference: the mail would not be routed to the boss.
Oh, in that case I agree it might be a bug.
I would have thought, if I'm a point, all mail would go to my boss (for final delivery), unless I had a specific relationship (and thus a configuration) directly to another system (including other points, either with a same boss as me, or a different boss).
The point would connect to the boss, not vice versa. Everything that was
to go to the point was routed through the boss first. No one, even the
boss, would need a direct route to the point.
The logic was changed/fixed in a commit today. Try it out. Are you also Alterego?
I would think if my system had an AKA of 1:2/3.2 and I wanted to send a netmail to 1:2/3.1, it should still be auto-routed to the boss note (1:2/3.0) by default. No?
Re: Re: routing to points
By: Digital Man to deon on Sat Feb 18 2023 02:57 pm
The logic was changed/fixed in a commit today. Try it out. Are you also Alterego?
Cool.
I'm not actually using any points at the moment, but I probably will down the track. So I'll let you know if something is not up.
I used the alias Alterego at some point, but dont anymore.
I would think if my system had an AKA of 1:2/3.2 and I wanted to send a netmail to 1:2/3.1, it should still be auto-routed to the boss note (1:2/3.0) by default. No?
Following on with this example, if I'm 1:2/3.2 and I want to send a Netmail to 1:2/4.2, *and* I have a configuration with 1:2/4.0 will sbbsecho package up my netmail for 1:2/4 or 1:2/3?
If it uses 1:2/3, I assume I can overrite it with a route 1:2/4.ALL to 1:2/4.0?
deon wrote to Kurt Weiske <=-
My point (no pun intended), is if the point defines some direct links, then they should be honoured, as well as the ability to receive direct connections from other systems (if the sysop desired).
Sysop: | MarisaG |
---|---|
Location: | South San Francisco, CA |
Users: | 5 |
Nodes: | 10 (0 / 10) |
Uptime: | 230:54:03 |
Calls: | 123 |
Files: | 36 |
Messages: | 30,547 |