In message <20050701014123.GB12905@mewburn.net>, Luke Mewburn writes:
>
>
>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.)

I think I'd opt for about 5 minutes (or maybe 10) as the default value
for all of these timeouts: you want to ensure that normal delays don't 
trigger them.  For example, the delay on the accept() calls should be 
greater than (default) timeout on the corresonding connect() calls.  
That way, the connect()er will give up first.  (A quick test on 
-current says that the connect() timeout is about 75 seconds.  I should 
read the source, I suppose, rather than testing....) In my situation,
the problem is with DNS queries.  How long can they take?  I know it's 
at least 2 minutes.

These timeouts are an excellent idea.  In fact, the place I'm running 
into the problem is when running /usr/pkg/sbin/download-vulnerability-list
from /etc/security.local; I don't want my daily job hanging forever.  
I'm glad the timers were added; just make the default values quite 
conservative.

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