Forums Bug Reports Bahamut SSL

When I perform whois on someone who is connected with SSL on bahamut the line '<nick> is using a secure connection (SSL)' is sent to the status window.

<- :irc.server.com 311 <nickname> <nickname> me 212.some.host.com * :realaname
<- :irc.server.com 319 <nickname> <nickname> :#channel1
<- :irc.server.com 312 <nickname> <nickname> irc.server.com :Default Server
<- :irc.server.com 307 <nickname> <nickname> :has identified for this nick
<- :irc.server.com 275 <nickname> <nickname> :is using a secure connection (SSL)
<- :irc.server.com 317 <nickname> <nickname> 1056 1355433259 :seconds idle, signon time
<- :irc.server.com 318 <nickname> <nickname> :End of /WHOIS list.

IRCD Version: bahamut-1.8.9

mIRC should show the 275 numeric on whois line.

Thanks this has been added to the next version. Most ircds seem to use numerics 320 and 671 to indicate an SSL connected client. Numeric 275 seems to have different meanings on different ircds, so the next version of mIRC will only treat numeric 275 as part of a /whois reply on DALnet servers.

Is there any reason you can't simply assume every line received after a 311 and before a 318 is part of the whois?

mIRC will only parse numerics as defined by the RFC or as defined by ircds when new numerics are created. It makes no assumptions about whether similar numerics are grouped or not or whether all ircds consistently and predictably send such information grouped or not.

Actually.. IS it possible for an ircd to send non-whois numerics between 311-318? I know it technically is, but I don't think I've ever come across any ircd implementation that could do this... a simple heuristic could cover the bases:

If an UNKNOWN numeric is sent between 311-318, assume it is part of whois

UNKNOWN being any numeric that is not already registered.

This will solve the problem in the future as IRCDs add more custom responses to WHOIS replies. AFAIK this is not the first time this issue has come up-- it happened previously with 338, right? Seems that it's likely to happen again, so there should be a more generalized solution here.

I do not know whether it is or is not possible either, so I would rather not make that assumption. I prefer to add support for numerics as defined by the RFC or when new numerics are verified by users as being used in a specific context.

Just a short analysis.

In theory it is possible that a single IRC server mixes replies for one command with other messages. For example, ircu sends the replies to the LIST command in batches, mixed with other traffic, to prevent flooding the user. However, in practice it is unlikely that this concept will ever be applied to the WHOIS command: it is simply much easier to generate and buffer the entire, typically reasonably small WHOIS output at once.

In practice it is also possible, namely when performing remote WHOIS queries. In this case, the remote numeric replies for a WHOIS may be interspersed with basically any other numeric replies, the latter typically coming from the local server. To make things worse, the message source may be the same for all these messages, if the network chooses to hide its individual servers' names. Undernet and QuakeNet do this, for example.

So this really is about a tradeoff. What is more likely, and which is worse? Numerics accidentally being recognized as being part of a whois (i.e. false positives) or numerics NOT being recognized as such (i.e. false negatives)? Like argv, I'd probably take a different decision here, but either decision can be justified..

It's happening again, raw 536 on swiftirc is used to indicate the user is using the mode +f (filtering urls) and mIRC displays it in the status window rather than active window (if set).

@Khaled: you decided recently to add a support for a raw numeric for any ircd, and that only during a whois reply. Couldn't you just assume any numeric recieved during a whois is a whois reply by default, as suggested by the others; instead of having reports about numeric not being displayed correctly, you would then have reports about numerics accidently being displayed during a whois reply, which is apparently less likely to happen and would solve the problem with ircds adding raw on the fly.