[Dxspider-support] Fwd: Max Spot per Minute (how to avoid flooding)

Fri Jan 24 13:37:46 GMT 2025

We seem to be starting to lose the "battle" between nodes <-> users on 
client programs issuing data (for whatever reason).

The piece of code shown below was introduced in March 2023, together 
with the following comment underneath:

    These default values are set generously deliberately to allow 
certain user
    programs to get with the program and reduce the number of cmds that they
    issue on connection down to something reasonable. For instance, I cannot
    see why things like name, qth, lat/long/QRA (amongst several other 
sticky
    user attributes that only need to be entered once) are sent on every 
login.

It is clear to me that the situation has got worse and the time to 
tighten the defaults has arrived. In addition, I will add a general 
re-login delay so that programs cannot instantly reconnect and just 
carry on. Maybe with a second/other safeguard of recording the IP 
address rather than the callsign with an backoff timer after Z number of 
"fast" attempts to re-login. Or something like that (maybe a timed local 
IP address ban?).

I will happily accept suggestions for "better" values for X = 16 and Y = 
9 below. As well as other ways of discouraging this sort of behaviour.

I fail to understand the point of spotting an entire FTx channel's 
decoded callsigns. You haven't worked them, your program just heard 
them, but you're probably drinking tea and working someone else OR 
you've simply left the computer on whilst going out for the day. This, 
incidentally, is why I won't, ever, gate out raw skimmer spots to users. 
Speaking of which: the FTx skimmer network will likely do a better job 
than your random user "skimmer" so why not just connect to that instead!

This person appears to have taken it upon himself (gender deliberately 
chosen) to become an FTx skimmer that gates his data out into the 
general spot pool. But he could not do this unless the CLIENT SOFTWARE 
he is using provides that facility. So the obvious solution to this is 
to try to identify the author(s) of the client software and persuade 
them to not allow this sort of thing to occur. Experience shows that 
authors are reluctant to change the behaviour of their creations (I can 
understand that) and simply ignore requests for changes from "outside" 
their user communities. It probably takes at least 15 years of full time 
professional programming before one truly believes that all software has 
bugs, or undesirable behaviours that have been discovered by users that 
require changes. Unfortunately many authors are hobby programmers and 
resistant to external pressure for change. Probably, because their 
software is written in a way that makes it too difficult to change. I 
remember that :-)

As I have been writing this, I am starting to get a bit annoyed by the 
thoughtlessness of some authors and users. So I will implement an 
linearly increasing IP address ban time, together with message on login 
(with a fixed delay of say 10 secs before forced disconnect) saying 
something like "You are sending too many commands too quickly, you are 
banned from reconnecting until <date/time>". Obviously if they reconnect 
and do it again (within some interval) they will be have more time added 
- and - "good behaviour" over a period of time will reduce their penalty 
ban time.

Your thoughts and suggestions for default values for these times / 
intervals will be gratefully received.

73 Dirk G1TLH

On 21/01/2025 21:31, IZ2LSC via Dxspider-support wrote:
> I know there is the following knob, but if the originating node is not 
> up to date (or is not a spider), then the flood is sent into the network.
>
>    Added cmd entry rate limiting. If a user sends X commmands in Y 
> secs then
>    they are disconnected without notice. The defaults are X
>    ($DXCommandmode::maxcmdcount) = 16 and Y 
> ($DXCommandmode::cmdinterval) = 9.
>
>
> Andrea, IZ2LSC
>
> -->
>
>
> On Tue, Jan 21, 2025 at 10:07 PM <ea3cv at cronux.net> wrote:
>
>     The only thing I can think of is to treat spotter+time as a
>     duplicate variant within a 1s window.
>     I don't know if Dirk has something implemented.
>     I'll look tomorrow, I'm curious.
>
>     Kin
>
>
>     Enviado desde Outlook para Android <https://aka.ms/AAb9ysg>
>
>     ------------------------------------------------------------------------
>     *De:* Dxspider-support <dxspider-support-bounces at tobit.co.uk> en
>     nombre de IZ2LSC via Dxspider-support <dxspider-support at tobit.co.uk>
>     *Enviado:* martes, enero 21, 2025 9:30:48 p. m.
>     *Para:* The DXSpider Support list <dxspider-support at tobit.co.uk>
>     *CC:* IZ2LSC <iz2lsc.andrea at gmail.com>
>     *Asunto:* [Dxspider-support] Fwd: Max Spot per Minute (how to
>     avoid flooding)
>
>     Hi sysops!
>     I was reviewing my cluster stats when I noticed this spike in spot
>     per minute (see attached image).
>
>     immagine.png
>
>
>     Looking at the logs I can see a flood of 55 spots coming in the
>     same second from the same user, an extract below:
>
>     7074.4^DH2YBG^1737474360^FT8^KC9LFD^32^226^DB0ERF-5^28^14^8^4^^^204.93.149.214
>     7074.4^GM6URC^1737474360^FT8^KC9LFD^65^226^DB0ERF-5^27^14^8^4^^^204.93.149.214
>     7074.4^N5TLH^1737474360^FT8^KC9LFD^226^226^DB0ERF-5^7^4^8^4^^^204.93.149.214
>     7074.4^LA8ENA^1737474360^FT8^KC9LFD^123^226^DB0ERF-5^18^14^8^4^^^204.93.149.214
>     7074.4^P40AA^1737474360^FT8^KC9LFD^326^226^DB0ERF-5^11^9^8^4^^^204.93.149.214
>     7074.4^F5SJF^1737474360^FT8^KC9LFD^42^226^DB0ERF-5^27^14^8^4^^^204.93.149.214
>     7074.4^VK2WN^1737474360^FT8^KC9LFD^198^226^DB0ERF-5^59^30^8^4^^^204.93.149.214
>     7074.4^N1UL^1737474360^FT8^KC9LFD^226^226^DB0ERF-5^8^5^8^4^^^204.93.149.214
>     7074.4^KA9SOG^1737474360^FT8^KC9LFD^226^226^DB0ERF-5^8^4^8^4^^^204.93.149.214
>     7074.4^VK3YW^1737474360^FT8^KC9LFD^198^226^DB0ERF-5^59^30^8^4^^^204.93.149.214
>     7074.4^N9IBM^1737474360^FT8^KC9LFD^226^226^DB0ERF-5^8^4^8^4^^^204.93.149.214
>     7074.4^W5ORC^1737474360^FT8^KC9LFD^226^226^DB0ERF-5^8^5^8^4^^^204.93.149.214
>     7074.4^KP2BH^1737474360^FT8^KC9LFD^119^226^DB0ERF-5^11^8^8^4^^^204.93.149.214
>     3573.4^K8CW^1737474360^FT8^KC9LFD^226^226^DB0ERF-5^8^4^8^4^^^204.93.149.214
>     3573.4^P40AA^1737474360^FT8^KC9LFD^326^226^DB0ERF-5^11^9^8^4^^^204.93.149.214
>     3573.4^K1TAP^1737474360^FT8^KC9LFD^226^226^DB0ERF-5^8^5^8^4^^^204.93.149.214
>
>
>     Is there a way to activate a sort of flooding protection?
>
>
>     Thanks and 73
>
>
>     Andrea, IZ2LSC
>
>
>
> _______________________________________________
> 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/20250124/c438c82f/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: immagine.png
Type: image/png
Size: 33364 bytes
Desc: not available
URL: <https://mailman.tobit.co.uk/pipermail/dxspider-support/attachments/20250124/c438c82f/attachment-0001.png>