--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)

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.

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).


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).

--Riir/E7CkIHPALLv
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (NetBSD)

iD8DBQFCwemmpBhtmn8zJHIRAgOnAKCmtBoyOzkBW+JeEh5qlxKi7ukAYgCdFxVD
m7M8Gzz8o9gImFtMgxSr5dY=
=5vQC
-----END PGP SIGNATURE-----

--Riir/E7CkIHPALLv--