[Dxspider-support] Weekend data

Keith, G6NHU g6nhu at me.com
Tue Apr 1 10:50:19 BST 2025


Interesting, thanks Dirk.   That ties up with my test last week showing how easy it is to set up an ar-cluster and drop spots onto the network to another ar-cluster without making any arrangements with the other node sysop.

They just hoover up and spit out any spots they receive.

73 Keith
On 1 Apr 2025 at 10:22 +0100, Dirk Koopman via Dxspider-support <dxspider-support at tobit.co.uk>, wrote:
> I have a direct connection to K1TTT and he was the primary source of the
> copy attack traffic. It appears that AR Cluster does not have the same
> resource issues when used just as a "bounce node" (A node that only
> allows connections to other nodes - no users). I would see a genuine
> spot come in from somewhere and then, within seconds, the copy attacks.
>
> Now it's not K1TTT that is responsible, his node is just the vehicle.
>
> Dirk G1TLH
>
> On 2025-03-31 17:37, Kin via Dxspider-support wrote:
> > Hi,
> >
> > In case anyone is interested.
> > This is the data for the weekend. It includes build changes made over
> > the
> > last two days (CQ WPX SSB 2025).
> >
> > The test setup was:
> >
> > Peers Nodes: 7
> > Total Users: 1
> >
> > --------------------------------- Spots Vars
> > -----------------------------------
> >
> > Slot Time (s): $Spot::timegranularity = 60
> > Slot QRG (kHz): $Spot::qrggranularity = 1
> > Dupe Page (s): $Spot::dupage = 300
> > Length text in the deduping: $Spot::duplth = 15
> > Max length call for dupes: $Spot::maxcalllth = 12
> > Granularity input time Spot (s): $Spot::spotage = 125
> > Bad spots: $DXProt::senderverify = 1
> >
> > Enable/disable 'node' checking: $Spot::do_node_check = 0
> > Enable/disable 'call' checking: $Spot::do_call_check = 1
> > Enable/disable 'by' checking: $Spot::do_by_check = 1
> > Enable/disable 'ipaddr' checking: $Spot::do_ipaddr_check = 1
> >
> > Check 'call' is not spotted too often: $Spot::dupecall = 10
> > Threshold 'call' to become a duplicate: $Spot::dupecallthreshold =
> > 35
> > Check 'node' is not spotted too often: $Spot::nodetime = 10
> > Threshold 'node' to become a duplicate: $Spot::nodetimethreshold =
> > 50
> >
> > ----------------------------------------------------------------------------
> > ----
> >
> > Results:
> >
> > String Total
> > --------------- -------
> > DXDupe::add 376926
> > DXDupe::del 373686
> > DXDupe::clean 32100
> > Bad Spot 1113
> > Bad Node 16496
> > Badwords 98
> >
> > Normalised call 171
> > RFC1918-dropped 5214
> >
> > PC11 in 78519
> > PC11 out 7019
> > PC61 in 449619
> > PC61 out 135223
> >
> > PC92 A in 423802
> > PC92 A out 497918
> > PC92 D in 324649
> > PC92 D out 377591
> > PC92 C in 68236
> > PC92 C out 68343
> > ------------------------
> >
> > Observations:
> > There were delays of up to 9 minutes on some nodes.
> > Some nodes failed. It took me 15 minutes to reconnect to VE7CC-1 (CC
> > Cluster).
> > The retransmission of bad points on VE7CC-1, N2WQ-1, and AE5E was
> > massive.
> > On EA3CV-2, EA3CV-3, and WA9PIE-2, bad point discarding was very
> > effective,
> > as the avalanche of bad points was not detected.
> > I selected the CCCluster and DXSpider nodes, which I knew were on the
> > latest
> > version.
> >
> > I am attaching a plain text file for those who cannot see the data
> > correctly.
> >
> > Conclusions are at the discretion of the reader.
> >
> > Kin EA3CV
> >
> >
> >
> > _______________________________________________
> > Dxspider-support mailing list
> > Dxspider-support at tobit.co.uk
> > https://mailman.tobit.co.uk/mailman/listinfo/dxspider-support
>
> _______________________________________________
> Dxspider-support mailing list
> Dxspider-support at tobit.co.uk
> https://mailman.tobit.co.uk/mailman/listinfo/dxspider-support
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.tobit.co.uk/pipermail/dxspider-support/attachments/20250401/2a62c4b3/attachment.htm>


More information about the Dxspider-support mailing list