Xref: utzoo comp.sys.att:1921 comp.mail.uucp:888 comp.unix.wizards:5905
Path: utzoo!mnetor!uunet!van-bc!sl
From: sl@van-bc.UUCP (Stuart Lynne)
Newsgroups: comp.sys.att,comp.mail.uucp,comp.unix.wizards
Subject: Re: HDB UUCP fails on AT&T 3B2/310
Message-ID: <1648@van-bc.UUCP>
Date: 30 Dec 87 00:02:16 GMT
References: <75@quincy.UUCP> <2211@crash.cts.com>
Reply-To: sl@van-bc.UUCP (Stuart Lynne)
Organization: Public Access Network, Vancouver, BC.
Lines: 47
Keywords: HDB, UUCP, fails, bombs, SLAVE MODE

In article <2211@crash.cts.com> ford%kenobi@crash.CTS.COM (Michael Ditto) writes:
>>			CONVERSATION FAILED 
>>			IN SEND/SLAVE MODE INPUT FAILURE

>This sounds like something I've seen happen with "normal" (non-HDB) uucp.
>I had a large (almost 1 Meg) compressed tar archive that I tried to send
>to another system.  The transfer was attempted five different times, to
>two different systems, and never worked.  I don't remember if the transfer
>always stopped at a certain point (the only way to tell would be from the
>call duration).  The logfile showed the above "SEND/SLAVE MODE INPUT
>FAILURE" message every time.  All three systems were Unix PCs running the
>normal uucp.
 
>I split the large file into four pieces and they all went through on the
>first try.  I was suspecting that there might be some sequence of bytes
>that interferes with the "G" uucp protocol, but I doubt that spliting
>the file would have fixed that.  (I split the file with dd(1), so the
>smaller files contain the exact same bytes as the original, just split
>up).
 
>Does anyone know if the uucp protocol is at all data-dependent?  I thought
>it basically just packetized the file into 64-byte chunks with a header,
>or something like that.

This happened here a year or so back before our news feed converted to a
sendbatch which limited the size of batch files to 50k. I came home one day
to find that my system had been dutifully trying to download the same larger
than 1MB news file for the better part of 24 hours. Each time it would stop
at some point between 500 and 600 kb. 

In this case a simple change in modem and the file came through first time.

What (seems) to be happening in these cases is that you are experiencing a
noisy communications channel. Uucico will only try upto 5 times to receive a
packet. If there are five bad tries it will abort

For a specific error rate it is not to hard to compute how long you can run 
before you will get a packet which has five errors in a row. 

The solution is to get better/different lines (or modems); or split the file
into chunks that are smaller than the expected value for failure. This can
be empirically done simply by averaging the size of the temporary (TM.)
files which are (usually) left after the failure.


-- 
{ihnp4!alberta!ubc-vision,uunet}!van-bc!Stuart.Lynne Vancouver,BC,604-937-7532