View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001335 | unreal | ircd | public | 2003-11-02 23:18 | 2004-10-06 22:12 |
| Reporter | Cnils | Assigned To | syzop | ||
| Priority | normal | Severity | feature | Reproducibility | N/A |
| Status | resolved | Resolution | fixed | ||
| Fixed in Version | 3.2.2 | ||||
| Summary | 0001335: Preventing flooding when q-lined nicks connects | ||||
| Description | To prevent the connection notice floods you can get if a q-lined nick is used - Would it be possible to allow the use of the NICK command on connects only once to prevent it. If not, at least trhottle it's usage. | ||||
| Tags | No tags attached. | ||||
| 3rd party modules | |||||
|
|
Do you mean pre-registered q-lined notices, or when 2 servers link? (the latter should be fixed in beta18, unless you have non-b18 servers) |
|
|
The former. Q-lines set by services. |
|
|
For 'additional Infos', look http://bugs.unrealircd.org/bug_view_advanced_page.php?bug_id=0001436 I am only making /mode Rocko +s -q Seeing, that someone floods like that way, every few hours, is to much stress :P |
|
|
i have also noticed since the release of 3.2-RC1, that when services connects, now its q:Lines show up as *** Permanent Global Q:Line etc etc etc Problem is, if u got a few bots on your botserv (like about 30 or so) it floods all the IRCops with the notice. Maybe we need to put that back the way it was (no notice), or make the notices optional in setup config...? (since these notices would go to the TKL snomask, right?) |
|
|
The snomask is "q", what do you think, why I wrote, that I use "/mode Rocko +s -q" ??? Since there isn't a way to protect from q:line notices flood, there is an extra snomask, otherwise you would go crazy when you can't disable it :P |
|
|
Semi-solved in .147: - If a nick is qlined, the user is now lagged up to limit qline floods a bit (0001335). I did some research and noticed that a user (eg: in pre-register state) could generate such notices like *14x* in 4 seconds.. this was because in case of a unsuccesfull qline nick the user did not receive any extra lag, did so now.. now it's just like 3 in 4 seconds, and every time they try to use a qlined nick they are lagged up an additional 4 seconds. This is pretty much all I can/will do, but I think this pretty much solves most of the problems ;). |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2003-11-02 23:18 | Cnils | New Issue | |
| 2003-11-02 23:32 | syzop | Note Added: 0003932 | |
| 2003-11-03 07:36 | Cnils | Note Added: 0003947 | |
| 2004-03-13 14:04 | Rocko | Note Added: 0005455 | |
| 2004-07-14 23:53 | Zell | Note Added: 0007075 | |
| 2004-07-15 03:24 | Rocko | Note Added: 0007084 | |
| 2004-10-06 22:12 | syzop | Status | new => resolved |
| 2004-10-06 22:12 | syzop | Fixed in Version | => 3.2.2 |
| 2004-10-06 22:12 | syzop | Resolution | open => fixed |
| 2004-10-06 22:12 | syzop | Assigned To | => syzop |
| 2004-10-06 22:12 | syzop | Note Added: 0007890 |
