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

[Kin]

A great idea to minimise changes in the protocol 👏👏👏
With this, nodes that have purposely deactivated PC92 will be considered as ‘suspicious’, and those that have not been updated since the Pleistocene will cease to exist.
 
I propose that nodes that have their connections between nodes with passwords should also be considered as good nodes.
If this is included with the routing table, it would give more reliability to those nodes.
And if it also includes $main::reqreg = 1 with $main::passwdreq = 0, those nodes would be the most secure.
 
What do you think?
 
Kin EA3CV
 
PS
It would be convenient for sysops to activate:
set/var $DXProt::pc92c_ipaddr_enable 1
 
 
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, 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/af12f8ef/attachment-0003.htm>