From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041115 Firefox/1.0 Description of problem: telnet client and server are both the above version both fully up2date RHEL3 systems. /etc/sysconfig/i18n: LANG="de_DE.UTF8" #"en_US.UTF-8" SUPPORTED="de_DE.UTF-8:de_DE:en_GB.UTF-8:en_GB:en:en_US.UTF-8:en_US:en:en_US.UTF-8:en_US:en" SYSFONT="latarcyrheb-sun16" on the Server side: LANG="de_DE.UTF-8" SUPPORTED="en_GB.UTF-8:en_GB:en:de_DE.UTF-8:de_DE:de" SYSFONT="latarcyrheb-sun16" However this should not matter the telnet client does not take the caracters like ����� and pass them on the the server during a normal logon scession. Version-Release number of selected component (if applicable): telnet-0.17-26 How reproducible: Always Steps to Reproduce: 1.telnet ip 2. log on a user 3. type caracter like ������ Actual Results: diffrent caracters than the expected ones. Expected Results: Should pass on these typed caracters. Additional info: Tested on two RHEL3 fully up2date systems.
*** Bug 144249 has been marked as a duplicate of this bug. ***
From the duped bug: The weird looking characters should be german umlauts like the special characters for ae oe ue and sz.
It seems to me that this is a problem with the telnet client only? When using a windows telnet client I don't get the problem, it only appears when makeing a telnet between two Red Hat machines.
could you please provide the output of: $ which telnet
Can your X-Terminal (xterm, konsole, gnome-terminal) display the Umlauts correctly? Does "ssh" work?
Harald; [root@smann redhat]# which telnet /usr/kerberos/bin/telnet [root@smann redhat]# ssh does work, even windows telnet clients do. Gnome-terminal do display the Umlauts correct.
which telnet /usr/kerberos/bin/telnet Interesting. /usr/bin/telnet does not have the Problem. Everything else works correctly.
reassigning to kerberos
Telnet is stripping off the high bit of characters you're inputting before sending them because the telnet binary option hasn't been negotiated. I'm not actually sure yet that this is a bug, because the telnet specs default to treating options which haven't been negotiated as if they were disabled. Either way, passing "-8" to telnet on the command line should force the telnet binary option to be negotiated, which will give you the results you're expecting.
Closing because the telnet client is obeying the protocol specs, and there's a command-line option which provides the desired behavior.