I have recently gone back to IRC — specifically Freenode — and among the delicious problems of the old days, such as the inability to easily establish DCC transfers (more on that later), I have been presented with the inevitable ident check delay during the connection to server. Ident is essentially a protocol that lets the server know what user is effectively connecting from the client machine. It can be very handy, but most people are behind NAT and/or do not run any ident daemon. This translates to a delay while the server patiently waits for an ident reply before giving up and adding a tilde to the username in the hostmask, which effectively means “this user claims to be called foobar, but I could not verify it.” In practice, this doesn’t change anything at all.
The ident check timeout depends on how the IRC server is configured. Freenode takes a very conservative approach, using a timeout of 15 seconds. This is what happens:
[08:43:08] --- Looking up irc.freenode.net..
[08:43:08] --- Connecting to chat.freenode.net (2001:6b0:e:2018::172) port 6667..
[08:43:08] --- Connected. Now logging in..
[08:43:08] --- *** Looking up your hostname...
[08:43:08] --- *** Checking Ident
[08:43:08] --- *** Couldn't look up your hostname
[08:43:23] --- *** No Ident response
[08:43:23] --- Welcome to the freenode Internet Relay Chat Network Jollino
...etc...
Not exactly the fastest thing. The problem here is not that I lack an ident daemon; it’s that my router filters all ports by default. A filtered port is neither open or closed, so a remote party trying to connect to it is left waiting indefinitely. After all, the lack of an immediate response might be due to a congested network. Indeed, when I tried connecting to port 113 (ident) from a remote shell, here is what happened:
[cyclops]$ time telnet 151.64.126.29 113
Trying 151.64.126.29...
telnet: Unable to connect to remote host: Connection timed out
real 0m21.003s
user 0m0.000s
sys 0m0.000s
Linux’s telnet in this case seems to have a timeout of 21 seconds. Freenode’s IRC deamon waits 15. It’s still too much. Compare to what happens with a closed port:
[cyclops]$ time telnet 151.64.126.29 6870
Trying 151.64.126.29...
telnet: Unable to connect to remote host: Connection refused
real 0m0.266s
user 0m0.000s
sys 0m0.004s
Much better, isn’t it? The solution is straightforward: unfiltering port 113. My router however only does that by forwarding a port to an internal machine (that is, I have to selectively pierce the NAT so that incoming connections to port X are forwarded to internal machine a.b.c.d on port Y — X and Y can be the same, of course). Is that a problem? Not really, but the recipient machine has to be active, otherwise you will incur into another connection timeout and you’re back to square one. Interestingly enough, it turns out that my router is perfectly fine with redirecting ports to itself, so I simply had connections to (external) port 113 to port 113 on itself. Here is the result from the shell:
[cyclops]$ time telnet 151.64.126.29 113
Trying 151.64.126.29...
telnet: Unable to connect to remote host: Connection refused
real 0m0.234s
user 0m0.000s
sys 0m0.000s
And here is how it works when connecting to IRC:
[10:59:03] --- Looking up irc.freenode.net..
[10:59:03] --- Connecting to chat.freenode.net (2001:6b0:5:1688::10) port 6667..
[10:59:03] --- Connected. Now logging in..
[10:59:03] --- *** Looking up your hostname...
[10:59:04] --- *** Checking Ident
[10:59:04] --- *** Couldn't look up your hostname
[10:59:04] --- *** No Ident response
[10:59:04] --- Jollino already in use. Retrying with Jollino_..
[10:59:04] --- Welcome to the freenode Internet Relay Chat Network Jollino_
...etc...
Much better, isn’t it?
As for DCC, the situation is more complex. The protocol works with the recipient connecting to the sender, so opening up specific ports on the router (and redirecting them to the machine where the IRC client is running) and telling the client to use such ports should work. That’s how I used to work it around years ago. However, it’s not working anymore. I can connect to myself from a remote shell, but the actual recipient won’t. In this time and age, though, it‘s much faster to just upload things to Dropbox and share the link, so I’m not going to investigate that further.
NAT has killed the peer-to-peer, everyone-is-equal internet as we used to know it. It’s really sad.
man,
im using 1 trivia eggdrop with same IRCD. do this make my server slow ?
No, unless the server has very little RAM or a very slow CPU it won’t affect the speed.
Why do IRC servers even bother with the ident check anyway? Virtually no-one uses it, and it doesn’t mean anything anyway.
Well, back in the day IRC was born it was meaningful, as you would normally come out of a shared box with your own actual user account. Nowadays it’s pretty much pointless and most newer IRC daemons allow you to skip ident check entirely as to not waste resources on the server, but some big networks keep up with the tradition because a “properly configured client” (ie. one that provides an ident reply) is less likely to be a spambot. In fact, some networks have stricter I-lines for clients without ident.