Hi,

I have a telnet issue which is proving tiresome to say the least (I know we should be using ssh but as yet its not feasible to do so - blame the users)

Basically, I can telnet from putty at one site to a server, however someone else on a different site can access the box but does not get a login prompt even after 5 minutes. PLease note all 3 servers are on a different subnet.

When trying to telnet the following occurs

Red Hat Linux release 6.1 (Cartman)
Kernel 2.2.12-20 on an i686

It then hangs around until killed.

Its not DNS as the same symptoms appear when telnetting to the IP and there are no useful error messages in /var/log/messages although I can see a connection coming in when looking at /var/log/secure.

Strange thing is the user who is unable to telnet to the server can ftp ok...

After doing some googling someone had a similar problem and resolved it by changing the DISPLAY variable but as the server is being accessed via putty from an XP client this may not count in this case.

The same problem occurs when telnetting via DOS.

Hopefully someone will be able to assist before I go nutty.



Thanks in advance.

Since you ruled out a DNS issue by going straight through to IP, is the performance any better if you're on the same subnet as the box? Telnet is an old protocol, and your network guys may have tweaked some things, thinking that no one is going to be using that. Try from the same subnet as the box, and see what happens. If it still occurs, try to stop/restart the telnet service...shake out the cobwebs. Also try flushing the ARP tables, and perhaps ask the network guys to flush the switch/router too.

Now, onto my 'sysadmin' spiel:
You do realize how INCREDIBLY old that version of Linux is, right?? If that box isn't slated for an upgrade, I'd definitely put it on the 'rush' list.

And if you are the administrator, YOU tell the users that you're not going to support Telnet anymore, and they can use SSH, period. No reason not to...plenty of free SSH Clients for any OS these days. If they complain, run Wireshark, and snag a few of their passwords, then visit their desks with them. Remind them how UNSAFE it is, and also remind their managers of it too. Give a FIRM date for the SSH cutover, and stick to it. YOU are responsible for the box...if they're careless, YOU still have to restore files, or explain why data got stolen, and YOU will be held responsible for it. Managers don't want it? Get them to physically sign a piece of paper, acknowledging that you told them about this SERIOUS problem, and they wanted you to ignore it. Unless they sign it, you go ahead with the cutover, and they can update or evaporate...

TBOne makes a very good point here; I've seen in my career many occasions where even though the admin was not the person at fault (situations similar to yours) - should something go wrong; you will be fired/warned! Upgrade to SSH ASAP!!!

Thanks for replies which were much appreciated.

I am aware the OS is very old (we also have release 6.2 servers out there) but there is not much point in upgrading as hopefully they are all being decommisioned in the near future and to change their scripts to use ssh is basically not worth the effort im told.

Server's on the same subnet as the box work perfectly with no wait when telnetting and go direct to 'user' prompt. I am logging onto the box from a different subnet than the box which works ok but other users on different sites/subnets have the problem where the 'user' prompt does not appear which is confusing.

Im going to reboot the server to give it a good kick up the backside and see what happens. Will post an update...


Thanks again..

Well, just flushing the ARP tables may do it...no need for a reboot. Sounding like a network cramp, if it works right on the same subnet, but not from others.

I've seen similar issues with ssh attempts to a remote server. The problem could simply be that a route needs to be added to the Linux 6.1 server in question so that the outbound reply packets can make it back to the machine(s) trying to telnet into the server.

I wish I could give you the exact 'route add' command to try, but I don't know how your network is set up.

Good luck.

Shahriar.

Wonder if changing ports would diag a port blocked issue?

Why do I think telnet uses some other port number to connect?

Thanks for all the suggestions which are appreciated.

After the reboot the user tried again and after approx 1 minute the login prompt appeared (think this happened anyway prior to the reboot but he didn't wait long enough). As a last resort I moved resolv.conf and behold the user logged directly on with no issues.

I plan to ask the guys who look after the DNS server to confirm I have the correct nameserver etc etc but the strange thing is a server on the same subnet works as expected and that has exactly the same resolv.conf as the server which has the issue - spooky.

TBOne - excuse my ignorance but what do you mean by a Network Cramp??

Sorry, a bit of slang. I meant just "a previously unknown network issue". Like ARP tables not being flushed, bad routes, DNS issues, etc.

I've had this issue in the past and it was caused by the server trying to do a double reverse DNS lookup of the incomming IP address, it eventually times out on this and issues the login prompt.

Correct you DNS/network setup so reverse lookups work.

Thanks Simon, ive asked the DNS people to confirm everything looks ok...