telnet not accessible?

[Doug O'Leary]

Hey;

This one's got me buggered. I apparently need to enable telnet on an HPUX 11.00 system. Telnet's uncommented in /etc/inetd.conf and I'm able to telnet to localhost on the box.

No one off the box, though, can telnet to the system - we get a connection timed out error.

I've verified that telnet's not wrapped via tcpwrappers and that the /var/adm/inetd.sec file is all commented out.

The networking people swear there's no firewall between the system and anything else in the network.

Anyone have any ideas what may be blocking telnet on this antique?

Thanks for any hints/tips/suggestions.

Doug O'Leary

[Steven Schweda]

> [...] I apparently need to enable telnet
> [...]

> [...] I'm able to telnet to localhost on
> the box.

That sounds enabled, doesn't it? How about
to its real interface name, not "localhost"?

Bad routes? (Can't see 'em from here.)
Firewall (external)? Is Telnet the only
service affected?

[Andrew Rutter]

hi,

did you remove the hash in the inetd.conf or was it always uncommented?

if you uncommented it did you run the inetd -c command to re-read the config file?

or have you checked the /etc/services file as well? check the port?

or use netstat to see if telnet is running something like this

#netstat -an |grep LISTEN |grep 23

Andy

[Doug O'Leary]

Hey;

I can ssh to the system so the network routes are good. I just checked and telnet/ftp both are unable to connect.

So, to rephrase:

1. I can connect to telnetd on the localhost
2. I can ssh to the system, ping it, etc.
3. telnetd/ftpd both get connection time outs.
4. network people say there's no firewall on the network affecting these protocols
5. telnet/ftp aren't wrapped, have always been uncommented, and /var/adm/inetd.sec is empty.

Any ideas?

Thanks.

Doug O'Leary

[Steven Schweda]

> Any ideas?

Find new network people?

If you had enough loose junk lying around,
then you could run an experiment like: Take
a system which works properly as a Telnet/FTP
server, yank the problem system, and
reconfigure/substitute the known-working
system for the problem system. (So, same IP
address, same network cable, ...) If the
problem remains, then I'd show the evidence
to the network people. If it disappears,
then I'd throw up my hands, because I haven't
thought of another good reason for the
problem.

[Doug O'Leary]

Hey;

>>Find new network people?

Yea, that's kind of where I ended up too. I just wanted to reconfirm that there's nothing else in the OS that could be blocking this.

Thanks; appreciate the replies.

Doug

[Steven Schweda]

> [...] I just wanted to reconfirm that
> there's nothing else in the OS that could
> be blocking this.

My inability to think of it is not exactly a
proof of nonexistence, but, on the bright
side, at least I'm not suggesting that you
check to see if the server's listening after
you said that you were "able to telnet to
localhost on the box."

[Ismail Azad]

Hi Doug,

I would like to ask one question, since you are not able to telnet/ftp to your server... Are you able to do an rlogin or remsh?? If that is also not happening then something sounds fishy with the inetd superdaemon. Your /etc/hosts has a loopback address entry?? I know that sounds like a strange question but upper layer protocols do not function properly without the presence of loopback address in the /etc/hosts file. Just a small tip documented in a lotta places. Sometimes getting out of the troublshooting loop involves checking really simple stuff, like is the inetd control variable set as 1 on your /etc/rc.config.d/netdaemons?

Regards
Ismail Azad

[Doug O'Leary]

Hey;

Hey;

All the insecure protocols work on the box itself. For instance, I can ssh to the system, then run "telnet 0" and get an immediate response from the indetd/telnetd.

loopback is in the /etc/hosts file too. Confirmed that just now.

I just kicked the service call back to the network people. I love these ping-pong trouble tickets

Thanks again for the replies.

Doug O'Leary