From owner-freebsd-pf@FreeBSD.ORG Fri Jul 21 10:03:56 2006 Return-Path: X-Original-To: freebsd-pf@freebsd.org Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EA2ED16A4DA; Fri, 21 Jul 2006 10:03:56 +0000 (UTC) (envelope-from mime@traveller.cz) Received: from ss.eunet.cz (ss.eunet.cz [193.85.228.13]) by mx1.FreeBSD.org (Postfix) with ESMTP id 59B9043D55; Fri, 21 Jul 2006 10:03:56 +0000 (GMT) (envelope-from mime@traveller.cz) Received: from localhost.i.cz (ss.eunet.cz [193.85.228.13]) by ss.eunet.cz (8.13.6/8.13.6) with ESMTP id k6LA3mt2039954 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Fri, 21 Jul 2006 12:03:48 +0200 (CEST) (envelope-from mime@traveller.cz) From: Michal Mertl To: Daniel Hartmeier 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> Content-Type: text/plain Date: Fri, 21 Jul 2006 12:03:40 +0200 Message-Id: <1153476220.1140.34.camel@genius.i.cz> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org, freebsd-pf@freebsd.org Subject: Re: Kernel panic with PF X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jul 2006 10:03:57 -0000 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 >