I've encountered a problem using Taylor-UUCP's i-protocol on my
NetBSD-1.0 ALPHA and now 1.0 BETA system on serial lines (tcp
connections not fully tested). Everything seems OK, if there are queued
jobs only on one side. If there are jobs waiting on both sides (I'll
need only a 50 kb uucp job on both sides), then I get a lot of errors.
Sometimes the opposite side (Taylor-UUCP 1.04) isn't able to recover,
if there are more queued jobs waiting on both sides.

I've tried Taylor-UUCP 1.04 (NetBSD-current) and 1.05 on my system
running NetBSD-current (1.0 ALPHA and BETA, latest tested version from
Aug. 4.). Both Taylor-UUCP versions were configured with several
different options enabled/disabled in policy.h (HAVE_UNBLOCKED_WRITE,
USE_STDIO, SINGLE_WRITE=[1,16,64,100], ...). I checked this on two
different systems and used different hardware (one 16550 based card and
the another multiport card with onboard CPU and vendor-specific driver)
and different baudrates (9600, 19200 and 57600, got NO silo overflows).

While using 64 byte packets, everything seems to work without a
problem. With a packetsize of 256 bytes and above I see a lot of errors
(the first after sending only 6 packets). With a packet-size above 256
byte the error-rate increases.

On the sending-side I see messages like the following:
"fsysdep_conn_io: Blocking write of 100"
The SAME block will be resend later, after the uucico got a NAK for
this packet.


NetBSD-System:

DEBUG: fisenddata: Sending packet 5 size 256 local 1 remote 0
DEBUG: fconn_io: Writing 266 "..."
DEBUG: fconn_io: Wrote 266 of 266, read 0 of 16349
DEBUG: fisenddata: Sending packet 6 size 256 local 1 remote 0
DEBUG: fconn_io: Writing 266 "..."
DEBUG: fsysdep_conn_io: Blocking write of 100
       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
DEBUG: fconn_io: Wrote 266 of 266, read 816 of 16349
DEBUG: fconn_io: Read 816 "..."
DEBUG: fiprocess_packet: Got DATA packet 1 size 79 local 0 remote 1
[...]
DEBUG: fiprocess_packet: Got DATA packet 16 size 256 local 0 remote 1
DEBUG: fiprocess_packet: Got NAK 6; resending packet
       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
DEBUG: fconn_io: Writing 266 "..."
DEBUG: fconn_io: Wrote 266 of 266, read 0 of 13009
DEBUG: fiprocess_packet: Got NAK 12; resending packet



Other non NetBSD-System, no problems with Taylor-UUCP 1.04/1.05 and
i-protocol for over a year:

[...]
DEBUG: fisenddata: Sending packet 16 size 256 local 1 remote 0
DEBUG: fconn_io: Writing 266 "..."
DEBUG: fconn_io: Wrote 266 of 266, read 40 of 15141
DEBUG: fconn_io: Read 40 "..."
DEBUG: fiwindow_wait: Waiting for ACK
DEBUG: fiwait_for_packet: Need 35 bytes
DEBUG: fconn_read: Read 72 "..."
DEBUG: fiprocess_packet: Got DATA packet 5 size 256 local 0 remote 1
DEBUG: fiwindow_wait: Waiting for ACK
DEBUG: fiwait_for_packet: Need 229 bytes
DEBUG: fconn_read: Read 232 "..."
DEBUG: fiprocess_data: Bad checksum; data 4112989840, frame 182404709
DEBUG: finak: Sending NAK 6
DEBUG: fconn_io: Writing 6 "..."
DEBUG: fconn_io: Wrote 6 of 6, read 0 of 14797
DEBUG: fiwait_for_packet: Need 5 bytes
DEBUG: fconn_read: Read 40 "..."
DEBUG: fiprocess_data: Saving unexpected packet 7 (recseq 5)
DEBUG: fiprocess_data: Saving unexpected packet 8 (recseq 5)

I've a lot more output from debug (more then 200 kb from both sides),
but I think these two short examples should show the problem.

What am I doing wrong or has anyone else seen this behavior ?

Any help would be greatly appreciated.

Thanks.

--
Michael Havemester                                    VOICE:   +49 40/29 33 56
Weidestrasse 41                                       Fax  :   +49 40/29 45 17
D-22083 Hamburg, Germany                              EMail: mh@abqhh.Hanse.DE

------------------------------------------------------------------------------