[Dxspider-support] Attempted usurpation

[Kin]

Hi,

While analysing the traffic on one of the nodes I manage, I came across
this:

008.dat:1736341049^(chan) -> D EA4URE-5
PC92^EA4URE-3^46648^D^^5SV2HRT-2^H98^

008.dat:1736341049^(chan) -> D EA4URE-3
PC92^WB3FFV-2^46648^D^^5SV2HRT-2^H96^

SV2HRT-2 is supposed to be trying to connect to EA4URE-3 and WB3FFV-2, but
is not succeeding.

Pulling the thread, you can see that the IP associated to SV2HRT-2 in these
attempts is 109.242.175.75

008.dat:1736340181^(chan) <- I EA4URE-5
PC92^WB3FFV-2^45780.02^A^^5SV2HRT-2:109.242.175.75^H97^
008.dat:1736340421^(chan) -> D PI4CC
PC92^EA4URE-3^46020.02^A^^5SV2HRT-2:109.242.175.75^H98^

But that same IP is associated with a user called: LZ1MAR

008.dat:1736339827^(chan) <- I EI7MRE
PC92^SV2HRT-1^45427^A^^1LZ1MAR:109.242.175.75^1M0JUI^H97^

And also, we have that the current node SV2HRT-1 (not SV2HRT-2) has the IP
37.98.198.223.

WB3FFV-2  9-Jan-2025 1254Z dxspider >
  SV2HRT-1 DXSP  7-Jan-2025 0523Z    2d 7h 31m   0.13   2    300    69
Y    37.98.198.223

I don't think it's a bug in dxspider, it's more like a clear usurpation in
order to interconnect two nodes.

But it seems that this is nothing new, because from conversations with
several sysops, it seems that there are a few nodes that are trying to
establish connections without having asked the receiving node to do so.

I still think that something should be done to make sure that only
authorised nodes can establish a connection.
I know that in the case of spiders we have the possibility to include a
password in these connections (I have it), but even so, a lot of traffic is
generated by not being able to initialise the session between applications.

At the moment, the only thing that can be done is:
set/lock LZ1MAR
set/badip 109.242.175.75

We should make sure that only our partners are defined as nodes, and when
they are no longer defined as nodes, redefine them as users. It doesn't take
that much time, if it's done at least once a month, it would help. That's my
modest opinion.
I already published a small utility that shows the PC92 A/D associated with
connection attempts to our nodes. If you run it from time to time, you can
see the failed attempts and from which callsign they came from.

73 de Kin EA3CV