Index | Thread | Search

From:
Andrew Hewus Fresh <andrew@afresh1.com>
Subject:
Re: syspatch -c : call ftp(1) with timeout
To:
Theo de Raadt <deraadt@openbsd.org>
Cc:
Klemens Nanni <kn@openbsd.org>, ajacoutot@bsdfrog.org, matthieu@openbsd.org, tech@openbsd.org
Date:
Thu, 9 Apr 2026 15:23:03 -0700

Download raw body.

Thread
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

 
> Surely there are more.

Possibly sysupgrade?


> 
> Klemens Nanni <kn@openbsd.org> wrote:
> 
> > 24.02.2026 09:35, Klemens Nanni пишет:
> > > 23.02.2026 00:44, Kirill A. Korinsky пишет:
> > >> On Sat, 21 Feb 2026 18:30:14 +0100,
> > >> Klemens Nanni <kn@openbsd.org> wrote:
> > >>>
> > >>> 21.02.2026 15:00, Antoine Jacoutot пишет:
> > >>>> On Sat, Feb 21, 2026 at 08:48:58AM +0100, Matthieu Herrb wrote:
> > >>>>> Hi,
> > >>>>>
> > >>>>> I'm using syspatch -c in the monitoring system for a number of OpenBSD
> > >>>>> machines at work.
> > >>>>> From time to time the host listed in /etc/installurl becomes
> > >>>>> unavailable for hours. (I've seen that both with a dedicated mirror or
> > >>>>> with the cdn) causing monitoring errors because the agent (check_mk)
> > >>>>> is stuck.
> > >>>>>
> > >>>>> Adding a timeout option to the ftp(1) command run by syspatch -c is
> > >>>>> enough for me to not have the OpenBSD machines appear unresponsiv in
> > >>>>> the monitoring system.
> > >>>>>
> > >>>>> Would something like this make sense ?
> > >>>>
> > >>>> I think it does.
> > >>>> But why not add it to some of the other ftp(1) calls?
> > >>>
> > >>> ... and sysupgrade(8) and bsd.port.mk(5) FETCH_CMD as well, I guess.
> > >>>
> > >>> Wouldn't it make more sense to provide a more sensible default in ftp(1)
> > >>> so it doesn't wait forever?  -w0 could do that if you really wanted, no?
> > >>>  
> > >>
> > >> ...which may wait forever if you run pkg_add via something like LTE modem,
> > >> and it decided to "renew" it's public IP.
> > > 
> > >      -w seconds
> > >              Wait for seconds for the remote server to connect before giving
> > >              up.
> > > 
> > > This should be the equivalent to curl(1)'s --connect-timeout, although I
> > > did not see which default value they provide.
> > > 
> > > Ours is zero, i.e. no timeout;  -w goes through strtonum(0, 200), so 3m20s
> > > is the maximum value.  I picked 30s as new default just to show a diff.
> > > 
> > > See util.c:timed_connect().
> > > 
> > > Works great for me.  Extra testing done like this:
> > > 
> > > 	$ time timeout 40s ftp -4 -o- http://resolves-but-drops-packets
> > > 	Trying 192.0.2.1...
> > > 	    0m40.02s real     0m00.02s user     0m00.03s system
> > > 
> > > 	$ time       ./obj/ftp -4 -o- http://resolves-but-drops-packets
> > > 	Trying 192.0.2.1...
> > > 	ftp: connect: Operation timed out
> > > 	    0m30.04s real     0m00.01s user     0m00.02s system
> > > 
> > > Thoughts?
> > 
> > Almost forgot this one.
> > 
> > So 30s may or may not be too short, but forever is definitely too long.
> > 
> > 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.
> > 
> > job:
> > > FWIW, rpki-client/extern.h has a MAX_CONN_TIMEOUT of 15 seconds and a
> > > MAX_IO_TIMEOUT of 30 seconds for its HTTPS session handling. Those two
> > > values mean that TCP sessions must establish within 15 seconds and the
> > > connection will be dropped if no data moves for more than 30 seconds.
> > > Makes sense to me to use timeouts in ftp(1) calls too by default.
> > 
> > 5m and 15s seem a little too long and short for ftp, given it has just
> > one knob to time out.
> > 
> > Perhaps 60s to be on the patient side?
> > 
> > I argue, anything >0s is a better default, really.
> > 
> > Feedback? OK?
> > 
> > Index: ftp.1
> > ===================================================================
> > RCS file: /cvs/src/usr.bin/ftp/ftp.1,v
> > diff -u -p -r1.124 ftp.1
> > --- ftp.1	15 Sep 2022 12:47:10 -0000	1.124
> > +++ ftp.1	9 Apr 2026 22:08:03 -0000
> > @@ -323,6 +323,7 @@ as report on data transfer statistics.
> >  Wait for
> >  .Ar seconds
> >  for the remote server to connect before giving up.
> > +The default is 60.
> >  .El
> >  .Pp
> >  The host with which
> > Index: main.c
> > ===================================================================
> > RCS file: /cvs/src/usr.bin/ftp/main.c,v
> > diff -u -p -r1.146 main.c
> > --- main.c	23 Dec 2023 23:03:00 -0000	1.146
> > +++ main.c	9 Apr 2026 22:07:21 -0000
> > @@ -188,7 +188,7 @@ char macbuf[4096];
> >  
> >  FILE	*ttyout;
> >  
> > -int connect_timeout;
> > +int connect_timeout = 60;
> >  
> >  #ifndef SMALL
> >  /* enable using server timestamps by default */
> > 
> 

-- 
andrew

($do || !$do) && undef($try) ;  # Master of Perl, Yoda is.  Hmmmm?