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

[HB9DHG Fulvio]

Kin, I'm happy to help make the network more friendly and
security-compliant.

Are you so kind as to explain what this command does?

set/var $DXProt::pc92c_ipaddr_enable 1

I'm sure I missed this thread, my apologies.

HB9DHG Fulvio

Sysop : HB9ON-8 Dxspider Cluster



On Tue, Feb 11, 2025 at 8:48 PM Kin via Dxspider-support <
dxspider-support at tobit.co.uk> wrote:

> 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
>
>
> _______________________________________________
> 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/20250211/87c80a48/attachment.htm>