View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0002583 | unreal | ircd | public | 2005-07-04 07:57 | 2005-07-18 18:58 |
| Reporter | galahad | Assigned To | |||
| Priority | normal | Severity | major | Reproducibility | always |
| Status | closed | Resolution | duplicate | ||
| Product Version | 3.2.3 | ||||
| Summary | 0002583: All user channel modes not displayed | ||||
| Description | This problem is similar to the ones described about user modes on channel out of sync. This is the problem I noticed, and I noticed it in UnrealIRCd 3.2.3, and I had installed UnrealIRCd 3.2.2, and this worked fine in that version: when a user has multiple user modes (+o and +v, for example), all users in the channel will see both modes. I use ViRC as a client and it shows these modes as (@+nick). Now, here is the problem. When a new user comes in, they will only see the highest mode set on a user, and not the rest... So, if I have mode +q +a +o (@&~nick), and a new user comes, they will only see +q (~nick) and not the rest of them. All the users already on the channel, will see other modes. | ||||
| Steps To Reproduce | 1. Join a channel 2. Assign a User1 multiple modes 3. Join a channel with another client 4. Remove the highest mode from User1 5. Newly joined User2, will not see other modes on User1 | ||||
| 3rd party modules | |||||
|
|
This is not a bug. It's a limitation of the IRC protocol. For more information, read up on the NAMES command in the respective RFCs. *sigh* let me try and explain... When a client joins a channel, the following is what happens: (-> means im sending something, <- recieving) -> hertz.netronet.com JOIN #netroNet <- :[email protected] JOIN :#netroNet -> hertz.netronet.com MODE #netroNet <- :hertz.netronet.com 332 w00t #netroNet :Boo is getting worked on again, second HD failure in a month || Pleaes don't complain - marx1 is doing a LOT of work to try and fix these problems <- :hertz.netronet.com 333 w00t #netroNet w00t 1120486410 <- :hertz.netronet.com 353 w00t = #netroNet :w00t +DarkLiege +fishmonkey %Ebola %Om %OMFG +Dustin +trust +Dave2|Laptop @nicole-away %Lauren +Dave2 +Dave2|server +bacon +pepolez- %sleepynight +Ragnar <- :hertz.netronet.com 366 w00t #netroNet :End of /NAMES list. <- :hertz.netronet.com 324 w00t #netroNet +ntr <- :hertz.netronet.com 329 w00t #netroNet 1120120948 So, I join, request the channel modes, get sent the channel topic - who set it and when, followed by a 353 - those up on protocol will know this is RPL_NAMES, how the userlist is populated. You will notice that only one prefix character is shown - this is how NAMES was designed to function (nobody ever considered users having multiple status levels i guess, since originally there was only op and voice). So, to new clients, they really only _do_ have one mode. For them to solve that, at the moment they just need to issue a /names #chan to get the refreshed userlist with their new highest status. And err, it wouldn't have worked correctly in 3.2.2 - it's worked this way back since waaaaaaay back in the dark, dank days of ircd. NAMESX has been proposed on here before I believe, but nobody has done it. Maybe we should be the first ;). |
|
|
Err... Okay :) I believe it did work correctly, but hey, maybe I'm mistaken... Anyway, on a irc server using unreal 3.2.2b this doesn't happen, but on my friends irc running 3.2.3 this does happen... But maybe it has something with the services... Anyway, thanx for the quick reply p.s. I do have all IRC RFC's on my comp ;) |
|
|
See: 0000606 |
|
|
If you have the RFCs, then you would have already read the relevant section. As Unreal follows this convention - and always has, then you would know why this occurs. I have a copy of 3.2.2b, as well as a number of the 3.2-beta versions - I have a few tar.gzs of 3.1 as well - any other versions you'd like me to test? ;) Ta for the link Bugz. re: NAMESX- Do we really need client-server negotiation on it? I mean, are client/server coders really going to agree how to do it? Perhaps only use NAMESX if requested and let client coders know that it's there for them to use. |
|
|
I had a long conversation with codemastr about NAMESX once... It's a lot of log so I'll sum it up :) - the basic idea is to use the "unused" USER <server> parameter to signal a request for protocol negotiation. Something like this: -> PASS :blah -> USER username <ignored[1]> NEGO :<realname> -> NICK nickname <- :irc.blah NEGO NAMESX otherstuffhere -> NEGO +NAMESX <- NEGO +NAMESX <- pingcookiewelcomestuff etc [1]=USER command in this case conforming to RFC 2812 instead of 1459... which leads me to suspect codemastr might sneak in "user-modes-on-connect-specified-by-user" in the <ignored> parameter defined by 1459 as the hostname parameter :) (and from the ranting from codemastr in my log, I doubt it's going to be the same numeric style IRCD uses, which, I have to agree, is stupid :) ). Only problem I can see is we really can't hope for "virtual server" type configurations like I was planning on trying to do one day when I was bored... (Anyone who knows enough about HTTP/1.1 and/or apache or other web servers knows that http servers can have multiple virtual servers that is really just one server feeding files out of different webroots based on the hostname passed in the http request. I had hoped that the RFC 1459 server parameter could in theory be used to create a similar configuration for IRC servers. Although, this is generally unreasonable in practice :) .) For the record, I have seen ONE ircd do a psuedo-NAMESX solution (just send multiple prefixes - to hell with standards or clients that don't understand it). I believe it is PTlink's ircd in fact... memory is fuzzy here... |
|
|
Alright.. Sorry to intrude here, but I have an mIRC script that avoids these kinds of desynchs... If you don't use mIRC, and your IRC client supports a scripting language, check the documentation that was distributed with it for a way to automatically do a /names command on a mode change. Heres the script: [code] ; DESYNC AVOIDANCE SCRIPT ; By Dodge ; To catch the mode change: on *:RAWMODE:#:{ ; To execute the /names command without the ; results being displayed to the user. /.names $chan } ; END OF AVOIDANCE SCRIPT [/code] |
|
|
duplicate of 0000606 |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2005-07-04 07:57 | galahad | New Issue | |
| 2005-07-04 10:42 | w00t | Note Added: 0010174 | |
| 2005-07-04 10:48 | w00t | Note Edited: 0010174 | |
| 2005-07-04 15:45 | galahad | Note Added: 0010176 | |
| 2005-07-04 16:14 | Stealth | Note Added: 0010177 | |
| 2005-07-05 02:28 | w00t | Note Added: 0010180 | |
| 2005-07-05 03:46 | aquanight | Note Added: 0010181 | |
| 2005-07-05 03:48 | aquanight | Note Edited: 0010181 | |
| 2005-07-15 12:26 | Dodge_Ram | Note Added: 0010220 | |
| 2005-07-18 18:58 | syzop | Status | new => closed |
| 2005-07-18 18:58 | syzop | Note Added: 0010225 | |
| 2005-07-18 18:58 | syzop | Resolution | open => duplicate |
