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
_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
