Telnet Server Problem

It looks like a recent Yum update (20 July 2016) broke the telnet-server on one of our VMs. Using an SSH connection to the same server works fine. I'm trying to track down where the problem is exactly, but don't really know what I'm doing, so any help would be appreciated.


When we log on to the server using the telnet protocol we get this sort of behaviour:

[uniworks@mort ~]$
                   [uniworks@mort ~]$
                                      [uniworks@mort ~]$
                                                         [uniworks@mort ~]$
                                                                            speed 9600 baud; rows 64; columns 80; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0;
-parenb -parodd cs8 -hupcl -cstopb cread -clocal -crtscts -cdtrdsr
-ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon -ixoff
-iuclc -ixany -imaxbel -iutf8
opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt
echoctl echoke

As you can see, command are not being echoed to the screen (like having "stty -echo" on), and we get this "staircase" effect when hitting Enter.

Perhaps significantly, we get some problems as soon as we connect - even before logging in:

Connected to mort.
Escape character is '^]'.
Scientific Linux release 6.8 (Carbon)
Kernel 2.6.32-504.16.2.el6.x86_64 on an x86_64
                ast login: Mon Jul 25 12:15:44 from sam
ress the <Backspace> key now:

As you can see, the first character of "login:" is missing and the username I entered hasn't been displayed.


First of all, these symptoms only appear when we are using telnet. I have tried using an already connected session to another old RHEL 4.7 server, then from that session I telnetted to the server with the problem. I then exited and in the same session I then ssh'ed to the problem server using the same username, etc. I have then repeated the process a couple of times and the results are the same. So the telnet emulator, user, and other settings aren't the problem.

I checked the TERM and stty settings once logged in and they are almost the same. In the telnet session the speed is set to 9600 cf. 38400 when I use an ssh connnection, and "stty lnext" is set to "^V" cf. "" - neither of which appear to be significant. I've tried making them identical just in case, but that doesn't make any difference.

When I use the "up arrow" key + Enter to repeat the last command, the command is displayed, but with the first character missing. If I enter "man stty", the man page seems to be displayed fine.

I've also tried running vim on a text file and I'm getting some strange characters, so the problem looks like a terminal issue, but not sure why it works for ssh connections...


Scientific Linux 6x:

[root@mort ~]# cat /etc/redhat-release
Scientific Linux release 6.8 (Carbon)

Some package versions:

[root@mort ~]# rpm -q glibc xinetd telnet-server ncurses ncurses-base ncurses-libs
  • It's helpful, if you don't have it already, to install yum-plugin-changelog. Then you can do yum changelog 5 telnet-server to get the most recent changes.
    – miken32
    Aug 2, 2016 at 20:32

2 Answers 2


Hmmm... The problem seems to have disappeared after I did the following:

  1. did another yum update which installed the kernel-2.6.32-642.3.1.el6.x86_64 package and its associated kernel-firmware package
  2. applied the universal Microsoft fix from a few years ago - I kicked everyone off and rebooted the server (VM)

(There were also updates to samba4-libs, xorg-x11-drv-ati-firmware, kernel-devel and kernel-headers packages but I doubt any of these are significant.)

I can see from the output from "last" that I had already rebooted the server on the same morning I wrote this question, which leads me to believe that the kernel update fixed the problem. The patterns "kernel*" and "*firmware*" are specifically excluded from the auto-update process in the default configuration of the (Scientific Linux) yum-autoupdate package, so if I had installed the updates manually, I may never have seen the problem. I've never seen this kind of behaviour before, in fact I can't remember seeing any noticeable side-effects from kernel updates before, so that's a new one for me.


It looks like you had a background process still connected to the tty that was being used to handle your (new) login. Rebooting would have killed that process, thereby fixing the problem.

Another solution would have been to determine the name of the affected tty (run tty) and use ps -ft {ttyname} to identify the processes, and kill them.

ps -t $(tty) | awk 'NR>1 {print $1}' | sudo xargs kill -TERM
  • I couldn't still have a process attached to a tty as I had already restarted xinetd a couple of times and had previously rebooted to try and fix the problem - as I said above. It was only after I had updated the kernel and rebooted again to pick up the new kernel that the problem went away.
    – wanpelaman
    Aug 2, 2016 at 20:20
  • @wanpelaman can't see anything in the question that had said you'd rebooted and were still seeing this problem. Your description is a typical symptom of a running backgrounded process. Aug 2, 2016 at 20:46
  • sorry it was in the answer, not the question.
    – wanpelaman
    Aug 3, 2016 at 9:54

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .