mIRC Home    About    Download    Register    News    Help

Print Thread
Bahamut SSL #239994 14/12/12 12:56 PM
Joined: Dec 2012
Posts: 11
D
DM__ Offline OP
Pikka bird
OP Offline
Pikka bird
D
Joined: Dec 2012
Posts: 11
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.

Re: Bahamut SSL [Re: DM__] #239996 14/12/12 05:42 PM
Joined: Dec 2002
Posts: 4,753
Khaled Offline
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 4,753
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.

Re: Bahamut SSL [Re: Khaled] #239998 14/12/12 07:27 PM
Joined: Dec 2002
Posts: 344
D
drum Offline
Pan-dimensional mouse
Offline
Pan-dimensional mouse
D
Joined: Dec 2002
Posts: 344
Is there any reason you can't simply assume every line received after a 311 and before a 318 is part of the whois?

Re: Bahamut SSL [Re: drum] #240001 14/12/12 11:24 PM
Joined: Dec 2002
Posts: 4,753
Khaled Offline
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 4,753
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.

Re: Bahamut SSL [Re: Khaled] #240094 25/12/12 01:03 AM
Joined: Oct 2003
Posts: 3,918
A
argv0 Offline
Hoopy frood
Offline
Hoopy frood
A
Joined: Oct 2003
Posts: 3,918
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.


- argv[0] on EFnet #mIRC
- "Life is a pointer to an integer without a cast"
Re: Bahamut SSL [Re: argv0] #240096 25/12/12 01:00 PM
Joined: Dec 2002
Posts: 4,753
Khaled Offline
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 4,753
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.

Re: Bahamut SSL [Re: Khaled] #240137 28/12/12 05:50 PM
Joined: Apr 2004
Posts: 848
Sat Offline
Hoopy frood
Offline
Hoopy frood
Joined: Apr 2004
Posts: 848
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..


Saturn, QuakeNet staff
Re: Bahamut SSL [Re: Sat] #242666 17/08/13 09:06 PM
Joined: Jul 2006
Posts: 3,702
W
Wims Offline
Hoopy frood
Offline
Hoopy frood
W
Joined: Jul 2006
Posts: 3,702
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.

Last edited by Wims; 17/08/13 09:17 PM.

Looking for a good help channel about mIRC? Check #mircscripting @ irc.swiftirc.net