[Dxspider-support] FTx autogenerated spots
Christopher Schlegel
sutehk.cs at gmail.com
Tue Mar 18 13:55:38 GMT 2025
You are absolutely correct, Ciemon. However, we can't sit back and expect
Dirk to do all the documentation. We, as sysops, need to help. I took the
liberty of putting a bit about the wiki in my MOTD to help advertise that
location. I know you have helped me with the wiki and have put some effort
in to remediating this issue.
I'd say a good starting point to your questions would be to start a new
thread with a topic question of "What should a new sysop know?" Compile a
list of questions/issues and provide the answers.
This is something I would gladly help out with.
73, Chris WI3W
On Tue, Mar 18, 2025, 09:08 Ciemon Dunville via Dxspider-support <
dxspider-support at tobit.co.uk> wrote:
> Ah, in the lab, a good place to start.
>
> I guess that with a lot of this work that's going on here part of the
> problem is that the users generally don't know.. anything, because cluster
> practises (rather than the configurations discussed here) is not documented
> anywhere useful.
>
> Why shouldn't 800 people connect to one node, why should 20 nodes spoke
> off one, why shouldn't people spot and re-spot, why shouldn't we advertise
> nodes through announcements, why shouldn't people flood-spot, why should
> you contact a sysop before you try to establish a node-to-node link etc
> etc. Are any of these things bad? Aren't they all?
>
> What is the webcluster strategy for the delivery of timely spots to the
> world, by the world? Where is it stated?
>
> ---
> Ciemon Dunville - GØTRT <https://www.qrz.com/db/G0TRT>
> Warminster, Wiltshire. UK
>
>
>
>
> On Tue, 18 Mar 2025 at 12:51, IZ2LSC <iz2lsc.andrea at gmail.com> wrote:
>
>> I Ciemon,
>> it was just a different approach, not yet implemented because I'm sure
>> Dirk could do something better.
>> I'm just doing some experiments on a lab node.
>>
>> 73s
>>
>> Andrea
>> -->
>>
>>
>> On Tue, Mar 18, 2025 at 11:48 AM Ciemon Dunville via Dxspider-support <
>> dxspider-support at tobit.co.uk> wrote:
>>
>>> Andrea,
>>>
>>> I'm curious as to whether or not your rate limiting applies to your (you
>>> only) 'OTA cluster? Or are you not forwarding spots into those systems?
>>>
>>> Having just had a look, I can't see any mention of you rate limiting
>>> spots on your cluster, it would be useful to understand your
>>> thinking/levels etc
>>>
>>> 73, Ciemon
>>>
>>> ---
>>> Ciemon Dunville - GØTRT <https://www.qrz.com/db/G0TRT>
>>> Warminster, Wiltshire. UK
>>> Sysop @G0TRT-9
>>>
>>>
>>>
>>>
>>> On Tue, 18 Mar 2025 at 08:46, IZ2LSC via Dxspider-support <
>>> dxspider-support at tobit.co.uk> wrote:
>>>
>>>> Because I don't tolerate serial spotters (human or robot, SSB or DATA
>>>> or CW), my approach is different and radical.
>>>> If a spotter exceeds a threshold of spots/m it is blacklisted for a
>>>> certain time.
>>>>
>>>> 73s
>>>>
>>>> Andrea, iz2lsc
>>>>
>>>> -->
>>>>
>>>>
>>>> On Tue, Mar 18, 2025 at 3:28 AM Christopher Schlegel via
>>>> Dxspider-support <dxspider-support at tobit.co.uk> wrote:
>>>>
>>>>> Agreed on the update point...
>>>>>
>>>>> And I see your point on the likeness of the auto generation, but I'm
>>>>> going to play devil's advocate here. In the last week the K index has been
>>>>> horrible for barefoot and a wire operators leading to an increase in
>>>>> digital mode activity. I am one of these operators. Now, I don't care for
>>>>> auto generated spots and have it disabled as I feel that I can filter the
>>>>> spots better than just automagically letting it happen (my opinion). I am
>>>>> capable and educated (through effort) enough to do that. I understand the
>>>>> argument for general users and their capabilities, ignorance is not an
>>>>> excuse at some point. Perhaps an education campaign by sysops could help
>>>>> the situation, but that's a losing battle as well. Proven by Kin's efforts.
>>>>> Gives me the idea to put a link to the wiki in the MOTD.
>>>>>
>>>>> Most software that I have been exposed to will automatically spot (if
>>>>> set) when a contact has been logged. No different than an overzealous
>>>>> spotter at say a few spots a minute. The gotcha here is that the
>>>>> information is valid (as much as any manually entered spot) and authentic
>>>>> to the contact. Even during contests, if all QSOs were automatically
>>>>> spotted of even the best CW 2BSIQ operators you're looking at maybe 9 spots
>>>>> per minute by various call signs. 500 QSOs/hr / 60min = 8.33 spots/min
>>>>> (exaggerated for headroom)
>>>>>
>>>>> I think there is merit in the idea of rate limiting, at least in
>>>>> mitigating the effect of flooding. Websites and other software (thinking
>>>>> PSKReporter, rate limiting login attempts, etc.) do this all the time. The
>>>>> deduping algorithms employed in the cluster (haven't forgotten the bypass)
>>>>> do to some extent but not in the manner needed.
>>>>>
>>>>> Authenticity of spots is a separate issue to me. As you mentioned
>>>>> previously, the cluster is far too disparate and open to truly fix that
>>>>> issue while being inclusive to older technologies and formats. Again, we
>>>>> mirror the greater Internet at this point and trying to get everyone on
>>>>> board is like pulling teeth. Do we use the greater share that Spider nodes
>>>>> have to force a movement? Is it worth an essentially civil war at this
>>>>> point alienating older nodes? I don't think this is in the spirit of
>>>>> Amateur Radio nor is keeping everything a secret by way of going closed
>>>>> source. I applaud Dirk's efforts here in adhering to the spirit. If someone
>>>>> used my radio gear to broadcast a commercial transmission, would I not have
>>>>> the responsibility to prevent that and suffer the consequences that follow?
>>>>>
>>>>> Sysops need to wake up and pay attention. These attacks are coming
>>>>> from somewhere, there has to be a way to find the holes and do what we can
>>>>> to patch them. My personal opinion is that I provide a service and
>>>>> compromising that to solve a problem is the easy way out. I would
>>>>> respectfully request that these changes remain optional so that I can
>>>>> provide the service to users the way I believe it should be. Some other
>>>>> sysops have already filtered out FTx spots on their nodes and advertise
>>>>> them that way. I do not filter announcements so any user that would prefer
>>>>> that, is able to see them and make that choice for themselves.
>>>>>
>>>>> It has been danced around on this list and I'm just going to go and
>>>>> outright say it...sysops that are absent or apathetic perhaps need to be
>>>>> disconnected as a warning or make their nodes inaccessible to the public. A
>>>>> culling of sorts to prune the dead weight and reduce the vulnerable attack
>>>>> surface. This I feel is the real vulnerability of the system that gets
>>>>> exploited. Checking in once in a while or paying attention to communication
>>>>> from a group that a sysop directly affects is the first and foremost thing
>>>>> we can do to cooperate on keeping things healthy. I for one will keep
>>>>> paying attention in hopes of finding that slip that lets us figure out the
>>>>> hole and I will continue to work with other sysops here in that effort.
>>>>>
>>>>> As always, I am not a developer, but I will respect the decisions of
>>>>> the group and the developer who has so graciously spent his time providing
>>>>> the software needed to provide this service to the hobby.
>>>>>
>>>>> 73, Chris WI3W
>>>>>
>>>>> Sorry for the rant like prose, but a call to arms is needed...
>>>>>
>>>>>
>>>>> On Mon, Mar 17, 2025, 18:58 Dirk Koopman <djk at tobit.co.uk> wrote:
>>>>>
>>>>>> Which is the place that I am coming from. Maybe, in this case, on
>>>>>> somewhat specious grounds but is precisely in the light of the recent
>>>>>> uptick in
>>>>>> attacks on the network that caused me to do this.
>>>>>>
>>>>>> Please bear in mind that the network was recently used to promote and
>>>>>> facilitate someone’s commercial activity by sending genuine (looking) spots
>>>>>> by irregular means. But ignoring the whys and wherefores of the
>>>>>> circumstances: consider the nature of the generation. The majority of those
>>>>>> spots were automatically generated by design. Just like these spots AND
>>>>>> they too were then modified by some people to get around the filters - just
>>>>>> like the spots causing the recent flooding.
>>>>>>
>>>>>> They were designed to affirm rather than inform the user. The system
>>>>>> generated them rather than the user. As sysops and I struggled to contain
>>>>>> the flood, and the resulting vendetta that ensued, caused even more
>>>>>> problems and has led me to conclude that any automated spots are to be
>>>>>> discouraged or removed.
>>>>>>
>>>>>> Some years ago I had a similar spat with an author about automated
>>>>>> FTx spots. Which went nowhere. The volume may not be the same but these
>>>>>> spots annoy many, many users when they appear in large runs as they did
>>>>>> (for a time) this afternoon. Hence this little experiment.
>>>>>>
>>>>>> Users are not literate enough to (force their user programs to)
>>>>>> create filters for themselves*. Either I have to provide a mechanism or
>>>>>> sysops have to each create a local command / filter to do it for them.
>>>>>>
>>>>>> Anyway I shall be merging the test branch tomorrow (with this feature
>>>>>> switched off) and I’ll do something about a user version as well (maybe
>>>>>> disable/ftx) with a sysops function to allow or disable Ftx spots for users
>>>>>> as well. Maybe that will mean that the nodes running very old software
>>>>>> offering this as a selling point might upgrade. Sigh.
>>>>>>
>>>>>> 73 Dirk G1TLH
>>>>>>
>>>>>> * In the last couple of days I have had a request from a user to fix
>>>>>> his filters for Hamclock.
>>>>>>
>>>>>> > On 17 Mar 2025, at 19:19, Christopher Schlegel <sutehk.cs at gmail.com>
>>>>>> wrote:
>>>>>> >
>>>>>> > Flooding, providing false info, or other abuses to the cluster is
>>>>>> our domain as it directly relates to the above sysop responsibilities.
>>>>>>
>>>>> _______________________________________________
>>>>> Dxspider-support mailing list
>>>>> Dxspider-support at tobit.co.uk
>>>>> https://mailman.tobit.co.uk/mailman/listinfo/dxspider-support
>>>>>
>>>> _______________________________________________
>>>> Dxspider-support mailing list
>>>> Dxspider-support at tobit.co.uk
>>>> https://mailman.tobit.co.uk/mailman/listinfo/dxspider-support
>>>>
>>> _______________________________________________
>>> Dxspider-support mailing list
>>> Dxspider-support at tobit.co.uk
>>> https://mailman.tobit.co.uk/mailman/listinfo/dxspider-support
>>>
>> _______________________________________________
> 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/20250318/e2b2ac70/attachment.htm>
More information about the Dxspider-support
mailing list