Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!harbinger.cc.monash.edu.au!nntp.coast.net!howland.reston.ans.net!news5.ner.bbnplanet.net!news.ner.bbnplanet.net!news3.near.net!transfer.stratus.com!xylogics.com!xylogics.com!not-for-mail From: carlson@xylogics.com (James Carlson) Newsgroups: comp.protocols.kerberos,comp.bugs.4bsd Subject: Re: krlogin/krlogind usage of OOB data is broken Date: 16 Feb 1996 07:29:06 -0500 Organization: Xylogics Incorporated Lines: 50 Message-ID: <4g1tai$2vq@newhub.xylogics.com> References: <4fiobt$590@jik.datasrv.co.il> <ridenrwqo4c.fsf@ginger.lcs.mit.edu> Reply-To: carlson@xylogics.com NNTP-Posting-Host: newhub.xylogics.com Xref: euryale.cc.adfa.oz.au comp.protocols.kerberos:5471 comp.bugs.4bsd:2094 In article <ridenrwqo4c.fsf@ginger.lcs.mit.edu>, shep@ginger.lcs.mit.edu (Tim Shepard) writes: [...] |> The root of this bug is in the way the BSD socket semantics are |> implemented over TCP. TCP does not have an out-of-band data |> mechanism. It has only an unreliable urgent pointer. The way MSG_OOB |> is currently implemented over TCP (by using the urgent pointer) there |> is no guarantee that data sent with MSG_OOB will not wind up in-band |> at the other end. The problems with krlogin apparently demonstrate |> that this does indeed happen. TCP's urgent pointer is not "unreliable," and it's not at all an OOB mechanism (although the Berkeley interface calls it that). When you send something as "urgent" in TCP, you're saying that *all* octets outstanding up to that point are to be considered "urgent." There is no way to indicate that only some bytes are "urgent" and others are not, although this is what one might expect given the "OOB" name. |> I believe you are right on target with your analysis. Yes, a protocol |> change is apparently needed in krlogin to make it robust in light of |> this problem. |> |> I've never seen any similar problem with the regular BSD rlogin |> program. I have not investigated why it would not have the problem, |> but I would guess that it is prepared to correctly handle OOB data |> that has wound up in-band (which is IMHO the right way to cope with |> this problem). Uh, no, not really. Regular BSD rlogin just uses TCP urgent pointers correctly (that is, the way they were intended to be used). In regular BSD rlogin, the urgent signal indicates that all octets outstanding up to the current urgent pointer should be discarded. It implements an "output flush" mechanism. The next octet is a command code which tells the receiver whether or not to enter special modes (id est, to turn in-band flow control on and off). If another urgent signal is sent before this command code is read, then it becomes urgent along with any other outstanding data and is also discarded. This is by intention. Anyone who is expecting anything to wind up actually transferred out-of-band is mistaken about the specification of TCP. If krlogin relies on this, then it's misdesigned, not TCP. To send out-of-band signals, open an out-of-band connection. FTP protocol, for instance, does this by opening one connection for commands (the "control" connection) and another for data. -- James Carlson <carlson@xylogics.com> Tel: +1 617 272 8140 Annex Interface Development / Xylogics, Inc. +1 800 225 3317 53 Third Avenue / Burlington MA 01803-4491 Fax: +1 617 272 2618