View Issue Details

IDProjectCategoryView StatusLast Update
0000481unrealdocumentationpublic2003-11-20 19:46
ReporterJimmyZ Assigned Tosyzop  
PrioritynormalSeverityminorReproducibilityalways
Status closedResolutionfixed 
PlatformIntelOSFreeBSDOS Version4.5
Product Version3.2-beta12 
Summary0000481: Problem with channel flood protection (+f)
DescriptionI've been seeing a problem with channel mode +f on my servers, where it sems to be kicking users who have not actually exceeded the flood settings. I have it set to +f 8:10 (8 lines in 10 seconds) but I keep seeing users getting kicked with 8 lines in 20 or even 30 or more seconds. Here's my theory: if one of the servers is lagged a bit it could recieve an entire conversation in one burst instead of in real time. This would cause the 8 lines that a user may have typed over 30 or more seconds to hit the lagged server all at once and look like a flood.

Aside from the obvious (try to get rid of the lag), can anyone think of a workaround or fix for this problem? Is there any way to get servers to ignore channel mode +f? I was thinking if this was possible that I could leave one server (on a better connection) with +f enabled to do flood checking.

Thanks in advance
Joe Carroll
irc.j-body.org
TagsNo tags attached.
3rd party modules

Activities

JimmyZ

2002-11-26 21:13

reporter   ~0000741

Another thought I had, related to the possibility of lagged servers kicking users it thinks are flooding...

Most of the times I've seen users kicked in this manner it has been by a server other than the one they're connected to, which is where my lag theory came from. Would it be possible to restrict flood-kicking a user to only the server they're on?

Griever

2002-11-30 20:15

reporter   ~0000768

Documentation problem

+f 10:2 means it will kick you if you send 10 messages WITHOUT STOPPING FOR 2 SECONDS!

this is misdocumented and causes lots of confusion, someone fix.

JimmyZ

2002-12-01 00:15

reporter   ~0000777

I understand how it's "supposed" to work. Like I said, I have it set for 8 lines in 10 seconds. Sometimes users have been kicked from the channel and when I go back and count the lines in my client their last 8 lines have taken place over 20, or sometimes even 30 or more seconds. Not nearly enough of a flood to trigger a kick, but one of the servers is kicking them anyway. I also looked at the logs of the eggdrop bot in one of the channels (which lives on the same box as one of the ircd's) and the itmes were about the same as in my client.

Like I said, I think it's being caused by lag between the servers that's causing one of them to see a burst of messages that actually took place over a longer period of time.

The trick is what to do about it.....

JimmyZ
irc.j-body.org

Rocko

2003-04-05 14:34

reporter   ~0002109

Well, I experienced this bug for a long time too.

It is not caused, because the servers are lagging. I don´t think that.
Then they must lag the whole time they are online.

I had the setting +f *15:15, and the user got kickbanned, and he haven´t said more than 9 lines in 45 seconds.
The ban was set from the server, which the user was on.

The other example, (the same user, 10 mins ago) the setting was +f *8:10, the user got kickbanned, and he haven´t said more than 8 lines in 37 seconds.

Thats very wierd. Because the server don´t ban immediately AFTER the user said the last sentence, it bans 4 seconds after it in the first example, and 2 seconds in the second example. The Server haven´t lagged !

And it´s not a documentation thing !
Thats a bug.

syzop

2003-04-05 20:58

administrator   ~0002111

Yep. It's because the "algoritm" sucks. With +f 15:15, as long as the person says something every 14s (or something) he will be kicked after 14*15=70s. I've showed it to stskeeps already a month ago. I also had an idea to make it better but I didn't code it... I don't get paid for this eh ;).

syzop

2003-04-13 16:40

administrator   ~0002296

Now fixed in CVS.
[technical]
from:
/* Theory here is
   If current - lastmsgtime <= mode.per
   and nummsg is higher than mode.msgs
   then kick
 */
to:
/* if current - firstmsgtime >= mode.per, then reset,
 * if nummsg > mode.msgs then kick/ban
 */
[/technical]

Issue History

Date Modified Username Field Change
2003-04-13 16:40 syzop Status confirmed => resolved
2003-04-13 16:40 syzop Resolution open => fixed
2003-04-13 16:40 syzop Assigned To => syzop
2003-04-13 16:40 syzop Note Added: 0002296
2003-11-20 19:46 syzop Status resolved => closed