emy@login.dkuug.dk (Eric Mynatt) (07/23/90)
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. The file consist only of displayable ascii characters and linefeeds. The problem does not happen between two unix machines linked directly with an asynchronous line. Is there anybody who can shed some light on this problem? 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? 'preciate any comments or suggestions. Eric Mynatt... 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).
urlichs@smurf.sub.org (Matthias Urlichs) (07/26/90)
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)