sean@utodaycom (Sean Fulton) (11/26/90)
I'm having trouble with outgoing calls on my TB T2500 connected to a 386 PC running SCO Unix 3.2.2. Specifically, the port is enabled using the ``n'' entry from /etc/gettydefs, and seems to answer calls at 19,200 bps quite well. I can't get it to keep from jamming up on outgoing UUCP calls, though. When I use cu to connect to the UUCP site, then do a ``~!stty'', I see my baud is set for 9600, no rts or cts, even though dialTBIT (which I use to dial) supposedly sets these modes when dialing out. The TB is set to speak to the DTE at any speed, default to 19200. Also set to use flow control (S66=1) and RTS/CTS (S58=2; S68=255). Adding RTSFLOW CTSFLOW to the ``n'' gettydefs entry doesn't seem to make a difference (I believe this is because gettydefs is only for when the modem answers a call, not outgoing). Any ideas would be appreciated. -- Sean Fulton sean@utoday.com UNIX Today! (516) 562-5430 /* The opinions expressed above are not those of my employer */
wht@n4hgf.Mt-Park.GA.US (Warren Tucker) (11/28/90)
In article <1838@utodaycom> sean@utoday.UUCP (Sean Fulton) writes: >... trouble with outgoing calls on my TB T2500 [with SCO 3.2.2 ... RTS/CTS] I think the problem is with the cu code. It just about has to be. RTSFLOW and CTSFLOW are SCO extensions. The problem arises when standard System V code (cu) manipulates the termio state; not knowing about the two extsion bits, it is probably jamming certain values into c_iflag rather than ANDing out unwanted bits and ORing in wanted bits. May I suggest you try ECU, an -er- optimized comm program for SCO, which does one or two things cu doesn't and, specifically, lets you diddle with rts/cts to your hearts content. I almost have rev 3 ready to release, but comp.sources.misc has 2.80, which with patches 1-4 applied, does fairly well. -------------------------------------------------------------------- Warren Tucker, TuckerWare emory!n4hgf!wht or wht@n4hgf.Mt-Park.GA.US ANSI C should have been named D, or Son of C
cec@cup.portal.com (Cerafin E Castillo) (11/28/90)
I would highly recommend the Digiboard Mux or the Anvil Designs
Stallion or Brumby Mux boards, as well as Maxpeed boards. I have
used these boards, while at TELEBIT, on my SCO XENIX 2.3.2 system
with RTS/CTS flow control and never had a problem at 19200 or
below. Give it a try. If you are using your cpu serial ports,
make sure that they have 16450/16550 fro best performance with
your TELEBIT modem. Good Luck!
===============================================================================
Cerafin E. Castillo || //\\ ||\\ ||
Network Consultant || //__\\ || \\ || Los Altos
Los Altos Networks || // ---\\|| \\|| Networks
340 Second St. #6 ||___// \ | \ |
Los Altos, CA 94022
(415) 941-8031 UUCP: {apple,sun,uunet}!portal!cup.portal.com!cec
INTERNET: cec@cup.portal.com
"...No hay mal que por bien no venga..."
===============================================================================pizzi@esacs.UUCP (Riccardo Pizzi) (11/29/90)
In article <1838@utodaycom> sean@utoday.UUCP (Sean Fulton) writes: >I'm having trouble with outgoing calls on my TB T2500 connected to a >386 PC running SCO Unix 3.2.2. >The TB is set to speak to the DTE at any speed, default to 19200. Also >set to use flow control (S66=1) and RTS/CTS (S58=2; S68=255). Adding >RTSFLOW CTSFLOW to the ``n'' gettydefs entry doesn't seem to make a >difference (I believe this is because gettydefs is only for when the >modem answers a call, not outgoing). Any ideas would be appreciated. The problem is, you need to lock the DTE/DCE speed at 19200. Then you set your /etc/gettydefs so that getty will not cycle entries, i.e. you use the 'n' keyword as next entry in the 'n' line. This should work fine. Remember to set to 19200 the Devices and Systems file too. Hope this helps, Rick -- Riccardo Pizzi @ ESA Software, Rimini, ITALY e-mail: pizzi%esacs@relay.EU.net -or- root@xtc.sublink.org Public Access Unix @ +39-541-27858 (Telebit) << Object Oriented is an Opaque Disease >>