View Issue Details

IDProjectCategoryView StatusLast Update
0002994unrealircdpublic2015-05-28 18:53
Reportermike414Assigned Tosyzop 
PrioritynormalSeverityminorReproducibilitysometimes
Status resolvedResolutionfixed 
PlatformOSWindows XP ProfessionalOS VersionSP2
Product Version3.2.5 
Target VersionFixed in Version3.4-alpha1 
Summary0002994: Missing users after nick collision
DescriptionAfter a nick collision when linking a server, one server shows both users getting disconnected, but the other server keeps the local user online, who is completely invisible for anyone not on the local server. Resulted in this error when testing it:

-irc.finalhit.org- Missing user mike2 in SJOIN for #test from mike.finalhit.org (@1 ~ !14ijEL #test :mike2 )
Steps To ReproduceLink two servers (mine had SSL and ziplinks on), causing a nick collision.
Additional InformationI have only reproduced it when connecting seperately to the servers while the network is split. Also, I can't find any .core file to include.
TagsNo tags attached.
3rd party modules

Relationships

related to 0001977 resolvedsyzop Desyncs after nickcollisions 

Activities

mike414

2006-11-14 23:29

reporter   ~0012659

-hub.finalhit.org- *** Notice -- Received KILL message for Mike!mike419@netadmin.finalhit.org from strawberrysnow.finalhit.org Path: vancity!strawberrysnow!strawberrysnow.finalhit.org (Mike(?) <- vancity.finalhit.org)

After a netjoin, someone remarked in the channel that I had quit with the message * Mike has quit IRC (Nick collision with no timestamp/equal timestamps), although in my perspective I was still in the channel. After a minute or so, I was killed with the message above.

Note View State: private: 12207 - curious about this if anyone wants to comment...

Cheers,

satmd

2007-04-19 04:26

reporter   ~0013589

Last edited: 2007-04-19 04:27

side note: the final kill message probably resulted from PING/PONG (instead of some kind of timer)

satmd

2007-04-19 04:31

reporter   ~0013590

My idea from bug 0001977 could take care of this bug as well if cleanly implemented.

syzop

2015-05-28 18:53

administrator   ~0018376

This should be fixed in 3.4-alpha1 and later (on a 3.4-only network, that is) thanks to the use of UID

Issue History

Date Modified Username Field Change
2006-07-10 18:15 mike414 New Issue
2006-11-14 23:29 mike414 Note Added: 0012659
2007-04-15 08:37 stskeeps Relationship added related to 0001977
2007-04-19 03:33 stskeeps View Status private => public
2007-04-19 03:34 stskeeps Status new => acknowledged
2007-04-19 04:26 satmd Note Added: 0013589
2007-04-19 04:27 satmd Note Edited: 0013589
2007-04-19 04:31 satmd Note Added: 0013590
2015-05-28 18:53 syzop Note Added: 0018376
2015-05-28 18:53 syzop Status acknowledged => resolved
2015-05-28 18:53 syzop Fixed in Version => 3.4-alpha1
2015-05-28 18:53 syzop Resolution open => fixed
2015-05-28 18:53 syzop Assigned To => syzop