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

Tue Feb 11 20:45:59 GMT 2025

Actually I have PC92 K sending the node's IP address now in test. This 
will not be an option, but obviously it will continue to be backward 
compatible with existing non-IP address PC92 K's.

Dirk

On 11/02/2025 20:36, Kin via Dxspider-support 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 👏👏👏
>
>     Withthis, 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.
>
>     Ifthis 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.
>
>     Whatdo you think?
>
>     Kin EA3CV
>
>     PS
>
>     Itwould 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
>
>
>
> _______________________________________________
> 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/9293a047/attachment-0001.htm>