[Dxspider-support] Trusting spots... A proposal
IZ2LSC
iz2lsc.andrea at gmail.com
Wed Feb 12 10:14:41 GMT 2025
Keith, read this please
https://wiki.dxcluster.org/wiki/Node_configuration_for_user_access
-->
On Wed, Feb 12, 2025 at 10:23 AM Keith via Dxspider-support <
dxspider-support at tobit.co.uk> wrote:
> Whilst I appreciate all of the hard work by those involved with the
> cluster software it is difficult to keep up-to-date with all that is going
> on.
>
>
>
> Relevant information seems to be located in different places.
>
>
>
> Kins Github the now restored DXspider Wiki and Dxspider pages on the web
> Is their one place where all this information is contained?
>
>
>
> Also what do all these new options mean its fine to say for example?
>
> Set/var $main::regreg = 1
>
> Set/var $main::passwdreq = 0
>
> For the less educated IE me what does this all mean? I keep seeing mention
> of various commands and options / switches but with no definition of what
> it will do if set.
>
>
>
> I am no Linux expert so it fine to say read a document but if it does not
> explain what effect the options will have its of little value.
>
>
>
> 73 Keith GU6EFB
>
>
>
> *From:* Dxspider-support <dxspider-support-bounces at tobit.co.uk> *On
> Behalf Of *Kin via Dxspider-support
> *Sent:* 12 February 2025 08:48
> *To:* elu9da at gmail.com; 'The DXSpider Support list' <
> dxspider-support at tobit.co.uk>
> *Cc:* Kin <ea3cv at cronux.net>
> *Subject:* Re: [Dxspider-support] Trusting spots... A proposal
>
>
>
> Hola Rick,
>
>
>
> * To configure the partners, I advise you to read this document:
>
>
>
>
> https://github.com/EA3CV/dxspider_info/blob/main/Docs/HOW_TO_SET_UP_A_PARTNER_NODE_IN_DXSPIDER.pdf
>
>
>
> * To update your DXSpider, in addition to the standard procedure, you can
> use this utility:
>
>
>
> https://github.com/EA3CV/dxspider_update
>
>
>
> Regards,
>
>
>
> Kin EA3CV
>
>
>
>
>
> *De:* Dxspider-support <dxspider-support-bounces at tobit.co.uk> *En nombre
> de *Ricardo Suarez via Dxspider-support
> *Enviado el:* martes, 11 de febrero de 2025 23:51
> *Para:* dxspider-support at tobit.co.uk
> *CC:* Ricardo Suarez <elu9da at gmail.com>
> *Asunto:* Re: [Dxspider-support] Trusting spots... A proposal
>
>
>
> 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 👏👏👏
>
> 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
>
>
>
>
>
>
>
> _______________________________________________
>
> 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/20250212/1c0511bf/attachment-0001.htm>
More information about the Dxspider-support
mailing list