Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 21 Jul 2006 12:03:40 +0200
From:      Michal Mertl <mime@traveller.cz>
To:        Daniel Hartmeier <daniel@benzedrine.cx>
Cc:        freebsd-stable@freebsd.org, freebsd-pf@freebsd.org
Subject:   Re: Kernel panic with PF
Message-ID:  <1153476220.1140.34.camel@genius.i.cz>
In-Reply-To: <20060721091549.GC23227@insomnia.benzedrine.cx>
References:  <1153410809.1126.66.camel@genius.i.cz> <200607210205.51614.max@love2party.net> <1153472248.1140.13.camel@genius.i.cz> <20060721091549.GC23227@insomnia.benzedrine.cx>

next in thread | previous in thread | raw e-mail | index | archive | help
Daniel Hartmeier wrote:
> On Fri, Jul 21, 2006 at 10:57:28AM +0200, Michal Mertl wrote:
> 
> > The proxy in fact runs in parallel (according to "pfctl -s info" it did
> > about 50 inserts and removal in the state table per second - some 10Mbit
> > of traffic, probably mostly HTTP) and it is quite possible that your
> > explanation is correct. I will forward your suspicion to the vendor.
> > This functionality of the software (using PF with anchors) is quite new
> > - they used different mechanisms in previous versions so it may well
> > have some bugs.
> 
> Anchors were introduced for this purpose, i.e. splitting the ruleset
> into separate pieces, over each of which a single process can have
> authority, so different processes don't stomp on each other's toes with
> ruleset modifications.

They (the Kernun authors) run multiple processes for each proxy.
Originally they used slightly modified Apached core for their proxies I
believe. Thus there are probably more processes using the same anchor.

I don't really understand what they do inside - I would think that when
there are no traffic blocking rules, there's no point in doing anything
with PF except initial setting of the rdr rule to the proxy.

> Ask them if they really need to still use DIOCCHANGERULE, as the idea
> with anchors is generally to only operate within one anchor, and usually
> flush or replace the (smaller) ruleset within.
> 
> Each anchor has its own ticket, so if you're seeing ticket mismatches,
> that means there are concurrent operations on the same anchor, even.

I see. It would be better if they were part of this communication
because I don't know the internals (although I have the source code). I
have problems reaching them at the moment though.


> Daniel
> 




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1153476220.1140.34.camel>