--aVD9QWMuhilNxW9f
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Tue, Jun 28, 2005 at 08:36:43PM -0400, Steven M. Bellovin wrote:
  | In message <20050629002158.GX5900@mewburn.net>, Luke Mewburn writes:
  | >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.
  |=20
  | It didn't help.  Rereading my post, I see I forgot an important detail:=
=20
  | I'm seeing the=20
  |=20
  | 	421 Service not available, remote server timed out. Connection closed
  |=20
  | 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).
  |=20
  | It's not the accept(); the connection is in ESTABLISHED state.

Ok, so it's the use of "alarmtimer(60)" in getreply(); that behaviour
has been there for a few years.

I think I need to modify that use of alarmtimer so that it uses
the -q quit_time value.
That leaves the issue of what timeout to use for the timeout in
dataconn() and getreply() if no quit_time is given?
Possibly revert back to very old ftp behaviour of "wait forever"...
(I may consider an environment various to set quit_time as well.)

Thoughts?

--aVD9QWMuhilNxW9f
Content-Type: application/pgp-signature
Content-Disposition: inline

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

iD8DBQFCxJ9DpBhtmn8zJHIRAo5BAKC685y9yJC2akKBb2lv6/N3T99m8gCcC7sI
a3MpIPw0/ZLOsLWqvAjJquk=
=+5RZ
-----END PGP SIGNATURE-----

--aVD9QWMuhilNxW9f--