What else is affected?

fw_update?

Surely there are more.

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 */
>