Anope Support > 1.6.x (Read Only)

Anope Channel Mode Problem - Bug?

(1/3) > >>

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 :/

Navigation

[0] Message Index

[#] Next page