From: belal@sco.COM (Bela Lubkin)
Newsgroups: biz.sco.general
Subject: the RTS/CTS story, Re: UUCP woes on 3.2.0 to 3.2.4 upgrade
Date: 4 Jan 93 10:16:34 GMT
Organization: [resent by] The SCOGEN gateway and Propagation Society
Resent-From: mmdf@xenitec.on.ca
Submit-To: scogen@xenitec.on.ca
Precedence: bulk

Greg Andrews wrote:

> The problem happens because changes were made in the tty driver between
> v2.0 and v4.0, but the dialTBIT source wasn't adjusted to match.
> 
> This is the problem in a nutshell:
> 
> A change was made in the stock tty driver concerning the RTSFLOW
> line discipline, and the dialTBIT source code was not changed to
> match.

Close.  Actually, you're right that the line discipline changed, but
that only indirectly caused the problem.

Prior to 3.2v4.0, SCO's serial driver (sio) only did one kind of
hardware handshake, "unidirectional", in which the external device can
tell the computer to shut up, but not vice-versa.  This is useless for
modem communications, and in fact it severely confuses some modems such
as Telebits.

Starting with 3.2v4.0, "bidirectional" flow control is also supported.
Note that the old "unidirectional" is also still supported.  In the
process of getting things ready for multiple hardware flow control
protocols, it was noticed that cu and uucico always turned off the
hardware flow control bits in the termio structure.  There wouldn't be
much point to having the right kind of hardware flow control if the
programs that will most benefit from it unilaterally disable it; so cu &
uucico were modified not to do that.  But it was not noticed that all
the dialers, for untold ages, had been turning *on* RTSFLOW+CTSFLOW,
i.e. the useless "unidirectional" flow control.  The dialers were always
wrong, but cu & uucico had been fixing the problem.  We "fixed" cu &
uucico not to do that, thus exposing the problem in the dialers.

The dialers in MSv4.1 fix this by 1) not automatically turning on
unidirectional flow control; 2) providing user control over the termio
settings after connection has been established.

> Solution that's worked for me:
> 
> Change dialTBIT.c to set CRTSFL instead of RTSFLOW and CTSFLOW, and
> recompile.  The change is made to mdopen() at or near line 1520.
> 
> Old line:
> 
> 	term.c_flag |= (CLOCAL | CTSFLOW | RTSFLOW)
> 
> New line:
> 
> 	term.c_flag |= (CLOCAL | CRTSFL)
> 
> If you're paranoid enough, you could even include a line that clears
> RTSFLOW and CTSFLOW, but it's probably not necessary.

A mystery remains.  The sio driver explicitly declines to do hardware
flow control on a local connection, defined by the setting of the CLOCAL
bit.  That doesn't jive with the setting of CLOCAL here.

... so I check the source.  cu & uucico call a routine "fixline" (you
can see it in the -x9 output) which, among other things, turns CLOCAL
off if the system you're connecting to is not "Direct"; and turns it
*on* if it is.  So the next surprise waiting is that flow control
*still* won't work between direct systems.  hmmm.

> If you want a more detailed explanation of why RTSFLOW doesn't work anymore,
> let me know.  I just didn't want to bore everyone with technicalities if
> they aren't wanted...  (Hint: Attach a breakout box and watch the RTS
> signal from the computer, then look up the meaning of S58=2 in your T1000
> manual).
> 
>   -Greg
> (Telebit Engineer)

Well, I hope people aren't bored, but that's OK.  They can read or not.
They can't read what you don't write...

>Bela<
Newsgroups: biz.sco.general