[Dxspider-support] Trusting spots... A proposal

[Dirk Koopman]

If you do a "set/debug suspicious" that implies a $DXProt::senderverify 
 >= 2.
On 11/02/2025 17:21, Kin wrote:
>
> Dirk,
>
> At 0 and with node < 3h, you see DUMPED traces and no spot in console.
>
> 1739294226^(suspicious) PCPROT: Bad Spot IU1RVT on 7093.0 by 
> IZ8STJ(79.51.37.108)@EA4RCH-5 User IZ8STJ not on node EA4RCH-5, DUMPED
>
> Itis the same behaviour as if I set senderverify = 1
>
Not the same:

1739294226^(suspicious) PCPROT: Bad Spot IU1RVT on 7093.0 by 
IZ8STJ(79.51.37.108)@EA4RCH-5 User IZ8STJ not on node EA4RCH-5

I.e not dumped. I have moved the test so that you only get one message 
(and not 15 of them like on version 564)

> I'mon build 564
>
> Kin
>
> *De:*Dxspider-support <dxspider-support-bounces at tobit.co.uk> *En 
> nombre de *Dirk Koopman via Dxspider-support
> *Enviado el:* martes, 11 de febrero de 2025 17:53
> *Para:* Dxspider-Support <dxspider-support at dxcluster.org>
> *CC:* Dirk Koopman <djk at tobit.co.uk>
> *Asunto:* [Dxspider-support] Trusting spots... A proposal
>
> A while ago, I suggested that I might implement the "nuclear option". 
> Well this is it.
>
> The "simple" answer is to compare the incoming spot with the contents 
> of the routing table.
>
> If the user or the node is not in the routing / user tables, then the 
> spot is *likely* fake.
>
> Now, there are a number of circumstances where this assumption is not 
> true. They include:
>
>   * When a node restarts, it will have an empty routing table which
>     will not be fully informed for at least three hours - by which
>     time it will have received PC92 C records from all the nodes then
>     connected. Obviously PC92 A and records will have been received in
>     "real time" for all the users that have come and gone in the
>     interim. Therefore, until the enforcement wait time expires
>     (default three hours), all spots will be treated as "valid".
>   * It's a spot coming from a source that does not (reliably) send
>     PC92 [ADC] or PC16/17 records. That means anything behind a
>     gateway into the AR-Cluster network (e.g. K1TTT). The gateway
>     itself does supply this information to a directly connected node,
>     but it won't be passed on because of the problems deduping PC16/17
>     and the fact that they are likely to be isolated nodes. If we
>     don't pass these on, then I suspect the wailing and gnash of teeth
>     will be too great.
>
> So what I propose to do is to test every spot coming in and depending 
> and after three hours (configurable) the node will grade a spot and, 
> depending on the value of $DXProt::senderverify 
> <DXProt::senderverify>, will do one of these things if a spot fails 
> the test above:
>
> For users:
>
> If set to 1, add a '?' to the one or more callsign(s) e.g.:
>
> DX de II9IAKE:    7113.0  IQ9AAP       15.55 IQ\'S DISTRICTS ARMI 
> VESPUCCI AWARD
>
> becomes
>
> DX de II9IAKE*?*: 7113.0  IQ9AAP*?* 15.55 IQ\'S DISTRICTS ARMI 
> VESPUCCI AWARD
>
> It may be adequate to just add it to the spotter call...
>
> If it is set to 2 then users won't see it at all.
>
> For nodes:
>
> 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.
>
> Confession time: This variable already exists. You can set it to 1 
> (warning) or 2 (dump). But to see the sort of effect it can have,  
> just do a "set/debug suspicious" and start a "watchdbg suspicious" in 
> another window.  You can unset/debug it and normal service will be 
> resumed. This version does not affect what users see if set to 1.
>
> 73 Dirk G1TLH
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.tobit.co.uk/pipermail/dxspider-support/attachments/20250211/4613148f/attachment-0003.htm>