From: paul@aztec.ucsc.edu (Paul Tatarsky)
Newsgroups: comp.unix.ultrix
Subject: SUMMARY: What is the rlogin to Sun hang bugfix??
Date: 16 Oct 1992 00:18:08 GMT
Organization: UC Santa Cruz CIS/CE
Distribution: world
Reply-To: paul@terra.ucsc.edu
NNTP-Posting-Host: aztec.ucsc.edu

Well, I've been waiting for DEC support to call me back for two
days now, and I guess I'm not going to get an official answer from
them as I write this. I thought I should post this anyway, however.

Yes, there is a bug, it affects rlogin from a DEC to a Sun. 
It seems to affect mostly rlogins to quicker SPARC systems (1+, 2). 
(I was able to get rlogin to hang 1 out of 2 times connecting to an
 unloaded SPARCstation 2, the only way out was to kill it from another
 window)

This question went around in September. Sorry for dredging it up again.
I am told from reading the previous posts on the matter that the problem
involves the tcp_input.o section of the kernel. I have appended the posts
which were sent to me, rather than rehashing them. Those folks know
a hell of a lot more about the problem.

The solutions I tried were obtaining the patch tcp_input.o mentioned
in the following posts and rebuilding the kernel. This appeared to
work, but involved rebuilding all our DECstation kernels which might
not be a very attractive option to people with many systems. It is
however the only "real" soultion I came across. 

The other solution involves calling DEC to get some kind of kludged
rlogin which deals with the problem. I believe that running the 4.1
rlogin is a similar (if not identical) solution. I have also tried
that solution and have since not been able to get rlogin to hang.
(I am running the 4.1 rlogin, DEC has not called me back)

I guess I should rant and rave about Ultrix and quality control and
such things, but I'm getting too used to replacing half of Ultrix
anyway. Just once I would like to see a followup from a real live DEC
Ultrix engineer like the SGI folks do.

In the credit where credit is due department:

 robm@eecs.berkeley.edu (Rob McNicholas): 
   for mailing me the September posts and knowing his DEC particularly 
   well indeed.

 Previous Posters and Solvers: 
  jsw@umiacs.umd.edu (Jeff Webber)
  cole@dip.cs.wisc.edu (Bruce Cole)
  dean@cs.wisc.edu (Dean Luick)

Adios. Hopes this helps somebody. Should go on a FAQ. Would be nice
if it vanished under 4.3. Anyone seen it? 

 Paul Tatarsky         email: paul@cse.ucsc.edu
 UC Santa Cruz
 CIS/CE Board          
 Just some poor sod who manages DECstations


---------------posts on the same subject (abridged)--------------

From: jsw@umiacs.umd.edu (Jeff Webber)
Newsgroups: comp.unix.ultrix
Subject: Re: Ultrix 4.2 rlogin somewhat broken
Date: 14 Sep 92 01:54:38 GMT
Organization: UMIACS, University of Maryland, College Park, MD 20742

I have been investigating this problem.  Its related to the bug
that causes rlogin to hang when going from an Ultrix machine
to a fast sparc.  Its due to a kernel bug in the OOB handling
stuff in the socket code (soreceive()).

The problem of rlogin hanging is caused by Ultrix sending
rlogin a SIGURG and then not delivering the OOB packet.  The
rlogin program just eats everything coming across the connection
waiting for a MSG_OOB packet that never arrives.

The problem is intermittant (race condition or some such) and
is less severe under 4.2a then 4.2.  It however still occurs
even under 4.2a.

-- 
Jeff Webber /   U of Maryland Institute for Advanced Computer Studies
path: uunet!mimsy!jsw  phone (301)-405-6746 jsw@umiacs.umd.edu  DoD #243
1965 Ford Mustang Convertible                     1988 Honda Hawk GT 650

----------

From: cole@dip.cs.wisc.edu (Bruce Cole)
Newsgroups: comp.unix.ultrix
Subject: Re: Ultrix 4.2 rlogin somewhat broken
Date: 15 Sep 92 02:16:33 GMT
Organization: U of Wisconsin Madison - Computer Sciences

