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(a)buley.org
Cc: dalnet-src(a)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(a)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
