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

[HB9DHG Fulvio]

Thanks, Kin.

But what exactly does this mean for me (as Sysop) and for a user?

Sorry for the dumb question—if the command is "transparent," I’d really
like to implement it. :)

HB9DHG Fulvio

On Tue, Feb 11, 2025 at 9:36 PM <ea3cv at cronux.net> wrote:

> Fulvio,
>
> Send PC92C with IP address.
>
> Kin
>
>
> Enviado desde Outlook para Android <https://aka.ms/AAb9ysg>
>
> ------------------------------
> *De:* Dxspider-support <dxspider-support-bounces at tobit.co.uk> en nombre
> de HB9DHG Fulvio via Dxspider-support <dxspider-support at tobit.co.uk>
> *Enviado:* martes, febrero 11, 2025 9:32:36 p. m.
> *Para:* The DXSpider Support list <dxspider-support at tobit.co.uk>
> *CC:* HB9DHG Fulvio <hb9dhg at gmail.com>
> *Asunto:* Re: [Dxspider-support] Trusting spots... A proposal
>
> 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/e13711ee/attachment.htm>