<div dir="ltr"><div>Kin, </div><div>how many legitimate spots is senderverify=2 discarding during normal conditions?</div><div>I understood this is still work in progress as from Dirk email he got 60% of spots dropped. This is not fine:</div><div><span style="background-color:rgb(255,255,255)"><font color="#0000ff"><br></font></span></div><div><span style="background-color:rgb(255,255,255)"><font color="#0000ff">"</font></span></div><div><span style="background-color:rgb(255,255,255)"><font color="#0000ff">The result I got for a morning's traffic (the natural result of a grepdbg on today's log with sendverify set) is:</font></span></div><span style="background-color:rgb(255,255,255)"><font color="#0000ff"><br style="">        60.22 (%)<br style=""><br style="">Or to put it another way, most of the traffic sent today is very likely fake.<br style=""><br style=""><span class="gmail-il" style="">Houston</span>, we have a problem...<br style=""></font></span><div><span style="background-color:rgb(255,255,255)"><font color="#0000ff">"</font></span></div><div><br></div><div>Andrea</div><div><br></div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature">--></div></div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Feb 17, 2025 at 8:45 AM Kin via Dxspider-support <<a href="mailto:dxspider-support@tobit.co.uk" target="_blank">dxspider-support@tobit.co.uk</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
<br>
>From the last attack I have seen the following:<br>
* Link crashes with partners. With greater impact on those with less hw<br>
resources.<br>
* Delays of up to 5 minutes in sending spots to users in some of the larger<br>
nodes.<br>
* More affected on Windows than on Linux.<br>
* On my node with 'set/var $DXProt::senderverify 2' the behaviour was as<br>
expected, no forged spots were fake.<br>
        grep -i "bad spot" 047.dat | wc -l<br>
        287005 <-- EA4URE-2<br>
        381899 <-- EA3CV-2<br>
<br>
        1739707974^(*) PCPROT: Bad Spot CR3DX on 14089.6 by<br>
N3LPT-3(70.139.124.201)@SM4ONW-14 User N3LPT-3 not on node SM4ONW-14, DUMPED<br>
        1739707974^(*) PCPROT: Bad Spot CR3DX on 7025.0 by<br>
N0LPT-3(70.139.201.124)@SP6MI-2 User N0LPT-3 not on node SP6MI-2, DUMPED<br>
        1739707974^(*) PCPROT: Bad Spot CR3DX on 28431.4 by<br>
N3LPT-3(70.139.124.201)@PA0ESH-3 User N3LPT-3 not on node PA0ESH-3, DUMPED<br>
        1739707974^(*) PCPROT: Bad Spot CR3DX on 21132.3 by<br>
N5LPT-3(70.124.139.201)@GB7NHR User N5LPT-3 not on node GB7NHR, DUMPED<br>
        1739707974^(*) PCPROT: Bad Spot CR3DX on 28438.0 by<br>
N0LPT-3(70.201.139.124)@PI1LAP-1 User N0LPT-3 not on node PI1LAP-1, DUMPED<br>
<br>
  On my other node without enabling this feature, thousands of them were<br>
received.<br>
* The attack was based on varying the fields: spotted, comment, spotter,<br>
spotter ip and source node.<br>
* It appears that the spots were not sent from the source nodes listed in<br>
the spots. I have verified that the ones where my node appears as the source<br>
node, did not come from my node, so I think that this must have happened to<br>
most of them.<br>
<br>
My own conclusions<br>
* Dirk's algorithm was successful for nodes that used $DXProt::senderverify<br>
to remove dupes.<br>
* If the attack had been without 'dupes', it could not have been stopped.<br>
* The flood of spots that inundated the network clearly affected nodes with<br>
fewer resources, with a less efficient OS or with a sw other than spider.<br>
<br>
Kin EA3CV<br>
<br>
<br>
<br>
<br>
_______________________________________________<br>
Dxspider-support mailing list<br>
<a href="mailto:Dxspider-support@tobit.co.uk" target="_blank">Dxspider-support@tobit.co.uk</a><br>
<a href="https://mailman.tobit.co.uk/mailman/listinfo/dxspider-support" rel="noreferrer" target="_blank">https://mailman.tobit.co.uk/mailman/listinfo/dxspider-support</a><br>
</blockquote></div>