Request For Help With UUCP

MAJ Mark B. Bilodeau mbb at trotter.usma.edu
Mon Oct 3 22:04:10 AEST 1988


I've reposted this request as our commo lines have been down for several days
and I'm not sure if it made it out.  Haven't received a reply.

REQUEST FOR HELP WITH TCP/IP WIN/3B.

Recently we have installed a small LAN consisting of 4 3b2s interconnected
by a DECNet DELNI and standard 3b2 ethernet cards and drop cables.
We are using TCP/IP WIN/3b to communicate across the network.
At first all appearsed to be well.  Telnet, ftp, tftp, etc. all worked.
"rcp -r" died every so often but other than that no problems.  The uucp 
utilities did not work as they did not recognize the network.  In order to
resolve this problem, I modified the sources to the utilities by:
1) defining TCP, 2) changing the include files to the directories used in
this version, 3) set the master to use service 'telnet' with login nuucp
rather than service 'uucp', and 3) setting the 'e' protocol to use the
standard system calls to read and write when the interface is TCP.  Upon
testing, this setup works for SMALL files (< 1024 bytes).  However, on
large files (>1024 bytes) uucico hangs.  The master is waiting for a 'C'
message and the receiver is waiting for the last bytes of the files.
Diging through the debugging files leads me to believe that the last byte
of every uucp packet (1024 byte block) is being lost.  I've dumped the
write buffer to a file just prior to the write call on the socket and all
1024 bytes look good.  On the other side just after the read from the socket
I've dumped the the packet to a file only to find that the last byte of
the buffer is what should be the first byte of the next 1024 byte block.
I've tried experimenting with the block size of the 'e' protocol.  With the
buffer size set to 254 I still get the same results after a number of 
successful transfers.

I know this sounds strange.  I agree.  I sounds to me as if either the
network or the new system calls to read(2) and write(2) that can read from
a socket or stream are causing the problem.  Checking the status of the
network interface shows 0 accumulated errors.  I am thoroughly confused!!
Could the telnet daemon be swallowing a character??

I would appreciate any and all help with this problem.  I can be reached at
the above email address or mbb at westpoint.arpa.

	Thanks In Advance,
	Mark



More information about the Comp.bugs.sys5 mailing list