[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