Date: Fri, 21 Jul 2006 11:05:26 +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: <1153472726.1140.23.camel@genius.i.cz> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1153472726.1140.23.camel>