Re: wollongong telnet and new line processing


Kevin Carosso (@YMIR.BITNET:KVC@ENGVAX.SCG.HAC.COM)
Mon, 20 Jul 87 19:55 PDT


> Unix translate the \r into a \n and sends it across the net
> to the VMS machine which promptly deletes the word GUEST. This
> makes logging in a little difficult.

> I say this because if you are connect to the Unix machine
> via a direct line everything works fine. This problem only
> occurs when you are connected via a pty. We use Bridge
> cs/1 terminal servers almost exclusivly, hence you are always
> connected to a pty and never to a direct line.

> This leads me to think that the problem lies somewhere in the
> pty driver. Anyone have any ideas?
> Bill King

We had the same problem here, but a different manifestation (couldn't
run a local editor or TELNET to a VMS system running CMU IP/TCP).

The problem occurs when you connect via TELNET to a 4.3 system and then
run any program which reads in raw mode and expects to see EXACTLY the
key the user typed. I traced the problem to the fact that "telnetd.c"
has the following in it:

                        /*
                         * We map \r\n ==> \n, since \r\n says
                         * that we want to be in column 1 of the next
                         * printable line, and \n is the standard
                         * unix way of saying that (\r is only good
                         * if CRMOD is set, which it normally is).
                         */
                        if ((myopts[TELOPT_BINARY] == OPT_NO) && c == '\r') {
                                if ((ncc > 0) && ('\n' == *netip)) {
                                        netip++; ncc--;
                                        c = '\n';
                                } else {
                                        state = TS_CR;
                                }
                        }

I don't think it's right to map <CR><LF> to <LF>. I changed it to map to <CR>
instead, and everything works just fine. The terminal driver will map the <CR>
to <LF> when necessary and programs that think that are supposed to get a <CR>
now work fine.

My rationale was that the UNIX tty driver is set up to work with terminals
that usually send <CR> when the user hits "carriage return". A pty works
just like a tty, so we should be sending <CR> into it.

I suppose another approach might be to say that the Bridge TELNET code is
broken and that it shouldn't be sending <CR><LF> when you type
"carriage return" but should send <CR><NUL>. I can't fix the Bridge code,
though.

        /Kevin Carosso kvc@engvax.scg.hac.com
         Hughes Aircraft Co. kvc%engvax@oberon.usc.edu



This archive was generated by hypermail 2.0b3 on Thu Mar 09 2000 - 14:38:47 GMT