Back in Ultrix 4.0, DEC added support for X/Open's XTI.  This required 
supporting multiple bytes of outstanding out of band data.  In implementing
this, DEC broke out of band data, as used the the rlogin "protocol".  I
say broke because one could make their Decstation panic by pumping lots of
out of band data into a TCP connection, and because DEC's out of band data
implementation would often cause the rlogin program to hang, depending upon
how quickly the other end of the connection sent out of band data.

I QAR'ed this problem, with a Kernel fix to DEC in Sept. '90.  A DEC engineer
reworked my changes so that the Ultrix kernel could hopefully handle both
XTI and rlogin's requirements for oob data.  Unfortunately, his change made
the problem less severe but did not correct it entirely.

In Ultrix 4.2, the kernel implementation of out of band data remained 
partially broken.  DEC's new fix to the out of band data problem was to add a 
sleep(1) statement to rlogind right before it sends out of band data!!!  This 
fix seems to have avoided the rlogin hanging problem between DEC workstations.
Of course, it did not fix the use of rlogin with other vendor's machines.

Dean Luick locally reworked my out of band data kernel fix for Ultrix 4.2.
He even posted his fix to this newsgroup, in Nov. '91.  The fix has been
available in binary form for anonymous ftp since that time.  See the
files pub/README.tcp_input, pub/tcp_input.o-4.2 on dip.cs.wisc.edu.

Shame on DEC for never having properly fixed this bug after all this time.
Good thing we have kernel source.
-- 
Bruce Cole
Computer Sciences Department
U. of Wisconsin - Madison

-------the README.tcp_input file from that FTP site----------

The tcp_input.o-4.2 in this directory is compiled from the Ultrix 4.2 source
with the following modifications:

+ The initial tcp retransmit time is more conservative than the Ultrix
  default.  It depends more on the round trip time than on the variance.
  This helps out people connected via serial line IP (slip).
+ A panic message was corrected.
+ Incoming out of band data is appended to any oob data waiting to be
  read instead of overwriting it.  The waiting data _will_ be overwritten
  if we can't append the new data to the first mbuf.

------- Article posted to comp.unix.ultrix on 15 November 1991.

Why rlogin sometimes hangs on Ultrix 4.0 and 4.2 (and presumably 4.1):

When you rlogin to machine other than an Ultrix machine (tested on sun3,
sun4, sequent, BSD4.3 on a VAX) the rlogind on the remote machine ends up
sending 2 or 3 packets that contain out of band (oob) data.  The Ultrix
kernel overwrites any unread oob data with the new oob data.  This, to my
knowlege, does not break the TCP protocol, mostly because the protocol is
too vague on the subject of oob data.  If you are unlucky enough to have
unread oob data overwritten by new oob data [rlogin follows the convention
of a single byte of oob data per packet], then your rlogin process will
hang in the oob signal handler, oob() in rlogin.c.  It will be bypassing
all incoming data (login banners and such) waiting for some oob data to
show up.  Eventually the remote machine will be done sending login banners
and think the connection established.

It is unclear if the fault lies in the rlogin program, which expects
oob data for every oob interrupt and will hang if it doesn't get it,
the oob handling in the kernel, or something else (I ran into some
weird things while tracking this problem for 4.2).

A fix that seems to work is the following:  In 4.2, Change tcp_pulloobxti()
in sys/net/netinet/tcp_input.c so that it appends the oob data to the oob
mbuf (so->so_exrcv.sb_mb).  In 4.0, you need to do the above as well as
break the code into a xti vs non-xti case.  The xti protocol seems to assume
that the urgent data always starts at the beginning of the packet and ends
just before the urgent data pointer.

The fix for 4.0 was done by Bruce Cole here at the UW.  This fix was applied
locally and sent to DEC, but the problem still exits in 4.2.

The fixes work for us, although it should be noted that we use BSD derived
versions of Unix almost exclusively.  All bets are off if you have an xti
connection.  It isn't used around here and we don't know the protocol.

DEC "fixed" this problem by putting a sleep in their rlogind.  The result
is that only one oob data byte is ever sent, hence, none could be overwritten.

dean

Dean Luick
Systems Programmer
University of Wisconsin-Madison Computer Sciences Dept.
uucp:   ...!{allegra,harvard,seismo,topaz}!uwvax!dream!dean
arpa:   dean@cs.wisc.edu


------------
Newsgroups: comp.unix.ultrix