Date: Sun, 8 Dec 96 14:08 CST From: uhclem@nemesis.lonestar.org (Frank Durda IV) To: j@uriah.heep.sax.de, freebsd-bugs@freefall.freebsd.org Cc: uhclem@nemesis.lonestar.org Subject: Re: bin/1037 Message-ID: <m0vWpWe-000u3VC@nemesis.lonestar.org>
next in thread | raw e-mail | index | archive | help
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 <j@uriah.heep.sax.de> 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 = <undef>; eol2 = <undef>; stop = ^S start = ^Q; lnext = ^V; discard = ^O; reprint = ^R; status = <undef> 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 <uhclem@nemesis.lonestar.org>|"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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?m0vWpWe-000u3VC>