[Dxspider-support] New mojo version

[Keith Maton]

Additionally to this, I noticed that from yesterday morning, the number of disconnects actually started reducing.  Looking at my users chart on the mrtg page <http://g6nhu.getmyip.com:1090/dump1090-fa/mrtg/stats.html> and going through the debug log, there were people who had previously been getting the disconnect, who were getting on.  I was actually up to around 130 users this morning.  Now I’ve restarted again, I’m back down to under 50,

Why would dxspider disconnect people for a while and then start accepting them?  Is there some kind of flood control going on here?

I really don’t understand why this is happening.



> On 21 Sep 2024, at 11:30, Keith Maton <g6nhu at me.com> wrote:
> 
> This morning I took a fresh Pi, a new SSD and built a new node from scratch.  I copied over the user file and imported it.  I also copied the spots directory so no history would be lost and the filters directory so my users would still have their filters.
> 
> I also copied my startup file, my connect scripts and my crontab.
> 
> I hashed out pretty much everything in the crontab.  I started the node, disconnected some links from the old one and manually started them on the new one to confirm I could connect and get data in.
> 
> Then I stopped the old node and changed the port forwarding in my router to the new one.
> 
> It’s no different. I’m still getting exactly the same thing.  Some (but not all) HamClocks are connecting and then immediately being disconnected before they can send any commands.  I’m 99.9% sure the disconnect is coming from the dxspider and not the HamClock because HamClock tracks whether the disconnect is coming from local or remote.
> 
> There’s no pattern to this, it doesn’t seem to be HamClock version specific as I sent a sample to the developer who checked and saw multiple different versions.
> 
> The HamClock connects
> I see the connection in the debug log and then immediately, after two commands are forced by the node (unset/beep and show/cluster), the node disconnects.
> This repeats ten times then the HamClock stops connecting for one hour because it’s reached its hard limit of ten disconnects/hour.  It only tracks remote disconnections towards this limit.
> 
> But the crazy and unexplained thing is that when I reverted back to build 536 by restoring a backup, the same thing is still happening.  Nothing has changed on my network as the connections are still making it to the node.
> 
> I’m really lost here.  I feel bad because there are well over 200 people who won’t have been able to connect since Thursday afternoon.  They’ve probably gone over to other nodes, which is fine but it doesn’t resolve the problem I’ve got here and what could happen to me could happen to anyone.   I’ve gone out of my way recently to push my node as the best for HamClocks (because I know a lot of sysops weren’t happy with it) and now it’s utterly rubbish for them.
> 
> I owe it to my users to try and resolve this but at the moment, I feel as though after eight years of running a node (which I appreciate is a lot less than many), I just want to switch the damn thing off.  I’m not going to, because I don’t like things to beat me but it’s very, very frustrating.
> 
> 73 Keith
> 
> 
> 
> 
>> On 21 Sep 2024, at 04:25, Rene Olsen via Dxspider-support <dxspider-support at tobit.co.uk> wrote:
>> 
>> Hi.
>> 
>> Still waiting for a replay as to why G6NHU-2 lost like 75% of his users before I do anything with 
>> the new version.
>> 
>> So, will at least wait until next week. Like W1NR, I never update just before or during a 
>> weekend.
>> 
>> Vy 73 de René / OZ1LQH
>> 
>> On 20 Sep 2024 at 17:44, Kin via Dxspider-support wrote:
>> 
>>> Hi,
>>> 
>>> The new build is working very well for me.
>>> Only 60 out of 318 dxspider have been updated.
>>> Cheer up, it's been in testing for a while and it's stable.
>>> 
>>> 73 de Kin EA3CV
>>> 
>>> 
>>> De: Dxspider-support <dxspider-support-bounces at tobit.co.uk> En nombre de Dirk Koopman via Dxspider-support
>>> Enviado el: jueves, 19 de septiembre de 2024 15:24
>>> Para: Dxspider-Support <dxspider-support at dxcluster.org>
>>> CC: Dirk Koopman <djk at tobit.co.uk>
>>> Asunto: [Dxspider-support] New mojo version
>>> 
>>> There is a new mojo version which has been under test by a few brave sysops and they have determined that it is stable. Please look at the Changes file for the list of issues dealt with.
>>> 
>>> One of the issues that has become apparent is the random lock status (historically) granted to new nodes that appear on the network. For some reason they defaulting to "unlocked". I don't understand why this has suddenly become a problem AGAIN, but it does seem to affect longer running nodes more than newer ones. 
>>> 
>>> This release is an attempt to fix this. It will lock all nodes that are not specifically unlocked via explicit unset/lock or set/spider type commands. Unfortunately, previous attempts to deal with this may have got this all confused and it *MAY* (and I stress this) mean that a (very) few of your older node partners *MIGHT* get locked out. If this happens then simply unset/lock or set/spider any of these nodes manually.
>>> 
>>> There is new spot deduping code which seems to reduce the number of dupes, but since I have not been able to reproduce this further than making sure that nodes that issue multiple dupe spots with the same sequence number don't cause dupes.
>>> 
>>> 73 Dirk G1TLH 
>>> 
>> 
>> 
>> 
>> 
>> _______________________________________________
>> 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/20240921/cbf51288/attachment-0001.htm>