Forums Bug Reports CMODE +y bug

Im not sure if this is a true bug or not, but on conference room servers, lets say my nick is "Matt", if I /mode #channel +yu MATT Matt, then it will change the case of my nick in that channel, even though my nick hasn't actually changed. It appears +y isn't actually an in-use mode on Conference Room servers, so I'm wondering if this is an actual bug on mIRC that is doing something it shouldn't :-P

Can anyone confirm this on other IRC Networks? Thanks a lot :-)

Matt

It would seem to me that if that really does exist, it is a problem with CR, not mIRC.

I don't thinjk som, as it doesn't do it in other IRC Clients.. tried a few - Matt

/hs cmode

[03:06:11] -qld-chat.bigpond.com- r - Registered, R - n/a, s - Secret, t - Topic, u - Channel User, v - Voice, w - n/a, y - n/a, z - Encrypt Only

It's not a bug in mIRC or a problem with CR. The mode simply doesn't exist at channel level.

Also +u is a level of host status on CR which allows /cs invite and channel memo access. You cannot /mode #Room +u with it, it is given automatically.

Im aware of that, but Im saying that when you DO use it, with +u or +v in mIRC, it changes the case of the nick.. ie: /mode #channel +yu MATT Matt (MATT being the new nick).. try it

Matt

Do a /debug @debug and look at the MODE line returned by the server. Paste those lines for us. It sounds like a bug with how mIRC interprets MODE responses (if the server changes your nick on you, mIRC follows suit), and with CR sending a back a response with your lowercase nick.

So it's likely a bug with both CR and mIRC. mIRC's end of it seems reasonable though, it's only handling the data given to it. Other clients seem to ignore when the server lies about your nick, making mIRC a slightly more gullible client (I TRUSTED YOU!).

- Raccoon

It does too. I wouldn't be too concerned though. It's undocumented and therefore is as good as not there. CR is a bit like mIRC - alot of things get put in and not added to the mIRC.hlp. HelpServ is much the same in that respect.

It is NOT a bug.

Where is your paste.

My event looked the same as his but nonetheless if a mantufacturer indicates that something is not available then it can't be classed as a bug.

Actually. Commands that are unimplimented must not cause conflicts to the client. A simple "Command Not Implimented" response the proper response, and nothing else.

Care to paste what appears in /debug?

- Raccoon

<- :Jeff!PkmnRed1.1@=vYae-rdazodbtspxvi3i-y-87.albyny.adelphia.net PRIVMSG #MediaDriven :do you have a shitlist
<- :ThUgAnOmIcS!ThUgOnOmIc@=WA076-31-659-21.wit.cvx.blueyonder.co.uk PRIVMSG #Matt :im a thug is distress!
-> irc.MediaDriven.com MODE #Services +yu TIEKS Tieks
<- :Matt!Matter@irc.mediadriven.ops MODE #Services +yu TIEKS Tieks
<- :RoughKnight!QuietOne..@=lcSwitxf-SDE-seq827374.sympatico.ca PRIVMSG #NoHacks :Bee

And mIRC changes the nick TIEKS to appear as Tieks in the nicklist? That's kind of interesting.

I'd say it's more of mIRC's fault then in this case. I can't imagine why it would be updating the nicklist based off a MODE parameter. I thought it was changing the MODE target nick (<- :Matt!Matter@irc.mediadriven.ops) to lowercase.

This could be a fun exploit though. People come in with their nick ALLCAPS and an op can lower it for them.

"+y -- Allows a channel op to modify the CaSe of a user's nick as it appears in the channel. (mIRC Only)."

There is no conflict. What function in mIRC (or any client) ceases to operate, or is otherwise hindered due to this issue? Sure, the case of the nickname changes, but only to the case nominated by the user.

This could potentially cause problems in scripts which handle Nicknames in a case sensitive manner. If suddenly a nick changes without an On NICK event firing, it could screw with any number of scripts expecting a nick that is no longer there.

I'm not saying it's a serious issue, or that the user should be using the +y flag that is not implimented... but the server *could* handle it a little better if it wanted to, and mIRC *could* ignore it a little better as other clients do.

- Raccoon

Ahhh well, worse things can happen ay. At least we have established that it's not the fault of any IRCd.

I'm not to familiar with CR, but it does look like a problem with CR to me. The problem seems to be +y, although unimplemented, accepts a parameter. So when he does /mode #chan +yu BLAH blah, CR says 'ok BLAH goes with +y, blah goes with +u', however +y doesn't say (as per CHANMODES=) "I take a parameter" so mIRC doesn't know that. Therefore when it gets a +yu BLAH blah, it says "+y no param, +u has param BLAH, and then there is an extra param of blah so just ignore that". Therefore mIRC gets confused with the case. If you just did /mode #chan +u BLAH I assume it doesn't change the case? Therefore it would certainly seem that the problem lies in the fact that +y is not correctly listed in CHANMODES=.

I did some further research on this, the problem is with mIRC. Not only is mIRC the only programme affected by this (as far as I have sought to find out) but the case change is only seen by the users of mIRC that are in the affected room and also only in the room that the mode change had taken place, which is understandable since it's a room mode we are talking about, none-the-less the problem doesn't occur in the java applet or in Pirch. That said, and like with any problem, the issue has to come down to what is most commonly affected, an IRCd or a client. In this case one client is affected and by an undocumented issue, therefore the client (in this case mIRC) is at fault.

I 100% disagree with you, and your own argument proves you wrong. +y is undocumented. For all you know it's exact purpose is to allow the client to change the case in the nick list. You have no way of knowing it is a problem with mIRC. As I said +Y takes a parameter, +y does not tell mIRC it takes a parameter. Why isn't pirch affected? because pirch doesn't even know what CHANMODES= is!

+y is undocumented.

Yep, yep, I already said that...

For all you know it's exact purpose is to allow the client to change the case in the nick list.

Why the hell would a resource be put in an IRCd to do that when the user can do it at client level? Support for certain raw commands (for /svs* functions) was removed from CR in V1.8.7.1 (I believe) simply to trim down on stuff that isn't required therefore there is a perception, at least, that when the current version was written, efficiency was considered to a great degree. You are betting on hypothetics as per usual.

Why isn't pirch affected? because pirch doesn't even know what CHANMODES= is!

Correct, but neither does mIRC in this case because +y isn't included. :tongue:

CHANMODES=bouv,k,lOMN,cdejimnpqrstzALU

If you'd bother to read the CR manual you'd realise that modes such as w and y are reserved for future use.