pf(4) using inapropriate timeout values, 6.2-R

Jan Srzednicki w at wrzask.pl
Tue Nov 20 01:50:52 PST 2007


On Tue, Nov 20, 2007 at 07:53:34AM +0100, Daniel Hartmeier wrote:
> 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.)?

OK, here it comes.

This is the connection before sending the one-side FIN:

self tcp MY_IP_HERE:12525 <- MY_IP_HERE:64829       ESTABLISHED:ESTABLISHED
   [390096685 + 66608] wscale 1  [3173293905 + 65537] wscale 1
   age 00:00:00, expires in 24:00:00, 2:1 pkts, 116:64 bytes, rule 30
   id: 47207d980002e600 creatorid: 082298e6
self tcp MY_IP_HERE:64829 -> MY_IP_HERE:12525       ESTABLISHED:ESTABLISHED
   [3173293905 + 65537] wscale 1  [390096685 + 66608] wscale 1
   age 00:00:00, expires in 24:00:00, 2:1 pkts, 116:64 bytes, rule 30
   id: 47207d980002e5ff creatorid: 082298e6

(they're both on the same host)

Now the client sends FIN:

10:39:30.008969 IP MY_IP_HERE.64829 > MY_IP_HERE.12525: F 222:222(0) ack 1 win 33304 <nop,nop,timestamp 2239934566 2239932665>
10:39:30.009008 IP MY_IP_HERE.12525 > MY_IP_HERE.64829: . ack 223 win 33304 <nop,nop,timestamp 2239934566 2239934566>

And the state becomes:

self tcp MY_IP_HERE:12525 <- MY_IP_HERE:64829       ESTABLISHED:FIN_WAIT_2
   [390096685 + 66608] wscale 1  [3173294128 + 66608] wscale 1
   age 00:00:04, expires in 00:00:05, 4:3 pkts, 441:168 bytes, rule 30
   id: 47207d980002e600 creatorid: 082298e6
self tcp MY_IP_HERE:64829 -> MY_IP_HERE:12525       FIN_WAIT_2:ESTABLISHED
   [3173294128 + 66608] wscale 1  [390096685 + 66608] wscale 1
   age 00:00:04, expires in 00:00:05, 4:3 pkts, 441:168 bytes, rule 30
   id: 47207d980002e5ff creatorid: 082298e6

Timeout values:

# pfctl -s timeout
No ALTQ support in kernel
ALTQ related functions disabled
tcp.first                   120s
tcp.opening                  30s
tcp.established           86400s
tcp.closing                 900s
tcp.finwait                   5s
tcp.closed                   10s
tcp.tsdiff                   30s
udp.first                    60s
udp.single                   30s
udp.multiple                 60s
icmp.first                   20s
icmp.error                   10s
other.first                  60s
other.single                 30s
other.multiple               60s
frag                         30s
interval                     10s
adaptive.start                0 states
adaptive.end                  0 states
src.track                     0s


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

Nope, this happens on both sides.

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

Thx.

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



More information about the freebsd-stable mailing list