[comp.bugs.4bsd] uucp alarms, hangs, dies for no apparent reason.

mjranum@gouldsd.UUCP (Marcus J Ranum) (03/18/87)

	We're running Gould UTX32 2.0 on a powernode 9080 (for background)
and have been having nothing but trouble with our uucp. First we found that
for some stupid reason /usr/spool/uucp has to be 777 mode. (no, I *KNOW*
that is a security problem!) Now we are getting odd cases where we get alarms
constantly, and then uucico hangs up. It seems as if it dislikes a certain
(100% ascii) (I checked) file, since it ALWAYS dies at the same packet from
the same file. Sites dialing in to us have a similar problem. They can
transfer 3/4 of the files, most of the time, and then they get alarms and
drop off. 
	Another site I know of (running a Pyramid under OSX) has what appears
to be exactly the same problem. 

	Anyone out there know about this, or heard any rumors ? Is there 
some kind of general breakage in the code, or is it local to Goulds :-)
E-mail to me, if interesting I will summarize to the net.

ThanX in advance
--mjr();

-- 
"It is better to shred the bugger than to bugger the shredder."
					-ancient doltic proverbch

fair@ucbarpa.Berkeley.EDU (Erik E. Fair) (03/18/87)

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

root@ttl.UUCP (03/20/87)

We too have had the problem of UUCP alarm-ing and dying. We are running
a Pyramid 98X, (4.2BSD) with release 3.1 of the OS. Our modem is a Quattro
SB2422 V22bis working in hayes compatible mode. It talks to the outside world
on an analogue phone line (ie not a high speed link).

It appears that the UUCICO gives the alarm because it missed a SYN from
the remote machine - this always seems to happen after a few minutes when
we run at 2400 baud. However, when we changed to 1200 baud the problem
went away and our phone bills doubled.

We talk to two different modems - an identical Quattro for 2400 baud,
and a hayes lookalike at 1200, so the problem may be the quattros
talking to each other. If it helps anyone, here are the commands we give
the modem. It is a normal ACU device:

L.devices: 
============

ACU ttyi00 unused 2400 hayestone "" AT OK ATV1E0H0 OK ATF5 OK AT&E2 OK
DIR ttyi00 0 2400

ACU ttyi00 unused 1200 hayestone "" AT OK ATV1E0H0 OK ATF4 OK AT&E0 OK
DIR ttyi00 0 1200

============

L.sys:
============

lowsp Any ACU 1200 9,123456789 etc...
highsp Any ACU 2400 9,123456789  etc...

============

There is no more chat inside L.sys, so L-devices does all the modem control.

My guess is that the error correction in the modem keeps losing a part of 
the packet (AT&E2 on the 2400) as the only other difference in the Devices file
is the speed (ATFn).

Any help gratefully received.


R. Manzie, Trading Technology.

=============
UUCP: ...ukc!pyrltd!ttl
ARPA: ttl.UUCP@ukc