root@mjbtn.JOBSOFT.COM (Mark J. Bailey) (04/02/91)
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@mjbtn.JOBSOFT.COM CIS: 76314,160 --------------------------- <KA9Q-UNIX-USERS Mailing List-Subscribe: ka9q-unix-requests@mjbtn.jobsoft.com>