On 2026/04/09 22:09, Klemens Nanni wrote:
> sthen:
> > curl's --connect-timeout default is 5 minutes. this includes DNS (which
> > can be quite long if you have a few NS listed) and TLS (in particular,
> > the handshake can stall if you have MTU issues). I believe ftp(1) just
> > uses this on the connect call which would not be equivalent.
> 
> 
> 5m and 15s seem a little too long and short for ftp, given it has just

15s for a TCP connect() timeout doesn't seem too bad actually.

> one knob to time out.

It's not just that it just has one knob; there's _no_ specific timeout
for dns lookups, so they can take much longer. TCP connect timeout
happens after that.

And the MTU issue for TLS is a real problem with some broken networks
and again a connect timeout doesn't help you there, it can still be
hanging without progress at that point (after the connect timeout is
done).

I don't object to sprinkling some -w, but it seems like it only deals
with about a quarter of the problem.


On 2026/04/09 15:23, Andrew Hewus Fresh wrote:
> On Thu, Apr 09, 2026 at 04:11:58PM -0600, Theo de Raadt wrote:
> > What else is affected?
> > 
> > fw_update?
> 
> fw_update puts ftp in the background and times out if the size of the
> file doesn't change size for 12 seconds kills the download and fails.
> 
> https://github.com/openbsd/src/blob/master/usr.sbin/fw_update/fw_update.sh#L133

Interesting, I can see why handling this way would be more appealing
(and beneficial for sanity) than more timeouts inside ftp(1) ;-) That
should cover the various scenarios above. It doesn't allow time for
v6-to-v4 or v4-to-v6 fallback though I think.