From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5)
Description of problem:
telnet client and server are both the above version both fully up2date
on the Server side:
However this should not matter the telnet client does not take the
caracters like ï¿½ï¿½ï¿½ï¿½ï¿½ and pass them on the the server during a normal
Version-Release number of selected component (if applicable):
Steps to Reproduce:
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.
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?
[root@smann redhat]# which telnet
ssh does work, even windows telnet clients do.
Gnome-terminal do display the Umlauts correct.
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.