From owner-freebsd-bugs Sun Dec 8 12:11:21 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id MAA22239 for bugs-outgoing; Sun, 8 Dec 1996 12:11:21 -0800 (PST) Received: from nemesis.lonestar.org (fw16-26.ppp.iadfw.net [206.66.0.123]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id MAA22234 for ; Sun, 8 Dec 1996 12:11:16 -0800 (PST) Received: by nemesis.lonestar.org (Smail3.1.27.1 #22) id m0vWpWe-000u3VC; Sun, 8 Dec 96 14:08 CST Message-Id: Date: Sun, 8 Dec 96 14:08 CST To: j@uriah.heep.sax.de, freebsd-bugs@freefall.freebsd.org From: uhclem@nemesis.lonestar.org (Frank Durda IV) Sent: Sun Dec 8 1996, 14:08:36 CST Subject: Re: bin/1037 Cc: uhclem@nemesis.lonestar.org Sender: owner-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As Frank Durda IV wrote: [0]As above, replacing telnetd with the one shipped with 1.1.5.1 fixes [0]this problem. [1] wollman@lcs.mit.edu then said: [1]This is because the TELNET in 1.x had a broken LINEMODE. 2.x has a [1]working LINEMODE, but this is sometimes not what programs expect. [2]Frank Durda IV then said: [2]Hmm, this logic isn't obvious to me. It seems the goal is to have [2]the telnet session provide functionality identical of what you get [2]at the console or at any serial/dialup port. I don't understand [2]why "working" means to break what seems to be a basic compatibility [2]function of character I/O. [3]J Wunsch then said: [3]Read the RFC about telnet linemode (RFC 1184) and its background and [3]intentions, then you know why it behaves different than e.g. a serial [3]console line. [3] [3]As Garrett (or was it Bruce?) pointed out, you are free to not use [3]linemode, either by turning it off at the telnet prompt, or by running [3]``stty -extproc'' on the server side (which notifies telnetd to go [3]into character-at-a-time mode). What might be useful (why isn't it [3]already there?) is a command-line option on the telnet client to turn [3]off linemode negotiation. Then in my opinion, the default settings should be those that provide compatibility with existing applications and is compatible with the functionality seen on other UNIX platforms. As a point of reference, Digital OSF 3.x and 4.x systems work consistently when the test program is used, ie [ENTER], CTRL-M, and CTRL-J all return 0x0a regardless of whether the program is run from a telnet or a serial/console session. Here the Digital OSF stty -a output from a telnet session: #2 disc;speed 115200 baud; 25 rows; 80 columns erase = ^H; werase = ^W; kill = ^U; intr = ^C; quit = ^\; susp = ^Z dsusp = ^Y; eof = ^D; eol = ; eol2 = ; stop = ^S start = ^Q; lnext = ^V; discard = ^O; reprint = ^R; status = time = 0; min = 1 -parenb -parodd cs8 -cstopb hupcl cread -clocal -crtscts -ignbrk brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl -iuclc ixon -ixany ixoff imaxbel isig icanon -xcase echo echoe -echok -echonl -noflsh -mdmbuf -nohang -tostop echoctl -echoprt echoke -altwerase iexten -nokerninfo opost -olcuc onlcr -ocrnl -onocr -onlret -ofill -ofdel tabs -onoeot Looks like DEC (and probably others) didn't interpret RFC 1184 the same way or decided that they would rather not break existing applications. Anyone tried the test program BSDi, SUNos, Solaris, Linux, SCO? Frank Durda IV |"The Knights who say "LETNi" or uhclem%nemesis@rwsystr.nkn.net | demand... A SEGMENT REGISTER!!!" |"A what?" or ...letni!rwsys!nemesis!uhclem |"LETNi! LETNi! LETNi!" - 1983