In message <20050629002158.GX5900@mewburn.net>, Luke Mewburn writes:
>
>--Riir/E7CkIHPALLv
>Content-Type: text/plain; charset=us-ascii
>Content-Disposition: inline
>Content-Transfer-Encoding: quoted-printable
>
>On Tue, Jun 28, 2005 at 02:42:16PM -0400, Steven M. Bellovin wrote:
>  | A couple of my v6-capable machines don't seem to be listed in a=20
>  | functional reverse name server.  That is, there is no working server=20
>  | that maps IPv6 addresses to host names.  (Yes, I'm trying to deal with=
>=20
>  | that.)  Worse yet, as best I can tell there's a non-functional server;=
>=20
>  | attempts to resolve the PTR record time out.  This in turn causes=20
>  | problems with using ftp -- the ftp server on ftp.netbsd.org tries to=20
>  | look up the name; it takes sufficiently long to fail that (as best I=20
>  | can tell) my client times out: ftp.c seems to have a fixed 60-second=20
>  | timer before it gives up on the connection.
>  |=20
>  | I'm not certain how best to fix this.  Clearly, I should try to get my=
>=20
>  | name server fixed.  The odds on that happening are, I think, reasonable.
>  | Others won't be that lucky.  Should we fix the timers on our ftp=20
>  | server?  On our clients?  Both?
>
>What ftp client version are you running?  (ftp about:version)


># ftp about:version
Version: NetBSD-ftp 20050601

>I recently modified ftp to enhance the support for timeouts
>in network operations, including in the initial connect()
>and in the active mode accept().
>
>This feature is enabled with '-q quittime'; the default value of 0
>disables timeouts _except_ for active mode accept(), which defaults
>to 60 seconds if no quit time is requested.
>
>I suspect that the 60s timeout in dataconn() for active mode accept()
>is what's timing out for you _if_ you're running a recent ftp
>client with active mode ftp.  You could try cranking the timeout
>with
>	ftp -q 120 ...
>and seeing if that helps.

It didn't help.  Rereading my post, I see I forgot an important detail: 
I'm seeing the 

	421 Service not available, remote server timed out. Connection closed

message.  That comes when trying to read the 220 line.
>
>If so, I may have to consider cranking that hard-coded 60s
>timeout in accept() (possibly to 120s, to take into account
>the default ~ 75s timeout that many DNS resolvers have).

It's not the accept(); the connection is in ESTABLISHED state.

# netstat -nf inet6
Active Internet6 connections
Proto Recv-Q Send-Q  Local Address          Foreign Address        (state)
tcp6       0      0  2001:468:904:16:.64089 2001:4f8:4:7:2e0.21    ESTABLISHED

>
>
>NOTE: before the change, ftp would hang forever in various
>situations if the accept() wasn't ready, which caused all sorts
>of problems for people behind certain firewalls, etc.
>(PRs, numerous questions about the pkgsrc fetch hanging, etc).
>



		--Steven M. Bellovin, http://www.cs.columbia.edu/~smb