View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000837 | unreal | ircd | public | 2003-03-24 21:39 | 2003-11-20 19:46 |
| Reporter | braindigitalis | Assigned To | |||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | closed | Resolution | no change required | ||
| OS | Redhat Linux, Debian Linux | OS Version | RH7.3 | ||
| Product Version | 3.2-beta15 | ||||
| Summary | 0000837: Channel mode +C (no channel CTCPs) not functioning | ||||
| Description | The channel mode +C (not lowercase +c) that prevents channel CTCPs does not function on this version under both of our servers (one debian, one redhat). Example: [21:28] --- Received a CTCP TEST from Phoenix^ (to #winbot) [21:28] <-- mUd has kicked Phoenix^ from #winbot (*Breaks Off Your Finger*) [21:28] --> Phoenix^ ([email protected]) has joined #winbot The channel was +C at the time, so neither me or the bot should have received the channel ctcp :) | ||||
| Steps To Reproduce | Set a channel to mode +C, attempt a channel ctcp from one client and observe effects in another. | ||||
| Additional Information | No messages are received saying CTCPs are not allowed, ircd acts as if +C is simply not set. | ||||
| Tags | No tags attached. | ||||
| 3rd party modules | |||||
|
|
lmao, pwned.. Same on my network :D |
|
|
w44 B4r7'z 1337 0day CTCP 7r1ck h45 b33n d15c0v3r3d... I love abusing eggdrops >:). edited on: 03-24 21:55 |
|
|
lol no eggdrops there to abuse ;) anyhow back to more serious stuff *leaves coders to do what they do and fix sometime in the future* |
|
|
Is Phoenix^ (the user sending the CTCP) +o +a or +q on the channel? Because if he/she is, then the CTCP will be allowed (channel ops and above can still send CTCPs when +C is set) |
|
|
I just tested, and it works perfectly. If I'm +o and I /ctcp #chan test it works, if I -o myself, then it doesn't, and I receive: codemastr CTCPs are not permitted in this channel (#test) So I don't know what you mean, you'll have to be more specific. |
|
|
Ah, i see. The help text doesnt mention that ops are able to ctcp the channel, this is not what we expected the mode to do based on /helpop ?chmodes - maybe the help should be updated (minor change). Is there any way to make it block channel ctcp's from ops too? (the net we use has services, the ops cannot remove the mode as its locked on) |
|
|
No there is no way to do that. Ops are in charge of the channel, thats the way it has always been... |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2003-11-20 19:46 | syzop | Status | resolved => closed |
