I run a remote point, when I write a message on my point and poll my
boss node (my mystic bbs) messages get sent just fine. So mystic then polls its boss node 340/400 then when mystic polls that boss the next time, that message I wrote on my point gets sent back to mystic and is populated in the correct echo, still no problem, however the next time
my point polls my mystic board that message gets sent to my point. So on
that the messages I send from my point, do not include seen by 202.1
just 202? Is this something I have set up wrong or is a limitation of
g00r00> SEEN-BY lines do not work with point systems unfortunantely so
g00r00> there will never be a seen-by entry for "202.1". This is not a
g00r00> Mystic limitation, its a FidoNet limitation.
sure they do... the standard 2D net/node is added like normal... either the point does it or the BOSS node, one of the two... at that point,
So if I am understanding it, your hub is sending echomail back to you that originated from your system? If thats true then that seems like an issue on the hub that is sending mail back to you, no?
Its difficult for me to comment further than that without seeing the
actual packets or more details.
Its of course possible something else is going on that is either a configuration issue or a bug but I think I will need very specific details to figure that out.
Ok so I write a message on my laptop (point 1:340/202.1) when I am finished I poll my uplink which is my mystic bbs (1:340/202) mystic then polls its hub with the new echomail (1:340/400). When mystic then polls hub again to receive packets that echo message that was written on point then comes to mystic (1:340/202) as new mail, then when I poll mystic
with my point I get that message as new mail therefore now as a dupe
Yep, so if I am understanding you then 1:340/400 is sending you duplicate messages and Mystic is catching them as a duplicate. The question is why is 340/400 sending you messages that originated from you as it should not be. What system is 340/400? It sounds like the issue is with 340/400, and Mystic is properly catching the duplicate loop.
Yep, so if I am understanding you then 1:340/400 is sending you duplicate messages and Mystic is catching them as a duplicate. The question is why is 340/400 sending you messages that originated from you as it should not be. What system is 340/400? It sounds like the issue is with 340/400, and Mystic is properly catching the duplicate loop.
Yep, so if I am understanding you then 1:340/400 is sending you duplicate messages and Mystic is catching them as a duplicate. The question is why is 340/400 sending you messages that originated from you as it should not be. What system is 340/400? It sounds like the issue is with 340/400, and Mystic is properly catching the duplicate loop.
Yep, so if I am understanding you then 1:340/400 is sending you duplic messages and Mystic is catching them as a duplicate. The question is
Yep, so if I am understanding you then 1:340/400 is sending you
duplicate messages and Mystic is catching them as a duplicate.
The question is why is 340/400 sending you messages that
originated from you as it should not be. What system is 340/400?
It sounds like the issue is with 340/400, and Mystic is properly
catching the duplicate loop.
So it goes <340/202.1> message written -----> Mystic BBS
(340/202)-------> SBBS 340/400 SBBS 340/400 ----->Mystic BBS 340/202-------> point 340/202.1 (DUPE)
Yep, so if I am understanding you then 1:340/400 is sendingyou duplic
messages and Mystic is catching them as a duplicate. Thequestion is
ok so I just logged on to my mystic system and noticed that the dupes showing up on my point system (sent from point) are also in the dupes
area of the bbs if that helps you.
Real quick I tried it from my point to my mystic then on to fsxnet
also mystic and the message still made it back to my point as a
dupe.. just an fyi
So it goes <340/202.1> message written -----> Mystic BBS
(340/202)-------> SBBS 340/400
SBBS 340/400 ----->Mystic BBS 340/202-------> point 340/202.1 (DUPE)
On Sat May 16 2020 20:51:50, Rick Smith wrote to g00r00:
Yep, so if I am understanding you then 1:340/400 is sending you
duplicate messages and Mystic is catching them as a duplicate.
The question is why is 340/400 sending you messages that
originated from you as it should not be. What system is
340/400? It sounds like the issue is with 340/400, and Mystic is
properly catching the duplicate loop.
Rick and I have basicly the same setupSo it goes <340/202.1> message written -----> Mystic BBS
(340/202)-------> SBBS 340/400 SBBS 340/400 ----->Mystic BBS
340/202-------> point 340/202.1 (DUPE)
1) 340/400 shouldn't send the message back to 340/202 first off.
2) 340/202 should catch it as a dupe before it is sent back to the
point.
From what I've gathered from previous postings, 340/202.1 (Golded) is using the same message base files as 340/202 (Mystic)? Or was this
changed recently?
In that case, Mystic is catching them as dupes properly, and placing them in your DUPES area. This is the way it's supposed to be, is it not?
Just as well, the dupes are on your point also, because you're utilizing the same Mystic message bases with Golded. So it seems your Mystic BBS
may not be "sending" your point the dupes, but in fact they're already there because you're seeing them with Golded in the DUPE base on your Mystic system, if that makes sense.
With that said, it seems the problem does in fact lie with 340/400.
this is starting to look like your point software is not properly detecting the dupes...
but shouldn't mystic be stopping a dupe from continuing down the line??
everytime I enter a message on my point (201.2), it does the same thing, it comes back as a dupe, but, I do not see a dupe mystic (a46)
but shouldn't mystic be stopping a dupe from continuing down the line??
I've understood the order the very first time you explained it, so you don't have to keep trying to reexplain each time. :)
340/202 is sending a message to 340/400 and then 340/400 is turning around and sending that message right back to 340/202. That shouldn't happen.
So that is why I am saying we need to start there and see whats up with 340/400.
340/202 is sending a message to 340/400 and then 340/400 is turning around and sending that message right back to 340/202. That shouldn't happen.
So that is why I am saying we need to start there and see whats up with 340/400.
I think the problem is with 400 or hpt, something somewhere I think is stripping off the seenbys or just ignoring them.
I did reach out to see if he had any ideas, I do not know if I
remembered to mention to you or not, but it also has the same behavior with the fsxnet hub.
was wondering, what does kill kludge do in multi.ini ?? it just says its on by default but does not explain what does it mean? disallow viewing
of kludges or???
Mystic has had problems reading and writing seen-bys. I think A45 had problems. TTBOMK the current A46 version does not, in fact A46 seem to
be working well in the echomail area from what I have seen.
I've understood the order the very first time you explained it, so you don't have to keep trying to reexplain each time. :)
Got it, apologies...
Ok I will reach out to him and see if he has any ideas.
netmail addressed to my point does not get routed to me through my
boss node, I still have to poll 340/400 with my point to get any
netmail addressed to it.
Ok I will reach out to him and see if he has any ideas.
Capturing the PKT files sent to the hub or received from the hub with the message in question would be the best thing for me to have. But I can
try to set up a local test here to see if I can reproduce and capture
that very thing.
point configuration
binkd for mailer
hpt (husky) for tosser
golded for message editor
I think the problem is with 400 or hpt, something somewhere I think is stripping off the seenbys or just ignoring them.
but shouldn't mystic be stopping a dupe from continuing down the
line??
Just to be clear my golded setup uses a mailer and tosser and so does
my winpoint system neither of them just point to my mystic msg
base,also on the point side they do not show in the "dupes" area they
are being tossed into the actual echo areas. They do get tossed into
the dupes area on the mystic system.
This is probably accurate, as netmail addressed to my point does not
get routed to me through my boss node, I still have to poll 340/400
with my point to get any netmail addressed to it.
I can tell you the problem isn't with HPT, as I use it as well. You may want to have a chat with 340/400 and see why it's being sent back to you.
netmail addressed to my point does not get routed to me through my
boss node, I still have to poll 340/400 with my point to get any netmail addressed to it.
340/400 has some work to do, then... they've either not updated to the latest sbbsecho
or their routing rules need some love but that's all a
topic for another area if/when that operator decides to ask ;)
I can't test that because my main system (boss node) is on raspberry though I did update my test point to the latest, and it came right back
Micheal
I can't test that because my main system (boss node) is on raspberry though I did update my test point to the latest, and it came right back
But the fact still remains that 340/400 is sending your original message back to you, which it shouldn't be.
This is probably accurate, as netmail addressed to my point does not get routed to me through my boss node, I still have to poll 340/400 with my point to get any netmail addressed to it.
Sounds like 340/400 has both your Mystic setup and your point configured on his
system, which he shouldn't. He should only have your Mystic system configured, and route any points you may have through that. That may or may not be the issue in this case though. Could be his dupe checker isn't set high enough, or is disabled completely? Another good place for him to look would be if he has "Circular Path Detection" enabled.
Assuming you are using Windows or Linux, can you upgrade to the version that is at:
www.mysticbbs.com/downloads/prealpha
And see if that fixes things for you?
When I re-enabled SEEN-BY dupe checking a few weeks ago I may have accidentally disabled the address checking for point systems that prevents the message from tossing back to itself. The latest version (dated 5/17) should not have that problem.
just tested, and its fixed ... yay!!!I can't test that because my main system (boss node) is on
raspberry though I did update my test point to the latest, and it
came right back
Micheal
Ahh okay, well then I will have to make you a Pi version. Stand by
I'll try to get that done for you in the next hour or two.
I can tell you the problem isn't with HPT, as I use it as well.
You may want to have a chat with 340/400 and see why it's being
sent back to you.
I have another theory: The message isn't being re-sent from his hub
at all, its just being reimported into Mystic by Mystic.
When I re-enabled SEEN-BY dupe checking a few weeks ago I may have accidentally disabled the address checking for point systems that
prevents the message from tossing back to itself. The latest version (dated 5/17) should not have that problem.
I don't have there point setup in my sbbsecho, only there main node
number as for the Circular Path Detection, look at it now, it's not
set (turn off)
do you have any other "ALL" entries that might be affecting the
routing of points?
are these the only point netmails routing through your system?
if you have other points routing through your system, do they also
exhibit this problem?
we really really should take this to one of the SYNC_* or dovenet sync support areas since it is majorly offtopic in here...
netmail is/was involved because the points were having to poll the BOSS' uplink to get their routed netmails... not sure if that has bee
The issues have been resolved with the latest pre-alphas - turned out
that it was not a synchronet issue.
netmail is/was involved because the points were having topoll the
BOSS' uplink to get their routed netmails... not sure ifthat has bee
The issues have been resolved with the latest pre-alphas - turned
out that it was not a synchronet issue.
For clarification there was no change to Netmail in Mystic any time recently.
The netmail PKTs I saw coming from the Synchronet system that were
sent out a few weeks ago were addressed to the wrong system which is
why they were not going through. There wasn't anything I could do on
the Mystic side to fix that. I think that is what Mark was refering
to.
(What I just changed in Mystic was something specific to the very
recent A46 pre-alphas only, so it would only affect people using the test-only versions that happen to feed a point).
ooops, I forgot that there were multible "point" related issues, though both now do seem to be fixed, points can now send routed netmail again with the latest synchronet builds and the letest mystic builds now works for points as it should :-)
Ok so I write a message on my laptop (point 1:340/202.1) when I am finished I poll my uplink which is my mystic bbs (1:340/202) mystic
then polls its hub with the new echomail (1:340/400). When mystic then polls hub again to receive packets that echo message that was written
on point then comes to mystic (1:340/202) as new mail, then when I
poll mystic with my point I get that message as new mail therefore now
as a dupe message, so everything I write on my point has two copies
the original message I wrote then the one that returns after the above routing happens.
| Sysop: | altere |
|---|---|
| Location: | Houston, TX |
| Users: | 66 |
| Nodes: | 4 (0 / 4) |
| Uptime: | 04:00:25 |
| Calls: | 620 |
| Calls today: | 6 |
| Files: | 7,638 |
| Messages: | 293,336 |