From owner-freebsd-pf@FreeBSD.ORG Fri Jul 21 09:05:50 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 28B4E16A4DA; Fri, 21 Jul 2006 09:05:50 +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 A7FA943D46; Fri, 21 Jul 2006 09:05:49 +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 k6L95YBY031301 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Fri, 21 Jul 2006 11:05:37 +0200 (CEST) (envelope-from mime@traveller.cz) From: Michal Mertl To: Daniel Hartmeier In-Reply-To: <20060721010559.GB23227@insomnia.benzedrine.cx> References: <1153410809.1126.66.camel@genius.i.cz> <200607210205.51614.max@love2party.net> <20060721010559.GB23227@insomnia.benzedrine.cx> Content-Type: text/plain Date: Fri, 21 Jul 2006 11:05:26 +0200 Message-Id: <1153472726.1140.23.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 09:05:50 -0000 Daniel Hartmeier wrote: > On Fri, Jul 21, 2006 at 02:05:45AM +0200, Max Laier wrote: > > > Which proxies are you using? The "pool_ticket: 1429 != 1430" messages you > > quote below indicate a synchronization problem within the app talking to pf > > via ioctl's. Tickets are used to ensure atomic commits for operations that > > require more than one ioctl. If your proxy app runs in parallel it might > > screw up the internal state and thus leave it undefined afterwards. I give > > you that this shouldn't cause a kernel problem, but if we could fix the app > > we can probably find the right sanity check more easily. > > This looks like a bug in pf_ioctl.c pfioctl() DIOCCHANGERULE > > if (((((newrule->action == PF_NAT) || > (newrule->action == PF_RDR) || > (newrule->action == PF_BINAT) || > (newrule->rt > PF_FASTROUTE)) && > - !pcr->anchor[0])) && > + !newrule->anchor)) && > (TAILQ_FIRST(&newrule->rpool.list) == NULL)) > error = EINVAL; > > i.e. the pool must not be empty for routing and translation rules, > except for translation rules that are actually anchor _calls_. > > The confusion is between translation rules within anchors > (pcr->anchor[0] != '\0') and calls to anchors' translation rules > (rule->anchor != NULL). > > If the proxy is using DIOCCHANGERULE (it must be the proxy, pfctl isn't > using it at all), AND is trying to add/update a rule that requires at > least one replacement address but contains an empty list, then this > would cause the panic seen when that rule later matches a packet. > > This needs fixing in OpenBSD as well. > > Michal, can you please confirm that the patch above fixes the panic? > The proxy will still misbehave and cause the log messages (one more > EINVAL in this case ;), but the kernel shouldn't crash anymore. I am afraid I can't test it at the moment. I am going to get one of the machines to my lab and will experiment with it there. I am afraid I will have problems generating enough traffic for the problem to appear but I will try. > Thanks for the excellent bug report! Thank you. I don't think is was that good as I now see that you had to guess there are anchors used. The rules look like this (except the rules seen by 'pfctl -s nat' they are generated by the proxies when they start): fw1#pfctl -s rule fw1#pfctl -s nat nat-anchor "/kernun/*" all rdr-anchor "/kernun/*" all fw1#pfctl -s Anchors -v kernun kernun/4026 kernun/4039 kernun/4088 kernun/4112 kernun/4134 kernun/4164 kernun/4197 kernun/4257 kernun/4296 kernun/4338 kernun/4383 kernun/4431 kernun/4482 kernun/4590 kernun/4649 fw1# pfctl -a kernun/4039 -s nat rdr on em0 inet proto tcp from any to any port = http label "HTTP" -> 127.0.0.1 When the system was under load I saw ~5000 states in 'pfctl -s state'. Thank you again. I will let you know when I get a chance to test your patch and or find out anything new. Michal