<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
Dirk, thank you very much for your hard work to give us the Spider's
software!<br>
<br>
73 Luigi IK5ZUK<br>
<br>
<div class="moz-cite-prefix">Il 11/02/2025 17:52, Dirk Koopman via
Dxspider-support ha scritto:<br>
</div>
<blockquote type="cite"
cite="mid:70ae7a32-f5fe-420e-a7ef-32d24513cfbf@tobit.co.uk">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<font size="4">A while ago, I suggested that I might implement the
"nuclear option". Well this is it.<br>
<br>
The "simple" answer is to compare the incoming spot with the
contents of the routing table. <br>
<br>
If the user or the node is not in the routing / user tables,
then the spot is *likely* fake. <br>
<br>
Now, there are a number of circumstances where this assumption
is not true. They include:<br>
</font>
<ul>
<li><font size="4">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".<br>
</font></li>
<li><font size="4">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. <br>
</font></li>
</ul>
<p><font size="4">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 $<a
class="moz-txt-link-freetext" href="DXProt::senderverify"
moz-do-not-send="true">DXProt::senderverify</a>, will do one
of these things if a spot fails the test above:</font></p>
<p><font size="4">For users: </font></p>
<p><font size="4">If set to 1, add a '?' to the one or more
callsign(s) e.g.:</font></p>
<p><font size="4" face="monospace">DX de II9IAKE: 7113.0
IQ9AAP 15.55 IQ\'S DISTRICTS ARMI VESPUCCI AWARD <br>
</font></p>
<p><font size="4">becomes <br>
</font></p>
<p><font size="4" face="monospace">DX de II9IAKE<font
color="#ff0000"><b>?</b></font>: 7113.0 IQ9AAP<font
color="#ff0000"><b>?</b></font> 15.55 IQ\'S DISTRICTS
ARMI VESPUCCI AWARD <br>
</font></p>
<p><font size="4">It may be adequate to just add it to the spotter
call... <br>
</font></p>
<p><font size="4">If it is set to 2 then users won't see it at
all.<br>
</font></p>
<p><font size="4">For nodes:</font></p>
<p><font size="4">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. <br>
</font></p>
<font size="4">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.<br>
</font>
<p><font size="4">73 Dirk G1TLH</font></p>
<br>
<br>
<fieldset class="moz-mime-attachment-header"></fieldset>
<pre wrap="" class="moz-quote-pre">_______________________________________________
Dxspider-support mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Dxspider-support@tobit.co.uk">Dxspider-support@tobit.co.uk</a>
<a class="moz-txt-link-freetext" href="https://mailman.tobit.co.uk/mailman/listinfo/dxspider-support">https://mailman.tobit.co.uk/mailman/listinfo/dxspider-support</a>
</pre>
</blockquote>
<br>
</body>
</html>