Date: Fri, 16 Feb 1996 13:16:19 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: fn@pain.csrv.uidaho.edu (Faried Nawaz) Cc: hackers@FreeBSD.ORG Subject: Re: fyi. Message-ID: <199602162016.NAA05309@phaeton.artisoft.com> In-Reply-To: <199602161448.GAA10052@pain.csrv.uidaho.edu> from "Faried Nawaz" at Feb 16, 96 06:48:26 am
next in thread | previous in thread | raw e-mail | index | archive | help
> (Comp.bugs.4bsd folks: This posting relates to a problem in how the Kerberos > rlogin and rlogind programs use out-of-band data. However, I believe that > the problem I'm describing here is shared by the stock BSD rlogin and rlogind > programs, which is why I'm cross-posting to comp.bugs.4bsd.) > > I understand that Sam Hartman has done a considerable amount of work on rlogin > and rlogind, trying to get their handling of out-of-band data to work > properly. I've done similar work independently of Sam, and I suspect that my > changes are quite different from the ones he's implemented; nevertheless, I've > come to the conclusion that the way the protocl uses OOB data is broken in at > least on way that simply cannot be fixed without changing the protocol. > > The basic problem I'm encountering is this: What happens if krlogind sends an > OOB message to krlogin, and then it sends a *second* OOB message before > krlogin has processed the first one? This *can* and *does* happen. For > example, when I krlogin from my Linux box at home to an AIX box at work over a > SLIP link, the AIX box sends three different OOB messages as part of the > initial initialization of the connection, and network congestion can easily > cause all of them to get to my Linux box in consecutive packets, too quickly > for it to deal with each of them before the next one arrives. The OOB protocol bug is specific to the BSD version. New (4.3 and better) versions correctly handle OOB. The old telnet code used to use the option negotiaton order to determine if it were talking to a 4.3 or a 4.2 telnetd so that it would know how to correctly handle the OOB channel. The recent telnet implementations seem to now ignore the option negotiation order (in fact they change it in some cases), causing incorrect assumptions on the part of older clients and servers. I believe that this loss of information engendered by the order changes to be a loss of backward compatability. I don't know what you can do about it. > Unfortunately, the way OOB data is implemented in the Linux kernel (and I > believe in many other UNIX kernels as well) is that only one OOB message is > allowed at a time. If a second message is received while the first one is > still pending, the first one becomes part of the normal data stream, and the > OOB mark is moved to the second one. This does appear to be legal, according > to the BSD documentation about OOB data. SVR4 streams and other MP capable streams implement a "priority banding" policy, and typically use band 0 for regular data and band 1 for the traditional OOB data. The distinction between the "read" and "recv"/"recvmsg" are used to implement band checking of the non-default band queue. Note that this will not work for use of "read" on an fd that is a descriptor for a socket vnode instead of a descriptor for a file; technically, it's a mistake to use "read". The use of the MSG_OOB bit and the examination of the msg_control and msg_control with a NULL data pointer (incorrectly an iov structure in the BSD implementation instead of a flat caddr_t as well) is the OOB message interface for a single OOB channel. See the recvmsy man page for details. > As far as I can tell, the only way to make this work reliably is to require > hand-shaking -- when krlogind sends OOB data to krlogin, krlogin needs to send > OOB data back to krlogind to tell it when it has processed the data, and > krlogind needs to wait for that ACK before sending any more OOB data. This > is, I believe, how telnet/telnetd handle their OOB data. This is the backward compatability code for the 4.2 OOB implementation, as far as I know, and may not be directly applicable to the non-4.2 case. Hopefully this will help, though I don't see a clearly portable soloution to your problem. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199602162016.NAA05309>