>Number:         902
>Category:       kern
>Synopsis:       TCP transfer of NxTCPss + (1..12) sessions fail
>Confidential:   no
>Severity:       critical
>Priority:       medium
>Responsible:    kern-bug-people (Kernel Bug People)
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Fri Mar 24 11:05:03 1995
>Originator:     Havard Eidnes
>Organization:
	SINTEF RUNIT
>Release:        1.0
>Environment:

System: NetBSD rype.runit.sintef.no 1.0 NetBSD 1.0 (RYPE) #59: Wed Dec 14 18:35:18 MET 1994 he@rype.runit.sintef.no:/usr/src/sys/arch/i386/compile/RYPE i386
System: NetBSD skarven.itea.unit.no 1.0 NetBSD 1.0 (SKRVN) #0: Mon Feb 20 20:25:02 MET 1995     arnej@skarven.dsl.unit.no:/local/usr/src/sys/arch/i386/compile/SKRVN i386
System: NetBSD lirype.runit.sintef.no 1.0 NetBSD 1.0 (LIRYPE) #4: Tue Jan  3 20:45:30 MET 1995     he@lirype.runit.sintef.no:/usr/src/sys/arch/hp300/compile/LIRYPE hp300

>Description:
	Recently one of our local users complained that when he used ftp
	between two boxes running NetBSD, certain files ended up being
	truncated on the receiving end.

	Observations:

	 - This does not appear to be an ftp client or server problem,
	   as the problem can be demonstrated using ttcp.

	 - The problem only seems to affect files which are 1 to 12
	   (inclusive) bytes larger than an integer multiple of the TCP
	   segment size one ends up using (in our test case going over
	   local ethernets, 1448 bytes).  The last 1 to 12 bytes of the
	   file ends up not being transferred to the receiving application.
	   This will e.g. hit files in the size range 2897-2908 inclusive;
	   files within this range will be truncated to 2896 bytes on the
	   receiving end.

	 - The problem has been observed when going i386->i386 and going
	   hp300->i386, which would seem to indicate that this is not an
	   architecture-specific problem.

	 - When using a machine running SunOS or HP-UX as one of the ends
	   of the transfer, the problem is not observed.  However, when 
	   going between an SGI system and a NetBSD system, the problem 
	   will be observed (at least when the NetBSD system is the sender).

	 - If tcp_do_rfc1323 is set to 0 on one of the NetBSD boxes,
	   the error goes away.

	 - The failing sessions always seem to end with a reset segment
	   being sent from the receiving machine, which is sent after the
	   final FIN/ACK sequence.  Just before this, a zero-size segment
	   is sent by the sender with a TCP urgent pointer of 1 (as told
	   by tcpdump).  This behaviour is not seen when tcp_do_rfc1323
	   is set to 0.

	Theory:

	 - From looking at tcpdumps of the failing sessions, it seems
	   that the sender sends 1 byte too few, and the receiver
	   seems to ignore any remaining data bytes sent in the last 
	   (small) segment.
	
>How-To-Repeat:
	% dd if=/dev/zero of=f bs=1 count=2900

	Try to ftp this file in binary mode between two NetBSD systems 
	connected to the same network, so that 1448 bytes segment size
	is used.  Watch it being truncated on the receiving end to 2896
	bytes.

>Fix:
	This is over my head.  I do not know how.
>Audit-Trail:
>Unformatted: