[Dxspider-support] $DXProt::senderverify =?utf-8?Q?=3D_?='2'

[Keith, G6NHU]

Andy, your final paragraph is really important.

"The flooding at the weekend feels like it could be prevented with a different mechanism - for example an incoming rate limit on spots with the same call or from the same IP."

The faked spots were appearing from different variations on the same callsign, with faked IP addresses.  What you’ve suggested would have made zero difference.

Mike...

"Dirk commented on this earlier. CC cluster is written in Visual Basic
and runs on Windows. It has serious memory and resource limitations
which prevent it from keeping tables of user/ipaddr data. This applies
to ALL CC cluster nodes, not just VE7CC-1. His node is particularly
vulnerable since he has 800+ Users on a contest weekend. This is a
significant number of users.

However, considering the attack this past weekend it is better to dump
these spots than have to deal with crashed nodes and logging programs
that a spot flood attack will create. Some nodes that did not crash were
15 minutes behind delivering spots to the local users."

This is the sort of thing I was referring to in a previous post.  It’s clear that CC Cluster isn’t up to the job.  If it can’t manage to do what is needed to keep the network secure, then as responsible sysops, we should effectively be shutting it out.  It's what I was saying about backwards compatibility and doing what is necessary to secure the network.  It appears as though CC Cluster is not fit for purpose for busy cluster endpoints.

 A few weeks ago, I had around 1000 users on my node, something happened (still don’t know what) and that number dropped after a router reboot.   Last weekend when this flood happened, I had around 750 users connected.  The CPU was still barely ticking over, it didn’t crash and I was delaying delivering spots by about 90 seconds.  And that’s on a Raspberry Pi 5, not some supercomputer.

73 Keith G6NHU
On 19 Feb 2025 at 14:43 +0000, g4piq--- via Dxspider-support <dxspider-support at tobit.co.uk>, wrote:
> Hi Mikel,
>
> Sorry - was trying not to create too much reflector traffic - but you ask a direct question - so here are my thoughts.
>
> My aim is to have a node which is contest optimised for a multi operator contest environment - I've been running this node to do that for well over 30 years. That means it misses as few spots as sensible, gets them quickly, and allows the mult station radio operator to use their ears / brain to figure out if the spots are good or not. Yes - some of the fake spots are really irritating in contests - and I'd love to see them go - but not at the expense of missing 70% of valid spots. Lots of the spots we are currently not seeing are perfectly valid - and unique. I appreciate that everyone has different use cases for their cluster and that's why I'd prefer the sendverify parameter to affect display rather than backbone forwarding.
>
> And I say that because I'm not convinced that Is backbone traffic from unverified spots is really an issue any more. The days of 1200 baud half duplex radio links are long gone. Dirk's code is so lightweight that it ticks along at a few percent CPU on a Raspberry Pi and the bandwidth consumption is tiny.
>
> The flooding at the weekend clearly caused some nodes real problems.  But I think that's a different behaviour to spots being sourced from nodes that for we haven't got up to date user lists for (many reasons for that in this complex heterogeneous network). The flooding at the weekend feels like it could be prevented with a different mechanism - for example an incoming rate limit on spots with the same call or from the same IP.
>
> BTW @Dirk - really appreciate all the hard work on this - I'm not having a pop - just sharing some data.
>
> 73
>
> Andy, G4PIQ
> -----Original Message-----
> From: Dxspider-support <dxspider-support-bounces at tobit.co.uk> On Behalf Of Mikel EA2CW via Dxspider-support
> Sent: 19 February 2025 14:34
> To: dxspider-support at tobit.co.uk
> Cc: Mikel EA2CW <ea2cw at gautxori.com>
> Subject: Re: [Dxspider-support] $DXProt::senderverify = '2'
>
> Dear Andy
> So d'you mean, "I will not show bad spots to my users, but I will keep spreading what I consider bad spots to the rest of the net", am I right ?
>
> I think the solution should not to be "soft" with old or missconfigured servers, but being oriented to the quality of the "product" server to our customers. Then they will decide.
>
>
> El 19/2/25 a las 14:49, g4piq--- via Dxspider-support escribió:
> > The difficulty is that - as I've read it (and I'd be delighted to be corrected) - with DXProt::senderverify = '2' the node drops the spot and doesn't forward on its neighbours - so that node makes a unilateral decision on whether the spot is good or not for the rest of the network. I'd be much more comfortable with the parameter just impacting what's displayed to the users on the node.
> >
> > Apologies if I have mis-understood this.
> >
> > 73
> >
> > Andy, G4PIQ
> > --
> 73 de Mikel Berrocal EA2CW-AE2CW
> Bilbao, Basque Country
> ea2cw at gautxori.com
> https://www.ea2cw.eus
>
>
> _______________________________________________
> 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/20250219/23a8562f/attachment.htm>