Linux – Telnet server terminal support not working

scientific-linuxtelnetterminal

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.

Symptoms

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:

Trying 128.222.3.71...
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
ogin:
      Password:
                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.

Diagnosing

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…

Platform

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
glibc-2.12-1.192.el6.x86_64
xinetd-2.3.14-40.el6.x86_64
telnet-server-0.17-48.el6.x86_64
ncurses-5.7-4.20090207.el6.x86_64
ncurses-base-5.7-4.20090207.el6.x86_64
ncurses-libs-5.7-4.20090207.el6.x86_64

Best Answer

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.

Related Question