I recently saw quite a few messages in Fidonet (and other nets) making the rounds I think because a node used the %+ALL command to areafix and was added to all the areas carried by the target node.
I am not excatly sure why that happened but maybe an addition to the SBBSecho wiki page that will point hubs at the info they need would be helpful?
Those messages that made the rounds also had a new (additional) origin line added from the node that those messages were rescanned from and a lot of tossers considered those new messages and so tossed them into the message base and sent them off to connected nodes.
Is there some technical reason why rescanned messages get the second origin line added, and if not would it be possible to change SBBSecho not to add it?
If it was not added other tossers in the nets would have a better chance
of catching the dupes and not passing them on.
I recently saw quite a few messages in Fidonet (and other nets) making
the rounds I think because a node used the %+ALL command to areafix and
was added to all the areas carried by the target node.
Okay. "+ALL" means add me (the areafix requester) to all available
echo areas.
Those messages that made the rounds also had a new (additional) origin
line added from the node that those messages were rescanned from and a
lot of tossers considered those new messages and so tossed them into the
message base and sent them off to connected nodes.
SBBSecho doesn't add origin lines to messages passed through it, only messages exported from a local message base.
Is there some technical reason why rescanned messages get the second
origin line added, and if not would it be possible to change SBBSecho
not to add it?
Was a rescan involved? I could double-check the rescan logic, but are you sure a rescan was actually involved?
I am not excatly sure why that happened but maybe an addition to the
SBBSecho wiki page that will point hubs at the info they need would be
helpful?
It sounds like the areafix requester has multiple uplinks (hubs) with duplicate areas (with the same echo tags) and created an inadvertent gateway and message loop.
Those messages that made the rounds also had a new (additional) origin
line added from the node that those messages were rescanned from and a
lot of tossers considered those new messages and so tossed them into
the message base and sent them off to connected nodes.
SBBSecho doesn't add origin lines to messages passed through it, only messages exported from a local message base.
Is there some technical reason why rescanned messages get the second
origin line added, and if not would it be possible to change SBBSecho
not to add it?
Was a rescan involved? I could double-check the rescan logic, but are you sure a rescan was actually involved?
If it was not added other tossers in the nets would have a better
chance of catching the dupes and not passing them on.
I think the case you're referring to involved Mystic BBS software on the "inadvertent gateway", not SBBSecho. I don't really know enough of the details of the issue to identify the existence a bug (or refute one).
Was a rescan involved? I could double-check the rescan logic, but are
you sure a rescan was actually involved?
SBBSecho doesn't add origin lines to messages passed through it, only messages exported from a local message base.
during a rescan, too?
Is there some technical reason why rescanned messages get the second
origin line added, and if not would it be possible to change SBBSecho
not to add it?
Was a rescan involved? I could double-check the rescan logic, but are you sure a rescan was actually involved?
can sbbsecho add the ^ARESCANNED w:x/y.z[@domain] control line to messages it is rescanning to a system? the address is the system holding the messages being
rescanned...
Re: SBBSecho
By: Digital Man to Al on Mon May 21 2018 04:32 pm
I am not excatly sure why that happened but maybe an addition to the
SBBSecho wiki page that will point hubs at the info they need would be
helpful?
It sounds like the areafix requester has multiple uplinks (hubs) with duplicate areas (with the same echo tags) and created an inadvertent gateway and message loop.
Yes, I think that is it. The requesting node requested %+All and a rescan, thinking he would only get Micronet areas. He had access to all the areas at the target system so was connected to and received a rescan of all the areas available at that hub. Micronet, Fidonet, fsxNet and others.
Maybe a HUB section with info that hubs need in the SBBSecho wiki page would be helpful for hubs in their setup.
Those messages that made the rounds also had a new (additional) origin
line added from the node that those messages were rescanned from and a
lot of tossers considered those new messages and so tossed them into
the message base and sent them off to connected nodes.
SBBSecho doesn't add origin lines to messages passed through it, only messages exported from a local message base.
Yes, that is what I have seen. I rescanned a number of areas from a test point here and all the messages had my nodes origin line added to them in addition to the original origin line.
If it was not added other tossers in the nets would have a better
chance of catching the dupes and not passing them on.
I think the case you're referring to involved Mystic BBS software on the "inadvertent gateway", not SBBSecho. I don't really know enough of the details of the issue to identify the existence a bug (or refute one).
It was a Mystic node requesting the %+All and rescan from SBBSecho.
I don't think there is a bug here but clarification for hub nodes might help those who serve us to get a better handle on their setup.
Not adding the second origin line would also (I think) help other tossers to trap dupes if something like that does happen.
On 05/21/18, Digital Man said the following...
Was a rescan involved? I could double-check the rescan logic, but are you sure a rescan was actually involved?
The full discussion is over on FSX_GEN in the "Barf" thread. The chain of events went something like:
* CCO BBS sets up a link to provide Micronet to Alcoholiday
* Alcoholiday Areafixes %+ALL to CCO BBS
* CCO BBS' Areafix links and sends Alcoholiday a rescan of all networks it carries (AFAIK CCO and Alcoholiday only intended to share Micronet)
* The othernet rescan traffic contains CCO's origin line in addition to the original origin and apparently slips past dupe detection on Alcoholiday
can sbbsecho add the ^ARESCANNED w:x/y.z[@domain] control line to
messages it is rescanning to a system? the address is the system
holding the messages being rescanned...
It doesn't. I suppose it could, but I've never heard of that control
line. Is there an FTSC doc?
Okay. "+ALL" means add me (the areafix requester) to all available echo areas.
It sounds like the areafix requester has multiple uplinks (hubs) with duplicate
areas (with the same echo tags) and created an inadvertent gateway and message >loop.
Was a rescan involved? I could double-check the rescan logic, but are you sure >a rescan was actually involved?
FWIW: one problem is that folks in multiple FTNs haven't figured out groups, yet, so that when someone does do a +ALL they only get those areas in the groups they are allowed access to...
On 2018 May 22 15:36:00, you wrote to me:
can sbbsecho add the ^ARESCANNED w:x/y.z[@domain] control line to
messages it is rescanning to a system? the address is the system
holding the messages being rescanned...
It doesn't. I suppose it could, but I've never heard of that control line. Is there an FTSC doc?
there is no spec on it... all i know is that fastecho and a couple of other old
school ones added it so that we could easily see the message was rescanned and from which system...
Okay. "+ALL" means add me (the areafix requester) to all available echo areas.
Is there a way to disable that command?
I was the hub and don't want
anyone to use it and did not even know it existed. I have disabled areafix for now to stop anyone else from using it.
It sounds like the areafix requester has multiple uplinks (hubs) with duplicate
areas (with the same echo tags) and created an inadvertent gateway and message >loop.
Yes, they did although, if we were discussing this on fsxnet, you would probably be reopening an arguement by suggesting that the node created the inadvertent gateway and message loop.
Was a rescan involved? I could double-check the rescan logic, but are you sure >a rescan was actually involved?
The node claims there was both a rescan and an all command executed. When they originally said there was a second origin line on his messages, I figured it was his origin line, but others have claimed it was mine. I don't know because I did not receive any of his duplicates but, if it was mine,
sbbsecho would have had to have put it there.
FWIW: one problem is that folks in multiple FTNs haven't figured out groups, yet, so that when someone does do a +ALL they only get those areas in the groups they are allowed access to...
To me, this is an issue allowing that command. A lot of folks do not run sbbs or mystic and do not have any concept of "groups" built into their software.
I am 99.9% certain that the fido hub I get my echoes from would respond to an +ALL by sending me everything they have in every FTN they belong to. I found that out by accident when I requested a fido echo from them whose
name was also part of multiple other echos and newsgroups they carry.
I don't blame them because I am guessing their software does not have any concept of groups. I blame me for not paying attention to the response
that areafix sent back to me.
othercan sbbsecho add the ^ARESCANNED w:x/y.z[@domain] control line to
messages it is rescanning to a system? the address is the system
holding the messages being rescanned...
It doesn't. I suppose it could, but I've never heard of that control
line. Is there an FTSC doc?
there is no spec on it... all i know is that fastecho and a couple of
old school ones added it so that we could easily see the message was rescanned and from which system...
Hi Digital,
On 2018-05-22 19:47:32, mark lewis wrote to you:
can sbbsecho add the ^ARESCANNED w:x/y.z[@domain] control line to
messages it is rescanning to a system? the address is the system
holding the messages being rescanned...
It doesn't. I suppose it could, but I've never heard of that control
line. Is there an FTSC doc?
there is no spec on it... all i know is that fastecho and a couple ofother
old school ones added it so that we could easily see the message was rescanned and from which system...
FMail also adds this kludge line to rescanned messages. For current versions though, the string behind it is the same as what's behind a 'Via' kludge line (in netmails). So to provide just a little bit more information than just the node number, incase of issues with it that need to be traced.
For instance, this is what it would look like:
^ARESCANNED 2:280/464 @20180523.061237.425.UTC FMail-lnx64(toss) 2.1.0.18-B20170815
Message-ID based dupe detection should've caught the dupes.
Yup. And that's now been fixed. The Message-IDs should have also been intact >however and allowed the messages to be caught as dupes. Oh well, it's good to >have the rescan origin-line issue resolved.
The sysop that performed the +ALL request should first request a list of >available echoes (%LIST) so they would know what areas would be linked if they >issued a +ALL request and compare the list of echoes to those they already >carry. If there's duplicates/overlap in the list of areas, then a +ALL is not >the appropriate AreaFix request to issue or you're asking for dupes, at >minimum, a message loop at worst.
The hub may have intended to be a feed (uplink) for multiple FTNs, in which >case, they *want* to have all of their carried echo areas, for all networks >(FidoNet and othernets) available to all of their downlinks. It depends on the >hub. If the hub is only an authorized uplink for a subset of their FTNs, then >they should limit AreaFix request access to echolists of those networks they're
authorized to hub for. SBBSecho supports this.
Yes, that is what I have seen. I rescanned a number of areas from a
test point here and all the messages had my nodes origin line added to
them in addition to the original origin line.
That's been fixed now.
Re: SBBSecho
By: Digital Man to Al on Tue May 22 2018 03:39 pm
Yes, that is what I have seen. I rescanned a number of areas from a
test point here and all the messages had my nodes origin line added to them in addition to the original origin line.
That's been fixed now.
I've updated and rescanned another few areas. Looks good along with the rescanned kludge.
| Sysop: | Winzlo |
|---|---|
| Location: | Minnesota, USA |
| Users: | 11 |
| Nodes: | 16 (0 / 16) |
| Uptime: | 495940:29:09 |
| Calls: | 82 |
| Files: | 1,070 |
| D/L today: |
27 files (11,920K bytes) |
| Messages: | 286,978 |