terry@eecea.eece.ksu.edu (Terry Hull) (10/03/89)
I have been very happily using my TB+ for dial-in/dial-out on a dumb
4-port Digiboard for almost a year now. Last weekend when I upgraded
to 3.2, things broke. The manual says that you can use /etc/getty for
bidirectional modem lines just like you could with XENIX, but that
does not seem to be true. When getty is active on my tty2A device,
neither cu or uucico can use the line. The error message is "CANNOT
ACCESS DEVICE." I can understand this since both cu and uucico run
SUID uucp and the device is owned by bin and not writable by anyone else.
I also tried changing the permissions on the device, but getty changed
those too.
When I use uugetty on the modem line, I can dial out without difficulty.
The problem is when someone tries to dial in. As soon as CD goes high,
the computer drops DTR and the modem hangs up. I am using
/usr/lib/uucp/uugetty -r -t 60 tty2A m
for my inittab file entry. Also, I am using the dialTBIT dialer if that
matters. I have tried it with and without the -r option. I would
really appreciate any ideas you 3.2 gurus out there might have. Thanks
in advance for your time.
--
Terry Hull
Department of Electrical and Computer Engineering, Kansas State University
Work: terry@eecea.eece.ksu.edu, rutgers!ksuvax1!eecea!terry
Play: terry@tah386.manhattan.ks.us, rutgers!ksuvax1!eecea!tah386!terryterry@eecea.eece.ksu.edu (Terry Hull) (10/04/89)
In article <832@eecea.eece.ksu.edu> terry@eecea.eece.ksu.edu (Terry Hull) writes: > [Problem with bidirectional line in SCO UNIX deleted.] Well, I called SCO support today and found out their drivers break when you try to use them at 19200 baud. They told me if I backed off to 9600 things world work. I was also told there would be a SLS fix coming for the problem. No time frame was given though. I guess that means that all you TB+ people out there had better be ready to go to 9600 when you upgrade to UNIX 3.2. -- Terry Hull Department of Electrical and Computer Engineering, Kansas State University Work: terry@eecea.eece.ksu.edu, rutgers!ksuvax1!eecea!terry Play: terry@tah386.manhattan.ks.us, rutgers!ksuvax1!eecea!tah386!terry
larry@nstar.UUCP (Larry Snyder) (10/04/89)
> I guess that means that all you TB+ people out there had better be ready > to go to 9600 when you upgrade to UNIX 3.2. That is indeed bad news.. I plan on upgrading next spring after most of the "glitches" are worked out. -- Larry Snyder uucp:iuvax!ndcheg!ndmath!nstar!larry The Northern Star Usenet Distribution Site Notre Dame, IN USA
brad@looking.on.ca (Brad Templeton) (10/05/89)
In article <833@eecea.eece.ksu.edu> terry@eecea.eece.ksu.edu (Terry Hull) writes: >I guess that means that all you TB+ people out there had better be ready >to go to 9600 when you upgrade to UNIX 3.2. Nonsense. While I can't say that 3.2 has been without upgrade problems, I am running the TB+ at 19.2 call in/call out with no problems. I am using RTS/CTS flow control -- perhaps that's the trick. Set that register on your TB and make sure you use a cable with all the wires. -- Brad Templeton, ClariNet Communications Corp. -- Waterloo, Ontario 519/884-7473
terry@eecea.eece.ksu.edu (Terry Hull) (10/05/89)
In article <27516@looking.on.ca> brad@looking.on.ca (Brad Templeton) writes: >In article <833@eecea.eece.ksu.edu> terry@eecea.eece.ksu.edu (Terry Hull) writes: >>I guess that means that all you TB+ people out there had better be ready >>to go to 9600 when you upgrade to UNIX 3.2. > >Nonsense. While I can't say that 3.2 has been without upgrade problems, >I am running the TB+ at 19.2 call in/call out with no problems. > >I am using RTS/CTS flow control -- perhaps that's the trick. Set that >register on your TB and make sure you use a cable with all the wires. That is interesting because I just spoke with Chris in SCO support and he claims that 19200 baud is broken no matter what you do and RTSFLOW CTSFLOW do not work correctly. Here is what happens on my machine: 1) Modem answers the phone. 2) Modem raises DCD. 3) uugetty is now able to open the port and apply the stty settings to the port. If RTSFLOW and CTSFLOW are specified in the gettydefs file, the computer promptly drops RTS, and the modem cannot send any data to the computer since the modem is waiting for an active RTS. 4) If I do not specify RTSFLOW/CTSFLOW in the gettydefs file, the computer will hold RTS high. I am really glad that it is working for you, but SCO claims that it is broken, and it is broken on my machine. I am using SCO's drivers for a DigiBoard Com/4 dumb serial card. SCO support claims there will be a support level supplement for the 19200 problem, but the RTS/CTS problem will not be fixed until 3.2.2 or so. BTW: What serial board are you using and what does your gettydefs entry look like? -- Terry Hull Department of Electrical and Computer Engineering, Kansas State University Work: terry@eecea.eece.ksu.edu, rutgers!ksuvax1!eecea!terry Play: terry@tah386.manhattan.ks.us, rutgers!ksuvax1!eecea!tah386!terry
rpeglar@csinc.UUCP (Rob Peglar x615) (10/05/89)
In article <111042@nstar.UUCP>, larry@nstar.UUCP (Larry Snyder) writes: > > I guess that means that all you TB+ people out there had better be ready > > to go to 9600 when you upgrade to UNIX 3.2. > > That is indeed bad news.. I plan on upgrading next spring after most > of the "glitches" are worked out. > How about Telebit T2500's? Same bad news? I can't believe it. We run a T2500 at 19.2, very successfully, to uunet. 19.2 performance and Telebit's great reliability at that speed was the crucial procurement factor for us. BTW, on Xenix 2.3.2GT. We have a developer's agreement with SCO for Unix 3.2 and ODT, and this is the first piece of *really* bad news so far. Sigh. Rob ...uunet!csinc!rpeglar
brad@looking.on.ca (Brad Templeton) (10/06/89)
Well, I don't have rtsflow or ctsflow set in the gettydefs line. (I do have a problem with getty where it insists that dialing in logins come in with 0 parity, which is a pain -- the istrip isn't working) Here's the gettydefs line p # EXTA HUPCL ISTRIP # EXTA CS8 SANE HUPCL TAB3 ECHOE IXANY #(Telebit 19200) login: # 3 The trick might be in my telebit registers, which are a bit different from SCO's setup. But they work with dialTBIT and uugetty. E0 F1 M1 Q0 T V1 X3 Version BA4.00 S00=001 S01=000 S02=043 S03=013 S04=010 S05=008 S06=004 S07=040 S08=002 S09=006 S10=007 S11=070 S12=050 S45=000 S47=004 S48=000 S49=000 S50=000 S51=005 S52=002 S53=001 S54=001 S55=003 S56=017 S57=019 S58=002 S59=000 S60=000 S61=045 S62=003 S63=001 S64=000 S65=000 S66=000 S67=000 S68=255 S90=000 S91=000 S92=000 S95=000 S100=000 S101=000 S102=000 S104=000 S110=255 S111=255 S112=001 S121=000 N0: N1:7414080\DATAPAC N2:(censored) N3:(censored) N4:5793225\TYMNET N5:14162658035\CIS Every once in a while I will get strange behaviour on dial-OUT when the relay will click on and off quickly 4 times in a row, but that's rare and everything seems to be working otherwise. Just fine at 19.2k Right now I have the modem connected to a standard COM1. But it also worked connected to my smart card Intellicon port, which I plan to switch it over to shortly. -- Brad Templeton, ClariNet Communications Corp. -- Waterloo, Ontario 519/884-7473