topic Re: Impossible to telnet port 5555 in Operating System - Linux

Impossible to telnet port 5555

Carles Viaplana — Wed, 10 Jan 2007 11:24:43 GMT

Hello,

I'm trying to connect to suse linux 9 enterprise server to port 5555 throught telnet, but I can't.

I already opened 5555 tcp port.
I added remote host to .rhosts file.
I granted telnet to remote host.

Do I miss something?

Thanks in advance for your help.
Regards,

Carles

Re: Impossible to telnet port 5555

Ivan Ferreira — Wed, 10 Jan 2007 13:10:09 GMT

What is the service that is running in the port 5555, is it data protector?

If you run

netstat -an |grep 5555

Do you see the port in the LISTEN state?

Try stopping the firewall if any:

service iptables stop

Re: Impossible to telnet port 5555

Jerome Henry — Wed, 10 Jan 2007 13:42:34 GMT

Hi Carles,

Just a quick thought :
telnet is enabled, right ? (in /etc/xinetd.d/telnet, you don't have disable to yes)
You firewall is not blocking, right ?

J

Re: Impossible to telnet port 5555

Carles Viaplana — Thu, 11 Jan 2007 04:00:27 GMT

Sorry for delay in my replay.

Yes, this is for data protector.

I executed command as you show and here you're output:

liubliana:/etc/xinetd.d # netstat -an |grep 5555
tcp 0 0 0.0.0.0:5555 0.0.0.0:* LISTEN
unix 3 [ ] STREAM CONNECTED 15555
liubliana:/etc/xinetd.d #

About firewalls, they're not active.

BTW, telnet is active, but it doesn't allow to me login (default port or 5555 port), so I think problem is due my telnet configuration.

Do you have any idea?

Thanks in advance for your help!
Regards,

Carles

Re: Impossible to telnet port 5555

Alexander Chuzhoy — Thu, 11 Jan 2007 04:16:27 GMT

On RedHat system if you want to configure the telnet server to listen on port 5555.
Then simply edit the file /etc/services. Locate the lines with telnet and change the port from what it is to 5555.
Then restart the telnet service and it works...
Have you done all equivalent steps on your machine?

Re: Impossible to telnet port 5555

Carles Viaplana — Thu, 11 Jan 2007 04:32:32 GMT

Hello,

I added the following entry in /etc/services file:

omni 5555/tcp # DATA-PROTECTOR

Regards,

Carles

Re: Impossible to telnet port 5555

Rob Leadbeater — Thu, 11 Jan 2007 07:35:57 GMT

Hi,

Can you confirm exactly what you're trying to achieve... and what you get when attempting to telnet to port 5555.

If you're simply testing that Data Protector is working (listening on port 5555) then you'll get a connection, but nothing more -you won't get a login prompt.

For example:

# telnet server01 5555
Trying 192.168.0.1...
Connected to server01.domain.com (192.168.0.1).
Escape character is '^]'.
^]

telnet> quit
Connection closed.

If you try to connect to a port which is not listening then you'll get a refused:

# telnet server01 5554
Trying 192.168.0.1...
telnet: Unable to connect to remote host: Connection refused

Cheers,

Rob

Re: Impossible to telnet port 5555

Carles Viaplana — Thu, 11 Jan 2007 08:49:20 GMT

Hello,

When I tried to telnet suse system with data protector working fine I get the following message:

# telnet riad 5555
Trying...
Connected to riad.santpau.es.
Escape character is '^]'.
HP OpenView Storage Data Protector A.05.50: INET, internal build 330, built on Tue Oct 12 23:06:00 2004
Connection closed by foreign host.
# telnet riad
Trying...
telnet: Unable to connect to remote host: Connection refused
#

But when I telnet new suse system I get the following message:

# telnet liubliana 5555
Trying...
Connected to liubliana.santpau.es.
Escape character is '^]'.
Connection closed by foreign host.
# telnet liubliana
Trying...
Connected to liubliana.santpau.es.
Escape character is '^]'.
Local flow control on
Telnet TERMINAL-SPEED option ON
Welcome to SUSE LINUX Enterprise Server 9 (x86_64) - Kernel 2.6.5-7.244-smp (1).

liubliana login: root
Password:
Login incorrect

telnet> quit
Connection closed.
#

So I think problem is on my services/telnet configuration instead data protector installation as inet service is running.

