0

On the telnet provided with my system (Debian), line feeds (\n) seem to be translated to CRLF (\r\n). Specifically, if I run, e.g., netcat -l -p 3334 > file and run echo a | telnet localhost 3334 in another terminal, then do hexdump file, I get:

0000000 0d61 000a                              
0000003

Which is a\r\n in little-endian, i.e., a followed by CRLF.

Yet, the manpage for telnet says, about the crlf toggle:

If this is TRUE, then carriage returns will be sent as <CR><LF>. If this is FALSE, then carriage returns will be send as <CR><NUL>. The initial value for this toggle is FALSE.

So I would expect to see carriage returns sent as CR followed by NUL. Why isn't this why I am observing?

(Note that I have no /etc/telnetrc or ~/.telnetrc. Also, by contrast, on my system, netcat (when used as a client) sends newlines as LF (\n), unless the -C option is used.)

2
  • Check the configuration of your terminal session. It should have a configuration variable for this. Both Putty and NetTerm have such variables. This is because different remote hosts have different requirements, so there is not any default.
    – John
    Apr 26 '20 at 14:13
  • @John thanks for the suggestion but why would this be specific to the telnet client, given that netcat doesn't give the same behavior?
    – a3nm
    Apr 26 '20 at 14:41
1

See what Telnet Protocol Specification says [emphasis mine]:

The sequence "CR LF", as defined, will cause the NVT to be positioned at the left margin of the next print line (as would, for example, the sequence "LF CR"). However, many systems and terminals do not treat CR and LF independently, and will have to go to some effort to simulate their effect. (For example, some terminals do not have a CR independent of the LF, but on such terminals it may be possible to simulate a CR by backspacing.) Therefore, the sequence "CR LF" must be treated as a single "new line" character and used whenever their combined action is intended; the sequence "CR NUL" must be used where a carriage return alone is actually desired; and the CR character must be avoided in other contexts. This rule gives assurance to systems which must decide whether to perform a "new line" function or a multiple-backspace that the TELNET stream contains a character following a CR that will allow a rational decision.

  • The crlf flag set indicates that CR qualifies under "CR LF combined action is intended".
  • The crlf flag unset indicates that CR means "a carriage return alone is actually desired".

But in your case the input (the output from echo a) did not contain CR at all. It contained LF which was translated to "CR LF" according to "CR LF combined action is intended". The flag did not apply because there was no CR in the input stream.

Provide input that actually contains CR:

printf '\r' | telnet localhost 3334

and the receiver will get either "CR LF" or "CR NUL", depending on your settings (in /etc/telnetrc or ~/.telnetrc).

1
  • Indeed, I got confused about the man page excerpt, which is indeed about how CR gets translated, and my input contains LF and no CR. So telnet is just transliterating LF to CRLF for some unrelated reason. Thanks!
    – a3nm
    Apr 26 '20 at 15:04

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.