<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;">Thanks Dirk, I have emailed you.<div><br></div><div>73 Keith</div><div><div><br><blockquote type="cite"><div>On 26 Sep 2024, at 13:37, Dirk Koopman via Dxspider-support <dxspider-support@tobit.co.uk> wrote:</div><br class="Apple-interchange-newline"><div>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<div>
<div class="moz-cite-prefix">I have been away from computers rather
a lot recently, but I my (failing) memory suggests that this sort
of thing has happened before and I enclose some comments from the
code that *may* shed some light on what is going on with HamClock.
This code has not be altered since May 2020. The point of this is
to discourage software hammering away at a node, filling the logs
with never ending connect requests.<br>
<br>
<br>
<font face="monospace">$bumpexisting = 1; # 1 =
allow new connection to disconnect old, 0 - don't allow it<br>
our $allowmultiple = 0; # This is used in
conjunction with $bumpexisting, in a rather weird way.<br>
our $min_reconnection_rate = 5*60; # minimum value of
seconds between connections per user to allow co-existing users<br>
our $max_ssid = 15; # highest ssid to be
searched for a spare one on multiple connections<br>
<br>
# If $allowmultiple > 0 and the $reconnection_rate is some
value of seconds<br>
# based on the average connection time calculated from the
$user->conntimel entries / frequency is<br>
# less than $reconnection_rate then we assume that there is more
than one device (probably HRD) trying<br>
# to connect "at once". In which case we probe for a spare SSID
for a user callsign to allow up to <br>
# $allowmultiple connections per callsign. </font><br>
<br>
and<br>
<br>
<font face="monospace">$maxconnect_user = 3; # the
maximum no of concurrent connections a user can have at a time<br>
$maxconnect_node = 0; # Ditto but for nodes. In
either case if a new incoming connection<br>
# takes the no of references in
the routing table above these numbers<br>
# then the connection is
refused. This only affects INCOMING connections.</font><br>
<br>
<br>
This is to prevent people trying to break the (default 3) limit of
connections a user can have to the (global) cluster.
Unfortunately, I won't give DXSpider privileges to install
"fail2ban" style iptables block commands for an IP address that
does this. But, having written that, I could put together an
actual "fail2ban" recipe and the necessary debugging so that it
can do this for us. Alternatively, you could fiddle with <font face="monospace">$allowmultiple and </font><font face="monospace">$min_reconnection_rate </font>to see whether
affects anything. <br>
<br>
If this is a "bump existing" situation, then you should see
evidence in the both the debug and log files. A "show/log bumped"
may show something. Also a "stat/user <affected callsign>"
may also show some clues.<br>
<br>
Also, Keith, if you would send me, privately, some login
credentials by email, I will have a look over the next couple of
days. <br>
<br>
73 Dirk G1TLH<br>
<br>
On 21/09/2024 15:41, IZ2LSC via Dxspider-support wrote:<br>
</div>
<blockquote type="cite" cite="mid:CAJowXJCEASri+0-DsAQjuxWMaa7psYHWGXC2B7GthS-QzgmW4g@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">Keith,
<div>from what was shared in this thread I can see the reset is
received by the dxspider, so someone else has generated it.</div>
<div>Before going for any conclusion, I want to be sure that the
tcpdump that was shared is really about a user that is having
the problem.</div>
<div>This is why I asked to get the tcpdump for a user IP as
long as the dxspider debug log for the same user captured at
the same time.</div>
<div><br>
</div>
<div>My hamclock is able to connect to your cluster without any
issue and I tried several disconnect/connect sequences.</div>
<div><br>
</div>
<div>Andrea</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div>
<div>
<div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature">--></div>
</div>
<br>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">Il giorno sab 21 set 2024 alle
ore 16:30 Keith Maton <<a href="mailto:g6nhu@me.com" moz-do-not-send="true" class="moz-txt-link-freetext">g6nhu@me.com</a>>
ha scritto:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<div>So what’s the current feeling, is the disconnect coming
from HamClock or the DXSpider?</div>
<div><br>
</div>
<div>I don’t think we can send attachments to this list so <a href="https://g6nhu.co.uk/users-week.png" target="_blank" moz-do-not-send="true">here’s a link</a> to
the mrtg users graph.</div>
<div><br>
</div>
<div>You’ll see it stops at 20:30z on Wednesday. That’s
because it all went wrong when I did the update on
Thursday afternoon and then a couple of hours later I
restored the 536 backup that was taken the previous
evening. The gap is from the time of the backup to when I
restored.</div>
<div><br>
</div>
<div>I’ve gone back to exactly how it was before the update.
I talk to the HamClock dev daily and there are multiple
different versions of HamClock all unable to connect.</div>
<div><br>
</div>
<div>I simply don’t know where to go from here, especially
as I built a new node on a different pi this morning and
the same thing happens.</div>
<div><br>
</div>
<div>73 Keith.</div>
<div><br>
</div>
<br id="m_8347237440925077952lineBreakAtBeginningOfMessage">
<div><br>
<blockquote type="cite">
<div>On 21 Sep 2024, at 14:58, Kin EA3CV <<a href="mailto:ea3cv@cronux.net" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">ea3cv@cronux.net</a>>
wrote:</div>
<br>
<div>
<div>
<div dir="auto">Yes, there is clearly something
HamClock doesn't like. I haven't looked at a
HamClock user that works but the ones that fail
don't terminate the socket with FIN. </div>
<div dir="auto">I had thought about setting up a
client in a container, but if you try it, you'll
let us know. <br>
</div>
<div dir="auto"><br>
</div>
<div dir="auto">Kin</div>
<div dir="auto"><br>
</div>
<div dir="auto"><br>
</div>
<div id="m_8347237440925077952mail-editor-reference-message-container" dir="auto"><br>
<hr style="display:inline-block;width:98%">
<div id="m_8347237440925077952divRplyFwdMsg" style="font-size:11pt"><strong>De:</strong>
IZ2LSC <<a href="mailto:iz2lsc.andrea@gmail.com" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">iz2lsc.andrea@gmail.com</a>><br>
<strong>Enviado:</strong> sábado, septiembre 21,
2024 3:23:04 p. m.<br>
<strong>Para:</strong> Kin <<a href="mailto:ea3cv@cronux.net" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">ea3cv@cronux.net</a>><br>
<strong>CC:</strong> The DXSpider Support list
<<a href="mailto:dxspider-support@tobit.co.uk" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">dxspider-support@tobit.co.uk</a>>;
Keith Maton <<a href="mailto:g6nhu@me.com" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">g6nhu@me.com</a>><br>
<strong>Asunto:</strong> Re: [Dxspider-support]
New mojo version<br>
</div>
<br>
<div dir="ltr">Kin,
<div>the netstat looks fine, I can see 87
sessions established.</div>
<div>But from the TCP dump you attached I see a
lot of RST (reset) coming from client side,
not from cluster.</div>
<div><br>
</div>
<div>Just to give you an example this is what
happen when is the cluster disconnecting a
user (192.168.1130 is the cluster):</div>
<div><br>
</div>
<div>15:15:53.503505 IP 192.168.1130.7373 >
192.168.1.111.52076: Flags [F.], seq 4172, ack
8, win 227, options [nop,nop,TS val 2856414384
ecr 3254272443], length 0<br>
15:15:53.504215 IP 192.168.1.111.52076 >
192.168.1.130.7373: Flags [F.], seq 8, ack
4173, win 501, options [nop,nop,TS val
3254273942 ecr 2856414384], length 0<br>
15:15:53.504340 IP 192.168.1.130.7373 >
192.168.1.111.52076: Flags [], ack 9, win 227,
options [nop,nop,TS val 2856414385 ecr
3254273942], length 0<br>
</div>
<div><br>
</div>
<div>So the cluster is the first sending the Fin</div>
<div><br>
</div>
<div>Can you try to follow a specific flow,
correlating the IP address you see in the
debug log of dxspider with the ip address you
find on the tcpdump?</div>
<div>I mean the sessions from the beginning to
end.</div>
<div><br>
</div>
<div>Meantime I'll set up a hamclock and test it
with your cluster.</div>
<div><br>
</div>
<div><br>
</div>
<div>Andrea</div>
<div><br>
</div>
<div><br>
</div>
<div><br clear="all">
<div>
<div dir="ltr" class="gmail_signature">--></div>
</div>
<br>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">Il giorno sab
21 set 2024 alle ore 14:43 Kin <<a href="mailto:ea3cv@cronux.net" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">ea3cv@cronux.net</a>>
ha scritto:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<div lang="ES">
<div><p class="MsoNormal"><span style="font-size:12pt">I <span>think</span>
<span>it</span> <span>is</span> <span>clear</span>
<span>that</span> <span>the</span>
<span>client</span> <span>is</span>
<span>being</span> <span>logged</span>
<span>out</span>:</span></p><div><span style="font-size:12pt"> </span><br class="webkit-block-placeholder"></div><p class="MsoNormal"><span><span style="font-size:12pt">7160<span>
</span>33.786132</span></span><span style="font-size:12pt">
216.189.132.128 → 192.168.1.8<span>
</span>TCP 72 56774 → 7300 [RST,
ACK] <span>Seq</span>=10 <span>Ack</span>=8
<span>Win</span>=32128 Len=0 <span>TSval</span>=1580625328
<span>TSecr</span>=201034149</span></p><p class="MsoNormal"><span style="font-size:12pt"> <span>7168<span>
</span>33.896513</span>
216.189.132.128 → 192.168.1.8<span>
</span>TCP 66 56774 → 7300 [RST] <span>Seq</span>=1
<span>Win</span>=0 Len=0</span></p><p class="MsoNormal"><span style="font-size:12pt"> <span>7169<span>
</span>33.896698</span>
216.189.132.128 → 192.168.1.8<span>
</span>TCP 66 56774 → 7300 [RST] <span>Seq</span>=7
<span>Win</span>=0 Len=0</span></p><p class="MsoNormal"><span style="font-size:12pt"> <span>7170<span>
</span>33.906293</span>
216.189.132.128 → 192.168.1.8<span>
</span>TCP 66 56774 → 7300 [RST] <span>Seq</span>=10
<span>Win</span>=0 Len=0</span></p><p class="MsoNormal"><span style="font-size:12pt"> <span>7178<span>
</span>34.340220</span>
171.100.240.62 → 192.168.1.8<span>
</span>TCP 66 63285 → 7300 [RST,
ACK] <span>Seq</span>=1 <span>Ack</span>=1
<span>Win</span>=0 Len=0</span></p><p class="MsoNormal"><span style="font-size:12pt"> <span>8448<span>
</span>39.243542</span>
209.193.104.69 → 192.168.1.8<span>
</span>TCP 66 40996 → 7300 [RST] <span>Seq</span>=1
<span>Win</span>=0 Len=0</span></p><p class="MsoNormal"><span style="font-size:12pt"> <span>9532<span>
</span>50.372818</span>
72.14.148.41 → 192.168.1.8<span> </span>TCP
72 64276 → 7300 [RST, ACK] <span>Seq</span>=2
<span>Ack</span>=2 <span>Win</span>=251
Len=0 <span>TSval</span>=3068700830
<span>TSecr</span>=1953125033</span></p><p class="MsoNormal"><span><span style="font-size:12pt">19600<span>
</span>91.809075</span></span><span style="font-size:12pt"> 74.132.91.47
→ 192.168.1.8<span> </span>TCP 72
36452 → 7300 [RST, ACK] <span>Seq</span>=13
<span>Ack</span>=8 <span>Win</span>=64256
Len=0 <span>TSval</span>=2598464619
<span>TSecr</span>=4079102387</span></p><p class="MsoNormal"><span><span style="font-size:12pt">19749<span>
</span>91.934857</span></span><span style="font-size:12pt"> 74.132.91.47
→ 192.168.1.8<span> </span>TCP 66
36452 → 7300 [RST] <span>Seq</span>=10
<span>Win</span>=0 Len=0</span></p><p class="MsoNormal"><span><span style="font-size:12pt">19750<span>
</span>91.937074</span></span><span style="font-size:12pt"> 74.132.91.47
→ 192.168.1.8<span> </span>TCP 66
36452 → 7300 [RST] <span>Seq</span>=13
<span>Win</span>=0 Len=0</span></p><p class="MsoNormal"><span><span style="font-size:12pt">21439<span>
</span>97.245904</span></span><span style="font-size:12pt">
67.190.210.166 → 192.168.1.8<span>
</span>TCP 66 57758 → 7300 [RST] <span>Seq</span>=1
<span>Win</span>=0 Len=0</span></p><p class="MsoNormal"><span style="font-size:12pt">23946
104.730291 86.150.197.182 → <span>192.168.1.8<span>
</span>TCP</span> 66 49319 → 7300
[RST, ACK] <span>Seq</span>=1 <span>Ack</span>=9
<span>Win</span>=0 Len=0</span></p><p class="MsoNormal"><span style="font-size:12pt">23947
104.730291 86.150.197.182 → <span>192.168.1.8<span>
</span>TCP</span> 66 49316 → 7300
[RST, ACK] <span>Seq</span>=1 <span>Ack</span>=2
<span>Win</span>=0 Len=0</span></p><p class="MsoNormal"><span style="font-size:12pt">24595
106.702456 74.132.91.47 → <span>192.168.1.8<span>
</span>TCP</span> 72 58432 → 7300
[RST, ACK] <span>Seq</span>=13 <span>Ack</span>=8
<span>Win</span>=64256 Len=0 <span>TSval</span>=2598479515
<span>TSecr</span>=4079117277</span></p><p class="MsoNormal"><span style="font-size:12pt">24614
106.848106 74.132.91.47 → <span>192.168.1.8<span>
</span>TCP</span> 66 58432 → 7300
[RST] <span>Seq</span>=10 <span>Win</span>=0
Len=0</span></p><p class="MsoNormal"><span style="font-size:12pt">24618
106.919363 74.132.91.47 → <span>192.168.1.8<span>
</span>TCP</span> 66 58432 → 7300
[RST] <span>Seq</span>=13 <span>Win</span>=0
Len=0</span></p><p class="MsoNormal"><span style="font-size:12pt">25499
114.246740 67.190.210.166 → <span>192.168.1.8<span>
</span>TCP</span> 66 41444 → 7300
[RST] <span>Seq</span>=1 <span>Win</span>=0
Len=0</span></p><p class="MsoNormal"><span style="font-size:12pt">26057
118.535648 72.14.148.41 → <span>192.168.1.8<span>
</span>TCP</span> 72 22727 → 7300
[RST, ACK] <span>Seq</span>=1 <span>Ack</span>=9
<span>Win</span>=64256 Len=0 <span>TSval</span>=3068768993
<span>TSecr</span>=1953190036</span></p><p class="MsoNormal"><span style="font-size:12pt">27133
121.696803 74.132.91.47 → <span>192.168.1.8<span>
</span>TCP</span> 72 33884 → 7300
[RST, ACK] <span>Seq</span>=13 <span>Ack</span>=8
<span>Win</span>=64256 Len=0 <span>TSval</span>=2598494508
<span>TSecr</span>=4079132270</span></p><p class="MsoNormal"><span style="font-size:12pt">27149
121.815184 74.132.91.47 → <span>192.168.1.8<span>
</span>TCP</span> 66 33884 → 7300
[RST] <span>Seq</span>=10 <span>Win</span>=0
Len=0</span></p><p class="MsoNormal"><span style="font-size:12pt">27150
121.815249 74.132.91.47 → <span>192.168.1.8<span>
</span>TCP</span> 66 33884 → 7300
[RST] <span>Seq</span>=10 <span>Win</span>=0
Len=0</span></p><p class="MsoNormal"><span style="font-size:12pt">27151
121.815250 74.132.91.47 → <span>192.168.1.8<span>
</span>TCP</span> 66 33884 → 7300
[RST] <span>Seq</span>=13 <span>Win</span>=0
Len=0</span></p><p class="MsoNormal"><span style="font-size:12pt">29651
131.245565 67.190.210.166 → <span>192.168.1.8<span>
</span>TCP</span> 66 56690 → 7300
[RST] <span>Seq</span>=1 <span>Win</span>=0
Len=0</span></p><p class="MsoNormal"><span style="font-size:12pt">29689
132.322988 171.100.240.62 → <span>192.168.1.8<span>
</span>TCP</span> 66 63313 → 7300
[RST, ACK] <span>Seq</span>=1 <span>Ack</span>=9
<span>Win</span>=0 Len=0</span></p><p class="MsoNormal"><span style="font-size:12pt">29690
132.323664 171.100.240.62 → <span>192.168.1.8<span>
</span>TCP</span> 66 63298 → 7300
[RST, ACK] <span>Seq</span>=1 <span>Ack</span>=2
<span>Win</span>=0 Len=0</span></p><p class="MsoNormal"><span style="font-size:12pt">30075
136.719069 74.132.91.47 → <span>192.168.1.8<span>
</span>TCP</span> 72 51106 → 7300
[RST, ACK] <span>Seq</span>=13 <span>Ack</span>=8
<span>Win</span>=64256 Len=0 <span>TSval</span>=2598509531
<span>TSecr</span>=4079147277</span></p><p class="MsoNormal"><span style="font-size:12pt">30094
136.842612 74.132.91.47 → <span>192.168.1.8<span>
</span>TCP</span> 66 51106 → 7300
[RST] <span>Seq</span>=10 <span>Win</span>=0
Len=0</span></p><p class="MsoNormal"><span style="font-size:12pt">30512
139.246966 74.132.91.47 → <span>192.168.1.8<span>
</span>TCP</span> 66 46146 → 7300
[RST] <span>Seq</span>=1 <span>Win</span>=0
Len=0</span></p><p class="MsoNormal"><span style="font-size:12pt">30730
141.916039 72.181.212.51 → <span>192.168.1.8<span>
</span>TCP</span> 72 52404 → 7300
[RST, ACK] <span>Seq</span>=10 <span>Ack</span>=8
<span>Win</span>=32128 Len=0 <span>TSval</span>=10881996
<span>TSecr</span>=4118248549</span></p><p class="MsoNormal"><span style="font-size:12pt">32092
148.245539 67.190.210.166 → <span>192.168.1.8<span>
</span>TCP</span> 66 60236 → 7300
[RST] <span>Seq</span>=1 <span>Win</span>=0
Len=0</span></p><p class="MsoNormal"><span style="font-size:12pt">33326
151.728538 74.132.91.47 → <span>192.168.1.8<span>
</span>TCP</span> 72 47306 → 7300
[RST, ACK] <span>Seq</span>=13 <span>Ack</span>=8
<span>Win</span>=64256 Len=0 <span>TSval</span>=2598524532
<span>TSecr</span>=4079162306</span></p><p class="MsoNormal"><span style="font-size:12pt">33340
151.867383 74.132.91.47 → <span>192.1681.8<span>
</span>TCP</span> 66 47306 → 7300
[RST] <span>Seq</span>=1 <span>Win</span>=0
Len=0</span></p><p class="MsoNormal"><span style="font-size:12pt">33341
151.867471 74.132.91.47 → <span>192.168.1.8<span>
</span>TCP</span> 66 47306 → 7300
[RST] <span>Seq</span>=10 <span>Win</span>=0
Len=0</span></p><p class="MsoNormal"><span style="font-size:12pt">33342
151.868904 74.132.91.47 → <span>192.168.1.8<span>
</span>TCP</span> 66 47306 → 7300
[RST] <span>Seq</span>=13 <span>Win</span>=0
Len=0</span></p><p class="MsoNormal"><span style="font-size:12pt">34141
156.245366 67.190.210.166 → <span>192.168.1.8<span>
</span>TCP</span> 66 59968 → 7300
[RST] <span>Seq</span>=1 <span>Win</span>=0
Len=0</span></p><p class="MsoNormal"><span style="font-size:12pt">36145
166.704908 74.132.91.47 → <span>192.168.1.8<span>
</span>TCP</span> 72 55558 → 7300
[RST, ACK] <span>Seq</span>=13 <span>Ack</span>=8
<span>Win</span>=64256 Len=0 <span>TSval</span>=2598539512
<span>TSecr</span>=4079177284</span></p><p class="MsoNormal"><span style="font-size:12pt">36150
166.844112 74.132.91.47 → <span>192.168.1.8<span>
</span>TCP</span> 66 55558 → 7300
[RST] <span>Seq</span>=1 <span>Win</span>=0
Len=0</span></p><p class="MsoNormal"><span style="font-size:12pt">36151
166.844112 74.132.91.47 → <span>192.168.1.8<span>
</span>TCP</span> 66 55558 → 7300
[RST] <span>Seq</span>=13 <span>Win</span>=0
Len=0</span></p><p class="MsoNormal"><span style="font-size:12pt">37488
173.246799 67.190.210.166 → <span>192.168.1.8<span>
</span>TCP</span> 66 55428 → 7300
[RST] <span>Seq</span>=1 <span>Win</span>=0
Len=0</span></p><p class="MsoNormal"><span style="font-size:12pt">37877
176.782641 72.14.148.41 → <span>192.168.1.8<span>
</span>TCP</span> 72 47454 → 7300
[RST, ACK] <span>Seq</span>=1 <span>Ack</span>=9
<span>Win</span>=64256 Len=0 <span>TSval</span>=3068827240
<span>TSecr</span>=1953255335</span></p><p class="MsoNormal"><span style="font-size:12pt">38468
182.245044 212.251.236.77 → <span>192.168.1.8<span>
</span>TCP</span> 66 25610 → 7300
[RST] <span>Seq</span>=1 <span>Win</span>=0
Len=0</span></p><p class="MsoNormal"><span style="font-size:12pt">40367
190.261692 67.190.210.166 →
192.168.1.8<span> </span>TCP 66
41508 → 7300 [RST] <span>Seq</span>=1
<span>Win</span>=0 Len=0</span></p><div><span style="font-size:12pt"> </span><br class="webkit-block-placeholder"></div><p class="MsoNormal"><span style="font-size:12pt">Kin EA3CV</span></p><div><span style="font-size:12pt"> </span><br class="webkit-block-placeholder"></div><div><span style="font-size:12pt"> </span><br class="webkit-block-placeholder"></div>
<div style="border-right:none;border-bottom:none;border-left:none;border-top:1pt solid rgb(225,225,225);padding:3pt 0cm 0cm"><p class="MsoNormal"><b><span>De:</span></b><span>
IZ2LSC <<a href="mailto:iz2lsc.andrea@gmailcom" target="_blank" moz-do-not-send="true">iz2lsc.andrea@gmail.com</a>>
<br>
<b>Enviado el:</b> sábado, 21 de
septiembre de 2024 13:10<br>
<b>Para:</b> The DXSpider Support
list <<a href="mailto:dxspider-support@tobit.co.uk" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">dxspider-support@tobit.co.uk</a>><br>
<b>CC:</b> Kin <<a href="mailto:ea3cv@cronux.net" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">ea3cv@cronux.net</a>>;
Keith Maton <<a href="mailto:g6nhu@me.com" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">g6nhu@me.com</a>><br>
<b>Asunto:</b> Re:
[Dxspider-support] New mojo
version</span></p>
</div><div> <br class="webkit-block-placeholder"></div>
<div>
<div><p class="MsoNormal">Hi,</p>
</div>
<div><p class="MsoNormal">Any change on
the router that is doing the port
forward?</p>
</div>
<div><p class="MsoNormal">Maybe there is
ddos protection on it that kick
in.</p>
</div>
<div><div> <br class="webkit-block-placeholder"></div>
</div>
<div><p class="MsoNormal">Are we sure
that the disconnect is coming from
dxspider and not from the router?</p>
</div>
<div><div> <br class="webkit-block-placeholder"></div>
</div>
<div><p class="MsoNormal">I think we have
to take a tcpdump to look at the
tcp flow to understand from where
the TCP RST or FIN is coming from.</p>
</div>
<div><div> <br class="webkit-block-placeholder"></div>
</div>
<div><p class="MsoNormal">If you need
help taking the tcpdump we can
setup a call with screen sharing
and I can guide you.</p>
</div>
<div><div> <br class="webkit-block-placeholder"></div>
</div>
<div><p class="MsoNormal">73</p>
</div>
<div><p class="MsoNormal">Andrea, iz2lsc</p>
</div>
<div><div> <br class="webkit-block-placeholder"></div>
</div>
<div><div> <br class="webkit-block-placeholder"></div>
</div>
<div>
<div><p class="MsoNormal">--></p>
</div>
</div><div> <br class="webkit-block-placeholder"></div>
</div><div> <br class="webkit-block-placeholder"></div>
<div>
<div><p class="MsoNormal">Il giorno sab
21 set 2024 alle ore 13:01 Kin via
Dxspider-support <<a href="mailto:dxspider-support@tobit.co.uk" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">dxspider-support@tobit.co.uk</a>>
ha scritto:</p>
</div>
<blockquote style="border-top:none;border-right:none;border-bottom:none;border-left:1pt solid rgb(204,204,204);padding:0cm 0cm 0cm 6pt;margin-left:4.8pt;margin-right:0cm"><p class="MsoNormal">Hi,<br>
<br>
I have been trying to help Keith
with his problem, and after
analysing<br>
everything I can think of, I can't
see the reason for the
disconnection with<br>
the traces we have.<br>
<br>
This is basically what is
happening to him:<br>
<br>
1726911492^(connect) ExtMsg accept
165:192.168.1.208 from<br>
<a href="http://68.117.200.55:58828/" target="_blank" moz-do-not-send="true">68.117.200.55:58828</a><br>
1726911492^(connect) ExtMsg
connect 165: login: <br>
1726911492^(connect) connect 165:
timeout set to 60<br>
1726911492^(connect) connect 165:
AE5DW<br>
1726911492^(state) AE5DW channel
func state 0 -> prompt<br>
1726911492^(DXCommand) AE5DW
connected from 68.117.200.55 cols
80<br>
1726911492^(progress) CMD:
'unset/beep ' by AE5DW ip:
68.117.200.55 0mS<br>
1726911492^(progress) CMD:
'show/cluster ' by AE5DW ip:
68.117.200.55 0mS<br>
1726911492^(DXCommand) AE5DW
disconnected<br>
<br>
But with the rest of the users it
is not failing.<br>
<br>
Kin EA3CV<br>
<br>
<br>
-----Mensaje original-----<br>
De: Dxspider-support <<a href="mailto:dxspider-support-bounces@tobit.co.uk" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">dxspider-support-bounces@tobit.co.uk</a>>
En nombre de<br>
Keith Maton via Dxspider-support<br>
Enviado el: sábado, 21 de
septiembre de 2024 12:30<br>
Para: The DXSpider Support list
<<a href="mailto:dxspider-support@tobit.co.uk" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">dxspider-support@tobit.co.uk</a>><br>
CC: Keith Maton <<a href="mailto:g6nhu@me.com" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">g6nhu@me.com</a>><br>
Asunto: Re: [Dxspider-support] New
mojo version<br>
<br>
This morning I took a fresh Pi, a
new SSD and built a new node from
scratch.<br>
I copied over the user file and
imported it. I also copied the
spots<br>
directory so no history would be
lost and the filters directory so
my users<br>
would still have their filters.<br>
<br>
I also copied my startup file, my
connect scripts and my crontab.<br>
<br>
I hashed out pretty much
everything in the crontab. I
started the node,<br>
disconnected some links from the
old one and manually started them
on the<br>
new one to confirm I could connect
and get data in.<br>
<br>
Then I stopped the old node and
changed the port forwarding in my
router to<br>
the new one.<br>
<br>
It’s no different. I’m still
getting exactly the same thing.
Some (but not<br>
all) HamClocks are connecting and
then immediately being
disconnected before<br>
they can send any commands. I’m
99.9% sure the disconnect is
coming from<br>
the dxspider and not the HamClock
because HamClock tracks whether
the<br>
disconnect is coming from local or
remote.<br>
<br>
There’s no pattern to this, it
doesn’t seem to be HamClock
version specific<br>
as I sent a sample to the
developer who checked and saw
multiple different<br>
versions.<br>
<br>
The HamClock connects<br>
I see the connection in the debug
log and then immediately, after
two<br>
commands are forced by the node
(unset/beep and show/cluster), the
node<br>
disconnects.<br>
This repeats ten times then the
HamClock stops connecting for one
hour<br>
because it’s reached its hard
limit of ten disconnects/hour. It
only tracks<br>
remote disconnections towards this
limit.<br>
<br>
But the crazy and unexplained
thing is that when I reverted back
to build<br>
536 by restoring a backup, the
same thing is still happening.
Nothing has<br>
changed on my network as the
connections are still making it to
the node.<br>
<br>
I’m really lost here. I feel bad
because there are well over 200
people who<br>
won’t have been able to connect
since Thursday afternoon. They’ve
probably<br>
gone over to other nodes, which is
fine but it doesn’t resolve the
problem<br>
I’ve got here and what could
happen to me could happen to
anyone. I’ve<br>
gone out of my way recently to
push my node as the best for
HamClocks<br>
(because I know a lot of sysops
weren’t happy with it) and now
it’s utterly<br>
rubbish for them.<br>
<br>
I owe it to my users to try and
resolve this but at the moment, I
feel as<br>
though after eight years of
running a node (which I appreciate
is a lot less<br>
than many), I just want to switch
the damn thing off. I’m not going
to,<br>
because I don’t like things to
beat me but it’s very, very
frustrating.<br>
<br>
73 Keith<br>
<br>
<br>
<br>
<br>
> On 21 Sep 2024, at 04:25,
Rene Olsen via Dxspider-support<br>
<<a href="mailto:dxspider-support@tobit.co.uk" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">dxspider-support@tobit.co.uk</a>>
wrote:<br>
> <br>
> Hi.<br>
> <br>
> Still waiting for a replay as
to why G6NHU-2 lost like 75% of
his <br>
> users before I do anything
with the new version.<br>
> <br>
> So, will at least wait until
next week. Like W1NR, I never
update just <br>
> before or during a weekend.<br>
> <br>
> Vy 73 de René / OZ1LQH<br>
> <br>
> On 20 Sep 2024 at 17:44, Kin
via Dxspider-support wrote:<br>
> <br>
>> Hi,<br>
>> <br>
>> The new build is working
very well for me.<br>
>> Only 60 out of 318
dxspider have been updated.<br>
>> Cheer up, it's been in
testing for a while and it's
stable.<br>
>> <br>
>> 73 de Kin EA3CV<br>
>> <br>
>> <br>
>> De: Dxspider-support <<a href="mailto:dxspider-support-bounces@tobit.co.uk" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">dxspider-support-bounces@tobit.co.uk</a>>
En nombre <br>
>> de Dirk Koopman via
Dxspider-support Enviado el:
jueves, 19 de <br>
>> septiembre de 2024 15:24<br>
>> Para: Dxspider-Support
<<a href="mailto:dxspider-support@dxcluster.org" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">dxspider-support@dxcluster.org</a>><br>
>> CC: Dirk Koopman <<a href="mailto:djk@tobit.co.uk" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">djk@tobit.co.uk</a>><br>
>> Asunto:
[Dxspider-support] New mojo
version<br>
>> <br>
>> There is a new mojo
version which has been under test
by a few brave<br>
sysops and they have determined
that it is stable. Please look at
the<br>
Changes file for the list of
issues dealt with.<br>
>> <br>
>> One of the issues that
has become apparent is the random
lock status<br>
(historically) granted to new
nodes that appear on the network.
For some<br>
reason they defaulting to
"unlocked". I don't understand why
this has<br>
suddenly become a problem AGAIN,
but it does seem to affect longer
running<br>
nodes more than newer ones. <br>
>> <br>
>> This release is an
attempt to fix this. It will lock
all nodes that are<br>
not specifically unlocked via
explicit unset/lock or set/spider
type<br>
commands. Unfortunately, previous
attempts to deal with this may
have got<br>
this all confused and it *MAY*
(and I stress this) mean that a
(very) few of<br>
your older node partners *MIGHT*
get locked out. If this happens
then simply<br>
unset/lock or set/spider any of
these nodes manually.<br>
>> <br>
>> There is new spot
deduping code which seems to
reduce the number of<br>
dupes, but since I have not been
able to reproduce this further
than making<br>
sure that nodes that issue
multiple dupe spots with the same
sequence number<br>
don't cause dupes.<br>
>> <br>
>> 73 Dirk G1TLH<br>
>> <br>
> <br>
> <br>
> <br>
> <br>
>
_______________________________________________<br>
> Dxspider-support mailing list<br>
> <a href="mailto:Dxspider-support@tobit.co.uk" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">Dxspider-support@tobit.co.uk</a><br>
> <a href="https://mailman.tobit.co.uk/mailman/listinfo/dxspider-support" target="_blank" moz-do-not-send="true">https://mailmantobit.co.uk/mailman/listinfo/dxspider-support</a><br>
<br>
<br>
_______________________________________________<br>
Dxspider-support mailing list<br>
<a href="mailto:Dxspider-support@tobit.co.uk" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">Dxspider-support@tobit.co.uk</a><br>
<a href="https://mailman.tobit.co.uk/mailman/listinfo/dxspider-support" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">https://mailman.tobit.co.uk/mailman/listinfo/dxspider-support</a><br>
<br>
<br>
_______________________________________________<br>
Dxspider-support mailing list<br>
<a href="mailto:Dxspider-support@tobit.co.uk" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">Dxspider-support@tobit.co.uk</a><br>
<a href="https://mailman.tobit.co.uk/mailman/listinfo/dxspider-support" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">https://mailman.tobit.co.uk/mailman/listinfo/dxspider-support</a></p>
</blockquote>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</blockquote>
</div>
<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>
</div>
_______________________________________________<br>Dxspider-support mailing list<br>Dxspider-support@tobit.co.uk<br>https://mailman.tobit.co.uk/mailman/listinfo/dxspider-support<br></div></blockquote></div><br></div></body></html>