Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!snorkelwacker!ira.uka.de!smurf!urlichs
From: urlichs@smurf.sub.org (Matthias Urlichs)
Newsgroups: comp.mail.uucp
Subject: Re: X.25 and uucp transmissions
Keywords: X.25 uucp
Message-ID: <-l_re2.ay1@smurf.sub.org>
Date: 25 Jul 90 19:22:21 GMT
References: <emy.648741888@dkuugin>
Distribution: comp.mail.uucp
Organization: University of Karlsruhe, FRG
Lines: 44

In comp.mail.uucp, article <emy.648741888@dkuugin>,
  emy@login.dkuug.dk (Eric Mynatt) writes:

< When attempting to transfer large files (> 12000 bytes) between two
< unix machines which are connected via an X.25 network and
< communicating with the uucp progrom, the transmission is aborted. The
< uucico debug trace shows the message "Data corrupted". We are
< employing the f protocol. The problem however only occurs when a
< large file from the slave system is to be transfered. [...]

This looks suspiciously like a flow control problem. Supposedly the "slave"
(actually, the site which wants to send the file -- "master" and "slave" do
get swapped during a UUCP conversation) talks to its PAD via XON/XOFF flow
control and the PAD wants RTS/CTS. Or vice versa. Or the problem may be on
your side. Have fun finding the offender.

(Since you can successfully start the f protocol, I assume that the PADs are
configured to run transparently, which may point to one of the hosts using
RTS/CTS, which is exactly what my version of f protocol sets the terminal line
to. You might have to play with the PAD parameters -- see the approproate
documentation. Whatever you do, parameter 1 must be set to zero and it must
disconnect when your host drops DTR.)

< Or is there any decent f...ing (That's the way Newsweek spells it)
< documentation about uucico and its error messages and uucp in
< general?
< 
Yes there is, it's called "source code". "f" protocol doesn't seem to be
documented anywhere else.

< PS: Incidently we are using the f protocol because the g protocol
< gave us initially so many problems. The uucp connection kept aborting
< in the beginning (the first data record was retransmitted and finally
< timed out).

Try setting the PAD to transparent mode (^P prof 3 <CR> <CR> should do the
trick in most cases).
Remember also to check if you have to pay per transmitted packet, in which
case g will become very expensive. (Besides, it's likely to be slow, even if
you set both uucico's window sizes to 7.)

-- 
Matthias Urlichs -- urlichs@smurf.sub.org -- urlichs@smurf.ira.uka.de
Humboldtstrasse 7 - 7500 Karlsruhe 1 - FRG -- +49+721+621127(Voice)/621227(PEP)