mIRC Home    About    Download    Register    News    Help

Print Thread
Joined: Sep 2003
Posts: 40
koitsu Offline OP
Ameglian cow
OP Offline
Ameglian cow
Joined: Sep 2003
Posts: 40
I've found what appears to be a slight quirk in how the Login Method feature (of a Server's settings) is implemented, when used in conjunction with the Connect / Options / Perform... feature, in the scenario where the Login Method fails (but the server IS connected and functional). I should note that in this particular network's case, NickServ is not truly required for authentication, but more as a nicety.

  • Server configuration uses Login Method "NickServ (/NICKSERV)" and a password is chosen
  • Connect / Options / Perform... has "Enable perform on connect" checked, "Network" set to "All networks", and "Perform commands" is "/join #test"


The situation:

  • mIRC connects to the server successfully -- note: IRC commands are fully functional
  • mIRC issues the /NICKSERV {password} command
  • /NICKSERV command fails (IRC protocol returns a 402 indicating No such server -- for example, the NickServ service is unavailable on the network)
  • mIRC sits for 60 seconds (interval seems to come from from Connect / Options / Retry...) -- you can issue manual commands during this time without any issue, of course
  • mIRC suddenly joins /#test even though it could have done so 60 seconds prior without issue


mIRC is treating /NICKSERV returning a 4xx as "failed to connect to server", which is not really true. However, as I think about it a bit more, I can see how/why mIRC might treat this scenario the way it does. But it's a bit strange to see the "Retry..." timeout/interval kick in in this situation. Are there actual IRC networks which *require* NickServ authentication before any other IRC commands are functional?

Prior to using the Login Method feature, I simply put /NICKSERV {password} into my "Perform commands" area/script, where I never encountered this problem (when NickServ was down). Of course, this also had the downside of storing the password in plaintext.

This is using mIRC 7.72, by the way.

Last edited by koitsu; 18/01/23 08:07 PM.
Joined: Jul 2006
Posts: 3,972
W
Hoopy frood
Offline
Hoopy frood
W
Joined: Jul 2006
Posts: 3,972
The delay does not come from a mirc option, because nickserv is not standard and can be set to any language and because mIRC does not offer a custom match string to compare against nickserv's message, mirc has a delay before joining channel to make sure you're auth before..

I'm not sure if mIRC has some correct understanding of the raw 402 and this is a bug, or if it simply does not handle it at all, for which there's the argument that it could, and the argument that khaled wants to avoid handling different custom raw per network.

Check this thread: https://forums.mirc.com/ubbthreads.php/topics/265317/


#mircscripting @ irc.swiftirc.net == the best mIRC help channel
Joined: Dec 2002
Posts: 5,246
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 5,246
Thanks for your bug report. I have not been able to reproduce this issue here. Can you provide a step by step method that reproduces this that I can test out in a clean install of mIRC?

As Wims mentioned, the way /nickserv was designed means that it reports success or failure using language, as opposed to an identifiable numeric or named event. This means that /nickserv on different IRC networks can use different combinations of words, and even a different language, to report success or failure. So there is no reliable/consistent way for an IRC client to test for this.

In your case, you have said that you are seeing numeric 402. Is this specifically related to nickserv? The only explanation I can get for this numeric is "No such server" and "Used to indicate the server name given currently doesn't exist". Can you post the raw numeric 402 you are seeing?

Joined: Sep 2003
Posts: 40
koitsu Offline OP
Ameglian cow
OP Offline
Ameglian cow
Joined: Sep 2003
Posts: 40
I've provided the step-by-step for the client side.

The IRC server in question returns a "402 No such server".

The way NICKSERV (the raw command) is implemented on this server/network (running ircd-ratbox) is through a custom in-house module called m_xxxxserv.c. I do not have permission from the author to post the entire code, but I can ask him if asked. It's nothing magical or secret.

The C code is very easy to understand. Kept short for brevity (though this forum's code tag support seems to destroy indentation; not my fault):

struct Message nickserv_msgtab = {
"NICKSERV", 0, 0, 0, MFLG_SLOW,
{mg_unreg, {mg_nickserv, 2}, mg_ignore, mg_ignore, mg_ignore, {mg_nickserv, 2}}
};

...

static int mg_nickserv(struct Client *client_p, struct Client *source_p, int parc, const char *parv[])
{
struct Client *target_p;
char combined[1024];

if ( (target_p = find_client(SERVICES_HOST)) == NULL )
{
sendto_one_numeric(source_p, ERR_NOSUCHSERVER,
form_str(ERR_NOSUCHSERVER), SERVICES_HOST);
return 1;
}

combined[0] = 0;
combine_string(parc, parv, combined);

sendto_one(target_p, ":%s PRIVMSG NickServ@" SERVICES_HOST " :%s", parv[0], combined);

return 0;
}

Here we can see that if the client issues a raw NICKSERV command, and the NickServ service/server is unavailable/not connected to the network, the server the client is using returns ERR_NOSUCHSERVER, which is a standard irc-ratbox response. From the official ircd-ratbox source:

include/numeric.h:#define ERR_NOSUCHSERVER 402
src/messages.tab:/* 402 ERR_NOSUCHSERVER, */ "%s :No such server",

Last edited by koitsu; 05/02/23 12:07 PM.
Joined: Sep 2003
Posts: 40
koitsu Offline OP
Ameglian cow
OP Offline
Ameglian cow
Joined: Sep 2003
Posts: 40
One thing I wanted to add: if it's felt that this is not the proper code + payload to respond with, and there is something more universal, let me know. The code in this in-house module can certainly be changed to be more compatible.

Joined: Dec 2002
Posts: 5,246
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 5,246
Thanks for the detailed reply. Numeric 402 existed long before nickserv, so it is a generic event that is not nickserv-specific. As far as I can tell, it is not possible for a client to know that the error is related to nickserv. mIRC does handle numeric 402 but only in relation to a /whois reply in a specific context sent by an ircd from 1995. Is the numeric 402 you are seeing specifying nickserv as the issue?

mIRC could assume that if it sees a generic numeric 402 event while waiting for a /nickserv reply, that it is related to nickserv, and to trigger perform immediately. As long as ircds don't send this numeric during the connection/logon process for other reasons, that could work.


Link Copied to Clipboard