Ok, looks like we are on the right track here.  Trouble is, I can't
figure out which end is at fault.  

My current setup is:

Wyse 75 <-- modems --> Campus Computing Xyplex <-- telnet --> NetBSD 1.3

A bit of tcpdump sleuthing seems to
show that:

The Wyse sends CR when you hit "Return," and the Xyplex interprets
this as me wanting to send just CR---it sends along CR-NULL via
telnet.  I can set my Wyse to send CR-LF, but if I do that, the Xyplex
sends CR-NULL-LF-NULL, which doesn't help (although if I use Line Feed
on the Wyse instead of return, the Xyplex sends LF-NULL, and that
"works"---i.e., it does what I would expect the return key to do).

Here are the stty settings:

speed 38400 baud; 0 rows; 0 columns;
lflags: icanon isig iexten echo echoe -echok echoke -echonl echoctl
	-echoprt -altwerase -noflsh -tostop -flusho pendin -nokerninfo
	-extproc
iflags: -istrip icrnl -inlcr -igncr ixon -ixoff ixany imaxbel -ignbrk
	brkint -inpck -ignpar -parmrk
oflags: opost onlcr -ocrnl oxtabs
cflags: cread cs8 -parenb -parodd hupcl -clocal -cstopb -crtscts -mdmbuf
	-cdtrcts
cchars: discard = ^O; dsusp = ^Y; eof = ^D; eol = <undef>;
	eol2 = <undef>; erase = ^?; intr = ^C; kill = ^U; lnext = ^V;
	min = 1; quit = ^\; reprint = ^R; start = ^Q; status = <undef>;
	stop = ^S; susp = ^Z; time = 0; werase = ^W;

When the NetBSD host receives CR-NULL on the wire, it responds with
0d 0a 5e 40---in other words, CR-LF-'^'-'@'.

Anyone know what's going on here?


     Mika


Alan Barrett writes:
>> I'm seeing the same thing, under certain circumstances. I have a PowerMac
>> running Stanford's kerberized telnet program. If I telnet directly to a
>> 486 running NetBSD, I get a kerberized connection, and I see the exact
>> thing you see above, a ^@ after every line. What's annoying is that I
>> think the telnetd is inserting it into the received data stream, and
>> passing to to the shell or running program. It makes using elm imposable
>> (to the extent it's possable at all :-)
>
>The TELNET protocol specifies that bare CR should never be sent over the
>wire; instead, you send <CR LF> if you want what Unix systems represent
>by "\n", or <CR NUL> if you want what Unix systems represent by "\r".
>
>See the bottom of page 10 in RFC854, and look for bugs in the client
>and server implementations of this part of the spec:
>
>"     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.
>
>--apb (Alan Barrett)
>