Xref: utzoo comp.unix.wizards:13170 comp.protocols.misc:408 Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!cs.utexas.edu!rutgers!noao!amethyst!rsm From: rsm@amethyst.ma.arizona.edu (Robert Maier) Newsgroups: comp.unix.wizards,comp.protocols.misc Subject: flaw in RLOGIN protocol? Message-ID: <858@amethyst.ma.arizona.edu> Date: 4 Dec 88 11:48:58 GMT Sender: news@amethyst.ma.arizona.edu Organization: Dept. of Math., Univ. of Arizona; Tucson, AZ 85721 Lines: 26 I recently dug into the BSD4.3 versions of rlogin.c and rlogind.c, and among other things figured out the (undocumented?) RLOGIN protocol. Once the TCP/IP connection between server and client has been initialized, it is only used to transfer data. The control path from server to client is out-of-band, and supports little more than an output flush request. There is one exception to this: the rlogin client may place in the data stream going to the server a notification that its screen size has changed. The client uses the escape sequence "\0377\0377ss", followed by the new screen size. So far as I can see, this escape sequence cannot be escaped. There is no way of passing "\0377\0377ss" from the client to the server without the following bytes being interpreted as a new screen size. Am I missing something here, or does this imply that the RLOGIN protocol doesn't support a true 8-bit data path? -- Robert S. Maier SNAIL: Dept. of Math.; Univ. of Arizona; Tucson, AZ 85721; USA VOICE: +1 602 621 6893 / +1 602 621 2617 UUCP: ..{allegra,cmcl2,hao!noao}!arizona!amethyst!rsm BITNET: maier@arizrvax INTERNET: rsm@amethyst.ma.arizona.edu