View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0002934 | unreal | ircd | public | 2006-05-29 18:10 | 2015-08-08 18:02 |
| Reporter | avenger | Assigned To | syzop | ||
| Priority | normal | Severity | tweak | Reproducibility | always |
| Status | closed | Resolution | no change required | ||
| Product Version | 3.2.4 | ||||
| Summary | 0002934: IRCd does not announce -r mode change on nick change. | ||||
| Description | There is missing a procedure to tell the client when he changes nick, that he lost the 'r' user mode. | ||||
| Steps To Reproduce | Change nick after identifying with any services. (nothing apparently happens) //mode $me You'll notice -now- that you no longer have the +r provided by services (normally) upon identifying. | ||||
| Additional Information | I can't say it is a bug, but it is at least what is expected, and what is sent by default by most services servers. It deserves at least a #define on setup.h to check whether or not notify the client, on nick change, about the mode change. | ||||
| 3rd party modules | |||||
|
|
This is an issue with services. Your services are using SVSMODE to -r, not SVS2MODE. SVSMODE does not send mode changes to the client, SVS2MODE does. |
|
|
Not entirely correct.. When a user switches nick to something that isn't the same (Stskeeps -> Sts), +r gets removed without telling the user.. This is a rather interesting discussion we also had on #unreal-support. |
|
|
Yes. Actually, the problem is generated on a module named m_nick.c. There's a var 'removemoder' set by default to '1', near to line 124 (as of unreal 3.2.4). It is used near to line 381 on the same file and function, where it sets removemoder to 0 (false) if a nick just tries to change case (Avenger -> avenger). Again, it is called near line 675 on a test. If true, it just rips apart the user's mode UMODE_REGNICK, and does nothing else. We could compare this with SVSMODE and SVS2MODE as an analogy; that SVS2MODE 'tells' the mode change to the client, and SVSMODE don't, well like it happens this way. I am not sure if a "sptr->umodes &= ~UMODE_REGNICK;" will send umode change to other servers (to synch a network) as well. |
|
|
If you check the flow, it does this with all nick changes (local or remote), so the synch is kept |
|
|
But services/stats/other may not assume a -r, so it's not exactly a nice thing to assume. Oh well. [also not documented anywhere.] |
|
|
This is indeed an unreal bug; anope does indeed send a SVS2MODE (which can easily be seen by turning debug mode on), but unreal simply doesn't send the notification to the client, this is highly annoying as it causes a client desync of the user mode r. |
|
|
That explains some things! I'll be needing to whine to aquanight about the incompletness of his protocol documentation again. |
|
|
it appears that unreal itself removes the r mode on nick change (without notifying the client), regardless of having any services running, so when the SVS2MODE from services is sent, it effectively does nothing as r is already unset, so no notice is sent to the client. |
|
|
Yes, you're right. I've contourned the problem by disabling ircd's internal behavior of ripping (silently) mode +r, and leaving it only and only for the services'. Though I posted a patch, but it is a simple piece of coding. If you want to change (and loose warranty of, heh) your ircd, I could post in the changes I made to make ircd not mess up with +r mode. SVS2MODE really announces the mode change. And one different thing you could notice is that the mode change is no longer '* OwnNick sets mode: -r', but, '* OperServ sets mode: -r' (or nickserv, or chanserv, whatever). But the irc clients recognize it just fine. IOW: works for me. |
|
|
Ah... As djGrrr said, anope or epona could send any SVS*MODE, but as it sends, the ircd -already- made its ~UMODE_REGNICK, so the services just tries to remove what's already removed, and the command output is suppessed even in SVS2MODE. By tweaking the removemoder var, you easily make services really send de -r mode to the user thus informing him/her of the mode change. |
|
|
well, as you said, that would require source hacking, which i'm not about to do, i think this should be fixed (either by making it notify the client when it changes the modes, OR by not removing the mode at all), maybe you should make it appear as server.name sets mode -r where server.name would be the server your connected to :) I can see why unseting mode r could be useful, think about if services is lagged, or down completely |
|
|
See previous comment, and as for why not announcing it I mentioned in another bugid - forgot which - basically if you have multiple accounts linked like Syz and Syz[AWAY] you would see -r and then within a second or so +r. If you or anyone else still feel we should send the -r to the client, then feel free to re-open and suggest a setting for this. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2006-05-29 18:10 | avenger | New Issue | |
| 2006-05-29 22:23 | Stealth | Note Added: 0011795 | |
| 2006-05-30 06:12 |
|
Note Added: 0011797 | |
| 2006-05-30 08:24 | avenger | Note Added: 0011801 | |
| 2006-05-30 08:27 |
|
Note Added: 0011802 | |
| 2006-05-31 00:59 | w00t | Note Added: 0011807 | |
| 2006-08-22 20:53 | djGrrr | Note Added: 0012218 | |
| 2006-08-24 10:07 | JasonTik | Note Added: 0012225 | |
| 2006-08-24 11:02 | djGrrr | Note Added: 0012229 | |
| 2006-08-24 17:42 | avenger | Note Added: 0012231 | |
| 2006-08-24 17:47 | avenger | Note Added: 0012232 | |
| 2006-08-24 17:53 | djGrrr | Note Added: 0012233 | |
| 2007-04-27 03:48 |
|
Status | new => acknowledged |
| 2015-08-08 18:01 | syzop | Note Added: 0018643 | |
| 2015-08-08 18:01 | syzop | Status | acknowledged => closed |
| 2015-08-08 18:02 | syzop | Assigned To | => syzop |
| 2015-08-08 18:02 | syzop | Resolution | open => no change required |
