[Dxspider-support] Trusting spots... A proposal
Ricardo Suarez
elu9da at gmail.com
Tue Feb 11 22:51:25 GMT 2025
Hello everyone
It is very difficult for me, and I think for many sysops, to keep up
with the number of emails with proposals, modifications, configuration
updates, opinions, different "I did...", even more "we should do".
As many of us have a life outside the cluster and we maintain it in our
free time, I suggest that Dirk and the other -very active and of course
appreciated- sysops make the decisions and then pass on to those of us
who watch from the outside what happens, a list of "do this, this and
this other thing, in this way", a kind of instruction manual on a
definitive update.
If this definitive update implies changing the way of connecting to
passwords, ssh, or smoke signals, let someone say "it should be done
this way" and the one who does it is in and the one who doesn't, is out.
At least that is my opinion, I don't know what others think about this
Rick LU9DA
El 11/2/2025 a las 21:18, HB9DHG Fulvio via Dxspider-support escribió:
> 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 👏👏👏
>
> 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/4478c44b/attachment-0001.htm>
More information about the Dxspider-support
mailing list