From: gdonl@sunrise.ssi1.com (Don Lewis)
Newsgroups: biz.comp.telebit,comp.sys.sun.admin,comp.mail.uucp
Subject: Flow control with Telebit in uucp spoofing mode
Date: 1 Sep 92 03:12:12 GMT
Organization: Silicon Systems, Nevada City CA

I don't have much outbound uucp traffic here, so I hadn't noticed this
before, but I think I've stumbled across a flow control incompatability.
The Sun is a Sparc 2 running 4.1.1 and Taylor uucp.  The modem is a
Telebit T2500.  I've got things configured as recommended in the
"SUNSPARC_4.1.setup" file I fetched from uunet quite a while ago.  The
relevent bits of information are:

	The modem and port are both locked at 19200.

	The eeprom setting is "ttya-mode=19200,8,n,1,h", which
	should turn on hardware handshake.

	The flow control settings on the modem are S58=0 (no
	flow control modem->Sun since the Sun doesn't support it)
	and S68=2 (modem will drop CTS to throttle the Sun).

While sending a large file using the g(3,64) protocol and uucp spoofing
on the modem, I noticed that the modem was dropping CTS a lot and leaving
it down for extended periods of time.  I then did a "stty -a >/dev/cua0"
to take a look at the port parameters (it was a outgoing call).  I noticed
that crtscts mode was off, so the Sun was not expecting to do outbound flow
control.  I forced this mode on with "stty crtscts >/dev/cua0", and the
behavior of the modem lights changed.  The CTS light still flickered a
bit, but stayed on most of the time.  The file transferred correctly.  I
looked at the uucico log, and noticed that there had been a couple of
previous failed attempts to send this file, which failed due to excessive
errors.  It looks like the modem's buffer was being overrun.

This prompts the following questions:

1) Is it possible to cause the Sun to set crtscts mode automatically
on outgoing calls?  I can do this in incoming calls with with /etc/gettytab,
but I thought that the eeprom setting would take care of this automatically
whenever the the device was opened.  If I really have to, I suppose I
can force this mode in uucp, since I have the source :-)  In Sun's BNU
uucp this can be done in the dialers file.

2) It would appear that the modem must be sending acks even when it
lacks the buffer space for a window's worth of packets following the
packet it is acking.  It this really the case?  Does it matter what
the flow control settings are on the sending modem (S62)?  It should
be possible to run uucp g(3,64) without hardware flow control by
delaying ack's when there is no room in the buffer.  How does Telebit
uucp spoofing handle the lack of hardware flow control?  Assuming that
it is able to to handle this, why does its behavior differ when S62=2.

3) Do the flow control settings on the receiving modem somehow affect
the flow control behavior between the transmitting modem and transmitting
computer in uucp spoofing mode?  I have seen many examples of failed
connections when receiving files that look suspiciously like flow control
problems on the transmitting end.  This happens with both my local news
feed and with uunet.  I would doubt that they both have misconfigured
flow control.
-- 
Don "Truck" Lewis              Phone: +1 916 478-8284   Silicon Systems
Internet: gdonl@ssi1.com       FAX:   +1 916 478-8290   138 New Mohawk Road
UUCP: {uunet,tektronix!gvgpsa.gvg.tek.com}!ssigv!gdonl  Nevada City, CA  95959
Newsgroups: biz.comp.telebit,mi.wanted