Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!lll-lcc!styx!ames!ucbcad!ucbvax!ucbarpa.Berkeley.EDU!fair
From: fair@ucbarpa.Berkeley.EDU (Erik E. Fair)
Newsgroups: comp.mail.uucp,comp.bugs.4bsd
Subject: Re: uucp alarms, hangs, dies for no apparent reason.
Message-ID: <17903@ucbvax.BERKELEY.EDU>
Date: Wed, 18-Mar-87 15:40:25 EST
Article-I.D.: ucbvax.17903
Posted: Wed Mar 18 15:40:25 1987
Date-Received: Fri, 20-Mar-87 01:35:42 EST
References: <478@gouldsd.UUCP>
Sender: usenet@ucbvax.BERKELEY.EDU
Organization: USENET Protocol Police, Western Gateway Division
Lines: 14
Xref: mnetor comp.mail.uucp:336 comp.bugs.4bsd:235

Unfortunately, you don't say anything about the type of link (phone,
commercial X.25, TCP/IP, etc.) or what kind of system is on the other
end. It sounds to me like you're trying to send stuff over a link that
is not 8-bit fully transparent (i.e. it eats the 8th bit, or it has
in-band flow control built in, or something equally egregious), and
UUCP is sending some offending packet which the data link is eating,
which results in UUCP giving up after some number of retries. If you're
using a phone link, check the two modems involved and the serial
interface boards (they might do ^S/^Q flow control in raw mode, which
exhibits this behaviour).

Note, however, that this only applies to the "g" protocol.

	Erik E. Fair	ucbvax!fair	fair@ucbarpa.berkeley.edu