Thanks in advance for your help.
Regards,

Carles

Re: Impossible to telnet port 5555

Jerome Henry — Thu, 11 Jan 2007 11:06:54 GMT

Ok
What do you logs tell you on riad ?

Re: Impossible to telnet port 5555

Ivan Ferreira — Thu, 11 Jan 2007 12:06:16 GMT

First of all, you can telnet to the 5555 port, but this service is not used for login. You telnet to the 5555 port only to ensure that is listening, do not expect a login prompt.

Second, you can telnet to the host to the normal 23 port, but you cannot login with root by default. If you try with another user you will login sucessfully.

Re: Impossible to telnet port 5555

Carles Viaplana — Fri, 12 Jan 2007 05:12:27 GMT

Hello,

This is the message in syslog when I try to telnet liubliana (new system with DP not working properly):

Jan 12 10:58:06 liubliana xinetd[22431]: execv( /usr/omni/bin/inet ) failed: Exec format error (errno = 8)

When I try to telnet riad (DP working properly), there isn't any message in any syslog file (warn, messages,...).

I hope it helps.
Regards,

Carles

Re: Impossible to telnet port 5555

Matti_Kurkela — Wed, 17 Jan 2007 08:46:55 GMT

This log message is a critical clue.

Jan 12 10:58:06 liubliana xinetd[22431]: execv( /usr/omni/bin/inet ) failed: Exec format error (errno = 8)

This means xinetd is trying to run /usr/omni/bin/inet but fails. "Exec format error" means the binary might be for the wrong architecture (maybe you've installed a package intended for 64-bit Itanium or Opteron architecture rather than 32-bit ix86, or some similar mistake).

Use "file /usr/omni/bin/inet" to check the type of the executable. Compare the result to a binary that is known to work, e.g. "file /bin/ls".

If the architecture is correct, check that all the libraries required by the /usr/omni/bin/inet binary are available:
use the command "ldd /usr/omni/bin/inet". If the command lists any library as "not found", you've found a problem. Check your distribution's software package catalog to find the necessary library packages, and install them.

Since xinetd is configured, the connection gets established and xinetd tries to start /usr/omni/bin/inet... but when xinetd finds it cannot start the binary that is supposed to handle the connection, it has no other options than to immediately close the connection.

Re: Impossible to telnet port 5555

Huc_1 — Wed, 17 Jan 2007 09:07:23 GMT

If Matti is right you should find trace of this is log files ... /var/log/messages ?

Jean-Pierre Huc

Re: Impossible to telnet port 5555

Carles Viaplana — Thu, 18 Jan 2007 03:57:47 GMT

Hello,

I executed file and ldd commands with next outputs:

liubliana:~ # file /usr/omni/bin/inet
/usr/omni/bin/inet: setuid ELF 64-bit LSB executable, IA-64 (Intel 64 bit architecture), version 1 (SYSV), for GNU/Linux 2.4.0, dynamically linked (uses shared libs), stripped
liubliana:~ # file /bin/ls
/bin/ls: ELF 64-bit LSB executable, AMD x86-64, version 1 (SYSV), for GNU/Linux 2.4.1, dynamically linked (uses shared libs), not stripped
liubliana:~ # ldd /usr/omni/bin/inet
not a dynamic executable
liubliana:~ #

As I told in previous posts, we're installing data protector 5.50 into this linux system. After your post it could be we're installing software from a wrong CD. Problem is this is the only CD for UNIX we've found and I already opened a thread in OpenView forum and for Suse Linux we have to use HP-UX CD, so I assume this is the right version.

About messages log file, line I posted before is the only message related with this issue.

Thanks in advance for your help.
Regards,

Carles

Re: Impossible to telnet port 5555

Matti_Kurkela — Thu, 18 Jan 2007 04:32:07 GMT

Based on the "file" command output you posted, the /usr/omni/bin/inet is for Itanium architecture.

Your server seems to be "x86-64" architecture which is also 64-bit, but incompatible with Itanium.
However, the x86-64 architecture is backwards compatible with the classic 32-bit x86 software: so you could install the 32-bit version of the Data Protector and it should work, provided that you have 32-bit versions of all the necessary libraries installed.

With a backup application, the difference between "native" 64-bit application and "legacy" 32-bit one might not be very significant. Just be aware of possible file size limitations (check if there are any) when using the 32-bit version.