View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0006580 | unreal | ircd | public | 2025-09-23 17:48 | 2025-10-25 15:32 |
| Reporter | rafaelgrether | Assigned To | syzop | ||
| Priority | low | Severity | minor | Reproducibility | always |
| Status | resolved | Resolution | fixed | ||
| Product Version | 6.2.0.2 | ||||
| Summary | 0006580: default profile for +F (transparency for chanops/users) | ||||
| Description | Hi, This is not necessarily a bug, maybe more of an improvement(?)... When a sysadmin sets a default-profile in the anti-flood setting like: anti-flood { channel { default-profile very-strict; } } Channel owners are not aware of this, because in the channel the mode +F <something> is not explicitly shown. When the limit is exceeded, the restriction mode occurs, like: *** Channel msg/noticeflood detected (limit is 30 per 15 seconds), setting mode +M But the chanop doesn’t know why this happened, since there is no explicit +F mode set in the channel. Most likely many chanops will contact IrcOps to understand what happened. If the mode +F <something> appeared explicitly in the channel, the channel owners would know the reason and could then change the +F to another profile if convenient. I believe that modes applied to a channel should be quite transparent, both for users and for chan owners. I understand that some already existing channels may have mlock restrictions... but if the mode +F <something> were already explicit in newly created channels, that would be interesting. Thanks | ||||
| Tags | No tags attached. | ||||
| 3rd party modules | |||||
|
|
Yeah, channel anti flood is standard now. It works like this because we want it to be on on all channels and if we don't do it this way then (as you already figured out) services or similar would interfere with setting -F or the like. This way we can have it on for everyone, regardless of how services are configured, regardless of what people have in their unrealircd conf, etc. (Well, I mean, you can still turn the new behavior entirely via set::anti-flood::channel::default-profile off, but this aside) What I agree with, though, and pegasus also brought this up again, is that we don't do a good job at communicating to chanops WHY channel anti flood kicked in. |
|
|
https://github.com/unrealircd/unrealircd/commit/b31c394cd0820e4f43366cfc45d6609d0d1fc5b8 commit b31c394cd0820e4f43366cfc45d6609d0d1fc5b8 (HEAD -> unreal60_dev, origin/unreal60_dev, origin/HEAD) Author: Bram Matthys <[email protected]> Date: Sat Oct 25 15:26:17 2025 +0200 When channel flood protection kicks in, tell chanops how to get more info, namely via "MODE #channel +F". Enhance "MODE #channel +F" by explaining a bit more (like, actions a chanop can do to change things). Example of protection kicking in: *** Channel CTCPflood detected (limit is 7 per 15 seconds), setting mode +C. Type "/MODE #test +F" to get more information on channel flood protection. Then if you type "MODE #test +F": Channel '#test' has effective flood setting '[7c#C15,30j#R10,10k#K15,40m#M10,8n#N15]:15' (flood profile 'normal') - You are currently using the default anti-flood profile normal. If you want to change to a different anti-flood profile, for example because flood protection is kicking in too quickly or too late, then you can use MODE #test +F <profile>. See the list of profiles below (ordered from lax to strict). List of available flood profiles for +F: off: []:0 very-relaxed: [7c#C15,60j#R10,10k#K15,90m#M10,10n#N15]:15 relaxed: [7c#C15,45j#R10,10k#K15,60m#M10,10n#N15]:15 normal: [7c#C15,30j#R10,10k#K15,40m#M10,8n#N15]:15 strict: [7c#C15,15j#R10,10k#K15,40m#M10,8n#N15]:15 very-strict: [7c#C15,10j#R10,10k#K15,30m#M10,5n#N15]:15 See also https://www.unrealircd.org/docs/Channel_anti-flood_settings (And actually there is some bold text there too) Indirectly suggested in https://bugs.unrealircd.org/view.php?id=6580 by rafaelgrether and PeGaSuS (being more clear to IRCOps what is happening). |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2025-09-23 17:48 | rafaelgrether | New Issue | |
| 2025-10-25 15:25 | syzop | Note Added: 0023530 | |
| 2025-10-25 15:31 | syzop | Assigned To | => syzop |
| 2025-10-25 15:31 | syzop | Status | new => resolved |
| 2025-10-25 15:31 | syzop | Resolution | open => fixed |
| 2025-10-25 15:31 | syzop | Note Added: 0023531 | |
| 2025-10-25 15:32 | syzop | Note Edited: 0023530 |