[Bug 6488] New: telnet client sometimes prints garbage due to missing byte from the telnet data stream

[bugzilla at busybox.net]

https://bugs.busybox.net/show_bug.cgi?id=6488

           Summary: telnet client sometimes prints garbage due to missing
                    byte from the telnet data stream
           Product: Busybox
           Version: unspecified
          Platform: All
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P5
         Component: Networking
        AssignedTo: unassigned at busybox.net
        ReportedBy: cjashfor at us.ibm.com
                CC: busybox-cvs at busybox.net
   Estimated Hours: 0.0


We recently ran into a problem where busybox, on an embedded system, was
displaying a Chinese character in the place of the "l" in "login".

After much tracing and debugging, we determined that what was happening is that
the telnet client appears to be behaving properly if we look at the data coming
in from the read() call, but that data is missing the Telnet protocol IAC (255)
byte that should tell the client that the following byte is a control code.

This doesn't happen every time, but about one in three times.  Here's a
copy/paste from my screen:

% sudo /usr/sbin/in.telnetd -h -debug 10016 &
% ./telnet localhost 10016

Entering character mode
Escape character is '^]'.

�cjashfor-w510 login: 

You can see the extra character in this example preceding the "cjashfor".

After we ran into this problem, we suspected a number of things, including the
telnet daemon, but the telnet daemon from the standard telnet package on Fedora
never encounters this error.

After doing some stracing, and tcpdump'ing, we discovered that in both cases,
using the standard telnet and the busybox telnet, tcpdump was showing the
escape code in the telnet datastream, but in the case of busybox telnet, the
read() call sometimes doesn't return that byte, and only sends the byte
following the escape code, a 242 (decimal) byte, which is a Telnet Data Mark
command (see RFC 854).  Because there is no escape code received, this byte is
treated as a printable character by the telnet daemon, and printed to the
screen.

In the case of the standard telnet, it doesn't used read(), and instead uses
recv(), and for whatever reason never misses this byte.

As a result, I am not certain that there is a bug in telnet or in the stack
somewhere between the read() call and the TCP/IP socket.  Or perhaps there's an
error in the busybox telnet daemon that it isn't properly conditioning the
socket to receive every byte. 

Note that our original problem was on an embedded system using a PowerPC
processor and 2.6.32-ish kernel, but I have replicated this problem in Fedora
18 using a 3.10 kernel on x86_64.  So the error is quite easy to reproduce.

-- 
Configure bugmail: https://bugs.busybox.net/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.