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

Wed Feb 12 10:58:27 GMT 2025

Hi Chris

Many thanks for the information .

The explanations you have given below are just what is needed for all of the new commands that are being talked about along with a default setting.

I appreciate that it take time for the documentation to catch up with  the software updates. 

Many thanks for restoring the Wiki which is most helpful.

73 Keith GU6EFB 

From: Dxspider-support <dxspider-support-bounces at tobit.co.uk> On Behalf Of Lists via Dxspider-support
Sent: 12 February 2025 10:19
To: The DXSpider Support list <dxspider-support at tobit.co.uk>
Cc: Lists <lists at g1fef.co.uk>
Subject: Re: [Dxspider-support] Trusting spots... A proposal

Hi Keith,

The restored Wiki is being updated and will, going forwards, be the main repository for information on DXSpider.

To answer your specific questions:

Set/var $main::regreg = 1

This setting means that all users connecting to your node must be registered before they can send spots. If an unregistered user connects they can still receive spots but will be unable to send any.

Setting it to 0 (instead of 1) would allow anyone to connect and send spots (!! NOT RECOMMENDED !!)

Set/var $main::passwdreq = 0

This setting means that registered users do not have to set a password in order to login to your node (they can still do so if they wish, but it is not enforced).

Setting this to 1 (instead of 0) would require all users to have a password set (not recommended).

If you have any other specific questions feel free to ask.

73,

Chris - G1FEF

On 12 Feb 2025, at 09:23, Keith via Dxspider-support <dxspider-support at tobit.co.uk <mailto: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 <mailto: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 <mailto:elu9da at gmail.com> ; 'The DXSpider Support list' <dxspider-support at tobit.co.uk <mailto:dxspider-support at tobit.co.uk> >
Cc: Kin <ea3cv at cronux.net <mailto: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> 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> https://github.com/EA3CV/dxspider_update

Regards,

Kin EA3CV

De: Dxspider-support < <mailto:dxspider-support-bounces at tobit.co.uk> 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:  <mailto:dxspider-support at tobit.co.uk> dxspider-support at tobit.co.uk
CC: Ricardo Suarez < <mailto:elu9da at gmail.com> 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 < <mailto:ea3cv at cronux.net> 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  <https://aka.ms/AAb9ysg> Outlook para Android

  _____  

De: HB9DHG Fulvio < <mailto:hb9dhg at gmail.com> hb9dhg at gmail.com>
Enviado: martes, febrero 11, 2025 9:42:55 p. m.
Para:  <mailto:ea3cv at cronux.net> ea3cv at cronux.net < <mailto:ea3cv at cronux.net> ea3cv at cronux.net>
CC: The DXSpider Support list < <mailto:dxspider-support at tobit.co.uk> 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 < <mailto:ea3cv at cronux.net> ea3cv at cronux.net> wrote:

Fulvio,

Send PC92C with IP address.

Kin

Enviado desde  <https://aka.ms/AAb9ysg> Outlook para Android

  _____  

De: Dxspider-support < <mailto:dxspider-support-bounces at tobit.co.uk> dxspider-support-bounces at tobit.co.uk> en nombre de HB9DHG Fulvio via Dxspider-support < <mailto:dxspider-support at tobit.co.uk> dxspider-support at tobit.co.uk>
Enviado: martes, febrero 11, 2025 9:32:36 p. m.
Para: The DXSpider Support list < <mailto:dxspider-support at tobit.co.uk> dxspider-support at tobit.co.uk>
CC: HB9DHG Fulvio < <mailto:hb9dhg at gmail.com> 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 < <mailto:dxspider-support at tobit.co.uk> 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 < <mailto:dxspider-support-bounces at tobit.co.uk> 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 < <mailto:dxspider-support at dxcluster.org> dxspider-support at dxcluster.org>
CC: Dirk Koopman < <mailto:djk at tobit.co.uk> 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
 <mailto:Dxspider-support at tobit.co.uk> Dxspider-support at tobit.co.uk
 <https://mailman.tobit.co.uk/mailman/listinfo/dxspider-support> https://mailman.tobit.co.uk/mailman/listinfo/dxspider-support

_______________________________________________
Dxspider-support mailing list
 <mailto:Dxspider-support at tobit.co.uk> Dxspider-support at tobit.co.uk
 <https://mailman.tobit.co.uk/mailman/listinfo/dxspider-support> https://mailman.tobit.co.uk/mailman/listinfo/dxspider-support

_______________________________________________
Dxspider-support mailing list
Dxspider-support at tobit.co.uk <mailto: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/c15502dd/attachment-0001.htm>