[Bug 2569] New: Telnet client doesn't strip NUL when server sends CR/NUL as end-of-line

bugzilla at busybox.net bugzilla at busybox.net
Fri Sep 17 09:29:05 UTC 2010


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

           Summary: Telnet client doesn't strip NUL when server sends
                    CR/NUL as end-of-line
           Product: Busybox
           Version: 1.16.x
          Platform: Other
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P5
         Component: Networking
        AssignedTo: unassigned at busybox.net
        ReportedBy: nick at leverton.org
                CC: busybox-cvs at busybox.net
   Estimated Hours: 0.0


Created attachment 2473
  --> https://bugs.busybox.net/attachment.cgi?id=2473
Fix telnet.c to convert CR/NUL end-of-lines into bare CR.

When operating with a telnet server that appends NUL to transmitted CRs,
busybox telnet client doesn't remove the NUL again.

Netkit telnetd (Linux) does this to a bare CR but not to CR/LF, which means
that it rarely shows up when talking to a shell based system with cooked I/O. 
However telnetting to another embedded device I have here - operating system
unknown - echoes a CR/NUL in response every time I send a \r.

This is a problem for me as I am using busybox telnet to script a session with
the device, and the NULs mean that 'empty' (http://empty.sourceforge.net)
wrongly assumes end of string.

It seems from RFC1123 section 3.3.1, on telnet interoperability practices, 
that CR/NUL is an end of line indication and the NUL should not be passed onto
applications.  Certainly netkit-telnet client removes the NUL from a CR/NUL.

The attached patch fixes busybox telnet.c to work like netkit-telnet, which
removes the NUL but passes the alternative End-of-line representation of CR/LF
through unchanged.

Patch should apply to 1.17 as well with a slight offset.  Hopefully I have
filed this against the correct product this time !

-- 
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.


More information about the busybox-cvs mailing list