|
From: Jim S. <jse...@Li...> - 2022-04-01 17:49:31
|
On Wed, 23 Mar 2022 10:18:54 -0700
Kevin Zheng <kev...@gm...> wrote:
> On 3/15/22 10:41 AM, Jim Seymour wrote:
> > Perhaps there should be a subsequent test, after the options are
> > all processed, to make sure pardon > stale and issue a warning if
> > not? Perhaps also automatically bump pardon by, say, 120 seconds
> > over stale if that happens?
>
> Do you mean that the stale time should be longer than the pardon
> time, not the other way around?
Nope :)
Because, as I noted: If stale time > pardon time and their attack
rate interval is longer than pardon time, then they'll get however
many bites of the apple they get until pardon time eventually
increases far enough.
E.g.:
Initial pardon time: 840 sec.
Stale time: 1200 sec.
Attack interval: 1000 sec.
They trigger a block. It's put in place for ~840 sec., then released.
±160 sec. later they strike again. Then, after three more hits
(assuming default dangerousness: 10, and accumulated dangerousness
is reset when the block is released [another assumption on my part]),
they get blocked for 1680 sec. *Then*, only after another four shots
at the target, are they actually blocked.
>
> For context, "pardon time" in the code refers to what is called
> "blocktime" in the man page, which is:
>
[snip]
>
> And "stale time" in the code is the "detection_time":
>
[snip]
>
> So if stale < pardon, each time an attacker gets blocked, it would
> be considered it's first time (because the attacker would have been
> forgotten by the stale threshold).
Ah. My bad. I'd *assumed* "stale" wouldn't get reset until "stale
time" after a block was removed.
Doing so would solve both problems, no?
Unless I'm misunderstanding how these times are used and I'm
completely off in the weeds :)
Regards,
Jim
--
Note: My mail server employs *very* aggressive anti-spam
filtering. If you reply to this email and your email is
rejected, please accept my apologies and let me know via my
web form at <http://jimsun.LinxNet.com/contact/scform.php>.
|