If SVSNICK is sent to the user's server is this actually an issue? A NICK sent from the user would go to the local server, which would have the correct ban information due to your patch. Or are we talking about non SVSNICK events... Where a user has changed to a nick that matches a ban on their own? ------Original Message------ From: Ned T. Crigler To: kevin@buley.org Cc: dalnet-src@lists.dal.net Sent: Apr 23, 2009 19:07 Subject: Re: [DALnet-src] SVSNICK and cached ban status handling On Thu, Apr 23, 2009 at 10:25:07PM +0000, kevin@buley.org wrote:
I like this! Too many times have I set a ban on guest*!*@somedomain only to watch an endless nick->guest->nick cycle. There are times when we don't want to remove a user from the channel, but we DO want to stop their lame script. Currently the only options are to kick the user or remove and re-set the ban... Both are undesdirable.
In our off-list discussion you mentioned a case where this may still happen... Is there a solution other than changing banserial for every NICK event?
That problem is because SVSNICK is relayed to the person's server, which then does the forced nick change locally, and then sends out a standard NICK protocol message to the other servers. The other servers cannot tell the difference between a normal nick change and a forced nick change. This will cause remote servers to have the old user's banserial cached, since a normal NICK change doesn't change banserial right now. I think a flush of the banserial in m_nick in addition to m_svsnick is the easiest way to fix this, unless maybe SVSNICK is changed to not use a regular NICK protocol message to other servers. That unfortunately, would probably involve backwards-compatibility protocol issues. With the m_nick change, unpatched servers would just have a out-of-date banserial cached. -- Ned T. Crigler -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -- Kevin Buley