freebsd stable - Nov 2007 - pf(4) using inapropriate timeout values, 6.2-R

Hello,

I'm running pf(4) on a 6.2-RELEASE system.

The problem occurs when on a TCP connection, one side sends a FIN (by issuing
shutdown(SHUT_WR) on the socket), which is then ACK-ed properly. According to
pf.conf(5), the connection should then be subject to tcp.closing timeout:

           tcp.closing
                 The state after the first FIN has been sent.

But, after testing, I have discovered that the connection is timeouted
after tcp.finwait value:

           tcp.finwait
                 The state after both FINs have been exchanged and the connec-
                 tion is closed.  Some hosts (notably web servers on Solaris)
                 send TCP packets even after closing the connection.  Increas-
                 ing tcp.finwait (and possibly tcp.closing) can prevent block-
                 ing of such packets.

I'm positively sure it's precisely this value that timeouts this
conection (which later on get state mismatches).

Default tcp.closing value is quite big (15 minutes), while tcp.finwait
ain't, and I have tuned tcp.finwait to a small value due to excesive
number of short-lived connections I have running.

This happens both with "keep state" and "modulate state".

Is it some kind of a known issue? Is there any fix avalaible?
I didn't test it on any other system than 6.2-R.

-- 
  Jan Srzednicki  ::  http://wrzask.pl/
  "Remember, remember, the fifth of November"
                                     -- V for Vendetta

On Mon, Nov 19, 2007 at 09:21:42PM +0100, Jan Srzednicki wrote:
> I'm positively sure it's precisely this value that timeouts this
> conection (which later on get state mismatches).
What does pfctl -vvss show for such a state entry, in particular the
right-most part of the first line ("ESTABLISHED:ESTABLISHED" while the
connection is still fully established, etc.)?

Does it matter which side of the connection (the client or the server)
half-closes the connection?

It's possible that there's a bug in mapping the timeout, I'll check.

Daniel