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

Tue Feb 11 21:18:29 GMT 2025

Perfect,

That answers my question :)

set/var $DXProt::pc92c_ipaddr_enable 1
Ok, $DXProt::pc92c_ipaddr_enable = '1'

73 de HB9DHG Fulvio

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

> It simply associates the node with the user and IP on the node where it is
> connected.
> It only serves for network management, it does not affect the user, it is
> the same as when connecting to any server.
>
> Kin
>
>
> Enviado desde Outlook para Android <https://aka.ms/AAb9ysg>
>
> ------------------------------
> *De:* HB9DHG Fulvio <hb9dhg at gmail.com>
> *Enviado:* martes, febrero 11, 2025 9:42:55 p. m.
> *Para:* ea3cv at cronux.net <ea3cv at cronux.net>
> *CC:* The DXSpider Support list <dxspider-support at tobit.co.uk>
> *Asunto:* Re: [Dxspider-support] Trusting spots... A proposal
>
> 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/57e05ffd/attachment.htm>