From: Jason McIntyre <jmc@kerhand.co.uk>
Subject: Re: Mention tcp.tsdiff in pf.conf(5)
To: tech@openbsd.org
Date: Sun, 14 Apr 2024 06:27:51 +0100

On Sat, Apr 13, 2024 at 10:16:55PM +0200, Jesper Wallin wrote:
> Hi all,
> 
> I noticed that tcp.tsdiff was specified in my pf.conf and got curious
> what pf.conf(5) said about it.  To my surprise, it doesn't seem to
> mention it at all.  I skimmed through and tried to find it in previous
> releases via man.openbsd.org but without any luck.
> 
> The patch below adds a short description about what tcp.tsdiff do.
> 
> While I'm here and after reading some code and doing some testing,
> I learned that 'set optimization' is just an alias for various presets
> of tcp.first, tcp.established, tcp.closing, tcp.finwait, tcp.closed and
> tcp.tsdiff.  This means that specifying these timeouts manually and
> using 'set optimization' is redundant, causing the last statement to
> overwrite the values by the statement that comes last.
> 
> This is correct behaviour, but might cause unintuitive behaviour and
> perhaps worth mentioning in pf.conf(5)?
> 

hi.

for this diff: would you like to have a go at also adding it to the
GRAMMAR section and resubmit?

for the optimisation stuff: you could submit a separate diff for that.
maybe a note where all the tcp.* bits are saying that they can be
handled more generally by set optimization?

jmc

> 
> Index: pf.conf.5
> ===================================================================
> RCS file: /cvs/src/share/man/man5/pf.conf.5,v
> retrieving revision 1.600
> diff -u -p -r1.600 pf.conf.5
> --- pf.conf.5	18 Nov 2022 18:11:10 -0000	1.600
> +++ pf.conf.5	13 Apr 2024 19:51:55 -0000
> @@ -1486,6 +1486,8 @@ The state after the first packet.
>  .It Cm tcp.opening Pq 30 seconds by default
>  The state after the second packet but before both endpoints have
>  acknowledged the connection.
> +.It Cm tcp.tsdiff Pq 30 seconds by default
> +Maximum allowed time difference between RFC1323-compliant packet timestamps.
>  .El
>  .Pp
>  ICMP and UDP are handled in a fashion similar to TCP, but with a much more
>