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