Equinox question

Chip Rosenthal chip at chinacat.Unicom.COM
Sat Feb 16 11:17:03 AEST 1991


In article <1991Feb15.165755.3231 at pcserver2.naitc.com>
	kdenning at pcserver2.naitc.com (Karl Denninger) writes:
>However, if you turn on XON/XOFF in a Telebit modem and use spoofing
>(S111-30), it is smart enough to disable it when a uucp call comes in or
>out.

True...but in the general case I don't believe it's a good thing to do.
This is a function of the spoofing code (thus I assume we have Honeyman's
foresight to thank for the modem `doing the right thing').  However, if
you've got uucp connections with non-telebit modems, the XON/XOFF handshaking
will not be inhibited, and you will almost certainly encounter problems.

I'd be hard pressed to recommend an option because `it's just going to
get disabled anyway'.  Realistically, I think your choices are either:
(1) run RTS/CTS handshaking, or (2) use no handshaking and run the serial
line speed at the modem speed.  Since the uucico g protocol only allows
a number of outstanding packets, it tends not to overrun buffers on either
side of the communication channel and option #2 tends to work just fine.
A third option is to lock the serial speed and run without any flow
control, but you'd better pray you've got big and fast buffers in the
serial cards on both ends.

For those unfamiliar with the problem, if you've got XON/XOFF flow control
enabled in the modem, transmission of a binary file with a '\023' byte
will look like an XOFF character to the modem, and thus it will halt all
transmission back to the system.  This problem manifests itself by uucico
going into an `alarm 1...alarm 2......alarm N...giving up' mode.  In the
typical case, this will occur when sending a compressed news batch.
-- 
Chip Rosenthal  512-482-8260  |
Unicom Systems Development    |    I saw Elvis in my wtmp file.
<chip at chinacat.Unicom.COM>    |



More information about the Comp.unix.sysv386 mailing list