identd won't work

G-Mantle · 10-20-2002, 03:35 AM

I've been hunting for a solution to this problem for the last few weeks. Hopefully someone here has encountered one...

For some reason, identd doesn't work when I'm running in OS X. I'll try to connect to an IRC server that requires it only to be denied access. I have identd enabled and I do not use OS X's firewall, so I'm confused as to what else could be causing this. I suspected it might be my router's firewall, but I tried rebooting into OS 9 and I connected with no problems. Any ideas about this?

(I don't know if this is related, but I also can't send files to people on my home network via AIM. Again, OS 9 allows this, X 10.2 doesn't.)

bradrf · 10-20-2002, 04:00 PM

You've probably already checked these, but just in case, I'll offer them up as a suggestion anyway.

First, make sure the service you want is actually listening on the intended port. For example, if you were trying to get imap working, you might use a command like the following...

netstat -atn | grep 143

...and you should see something like this...

tcp4 0 0 *.143 *.* LISTEN

...indicating that inetd (or something) is listening for connections from anywhere.

Next, watch the traffic when you try to use the service. Using imap again, I might make use of the following command...

sudo tcpdump -n -i en0 tcp port 143

...and I'll hopefully see a TCP handshake occur when I try to access the imap service. The handshake normally includes a SYN, SYN-ACK, ACK sequence.

My apologies if this is stuff you've already looked into.

G-Mantle · 10-20-2002, 05:12 PM

I tried out your suggestion and got a bunch of results back, although I'm not sure what it all means. It doesn't look like the handshake is taking place. (Or it is and I can't tell, please excuse my technical ignorance.) Instead of the syn, syn-ack, ack sequence, it looks more like:

[somewhat truncated]

S 2862224093:2862224093(0) win 5840 <mss 1460,sackOK,timestamp 1727676170 0,nop,wscale 0>
S 4011079042:4011079042(0) ack 2862224094 win 33304 <mss 1460,nop,wscale 0,nop,nop,timestamp 12542 1727676170> (DF)
. ack 1 win 5840 <nop,nop,timestamp 1727676352 12542>
P 1:15(14) ack 1 win 5840 <nop,nop,timestamp 1727676468 12542>
. ack 15 win 33290 <nop,nop,timestamp 12543 1727676468> (DF)
P 1:33(32) ack 15 win 33304 <nop,nop,timestamp 12543 1727676468> (DF)
F 33:33(0) ack 15 win 33304 <nop,nop,timestamp 12543 1727676468> (DF)
. ack 33 win 5840 <nop,nop,timestamp 1727676735 12543>
. ack 34 win 5840 <nop,nop,timestamp 1727676775 12543>
F 15:15(0) ack 34 win 5840 <nop,nop,timestamp 1727676892 12543>
. ack 16 win 33304 <nop,nop,timestamp 12544 1727676892> (DF)

What do you make of that?

bradrf · 10-20-2002, 07:26 PM

Don't worry about not understanding tcpdump's output...it's confusing as hell. I much prefer ethereal (or tethereal), but that's not always available like tcpdump is. Lowest common denominator.

So, this is actually good news. We have the full TCP handshake going...

S 2862224093:2862224093(0) win 5840 <mss 1460,sackOK,timestamp 1727676170 0,nop,wscale 0>
S 4011079042:4011079042(0) ack 2862224094 win 33304 <mss 1460,nop,wscale 0,nop,nop,timestamp 12542 1727676170> (DF)
. ack 1 win 5840 <nop,nop,timestamp 1727676352 12542>

...and we've got some data getting pushed through the connection...

P 1:15(14) ack 1 win 5840 <nop,nop,timestamp 1727676468 12542>
. ack 15 win 33290 <nop,nop,timestamp 12543 1727676468> (DF)
P 1:33(32) ack 15 win 33304 <nop,nop,timestamp 12543 1727676468> (DF)

...and we've got a normal TCP close occuring...

F 33:33(0) ack 15 win 33304 <nop,nop,timestamp 12543 1727676468> (DF)
. ack 33 win 5840 <nop,nop,timestamp 1727676735 12543>
. ack 34 win 5840 <nop,nop,timestamp 1727676775 12543>
F 15:15(0) ack 34 win 5840 <nop,nop,timestamp 1727676892 12543>
. ack 16 win 33304 <nop,nop,timestamp 12544 1727676892> (DF)

So, why is this good? It at least tells us the service you are trying to get working is running and accepting connections. It's a bit difficult to know who's doing what, but whoever sent the first FIN was the side that requested that the connection be closed. Odds are, there is a protocol problem between the client that is accessing the service and the server providing the service. It's difficult to know without knowing what the service is, what errors you are getting, and what the data looks like.

Hope this helps...

G-Mantle · 10-20-2002, 07:35 PM

Ah, so it's working after all. I wonder if this could possibly still be the router's firewall interfering, although I don't know why it would behave differently between OS 9 and X. Maybe it's time I emailed the people behind my IRC client. Thank you very much for explaining this to me.

yoel · 10-20-2002, 08:35 PM

I think you may have taken the instructions a little too literally. What you are seeing is probably IMAP traffic, since you are tcpdumping port 143, right? Ident (auth) is port 113, and is run out of inetd. To enable it, do the following:
edit /etc/xinetd.d/auth and change the line that says:
"disable = yes"
to
"disable = no"

Restart xinetd by doing:
"sudo killall -HUP xinetd"
on the command line.

Now test by telneting to that port locally, i.e.
"telnet localhost 113"

if you get a connection (no "connection refused" message), you are all set.

G-Mantle · 10-21-2002, 12:57 AM

Actually, the tcpdump output I posted was for 113. I did try your hint, though, just in case. When I tried telnetting to 113, I got:

Trying ::1...
telnet: connect to address ::1: Connection refused
Trying 127.0.0.1...
Connected to localhost.

I'm not sure what the ::1 is about. IRC still refuses to connect, however.

yoel · 10-21-2002, 01:50 AM

The ::1: is your local IPv6 address. If you look in your /etc/hosts, you will see:
::1 localhost

But as for your actual problem, it sounds like identd is running and you did everything right. So, I am now out of ideas

.

G-Mantle · 10-21-2002, 03:30 AM

Ah well. Thanks for letting me know about this other little switch. It might end up being part of the solution.

10-20-2002, 03:35 AM	#1
G-Mantle Prospect Join Date: Oct 2002 Posts: 5	identd won't work I've been hunting for a solution to this problem for the last few weeks. Hopefully someone here has encountered one... For some reason, identd doesn't work when I'm running in OS X. I'll try to connect to an IRC server that requires it only to be denied access. I have identd enabled and I do not use OS X's firewall, so I'm confused as to what else could be causing this. I suspected it might be my router's firewall, but I tried rebooting into OS 9 and I connected with no problems. Any ideas about this? (I don't know if this is related, but I also can't send files to people on my home network via AIM. Again, OS 9 allows this, X 10.2 doesn't.)

10-20-2002, 04:00 PM	#2
bradrf Prospect Join Date: Oct 2002 Location: WA Posts: 6	You've probably already checked these, but just in case, I'll offer them up as a suggestion anyway. First, make sure the service you want is actually listening on the intended port. For example, if you were trying to get imap working, you might use a command like the following... netstat -atn \| grep 143 ...and you should see something like this... tcp4 0 0 .143 .* LISTEN ...indicating that inetd (or something) is listening for connections from anywhere. Next, watch the traffic when you try to use the service. Using imap again, I might make use of the following command... sudo tcpdump -n -i en0 tcp port 143 ...and I'll hopefully see a TCP handshake occur when I try to access the imap service. The handshake normally includes a SYN, SYN-ACK, ACK sequence. My apologies if this is stuff you've already looked into.

10-20-2002, 05:12 PM	#3
G-Mantle Prospect Join Date: Oct 2002 Posts: 5	I tried out your suggestion and got a bunch of results back, although I'm not sure what it all means. It doesn't look like the handshake is taking place. (Or it is and I can't tell, please excuse my technical ignorance.) Instead of the syn, syn-ack, ack sequence, it looks more like: [somewhat truncated] S 2862224093:2862224093(0) win 5840 <mss 1460,sackOK,timestamp 1727676170 0,nop,wscale 0> S 4011079042:4011079042(0) ack 2862224094 win 33304 <mss 1460,nop,wscale 0,nop,nop,timestamp 12542 1727676170> (DF) . ack 1 win 5840 <nop,nop,timestamp 1727676352 12542> P 1:15(14) ack 1 win 5840 <nop,nop,timestamp 1727676468 12542> . ack 15 win 33290 <nop,nop,timestamp 12543 1727676468> (DF) P 1:33(32) ack 15 win 33304 <nop,nop,timestamp 12543 1727676468> (DF) F 33:33(0) ack 15 win 33304 <nop,nop,timestamp 12543 1727676468> (DF) . ack 33 win 5840 <nop,nop,timestamp 1727676735 12543> . ack 34 win 5840 <nop,nop,timestamp 1727676775 12543> F 15:15(0) ack 34 win 5840 <nop,nop,timestamp 1727676892 12543> . ack 16 win 33304 <nop,nop,timestamp 12544 1727676892> (DF) What do you make of that?

10-20-2002, 07:26 PM	#4
bradrf Prospect Join Date: Oct 2002 Location: WA Posts: 6	Don't worry about not understanding tcpdump's output...it's confusing as hell. I much prefer ethereal (or tethereal), but that's not always available like tcpdump is. Lowest common denominator. So, this is actually good news. We have the full TCP handshake going... S 2862224093:2862224093(0) win 5840 <mss 1460,sackOK,timestamp 1727676170 0,nop,wscale 0> S 4011079042:4011079042(0) ack 2862224094 win 33304 <mss 1460,nop,wscale 0,nop,nop,timestamp 12542 1727676170> (DF) . ack 1 win 5840 <nop,nop,timestamp 1727676352 12542> ...and we've got some data getting pushed through the connection... P 1:15(14) ack 1 win 5840 <nop,nop,timestamp 1727676468 12542> . ack 15 win 33290 <nop,nop,timestamp 12543 1727676468> (DF) P 1:33(32) ack 15 win 33304 <nop,nop,timestamp 12543 1727676468> (DF) ...and we've got a normal TCP close occuring... F 33:33(0) ack 15 win 33304 <nop,nop,timestamp 12543 1727676468> (DF) . ack 33 win 5840 <nop,nop,timestamp 1727676735 12543> . ack 34 win 5840 <nop,nop,timestamp 1727676775 12543> F 15:15(0) ack 34 win 5840 <nop,nop,timestamp 1727676892 12543> . ack 16 win 33304 <nop,nop,timestamp 12544 1727676892> (DF) So, why is this good? It at least tells us the service you are trying to get working is running and accepting connections. It's a bit difficult to know who's doing what, but whoever sent the first FIN was the side that requested that the connection be closed. Odds are, there is a protocol problem between the client that is accessing the service and the server providing the service. It's difficult to know without knowing what the service is, what errors you are getting, and what the data looks like. Hope this helps...

10-20-2002, 07:35 PM	#5
G-Mantle Prospect Join Date: Oct 2002 Posts: 5	Ah, so it's working after all. I wonder if this could possibly still be the router's firewall interfering, although I don't know why it would behave differently between OS 9 and X. Maybe it's time I emailed the people behind my IRC client. Thank you very much for explaining this to me.

10-20-2002, 08:35 PM	#6
yoel Prospect Join Date: Oct 2002 Posts: 5	I think you may have taken the instructions a little too literally. What you are seeing is probably IMAP traffic, since you are tcpdumping port 143, right? Ident (auth) is port 113, and is run out of inetd. To enable it, do the following: edit /etc/xinetd.d/auth and change the line that says: "disable = yes" to "disable = no" Restart xinetd by doing: "sudo killall -HUP xinetd" on the command line. Now test by telneting to that port locally, i.e. "telnet localhost 113" if you get a connection (no "connection refused" message), you are all set.

10-21-2002, 12:57 AM	#7
G-Mantle Prospect Join Date: Oct 2002 Posts: 5	Actually, the tcpdump output I posted was for 113. I did try your hint, though, just in case. When I tried telnetting to 113, I got: Trying ::1... telnet: connect to address ::1: Connection refused Trying 127.0.0.1... Connected to localhost. I'm not sure what the ::1 is about. IRC still refuses to connect, however.

10-21-2002, 01:50 AM	#8
yoel Prospect Join Date: Oct 2002 Posts: 5	The ::1: is your local IPv6 address. If you look in your /etc/hosts, you will see: ::1 localhost But as for your actual problem, it sounds like identd is running and you did everything right. So, I am now out of ideas .

10-21-2002, 03:30 AM	#9
G-Mantle Prospect Join Date: Oct 2002 Posts: 5	Ah well. Thanks for letting me know about this other little switch. It might end up being part of the solution.