From pst@Shockwave.COM  Fri Aug  4 05:30:31 1995
Received: from precipice.shockwave.com (precipice.shockwave.com [171.69.108.33])
          by freefall.cdrom.com (8.6.11/8.6.6) with ESMTP id FAA08696
          ; Fri, 4 Aug 1995 05:30:30 -0700
Received: (from pst@localhost) by precipice.shockwave.com (8.6.11/8.6.9) id FAA01869; Fri, 4 Aug 1995 05:29:59 -0700
Message-Id: <199508041229.FAA01869@precipice.shockwave.com>
Date: Fri, 4 Aug 1995 05:29:59 -0700
From: Paul Traina <pst@Shockwave.COM>
Reply-To: pst@Shockwave.COM
To: FreeBSD-gnats-submit@freebsd.org
Cc: wollman@freebsd.org
Subject: ftp or kernel - multiple transfers when sendport disabled are slow
X-Send-Pr-Version: 3.2

>Number:         653
>Category:       kern
>Synopsis:       ftp or kernel - multiple transfers when sendport disabled are slow
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    wollman
>State:          closed
>Quarter:
>Keywords:
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Fri Aug  4 05:40:00 PDT 1995
>Closed-Date:    Thu Feb 8 09:01:03 PST 1996
>Last-Modified:  Thu Feb  8 09:01:42 PST 1996
>Originator:     Paul Traina
>Release:        FreeBSD 2.0-BUILT-19950615 i386
>Organization:
Shockwave Engineering
>Environment:

FreeBSD-current as of 24 hours ago, current ftp client.

>Description:

Warning, I have -not- debugged this adequately,  I'm doing this off of the
top of my head and could be totally full of shit here.

I was testing some changes I made to the FTP client and daemon to limit the
data port ranges,  and I noticed that when excercising the no-send-port code
path, doing multiple transfers caused the second transfer to hang for several
seconds before completing.

I believe this is a kernel problem because of sockets being left in
FIN_WAIT2 for more than 3*irtt,  

>How-To-Repeat:

ftp ftp.cdrom.com
<login>
sendport
ls
ls			<-- everything after the first ls will take quite a
ls			    long bit of time to complete

I've seen the same problem under SunOS (both with SunOS clients and SunOS
ftpds,  so this is a generic BSD nasty.)

>Fix:

I actually don't think we should mess with the kernel in this regard, if,
indeed it's delaying things in order to avoid TCP connection collisions,
but it seems to me that when the SO_REUSEADDR socket option gets triggered
on the local side, any state about the old connection should be cleared.
>Release-Note:
>Audit-Trail:
Responsible-Changed-From-To: freebsd-bugs->wollman 
Responsible-Changed-By: pst 
Responsible-Changed-When: Wed Feb 7 17:44:05 PST 1996 
Responsible-Changed-Why:  
State-Changed-From-To: open->closed 
State-Changed-By: wollman 
State-Changed-When: Thu Feb 8 09:01:03 PST 1996 
State-Changed-Why:  
Andras says this is not a bug; I'm inclined to agree. 

>Unformatted:
