Help Please with Telebit and SCO RTS/CTS Setup?! (LONG)

Tue Apr 2 07:12:26 AEST 1991

Hello Netlanders,

I am having a problem that I am not sure how to handle.  Maybe some of you
can help.  

I am trying to get FULL DUPLEX hardware (RTS/CTS) flow control working on 
SCO ODT 1.0 (unix version 3.2.1).  I am not having much luck.  The modem is
a Telebit Trailblazer Plus modem.  I am locking the baud rate from the serial
port to the modem at 19200 baud.  I have S66=001 so that the modem serial
port baud rate stays locked at that no matter what.  I therefore need the
hardware flow control for it to work reliably.  

I setup my /etc/gettydefs for RTSFLOW CTSFLOW as best as I could determine
from the OS docs.  My 19200 baud entry is as follows:

19200 # EXTA IGNPAR ICANON IXON IXANY OPOST HUPCL ECHO ECHOE ECHOK CS8 CREAD # EXTA IGNPAR ICANON IXON IXANY RTSFLOW CTSFLOW OPOST CS8 HUPCL ECHO ECHOE ECHOK CREAD #Telebit (tty2A)\r\nmjbtn!login: # 19200

Before I began working on this, I had only set CTSFLOW (not RTSFLOW too).  That
seems to work most of the time, but I wanted to do it more like the book and
have the OS (DTE) signal RTS to the modem (DCE).  My troubles begin when I 
include RTSFLOW.

I use the dialTBIT.c file for my dialer.  The MSETUP strings are:

#define	MDSETUP1 "AT&FE0F1M0Q4V1X3S0=2S2=043S45=0S48=1S50=0S51=254S52=2\r"
#define MDSETUP2 "ATS53=1S54=3S55=0S58=2S60=0S66=1S68=255S92=1S110=255S111=255&W\r"

The Telebit settings resulting are:

E0 F1 M1 Q4 P V1 X1     Version BA4.00
S00=002 S01=000 S02=043 S03=013 S04=010 S05=008 S06=002 S07=040 S08=002 S09=006
S10=007 S11=070 S12=050 
S45=000 S47=004 S48=000 S49=000
S50=000 S51=254 S52=002 S53=002 S54=003 S55=000 S56=017 S57=019 S58=002 S59=000
S60=000 S61=045 S62=003 S63=001 S64=000 S65=000 S66=001 S67=000 S68=255 
S90=000 S91=000 S92=000 S95=000 
S100=000 S101=000 S102=000 S104=000 
S110=255 S111=030 S112=001 
S121=000 

What is happening is that when the RTSFLOW kicks in (in the "final" phase
of getty init - when calling login), the port freezes completely.  When it
first answers the phone, the prompt comes up just fine.  Doing 
'stty -a </dev/tty2A' results in:

speed 19200 baud;   ispeed 14 baud;   ospeed 14 baud; 
line = 0; intr = DEL; quit = ^\; erase = ^H; kill = ^U; eof = ^A; eol = ^@; 
swtch = ^@;susp = ^@;
-parenb -parodd cs8 -cstopb hupcl cread -clocal -loblk -ctsflow -rtsflow 
-ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -iuclc 
-ixon -ixany -ixoff 
-isig -icanon min = 1 time = 0 -xcase echo -echoe -echok -echonl -noflsh -iexten -tostop 
opost -olcuc -onlcr -ocrnl -onocr -onlret -ofill -ofdel 

This is when it is sitting at 'login:'.  Note that CTSFLOW and RTSFLOW are
still off.  Now, when I type a userid, and hit enter, the 'Password:' prompt
comes up, and it is frozen from there on.  You can hit ENTER, etc., and
*NO* data seems to be showing up on the modem.  The stty settings in this
state are:

speed 19200 baud;   ispeed 14 baud;   ospeed 14 baud; 
line = 0; intr = DEL; quit = ^\; erase = #; kill = @; eof = ^D; eol = ^@; 
swtch = ^@;susp = ^@;
-parenb -parodd cs8 -cstopb hupcl cread -clocal loblk ctsflow rtsflow 
-ignbrk -brkint ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl -iuclc 
ixon ixany -ixoff 
-isig icanon -xcase -echo -echoe -echok -echonl -noflsh -iexten -tostop 
opost -olcuc onlcr -ocrnl -onocr -onlret -ofill -ofdel 

Notice that 'loblk' came on even though it was not specifically specified.
It seems to be tied with RTSFLOW.  

Now, I was curious as to what was happening with the RTS signal from the
computer, so I got one of those dinky Radio Shack RS-232 Mini Testers (you
know that has the red and green lights for TD, RD, RTS, CTS, DSR, DTR, and
CD).  What is happening is very interesting.  I don't know for sure, but it
seems that when a light is OFF, there is no voltage, when it is GREEN, it
is +5v and when it is RED it is -5v (mere interpolations).  When the line
is in the -rtsflow state, the RTS light is GREEN (I assume high).  Now, when
the RTSFLOW flag kicks in the "final" state, the RTS light always drops 
RED (low?) and that is when the port freezes.  If RTS is not going high 
(GREEN), then that would explain why the modem will not transmit data to the
computer.  Why would RTS be staying low????  What other settings might be
at work here?  Help!?

Now, I spoke with a tech support rep at Telebit, and he said that there was
a limitation with SCO Unix that when you run a port at speeds greater than
9600, RTS/CTS does not work in full duplex mode.  He said 9600 or below it
works fine.  Well, I tried this at 9600, and the exact same behavior occurred.
I tried this on different serial ports; same thing.  I am using a straight
25-pin cable with serial port as DTE and modem as DCE.  The fact that it also
fails on 9600 baud makes me suspect that something else is fouled up here.

I think I have covered the problem completely enough to give an appropriate
picture.  If not, please ask for more details!  :-)  This is driving me 
crazy!  :-)  The Telebit guy said, most of the time, the CTS handshake the
modem does to have the computer wait is probably enough to work fine 99%
time.  But, I would like to get it working completely FULL duplex for 100%
of the time.

Any help and/or suggestions would be greatly appreciated.  I am sure I am 
not the only one to run into this.  I do know about FAS 2.08, but I am really
not sure how to implement it into the SCO scheme of 'uugetty' and the post
dial/connect reset (dial -h .....).  Ideas on that welcome too.

Thanks in advance,

Mark.

-- 
Mark J. Bailey, N4XHX                              _______/====X11====\_______
USMAIL: 511 Memorial Blvd., Murfreesboro, TN 37129 |         JobSoft         |
VOICE:  +1 615 893 0098                            | Design & Development Co.|
UUCP:   ...!uunet!mjbtn!mjb, ...!raider!mjbtn!mjb  |  Murfreesboro, TN  USA  |
DOMAIN: mjb at mjbtn.JOBSOFT.COM      CIS: 76314,160  ---------------------------
<KA9Q-UNIX-USERS Mailing List-Subscribe: ka9q-unix-requests at mjbtn.jobsoft.com>