occasional "Operation not permitted" on state-mismatch
Silver Salonen
silver.salonen at gmail.com
Tue Mar 4 10:39:40 UTC 2008
On Tuesday 04 March 2008 12:31, Jeremy Chadwick wrote:
> On Tue, Mar 04, 2008 at 11:43:37AM +0200, Silver Salonen wrote:
> > Any suggestions where the packet is getting lost or how should I debug it
> > further?
>
> Something I've seen on RELENG_6 and RELENG_7:
>
> Sometimes using "modulate state" works fine, while in some other cases,
> using it results in state mismatches. In those cases, I use "keep
> state" which appears to work fine.
>
> I don't have the details of all my testing available (I was in a very
> big hurry to get the issue solved, since it was affecting our production
> boxes), but reproducing it should be easy once we get our dev/test box
> in the datacenter.
>
> The only proof I have of this is the state-mismatch counter on our
> production machines, and reports from users saying "when I scp data
> to/from some of the boxes, the connection sometimes gets closed
> randomly" (hence the "I was in a big hurry to fix it" :-) ).
>
> eos# pfctl -s info | grep mismatch
> state-mismatch 332027 0.1/s
>
> anubis# pfctl -s info | grep mismatch
> state-mismatch 1514 0.0/s
>
> northstar# pfctl -s info | grep mismatch
> state-mismatch 12439 0.0/s
Actually, as I was saying, in my case, the state-mismatch counter isn't
increasing neither on the source-machine nor on the destination-machine. This
issue (the timeout, not the "operation not permitted") seems to be caused by
smth else..
--
Silver
More information about the freebsd-pf
mailing list