>Number:         16244
>Category:       kern
>Synopsis:       ipv6 packets get stuck in stack (ipv6 ftp demo)
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Mon Apr 08 07:28:00 PDT 2002
>Closed-Date:
>Last-Modified:
>Originator:     Wolfgang Rupprecht
>Release:        NetBSD 1.5ZC
>Organization:
W S Rupprecht Computer Consulting, Fremont CA
>Environment:
System: NetBSD capsicum.wsrcc.com 1.5ZC NetBSD 1.5ZC (WSRCC_ATHLON) #65: Sun Apr 7 09:46:57 PDT 2002 wolfgang@capsicum.wsrcc.com:/v/src/netbsd/src/sys/arch/i386/compile/WSRCC_ATHLON i386
Architecture: i386
Machine: i386
>Description:
	ipv6 packets sometimes get stuck in the stack

	ftp over ipv6 sometimes hangs with tcpdump showing a packet
	getting stuck in the local stack and only released when the
	TCP connection is torn down by the local system.

>How-To-Repeat:

	Setup: ipv6 connectivity via a gif tunnel over ipv4.  In
	general ipv6 connectivity "just works".  The only known
	anomaly is the following ftp example.

	ipf -D # disable ipf -- just so that there is no doubt.

	Here I start "ftp -p -6 dumbcat.example.org" here.

	    06:59:08.868872 sonic.wsrcc.com.49408 > dumbcat.example.org.ftp: S 3004566095:3004566095(0) win 16384 <mss 33160,nop,wscale 0,nop,nop,timestamp 0 0> [flowlabel 0x60518]
	    06:59:09.568490 dumbcat.example.org.ftp > sonic.wsrcc.com.49408: S 2983161253:2983161253(0) ack 3004566096 win 16912 <mss 1440,nop,wscale 0,nop,nop,timestamp 1215838319 0>
	    06:59:09.568578 sonic.wsrcc.com.49408 > dumbcat.example.org.ftp: . ack 1 win 16384 <nop,nop,timestamp 2 1215838319> [flowlabel 0x60518]

	Here the local ftp has its 60 second timeout and prints:
	"421 Service not available, remote server timed out. Connection closed"
	The local ftp then closes its side of the connection.

	    07:00:09.577992 sonic.wsrcc.com.49408 > dumbcat.example.org.ftp: F 1:1(0) ack 1 win 16384 <nop,nop,timestamp 122 1215838319> [flowlabel 0x60518]
	    07:00:10.338432 dumbcat.example.org.ftp > sonic.wsrcc.com.49408: . ack 2 win 16912 <nop,nop,timestamp 1215838440 122>

	I wait 15 seconds and then hit ^D at the ftp prompt.  The next
	two packets from dumbcat were cached / detained by the local
	system and were now released.  

			*** THIS IS THE BUG ***

	Note no packets get sent from my system to the remote one at
	the ^D time.  Either the timing of the remote packet is
	uncanny or the remote packet was already in the local system
	and was just released now.  Since this is very repeatable, it
	is clear it wasn't just a timing fluke.

	    07:00:25.408741 dumbcat.example.org.ftp > sonic.wsrcc.com.49408: P 1:8(7) ack 2 win 16912 <nop,nop,timestamp 1215838471 122>
	    07:00:25.408833 sonic.wsrcc.com.49408 > dumbcat.example.org.ftp: R 3004566097:3004566097(0) win 0 [flowlabel 0x60519]
	    07:00:25.455406 dumbcat.example.org.ftp > sonic.wsrcc.com.49408: FP 8:215(207) ack 2 win 16912 <nop,nop,timestamp 1215838471 122>
	    07:00:25.455432 sonic.wsrcc.com.49408 > dumbcat.example.org.ftp: R 3004566097:3004566097(0) win 0 [flowlabel 0x6051a]

	Slapping a snoop program on the line revealed that these two
	packets were the first two lines of the ftp greeting from the 
	remote system.
	
	    220- 
	    220-                      EXAMPLE.ORG -- [...]
	
	This bug is somewhat random in that a few times out of many
	tests ftp does work as expected.  For a while it appeared that
	ftp would work correctly whenever I turned ipf off.  That
	doesn't appear to be the case always.

>Fix:
	none supplied 
>Release-Note:
>Audit-Trail:
>Unformatted: