[Dxspider-support] Here we are again (huge flooding)

IZ2LSC iz2lsc.andrea at gmail.com
Mon Feb 17 10:35:55 GMT 2025


Iain,
if 60% of the traffic is fake and senderverify=2

then pc61 is dumped (discarded)
as per Dirk mail.
If set to 1, pass it onward to other nodes. If set to 2 and it's a PC61
then dump it. If set to 3 then just dump it.

Can you clarify where I misunderstood ?

-->


On Mon, Feb 17, 2025 at 11:12 AM Iain Philipps <iain.philipps at 77hz.net>
wrote:

> Andrea,
>
> You have misunderstood. Legitimate spots are **not** being discarded.
>
> Because:->  most of the traffic sent today is very likely fake. <-
>
>
>
>
> 73 de WR3D
>
>
>
>
> *From:* Dxspider-support <dxspider-support-bounces at tobit.co.uk> *On
> Behalf Of *IZ2LSC via Dxspider-support
> *Sent:* 17 February 2025 10:09
> *To:* The DXSpider Support list <dxspider-support at tobit.co.uk>
> *Cc:* IZ2LSC <iz2lsc.andrea at gmail.com>
> *Subject:* Re: [Dxspider-support] Here we are again (huge flooding)
>
>
>
> Kin,
>
> how many legitimate spots is senderverify=2 discarding during normal
> conditions?
>
> I understood this is still work in progress as from Dirk email he got 60%
> of spots dropped. This is not fine:
>
>
>
> "
>
> The result I got for a morning's traffic (the natural result of a grepdbg
> on today's log with sendverify set) is:
>
>
>         60.22 (%)
>
> Or to put it another way, most of the traffic sent today is very likely
> fake.
>
> Houston, we have a problem...
>
> "
>
>
>
> Andrea
>
>
>
> -->
>
>
>
>
>
> On Mon, Feb 17, 2025 at 8:45 AM Kin via Dxspider-support <
> dxspider-support at tobit.co.uk> wrote:
>
> Hi,
>
> From the last attack I have seen the following:
> * Link crashes with partners. With greater impact on those with less hw
> resources.
> * Delays of up to 5 minutes in sending spots to users in some of the larger
> nodes.
> * More affected on Windows than on Linux.
> * On my node with 'set/var $DXProt::senderverify 2' the behaviour was as
> expected, no forged spots were fake.
>         grep -i "bad spot" 047.dat | wc -l
>         287005 <-- EA4URE-2
>         381899 <-- EA3CV-2
>
>         1739707974^(*) PCPROT: Bad Spot CR3DX on 14089.6 by
> N3LPT-3(70.139.124.201)@SM4ONW-14 User N3LPT-3 not on node SM4ONW-14,
> DUMPED
>         1739707974^(*) PCPROT: Bad Spot CR3DX on 7025.0 by
> N0LPT-3(70.139.201.124)@SP6MI-2 User N0LPT-3 not on node SP6MI-2, DUMPED
>         1739707974^(*) PCPROT: Bad Spot CR3DX on 28431.4 by
> N3LPT-3(70.139.124.201)@PA0ESH-3 User N3LPT-3 not on node PA0ESH-3, DUMPED
>         1739707974^(*) PCPROT: Bad Spot CR3DX on 21132.3 by
> N5LPT-3(70.124.139.201)@GB7NHR User N5LPT-3 not on node GB7NHR, DUMPED
>         1739707974^(*) PCPROT: Bad Spot CR3DX on 28438.0 by
> N0LPT-3(70.201.139.124)@PI1LAP-1 User N0LPT-3 not on node PI1LAP-1, DUMPED
>
>   On my other node without enabling this feature, thousands of them were
> received.
> * The attack was based on varying the fields: spotted, comment, spotter,
> spotter ip and source node.
> * It appears that the spots were not sent from the source nodes listed in
> the spots. I have verified that the ones where my node appears as the
> source
> node, did not come from my node, so I think that this must have happened to
> most of them.
>
> My own conclusions
> * Dirk's algorithm was successful for nodes that used $DXProt::senderverify
> to remove dupes.
> * If the attack had been without 'dupes', it could not have been stopped.
> * The flood of spots that inundated the network clearly affected nodes with
> fewer resources, with a less efficient OS or with a sw other than spider.
>
> Kin EA3CV
>
>
>
>
> _______________________________________________
> 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/20250217/eba0db3d/attachment.htm>


More information about the Dxspider-support mailing list