Date: Wed, 6 Jul 2005 10:59:39 +0200 From: Daniel Hartmeier <daniel@benzedrine.cx> To: R A <bsdboxes@gmail.com> Cc: freebsd-pf@freebsd.org Subject: Re: Bad State question Message-ID: <20050706085939.GH6024@insomnia.benzedrine.cx> In-Reply-To: <60bf53d705070511595889365@mail.gmail.com> References: <60bf53d705070511595889365@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Jul 05, 2005 at 02:59:47PM -0400, R A wrote:
> I've read through some of the pf.c, in order to attempt to figure out
> what the state failure | 5 was, since it wasn't a really helpfull
> number, and the C code means very little to me, I'm still at a loss.
>
> At the end of this email, I do state what I hope to find out, or what
> I am asking for.
>
> First, the output from PF, complaining:
> =============================
> Jul 5 14:52:54 www1 kernel: pf: BAD state: TCP dest_host
> Jul 5 14:52:54 www1 kernel: :443 dest_host:443 src_host:60855
> [lo=2680241336 high=2680307943 win=33304 modulator=0 wscale=1]
> [lo=3834753739 high=3834820347 win=33304 modulator=0 wscale=1] 9:9 S
> seq=2686921612 ack=3834753739 len=0 ackskew=0 pkts=9:8 dir=in,fwd
> Jul 5 14:52:54 www1 kernel: pf: State failure on: 1 | 5
The digits correspond to the various sequence number comparisons pf
does. Those checks that are ok are not printed, the digits you see (1
and 5) show the checks failed.
SEQ_GEQ(src->seqhi, end) ? ' ' : '1',
SEQ_GEQ(src->seqhi + MAXACKWINDOW, end) ?' ' :'5',
The end of the packet, that is the start of the packet (its th_seq,
2686921612) plus its length (len=0), is end=2686921612. This is both
higher than the upper limit of the window (src->seqhi) and higher than
the upper limit plus fudge factor (src->seqhi + MAXACKWINDOW). This is
why pf blocks it.
The "dir=in,fwd" means that the state entry was created for an
incoming packet, and subsequently matched 9 incoming and 8 outgoing
packets ("pkts=9:8"). The "9:9" means the state entry is in
"FIN_WAIT_2:FIN_WAIT_2", i.e. it has seen a normal connection close or
RST, and the state will timeout in about 45s.
But the "S" means the packet being blocked has the SYN flag set, i.e. is
part of a handshake for a new connection. The client seems to be
re-using its source port 60855 to establish a new connection to the
server port 443, before waiting 2MSL (about 90s), which violates the TCP
RFC.
Maybe it's not a new handshake, but a late arrival of a retransmission
of the initial SYN, but then why is "seq=2686921612" (much higher than
the initial sequence number)?
So, why would you see a SYN packet (with a too-high, but not completely
different, th_seq), after the state has matched 9+8 packets already, and
seems to have seen a connection shutdown?
Maybe you can tcpdump on the real interface and try to capture one
entire connection up to the point where it stalls. For instance, limit
the dumping to one particular source port number, or dump everything for
a while, then grep the dump for one particular connection.
Daniel
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050706085939.GH6024>