Dec 191999

identd problems – patch

I had some identd problems on IRC today and I think I figured out the cause.

You may also want to see auth/tcp server failing (looping), service terminated.

The issue

Today I did some firewall work and rearranged the startup procedures on my box.   Basically, I moved stuff from /etc/rc.local to /usr/local/etc/rc.d (because the former is now deprecated and it is recommended that you use the latter only; see Starting stuff at boot time).   After restarting the box and gettng back onto IRC, I found my hostmask wasn’t correct.  It had a ~ in front of it.  This indicates that your ident failed (I admit to not knowing much about this area, so my basics may be wrong).

What I tried

My first thoughts were that my firewall was blocking the incoming requests.  So I tried this from an external connection:
$ telnet 113
Connected to
Escape character is '^]'.

OK.  The incoming requests are being accepted.  So what’s wrong?

What worked

After trying the above, I remembered that I’d been fooling around with the identd command line options.  I had recently added -o and -e  so I removed both of these and hup’d inetdidentd now worked.   With a bit more playing, I figured out it was the -o option which was causing the ident to fail.  From the ident man page:
The  -o flag tells identd to not reveal the operating sys-
tem type it  is  run  on  and  to  instead  always  return


Other notes

Most of you will know that I run Windows NT on my desktop.  mIRC is my favoured IRC client.  Within mIRC, under File | Setup | Identd, you’ll see the options for an identd server.  I found these options were not necessary when I was running identd on my gateway.  In fact, they had no effect.

Testing identd

Here is an easy way to test if identd is working.  This is best done with two telnet sessions.  This example assumes you have telnet enabled and you are worked

ident works quite simply by providing a mechanism to verify if someone is connected or not.  It allows one computer to ask another "is so-and-so connected to my port from this port on your box?".  It is a simple verification method.  In this test, we will connect to our box from our box, then check the ports being used, then ask ident for a verification.

In the first telnet session, we will set up a telnet to ourselves but not do anything with it.  In the second telnet session, we look at the first session and see what port it is connecting from.  Then we’ll use that information in our ident query.

  1. In your first telnet session, connect to the localhost, and leave it sitting there.   You don’t have to login.

    # telnet localhost
    Connected to localhost.
    Escape character is '^]'.
  2. In your second telnet session, find out what port your telnet is trying to connect from.   Run netstat -a and look for something like this:

    tcp 0 0 localhost.telnet localhost.1380 ESTABLISHED

  3. Then type this.  113 is the identd port.  23 is the port telnet connects to.  And 1380 is the port we were connecting from in step 2.   Subsititute the port you found in step 2.

$ telnet localhost 113
Connected to localhost.
Escape character is '^]'.
23 , 1380 : USERID : UNIX:DAN
Connection closed by foreign host.

Given all of the above steps, you should be able to verify that identd is running.

An identd patch

I created a patch for pidentd-2.8.5 because I didn’t like the way the -N option worked.  From man identd:
The  -n  flag  tells  identd to always return user numbers
instead of user names if you wish to keep the user names a
secret.   The  -N  flag  makes  identd  check  for  a file
".noident" in each homedirectory for a user which the dae-
mon  is  about  to  return the user name for. It that file
exists then the daemon will  give  the  error  HIDDEN-USER
instead of the normal USERID response.

However, identd returns this if you use the -N flag and have a .noident file in the home directory:

23 , 1380 : ERROR : HIDDEN-USER

which is an error, oddly enough.  I’d rather have success than a error.  So I made a patch to fix this.  With that patch, the following is returned for a .noident user:


That’s useful for some users which you may not wish to ident, but still wish to return a valid ident response.