Bug 2569

Summary:	Telnet client doesn't strip NUL when server sends CR/NUL as end-of-line
Product:	Busybox	Reporter:	Nick Leverton <nick>
Component:	Networking	Assignee:	unassigned
Status:	RESOLVED FIXED
Severity:	normal	CC:	busybox-cvs
Priority:	P5
Version:	1.16.x
Target Milestone:	---
Hardware:	Other
OS:	Linux
Host:		Target:
Build:
Attachments:	Fix telnet.c to convert CR/NUL end-of-lines into bare CR.

Description Nick Leverton 2010-09-17 09:29:03 UTC

Created attachment 2473 [details]
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 !

Comment 1 Denys Vlasenko 2010-10-29 00:13:30 UTC

Thanks for your work.

Your patch mishandles CR IAC and CR CR NUL sequences, though.

I reworked it and applied the fix to git.