Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[whoaboy]

I believe Anope has a bug that needs to be fixed in regards to holding channel modes on registered channels.

When a channel is empty, the channel's modes revert back to their default values (generally only +nt).  The modes that you have set in chanserv through MLOCK are only applied AFTER a user a rejoined the channel.

This creates issues in all sorts of examples.

Take for instances a channel that a user created and registered to only allow secured (SSL connected) users to join.  (UnrealIRCd)  In chanserv, I register the channel and I set a MLOCK for +z.  While the mode is in place, only SSL connected users can join the channel as it should be.  However, if the channel were to become empty, the mode +z is lost, and any user regardless of their connection can join the channel.  It is only AFTER the user has joined the channel that mode +z is placed back on the channel and this prevents nothing.

The same can be said of a channel in which it has been MLOCK'd to have +O so only IRCops can join.  If the channel becomes empty, any regular user can join initially, and then AFTER the user is there, is mode +O placed back on the channel.

Why is Anope not maintaining channel modes even when the channel is empty?  Isn't this one of the primary reasons for having services?

Also, please view the discussion and troubleshooting thread we went through on the UnrealIRCd forums before bringing it here.

http://forums.unrealircd.com/viewtopic.php?t=3033

[Edited on 15-2-2006 by whoaboy]

[whoaboy]

Here's the test I performed and tried to be as verbose as possible for readability sake.

So I did a test again.

(Connection 1) Connected on SSL port.

(Connection 1) /chanserv register #test password description.

(Connection 1) /chanserv set #test mlock +z

(Connection 1) /part

(Connection 1) /disconnect

(Connection 1) (Rejoin on non-SSL port)

(Connection 1) /join #test

(Connection 1) * Now talking in #test
(Connection 1) * ChanServ sets mode: +rz
(Connection 1) * ChanServ changes topic to ''
(Connection 1) -ChanServ- This channel has been registered with ChanServ.
(Connection 1) * ChanServ sets mode: -ahoq [PP] [PP] [PP] [PP]

I am able to join despite being on an unsecured connection. So to make sure I am right in my assumptions on how this is working I form another concurrent non-secured connection to my IRCd.

(Form another non-SSL connection to IRCd)

(Connection 2) /join #test (bear in mind there IS a user in #test right now, thus the channel modes are now in place)

(Connection 2) #test unable to join channel (not using secure connection)

Now, I'll go back to the user who is sitting in #test.

(Connection 1) /part #test

(test is now empty, and I go back to my second concurrent connection who just a moment ago was not able to join the channel due to mode +z)

(Connection 2) /join #test

(Connection 2)* Now talking in #test
(Connection 2)* ChanServ sets mode: +rz
(Connection 2)* ChanServ changes topic to ''
(Connection 2)-ChanServ- This channel has been registered with ChanServ.
(Connection 2)* ChanServ sets mode: -ahoq test test test test

As you can see (I hope), Anope is not maintaining channel modes when the channel is empty.

[Edited on 15-2-2006 by whoaboy]

[Edited on 15-2-2006 by whoaboy]

[alek]

When a channel is empty, it gets "uncreated" or destroyed, both by the ircd and by services. When there are no users, there are no channel modes, plain and simple. When you rejoin the channel, and channel is recreated on a blank slate. You are joining the channel, triggering the mode and topic changes. Therefore, when your initial client joins, there are no modes on the channel so you can join even without a secure client.

Its not a bug, per se, just a matter of making sure that certain channels maintain at least 1 client. The way services handle joins could be modified to deal with this problem, but could get messy.

[Pieter Bootsma]

Services shouldn't enforce channel modes, so making sure the first client to join a channel is allowed even when the MLOCK modes are set is not a task of services. This is a dark area which can't really be handled perfectly.

[Dave Robson]

If services do attempt to handle this, and kick the user out of the channel, the channel becomes empty again, as such the modes are lost, and the user can re-join the channel - repeat this a few zillion times, like say someones script with autojoin, and you get the problem :/

[FiXato]

So the best way to solve this would be if it was handled by the IRCd?
That the IRCd would remember what the last modes were and handle them at the moment the IRCd tries to create the channel (but not yet actually creates it) for the user, and if the user doesn't match the requirements for the last modes (ie. not invited itself, not on a SSL connection or not using the channelkey), deny access as it normally would?

[Edited on 2006.2.16 by FiXato]

[whoaboy]

Hrm, interesting.  The main reason I'm asking this question is because I'm considering switching to an IRCd that supports SSL connections (UnrealIRCd).  I've been using IRCu with SRVX services for about 2 years now and SRVX only really supports IRCu so I in turn must look for a new services package as well.

SRVX supports mode retention even while the channel is empty which is why I became used to this behavior.  I am no IRCd developer, but my best guess is that they are able to provide this functionality by having ChanServ join registered channels thus preventing a channel from ever becoming truly empty.

I'm not suggesting that SRVX is better, I'm just explaining how another services package handles this issue and why I would be asking about it.

[FiXato]

so I take it that with srvx/ircu the registered channels are never empty and thus will always appear in a /list? (Which is not what most servers would want.. and which could be done with anope as well with inhabitregisteredchannels)

[whoaboy]

Originally posted by FiXato
so I take it that with srvx/ircu the registered channels are never empty and thus will always appear in a /list? (Which is not what most servers would want.. and which could be done with anope as well with inhabitregisteredchannels)

Yes, that's correct.  Due to ChanServ joining registered channels and preventing a channel from becoming empty, channel modes are preserved.  This does also allow for registered channels to appear in a /list even when empty of "real" users.  Athough I don't see any real negative impact as /list supports -min and -max command, so a simple "/list -min 2" would remove any channels with a single user in them.

I was unaware of a inhabitregisteredchannels command(?), and after searching for that in services and the conf file in Anope, I was unable to locate it.  Could you tell me where I could find this setting/command?

[whoaboy]

Originally posted by Rob
If services do attempt to handle this, and kick the user out of the channel, the channel becomes empty again, as such the modes are lost, and the user can re-join the channel - repeat this a few zillion times, like say someones script with autojoin, and you get the problem :/

Well, I was thinking more along the lines of the modes being in place at all times, thus preventing the user from even being able to go through the join/kick process in the first place.

Exactly like when a channel is set as +i (invite) and when an uninvited user attempts to join, they simply are denied access without ever joining the channel.

[Edited on 20-2-2006 by whoaboy]

[FiXato]

Originally posted by whoaboy
I was unaware of a inhabitregisteredchannels command(?), and after searching for that in services and the conf file in Anope, I was unable to locate it.  Could you tell me where I could find this setting/command?

It is a module originally created by SGR, and patched/currently maintained by Trystan: http://www.nomadinc.net/mymods/files/cs_inhabitregistered.c