Bug 149100 - Strange hex codes "\xff\xf4\xff\xfd\x06" being sent
Summary: Strange hex codes "\xff\xf4\xff\xfd\x06" being sent
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: telnet   
(Show other bugs)
Version: 4.0
Hardware: All
OS: Linux
Target Milestone: ---
: ---
Assignee: Adam Tkac
QA Contact: Ben Levenson
Depends On:
TreeView+ depends on / blocked
Reported: 2005-02-18 18:17 UTC by Patrick Melo
Modified: 2013-04-30 23:33 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2010-02-22 17:01:29 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Patrick Melo 2005-02-18 18:17:23 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5)
Gecko/20041107 Firefox/1.0

Description of problem:
The script below works under telnet-0.17-25 but fails intermittently
under telnet-0.17-30.  When I look at the access_log I can see what
appears to be "\xff\xf4\xff\xfd\x06" without the quotes inserted
randomly in request.  I've included access_log examples below.  Please
note, the script is only two lines long.

{ echo "GET / HTTP/1.1" ; echo "Host: www.qicboy.com" ; echo
"User-Agent: sh" ; echo ; sleep 3 ; } | /usr/bin/telnet www.qicboy.com
80  2>/dev/null | tr -d '\15\32' | { while [ "`read r; echo $r`" != ""
]; do true ; done ; echo ; cat ; }
exit - - [17/Feb/2005:14:33:25 -0800]
"GE\xff\xf4\xff\xfd\x06 /qicboy/index.html HTTP/1.1" 502 432 "-" "sh" - - [17/Feb/2005:14:33:25 -0800]
"GE\xff\xf4\xff\xfd\x06 /
H\xff\xf4\xff\xfd\x06\xff\xf4\xff\xfd\x06P/1.1" 502 432 "-" "sh"

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Copy and save the two line bash script, give script execute
permission, change www.qicboy.com to a httpd you can view the
access_log of.
2. Tail the httpd access_log (tail -f access_log) and wait for the
appearance of strange hex characters in the request.
3. From another terminal, run the script a couple of times.

Actual Results:
The hex codes "\xff\xf4\xff\xfd\x06" appear in the GET request.

Expected Results:
These hex codes should not appear in the request at all.

Additional info:
This was not a problem in telnet-0.17-25.

Comment 1 Harald Hoyer 2005-02-21 13:39:46 UTC
could this be UTF-8 ??
Try to start the shell script with:

export LANG=C

Comment 2 Patrick Melo 2005-02-22 15:33:46 UTC
I added the export LANG=C but it didn't fix the problem.

Comment 3 Harald Hoyer 2005-03-02 16:59:31 UTC
does it help to call telnet with the "-8" option?
you may also want HTTP/1.0

Comment 4 Harald Hoyer 2005-03-02 17:05:51 UTC
but I can see no change between -25 and -30, which could produce this behaviour

Comment 5 Patrick Melo 2005-03-02 17:16:10 UTC
I added the -8 option and changed the header from HTTP/1.1 to HTTP/1.0.  I am 
still seeing the problem.  

Just to be clear, the telnet client changed, the httpd did not, so I'd be 
surprised if the HTTP header had anything to do with the problem.  I use the 
1.1 protocol because of name based hosting.  The problem might not actually be 
because of a change in the telnet code.  It might have been a change in an 
underlying library that has caused the telnet problem to become more prevalent.

Does anyone have any idea what these hex codes mean anyway?  

Comment 6 Harald Hoyer 2005-03-02 17:27:06 UTC
I cannot reproduce the problem...
[02/Mar/2005:17:50:55 +0100] "GET / HTTP/1.1" 200 31997 "-" "sh"
[02/Mar/2005:17:51:55 +0100] "GET / HTTP/1.0" 200 32029 "-" "sh"
[02/Mar/2005:17:51:59 +0100] "GET / HTTP/1.0" 200 32029 "-" "sh"
[02/Mar/2005:18:17:33 +0100] "GET / HTTP/1.0" 200 16227 "-" "sh"
[02/Mar/2005:18:17:54 +0100] "GET / HTTP/1.0" 200 31628 "-" "sh"
[02/Mar/2005:18:17:58 +0100] "GET / HTTP/1.0" 200 31628 "-" "sh"
[02/Mar/2005:18:19:41 +0100] "GET / HTTP/1.0" 200 31589 "-" "sh"

The hexcodes look like some "escape" chars... but telnet would not escape a "T".
If the protocol used for telnet was not tcp, I would say, you have network problems.

Try to insert a "tee output.txt" in the pipe before telnet. Just to be sure you
are not generating the hexcodes with the commands before.

Does it work again, if you install the old telnet rpm?

Comment 7 Harald Hoyer 2005-03-02 17:34:10 UTC
Also, I may suggest to use "nc" for that :)
Not that I don't want to know what is going on here, but "nc" is what you want
in this case, not a telnet client, which might want to negotiate the connection
using the telnet protocol :)

Comment 8 Harald Hoyer 2005-03-02 17:35:03 UTC
with nc, you don't need the "sleep 3" e.g.

Comment 9 Patrick Melo 2005-03-02 17:59:17 UTC
I copied the /usr/bin/telnet from the httpd machine [Red Hat Linux release 9 
(Shrike)] to /tmp/telnet on the telnet machine [Fedora Core release 3 
(Heidelberg)].  When I use /tmp/telnet I do not see the problem.  If I switch 
back to /usr/bin/telnet the hex codes show up again.

The script is used on various operating systems: ibm_aix, hp_ux, sco_unix, 
dec_unix, rh_linux under various versions of the operating system.  Fedora is 
the only one that seems to have this problem.  I suppose I could do and 
if/then to use nc on Fedora as a kludge.  Kind of a shame really.

I'm not sure why you're not seeing the hex codes on your system.  I see it 
coming from at least two machines in-house running the telnet script.  I've 
already mentioned one, the other is running RHEL [Red Hat Enterprise Linux ES 
release 4 (Nahant)] Admittedly my httpd system is pretty low budget, it's one 
of those fry's bare bones systems from a few years back (1 GHz processor, 
133MHz bus, 512M memory).

while [ 1 ] ; do

Comment 10 Harald Hoyer 2007-03-08 13:21:50 UTC
oh, btw, be sure to use /usr/bin/telnet and not /usr/kerberos/bin/telnet

$ which telnet

Comment 11 Adam Tkac 2010-02-22 17:01:29 UTC
There were no response from reporter since 2005. Red Hat Enterprise Linux 4.9 update will contain only security and performance related fixes thus I'm closing this ticket.

Note You need to log in before you can comment on or make changes to this bug.