Subject: kern/902: TCP transfer of NxTCPss + (1..12) sessions fail
To: None <gnats-admin@NetBSD.ORG>
From: Havard Eidnes <Havard.Eidnes@runit.sintef.no>
List: netbsd-bugs
Date: 03/24/1995 11:05:07
>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: