Not protecting all channel modes

BloodShed · Post by **BloodShed** » Sat Jul 29, 2006 3:14 pm

I couldn't find a post similar to my issue. For some reason, I can't seem to get my botnet to recognize my full list of channel modes.

Environment:

Code: Select all

.status

I am example, running eggdrop v1.6.17: 61 users (mem: 212k).
Online for 01:15 (background) - CPU: 00:00 - Cache hit: 33.0%
Admin: BloodShed
Config file: example.conf
OS: FreeBSD 5.3-RELEASE-p29
Tcl library: /usr/local/lib/tcl8.4
Tcl version: 8.4.11 (header version 8.3.5)

Configuration file:

Code: Select all

channel add #example {
  chanmode "+ntps-milk"
}

Partyline:

Code: Select all

.chanset #example chanmode "+ntps-milk"
Successfully set modes { chanmode { "+ntps-milk" } } on #example.

.chaninfo #example
Settings for static channel #example:
Protect modes (chanmode): +stn-klim

Notice that it completely ignores the private "+p" mode. I've tried rotating the modes around (i.e. chanmode "+pstn-klim") but it seems to ignore +p everytime.

Please note that the bot recognizes "-p" in other channels:

Code: Select all

.chaninfo #example2
Settings for static channel #example2:
Protect modes (chanmode): +tn-klipsm

krimson · Post by **krimson** » Sat Jul 29, 2006 4:26 pm

as far as i know, ircd's don't allow the simultaneous usage of +p and +s... maybe eggdrop has a built-in check to make him not force modes that are impossible

BloodShed · Post by **BloodShed** » Sat Jul 29, 2006 5:30 pm

Also, I forgot to mention that I'm using Efnet. net-type is set to "0" in the configuration.

krimson wrote:as far as i know, ircd's don't allow the simultaneous usage of +p and +s... maybe eggdrop has a built-in check to make him not force modes that are impossible

I don't see why +p and +s would be prohibited together since they have two different uses. Even so, I am able to manually set the channel mode to "+p" and "+s". The bots do not fight this but they will only protect "+s".

I have even tried killing all bots, deleting the .chan files and restarting fresh. It still won't work.

Alchera · Post by **Alchera** » Sat Jul 29, 2006 9:09 pm

Channel modes +p (private) and +s (secret) are basically the same as in the channel will not be seen by non-users if either is set.

I am on DALnet and both (apparently) cannot be used; it's either one of the other.

BloodShed · Post by **BloodShed** » Sun Jul 30, 2006 1:49 am

Alchera wrote:Channel modes +p (private) and +s (secret) are basically the same as in the channel will not be seen by non-users if either is set.

Actually, I think I figured out why.

First, private and secret are not the same. However, I had always read that private prevents a channel from displaying in a /whois request and secret prevents a channel from displaying in the channels list.

This is apparently not entirely accurate either.

Both private and secret do not show up in a /whois. However, private channels will display in a channel list. Secret channels do not (among other things). Basically, secret overrides private as being more hidden.

According to the RFC 2811 document (Internet Relay Chat: Channel Management) section 4.2.6, it specifically states that +p and +s must not both be set at the same time. Although some servers may allow it (Efnet), a +p mode is “silently ignored” if a +s is also present. See below:

The channel flag 'p' is used to mark a channel "private" and the channel flag 's' to mark a channel "secret". Both properties are similar and conceal the existence of the channel from other users.

This means that there is no way of getting this channel's name from the server without being a member. In other words, these channels MUST be omitted from replies to queries like the WHOIS command.

When a channel is "secret", in addition to the restriction above, the server will act as if the channel does not exist for queries like the TOPIC, LIST, NAMES commands. Note that there is one exception to this rule: servers will correctly reply to the MODE command. Finally, secret channels are not accounted for in the reply to the LUSERS command (See "Internet Relay Chat: Client Protocol" [IRC-CLIENT]) when the <mask> parameter is specified.

The channel flags 'p' and 's' MUST NOT both be set at the same time. If a MODE message originating from a server sets the flag 'p' and the flag 's' is already set for the channel, the change is silently ignored. This should only happen during a split healing phase (mentioned in the "IRC Server Protocol" document [IRC-SERVER]).

So krimson is probably correct that Eggdrop has a check for this because it is maintaining RFC compliance.

Alchera · Post by **Alchera** » Sun Jul 30, 2006 1:55 am

I was unable to connect to the DALnet channel modes page (yet again!) and was going via memory.

The bot would be maintaining RFC compliance.