Date: Thu, 16 Sep 2004 03:56:08 -0000 From: Daniel Hartmeier <daniel@benzedrine.cx> To: pf4freebsd@freelists.org Subject: [pf4freebsd] Re: nfsd send error 1 probably caused by pf ? Message-ID: <20031113163911.GR17343@insomnia.benzedrine.cx> In-Reply-To: <3FB2B5AB.50601@kasimir.com> References: <3FB2ACA6.7030302@kasimir.com> <20031112220709.GO17343@insomnia.benzedrine.cx> <3FB2B203.1030704@kasimir.com> <3FB2B5AB.50601@kasimir.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Nov 12, 2003 at 11:35:23PM +0100, Florian C. Smeets wrote: > I get a lot of these BAD state messages with debug leve misc: >=20 > Nov 12 23:32:25 bender kernel: pf: BAD state: TCP 172.30.1.1:2049=20 > 172.30.1.1:2049 172.30.1.2:1021 [lo=3D2879006265 high=3D2879023465=20 > win=3D16588 modulator=3D0] [lo=3D1139973024 high=3D1139974122 win=3D172= 00=20 > modulator=3D0] 4:4 A > seq=3D1139974472 ack=3D2879006265 len=3D1448 ackskew=3D0 pkts=3D40688= 6:392362=20 > dir=3Din,rev This means your peer is trying to exceed the allowed window. Your side defines a window, which is the maximum amount of data the peer may send unacknowledged. As pf sees you acknowledge further data, it slides the limits. In this case, the peer tried to send segment 1139974472 length 1448, which is only legal if you have previously acknowledged at least 1139974472 + 1448 - 17200 =3D=3D 1139958720 pf hasn't seen an ACK that high from your side (and hence, the peer can't have received it), therefore the peer is exceeding the window and pf blocks the packet. To prove this theory, you'd need a tcpdump -nvvvS of the entire connection (or at least a couple of packets before the first BAD state message). The connection doesn't use window scaling, so either the peer is at fault or pf saw a packet reducing your window size which got lost before the peer saw it. How regularly does this occur? Daniel
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20031113163911.GR17343>