Fedora Core 3 telnet problem, need advice

rymus

As the subject suggests, we are using fedora core 3 on several servers, most of which give the following problem. When connecting to the server via telnet, the connection dies before showing a login prompt. This could happen anywhere from once to three or four times before a user can successfully enter their login name. The session then seems to run perfectly; the only problem being the need to restart the terminal emulator due to the constant disconnects.

I've already tried updating to the most recent version of telnet available for FC3, I've pretty much ruled out the hardware being at fault (HP Proliant ML350/370) as I installed it on various servers with the same result. It's not an option to use SSH before anyone suggests it (as I've already suggested it several times). Googling has turned up nothing so far. Anyone ever encountered this problem? Better still, anyone know how to fix it? Cheers.

niallb

Hi Rymus,

Why is ssh not an option?
Do connections work perfectly with ssh?
Are you absolutely sure that the network is reliable,
and that this is actually a telnet problem?

Are you actually connecting to fedora, or are you connecting
to a remote admin card via telnet?

You say you're having constant disconnects.
Do you mean during the "succesful" connections?

You say "most of which" servers give this problem.
Do you have even one that never does?
Any hardware differences? Any difference in
the output of iptables-save

When it connects, does it go straight through, or
is there a delay? How far are your clients from the server?
Are you on the edge of a timeout period, so you're
sometimes getting through?

Curious problem!
Sorry for so many questions!

NiallB

rymus

niallb wrote:

Hi Rymus,

Why is ssh not an option?
Do connections work perfectly with ssh?

As far as I'm aware, ssh works flawlessly. It's not an option as I see it because it's too much of a headache to switch over.

Are you absolutely sure that the network is reliable,
and that this is actually a telnet problem?

99.999% sure

Are you actually connecting to fedora, or are you connecting
to a remote admin card via telnet?

To the fedora machine itself.

You say you're having constant disconnects.
Do you mean during the "succesful" connections?

Once a connection is made, i.e. a user enters their username & password, the session seems to stay active as it should. The problem is with the prompt to enter username and password. Sometimes it just doesn't appear when the user connects to the server and it closes the session.

You say "most of which" servers give this problem.
Do you have even one that never does?

It's quite possible there is one that never gives the problem. Its up to the individual users in their own premises to report problems. Some people complain about this, some people suffer on with it and think nothing of it. It's entirely possible its happening everywhere we have fedora installed, it's just not reported.

Any hardware differences? Any difference in
the output of iptables-save

The servers running fedora are all Proliants, most ML350's, two or three ML370's. Only differences really are some have more RAM than others and a couple have dual processors.

When it connects, does it go straight through, or
is there a delay? How far are your clients from the server?
Are you on the edge of a timeout period, so you're
sometimes getting through?

When it connects and logs in ok, there are apparently no further problems until the next time the user logs in. There is no noticable delay, unless of course we are running something in the background. Clients are all within shouting distance of the server, were not exactly stretching the limits of CAT5/6 cabling anywhere. You'll know immediately if it isn't going to connect. Normally, as with any telnet session, the login prompt should appear as soon as you hit connect. This doesn't happen sometimes.

krinDar

My guess is a DNS problem. The telnet daemon is probably trying to resolve
the ip address to a name. If there are not too many IP addresses, try putting
entries for them into /etc/hosts as a temporary test measure.

niallb

I agree with Krindar's suggestion as likely.
Do you use machine names or IP addresses for your connections?
Does an nslookup/dig on the names return a single IP address
which resolves back to that name?

Check /etc/hosts.deny for a PARANOID setting, and comment it out if it's there.
PARANOID is a good idea, but if it solves your problem, you've some work to do on DNS/DHCP before re-enabling it.



Is the system you connect from always the same?
Does it get it's IP address via DHCP?

Is it an MS DHCP server with a dynamically updated DNS server built in?
I've seen a problem with a possible configuration on one of these that
prevented connections in certain situations. The evidence was multiple
IPs registered for one name, leaving a possibility that a reverse lookup
would not always match.

I'll check the thread later this afternoon.
Good luck,
NiallB

rymus

were using an ip address for the connection, there's no DHCP active on the network. Chances are the only DNS server available to any of the PC's is eircom. The server may or may not have dns & gateway specified - it's happening both where dns & gateway addresses are and are not in use on the server.

liamo

Have you used tcpdump/ethereal to establish exactly what's happening when a client tries to connect? All this (it has to be said, very insightful and perceptive) guessing is all very well but a few minutes with tcpdump/ethereal could give you the answer.




Regards,

Liam

krinDar

rymus wrote:

were using an ip address for the connection,

If you are suggesting that there is not a DNS issue because you
are using an IP address for the server instead of a hostname
then you may have misunderstood me.

The issue that I was suggesting , it that when the client connects
to the server, the server tries to look up the clients IP Address, to resolve
it to a hostname so it use the hostname of the client for the utmp file,
any logging etc. instead of the IP address of the client.

It can take some time for the DNS lookup to fail, and this is what
could be producing the delay.

A quick workaround to this problem, is to place an entry for the
client into /etc/hosts on the server.