View Issue Details

IDProjectCategoryView StatusLast Update
0004470unrealdocumentationpublic2015-12-09 20:38
Reporterblank Assigned Tosyzop  
PrioritynormalSeverityminorReproducibilityhave not tried
Status resolvedResolutionfixed 
Fixed in Version4.0.0-rc5 
Summary0004470: connect-flood and WebIRC users
Descriptionconnect-flood doesn't seem to use the passed real IP address but the server IP address causing users to receive notices about being throttled as they're connecting from

workaround: use except throttle {}; block as suggested by DBoyz

can it be changed to perform the connect-flood checking on the passed real IP address instead?
TagsNo tags attached.
3rd party modules


related to 0004489 closedsyzop connect-flood and WebIRC users 



2015-11-28 11:56

administrator   ~0018887

* connect-flood is checked right after accept() - so when the tcp/ip connection is established but no data has been read or processed yet
* the IRCd only knows that something is a webirc connection after it has received the WEBIRC command (or the old pass style)

So in that respect there's no way to reverse the check.

What I _could_ do is, as soon as the WEBIRC command is received and authenticated, delete the entry holding that particular IP in the connect-flood table. That could work.
BUT, if there is enough lag between accepting the tcp/ip connection and reading the WEBIRC line, then connections may still be considered as flooding.

So: either implement a solution that "works most of the time" or add clear documentation saying you should add an except throttle block.

Irrespective of the above there is another request in this report: connection throttling based on the user IP passed by WEBIRC. I suppose that could be added, yes. I do feel that the webirc server also has a responsibility here, though.


2015-11-28 11:59

administrator   ~0018888

I've updated the example at


2015-12-09 20:30

reporter   ~0018911

I'd go for the second option (documentation) as it's cleaner.


2015-12-09 20:37

administrator   ~0018913

I agree. I'm marking this as fixed since the documentation has been updated.

I've split off the other request to 0004489

Issue History

Date Modified Username Field Change
2015-11-26 14:07 blank New Issue
2015-11-28 11:56 syzop Note Added: 0018887
2015-11-28 11:59 syzop Note Added: 0018888
2015-12-09 20:30 blank Note Added: 0018911
2015-12-09 20:35 syzop Category ircd => documentation
2015-12-09 20:36 syzop Issue cloned: 0004489
2015-12-09 20:36 syzop Relationship added related to 0004489
2015-12-09 20:37 syzop Note Added: 0018913
2015-12-09 20:37 syzop Status new => resolved
2015-12-09 20:37 syzop Fixed in Version => 4.0.0-rc5
2015-12-09 20:37 syzop Resolution open => fixed
2015-12-09 20:37 syzop Assigned To => syzop