Sergey G. Brester

> it is reacting to something that already happened up to a second ago. Typical latency (for fail2ban versions >= 0.10) is few milliseconds only. If you have larger delays...

> Without clearing the state an attacker is able to keep the connection open and to continue the attack I doubt it, because the ban occurs after failure, recognized from...

You have not understood what I wanted to say you... BTW, I'm not against this as "enhancement". Even possibly to enable it per default... But I'll try to explain what...

You still not understood me... > There's no need to be offensive. Hmmm... where? > if you aren't interested in fixing or improving. Sure we're interested, but for real fixing....

Corresponding man of pfctl: > -F states - Flush the state table (NAT and filter). Together with: > -a anchor - Apply flags -f, -F, and -s only to the...

Currently I've tried the old pf-syntax (without modifications) on a freebsd-vm with generic kernel (default settings)... Conclusion: The kill `pfctl -k ` seems to be not necessary at all, because...

> can continue brute forcing quite undisturbed For how long? I mean, is it sure not just the rest of the submitted buffer resp. fail2ban latency withing filter-backend?

I would like to understand why I cannot reproduce it... The statement "until TTL expires" does not really explained it. But again, I'm not against "kill states", but if properly......

@catsem, @IdahoPL, @distler, @koeppea, @fail2ban/contributors I want really close this issue, but I can't as long as I can't get it reproduced on my reference-systems (having pf). Thus a proposal:...

You are wrong a bit in the abovementioned case, - I meant not `pfctl` but ``, thus in our case it interpolates to anchored `pfctl -a ... -F states`.