View Issue Details

IDProjectCategoryView StatusLast Update
0001284unrealircdpublic2003-10-03 20:42
Reporterthilo Assigned To 
PrioritylowSeveritytweakReproducibilityunable to reproduce
Status closedResolutionopen 
Summary0001284: two svsnick bugs
DescriptionFirstly, I wanted to analyze why sometimes there is a difference in the usercount of my services and the actual servers on the network. In order to achieve this goal, I have placed a few sigint()s when certain events occur that lead to the duplicate users. When checking the text logs afterwards, I noticed two very curious things in the daemon behaviour:

########
[Sep 30 23:58:37 2003] debug: Sent: :services.kickchat.com 433 Namrael Namrael :Nickname is registered to someone else
[Sep 30 23:58:37 2003] debug: Sent: SVSNICK Namrael Guest26859 :1064966317
ENFORCER DEBUG: colliding Namrael.
[Sep 30 23:58:37 2003] debug: Received: :Namrael ! [email protected] :IDENTIFY <masked>
[Sep 30 23:58:37 2003] Namrael: :Namrael ! [email protected] :IDENTIFY <masked>
[Sep 30 23:58:37 2003] NickServ: [email protected] identified for nick Namrael
[Sep 30 23:58:37 2003] debug: Sent: :services.kickchat.com 304 Namrael :Password accepted for nick Namrael
[Sep 30 23:58:37 2003] debug: Sent: :NickServ n Namrael +r 0
[Sep 30 23:58:37 2003] debug: Received: :Namrael & Guest66001 :1064966317
[Sep 30 23:58:37 2003] debug: Namrael changed nick to Guest66001
[Sep 30 23:58:37 2003] debug: Sent: :NickServ n Guest66001 -r 0
#######

Although Namrael was supposed to be changed to Guest26859, the ircd changes it to Guest66001 .. how is this possible? I could not find any indications for this bug in the source code of the module m_svsnick.c either and I was not able to reproduce it afterwards. Maybe it is something to keep at the back of the head ...

Secondly:
[Oct 01 00:00:45 2003] debug: Sent: :NickServ SVSNICK Namrael Namrael :1064966438l
[Oct 01 00:00:59 2003] debug: Received: & Namrael 1 1064966457 Lord-Druya pD9EB1A49.dip.t-dialin.net irc.kickchat.com 0 +ix kick-2E0692E9.dip.t-dialin.net :Patrick

The events leading to the strange (and somehow pointless) SVSNICK command is a bug in my services, but the result is strange: although I am changing the same nick to this new nick, the ircd thinks services are joining a new user.

I suggest to change line 119 in m_svsnick.c to
if (find_client(parv[2], NULL) != acptr) /* Collision */
instead of
if (find_client(parv[2], NULL)) /* Collision */

or give out an error message if the case is that both arguments specify the same nick.
Additional InformationI am using Unreal 3.2 beta18 on Debian woody.
3rd party modules

Activities

thilo

2003-10-01 14:27

reporter   ~0003741

correction:

####
aClient *acptr2;

if ((acptr2 = find_client(parv[2], NULL)) && acptr2 != acptr) /* Collision */
####

My suggestion was wrong of course, having not tested the consequences (uah .. it takes long to compile Unreal3.2 on a 486 133Mhz ...)

syzop

2003-10-03 20:42

administrator   ~0003773

Unable to reproduce your 1st thing (like you said yourself).

And about the 2nd, I believe that this is used by services (self collision).. well not sure, but I don't see why it should be changed...

Issue History

Date Modified Username Field Change
2003-10-01 13:38 thilo New Issue
2003-10-01 14:27 thilo Note Added: 0003741
2003-10-01 20:54 syzop Priority normal => low
2003-10-01 20:54 syzop Severity minor => tweak
2003-10-01 20:54 syzop Summary m_svsnick.c with two bugs. => two svsnick bugs
2003-10-01 20:54 syzop Description Updated
2003-10-03 20:42 syzop Status new => closed
2003-10-03 20:42 syzop Note Added: 0003773