[Dxspider-support] Thoughts on concerns regarding CC and DXSpider cluster nodes

Wed Mar 5 15:23:43 GMT 2025

Hi all,

I've received a series of messages that have left me speechless.

I believe that disconnecting non CC Cluster nodes will help prevent further
flooding of bogus spots, especially during major contests. These bogus spots
do not originate on CC Clusters.

I suppose the statement could be true, but it's hard to know because CC
Cluster is a black box.

Many CC Cluster sysops probably are wondering what I am talking about since
they don't see any flood of bogus spots.  

Someone might say that this statement is far from the truth, but it won't be
me.  

There are those who claim that not only were there countless false spots on
the CC Cluster nodes, but they were also being relayed across the entire
network by the CCCs themselves. And, unable to handle that volume of
traffic, they began experiencing delays of over 4 minutes.  
I find it hard to believe-though I've seen the logs.  
I manage several DXSpider nodes, and I can confirm that they never went
down. In fact, one of them withstood peak loads with maximum delays of just
0.5 seconds.  
I suppose it must have been the same for the others, right?

Any CC Cluster that does not get spots from a non CC Cluster is probably ok.

Due to the network protocol and the network flooding mechanism, this claim
is quite difficult to defend, but what do I know?

You do not need more than 3 or 4 connections to other nodes. The only reason
you need this many is that occasionally you may lose a connection or two.

This is what I can say. I totally agree. 

My own cluster runs on a very fast computer. It can see the bogus spots and
drops them.

It seems that in this latest attack, that protection mechanism has been
shown to be ineffective-or at least not in a high percentage of cases. The
data is there, or so I'm told.

If you have a slow computer you may drop the bad spots but get way behind in
processing good ones. During a 6 hour period of the ARRL contest my computer
rebooted and in the next 6 hours it dropped almost one million spots because
the spot time was more than 4 minutes slow.  This time delay was not here,
it was in the nodes I was connected with. Since the contest ended and the
bogus spots stopped, my computer has seen zero spots that were more than 4
minutes old. Not a single one.

It's hard to believe that the evidence suggests the impact came from the
traffic received through each of the links (too many, some say), but the
software didn't seem to be able to handle that volume, even though the host
had high-performance hardware. I don't know-it's tough if true.

The CC Cluster software does not clutter up the backbone data by including a
list of all connected users and their IP addresses. There is enough garbage
already on the backbone.  None of the CC Clusters send out this data.
However, DX Spider node software wants to immediately see every user connect
and disconnect.  Their software keeps track of this data.

Can it really be said that sending connection/disconnection information of
users/nodes to the network could saturate the network? Some seem to think
so. I think it must be a joke: no one could seriously say that, because it
is very easy to calculate such traffic, and it is negligible, they say.

Of course, if this were true, one would suspect that not all node software
is capable of handling this information without being affected. As far as I
know, this is not a problem in DXSpider. It would be interesting to see what
the difference is, just out of curiosity.

I wonder why Dirk would want to include IP addresses in the control packets
between nodes. Could it be the same as with the badip lists that have helped
stop a lot of spam?

And why is this important to know?  If you go to the DX Spider Support page
you will see lots of posts about the VE7CC-1 node and that many of the
sysops are proudly stating that all spots from VE7CC-1 node are dropped and
not passed on.  This is being done because my node and all other CC Cluster
nodes do not notify DX Spider nodes of users  connected and their IP
addresses.

I have not read that any sysop boasts of having removed a CC cluster. What
is publicly known is that some sysops have decided their own security policy
for their node and extend it to their partners, no more and no less.  
Seems quite reasonable, doesn't it?

Although not stated it appears to me that ALL spots originating on ALL CC
Clusters are therefore being dropped by some of the DX Spider nodes.

They tell me that this is not true, that Lee should have known before making
these claims that this could lead to a conflict. I told them that this
should not be true, that it would be too far-fetched.

However, they also told me that VE7CC-1 has features enabled that almost no
other CC Cluster had enabled: PC92C, which shows the connected users; PC92A
and D; and even PC92K, so that everyone can see the number of users and
nodes connected. But for sysops not to have these same features on their
node is not possible, because it would have minimized the rejection of spots
from those nodes in the CC Cluster.
As I said, it is impossible for this to be true.

Looking at the nodes of origin of DX spots during major contests you will
see that the majority of spots originate on CC Clusters.  If these spots are
all being dropped then users of some of the DX Spider and AR Cluster nodes
will not see the majority of the DX spots.

Since none of this seemed to make sense, I thought I might try to turn to
the data, data that is available on any node in the network.

If we count the total number of spots from 1 January 2025 until now, we get
the following values:

Total spots generated on the network:                     862,245
Total spots generated in the DXSpider nodes:          489,837
Remaining spots not generated by DXSpider:          372,408

If we assume that everything not generated by a DXSpider node was generated
by the CC Clusters, these would account for only 43% of the total. However,
the actual amount is probably lower due to the presence of other types such
as AR Cluster, CLX, DXNet and AK1A.

Thus, more than half of the spots generated in the network seem to come from
a DXSpider node.

But as we have suffered several attacks, I considered these figures invalid
and analysed the whole year 2024:

Total spots generated in the network:                      3,772,177
100.00%
Total spots generated in the DXSpider nodes:          2,155,322
57.14%
Remaining spots not generated by DXSpider:          1,616,855        42.86%

The total number of nodes in the network (identified) that sent >= 1 spot,
was approx. 439 out of 540. See file 002.txt
The number of DXSpider nodes that sent at least 1 spot, was approx. 292 out
of 393. See file 001.txt

It seems that I have not made a mistake with the 2025 values.

Although the provided values are for long periods and not exclusively for
competitions, anyone could do the calculations, but is it really necessary?

And in case you want to go to the source:
https://groups.io/g/CC-Cluster/message/2152
https://groups.io/g/CC-Cluster/topic/111514058#msg2149

Let's work together, it will make us stronger.

73 de Kin EA3CV

PS
Please excuse me if what I've written isn't clear.
By the way, if any sysop would prefer that we stop sharing links, please let
me know by email before kicking me out without warning. I still have some
civility left in me, I won't get angry.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.tobit.co.uk/pipermail/dxspider-support/attachments/20250305/89100d8b/attachment-0001.htm>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: 001.txt
URL: <https://mailman.tobit.co.uk/pipermail/dxspider-support/attachments/20250305/89100d8b/attachment-0002.txt>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: 002.txt
URL: <https://mailman.tobit.co.uk/pipermail/dxspider-support/attachments/20250305/89100d8b/attachment-0003.txt>