Adding rpl_luserunknown message handler

[yanickrochon]

Connecting on freenode.net, I get this warning :

Unhandled message: { prefix: 'barjavel.freenode.net',
  server: 'barjavel.freenode.net',
  command: 'rpl_luserunknown',
  rawCommand: '253',
  commandType: 'reply',
  args: [ 'HelloNodeBot', '3', 'unknown connection(s)' ]
}

This has something to do with freenode.net allowing users to register their nicks. I guess it coiuld be added to the ignored welcome messages by default? Or, better yet, treat it as a nick auth request?

For the latter, the proper response should be sending PRIVMSG NickServ identify <password>.

[dman777]

I am getting this same issue. Does there need to need to be a identify protocol that is missing?

one@public-node ~/github/jayp-bot $ node try.js 
18 Apr 19:31:21 - SEND: PASS pass
18 Apr 19:31:21 - SEND: NICK user
18 Apr 19:31:21 - SEND: USER user 8 * :nodeJS IRC client
18 Apr 19:31:21 - Unhandled message: { prefix: 'asimov.freenode.net',
  server: 'asimov.freenode.net',
  command: 'rpl_luserunknown',
  rawCommand: '253',
  commandType: 'reply',
  args: [ 'user', '3', 'unknown connection(s)' ] }
/home/one/github/jayp-bot/node_modules/irc/lib/irc.js:759
                        throw err;
                              ^
TypeError: undefined is not a function

Note: If make secure: true in options, then I get some success but I also get:

18 Apr 19:42:37 - Network error: Error: write EPROTO 140376192080:error:1470FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol:../deps/openssl/openssl/ssl/s23_clnt.c:795:

18 Apr 19:42:37 - Connection got "close" event

I don't want to use ssl, but identify instead.

[dman777]

@yanickrochon I think this is the same issue #342 .

Pull #318 addresses this issue. I don't think that the fix has been pushed to npm though so you'll have to install directly from Github for the latest version.
"irc": "git://github.com/martynsmith/node-irc" should do it.

[dman777]

blah...didnt work for me

[yanickrochon]

@dman777 I don't know why there's a mention of rpl_luserunknown in either of these issues... it has nothing to do with it. It's about registered IRC nicks because the server is basically saying "Yeah, you can connect, but I don't know who you are." The proper handler should PRIVMSG to NickServ with identify as command, providing the registered nick's password. But this is not implemented, yet.

[dman777]

Yep....I tried placing

            case 'rpl_luserunknown':
                self.send('IDENTIFY', self.opt.password);
                break;

in both case selects, but I still get

/home/one/jayp-bot/node_modules/irc/lib/irc.js:754
                        throw err;
                              ^
TypeError: undefined is not a function

can't find exactly where it is calling a undefined function.

[yanickrochon]

Your error "undefined is not a function" seems to be unrelated to this module. My guess is that one of your handler fails (i.e. tries to call something, which is not a function).

[dman777]

This is strange...all I have running is:

irc = require('irc');
var client = new irc.Client('irc.freenode.net', 'jayP', {
    userName: 'jayP',
    password: 'pass',
    showErrors: true,
    debug: true,
    channels: '["#grandmasboy"]'
});

[dman777]

@yanickrochon I might also suggest https://www.npmjs.com/package/tennu for a node bot. havvy is the author and is always on ##javascript for help.

[Havvy]

The rpl_lusersunknown message isn't an auth request. It's telling you that there are three users who have this unknown status. Given the lower number, I think they're just services bots. In any case, there's no default behavior other than possibly tracking it that would make sense.

[Zamiell]

Bump. I think that there are two separate issues here. Issue 1 should be fixed in the short term and issue 2 is an improvement to the framework that provides for a higher level of abstraction.

Issue 1:
As yanickrochon mentioned in the original post, when you use this framework to connect to popular IRC servers such as Freenode or SpeedRunsLive, you are greeted by a big ugly red warning/error:

14 May 11:37:05 - Unhandled message: { prefix: 'irc.speedrunslive.com',
  server: 'irc.speedrunslive.com',
  command: 'rpl_luserunknown',
  rawCommand: '253',
  commandType: 'reply',
  args: [ 'Zamiell', '1', 'unknown connection(s)' ] }

Regardless of what you guys decide the default behavior should be, at the end of the day this should be handled by the framework in some manner and not produce a big error message.

Issue 2:
This framework is missing a layer of abstraction. The IRC server's use of the "rpl_luserunknown" message is related to nickserv identification, as dman777 already mentioned above. If someone using this framework wishes to register their bot with the nickserv, then they have to manually include their own such identification mechanism like so:

/* Connect to the server */
var irc = require('irc');
var client = new irc.Client('irc.speedrunslive.com', 'Zamiell', {
    channels: ['#speedrunslive']
});

/* Register with NickServ */
client.addListener('registered', function(message) {
    SRLBot.say('NickServ', 'IDENTIFY mypassword123'); 
});

It would be much nicer if this could be specified in the server configuration object, like so:

/* Connect to the server */
var irc = require('irc');
var client = new irc.Client('irc.speedrunslive.com', 'Zamiell', {
    identify: 'mypassword123',
    channels: ['#speedrunslive']
});

Of course, I haven't read the IRC RFC myself. And I would venture to guess this kind of nickserv identification is not specified in there. If it isn't, then implementing this feature would be an implementation of an IRC convention as opposed to the actual IRC standard.

With that said, mark me down as one who votes on implementing this anyway. This is the kind of thing that goes towards providing the highest-level IRC framework possible.

[yanickrochon]

@Zamiell you're spot on. +1 for that. Regardless of RFC specs, this should be handled. The handler would catch rpl_luserunknown and check if an identify config exists, then send a private message to NickServ as you mentioned. If no rpl_luserunknown is sent, then disregard the identify config, if one is provided.

Of course, the identify password would only apply if the primary nickname is not already in use. ...That being said, I'm not sure how this framework behaves with nickname collision...

This sounds like a really good enhancement, I'm wondering since this was months ago, that code somewhere exists for this in one of the forks or a pull request.

I recommend this be labeled an enhancement.