On Mon, Aug 03, 2015 at 12:55:46AM +0200, Mike Belopuhov wrote:
> On 2 August 2015 at 22:00, RD Thrush <[email protected]> wrote:
> > On 08/02/15 13:37, Mike Belopuhov wrote:
> >> most likely it's triggered by the reply-to statement. you may try the
> >> attached
> >> diff to see which rule the state belongs to. since you're using
> >> anchors, figuring
> >> out rule numbers will not be easy but you may try to see if one of those
> >> give
> >> you something reasonable:
> >>
> >> pfctl -a '*' -vvsr
> >> pfctl -a 'ext1' -vvsr
> >> pfctl -a 'ext2' -vvsr
> >
> > Thanks, "panic: no appropriate pool for 23/23" is the new result. Since
> > the main pf has less than 23 rules and only one of the anchors has an
> > active interface, I assume it's rule 23 from the ext1 anchor. I've
> > attached the pfctl results from above as well as a short gdb session w/ the
> > crash dump.
> >
> > panic: no appropriate pool for 23/23
>
> thanks for testing. rule 23 is a reply-to rule. jonathan, if
> you don't object, i think we should commit the dif as is at least
> for the release.
>
Well if we want to do that the diff should really be a return where
the panic is.
Index: pf_lb.c
===================================================================
RCS file: /cvs/src/sys/net/pf_lb.c,v
retrieving revision 1.48
diff -u -p -r1.48 pf_lb.c
--- pf_lb.c 20 Jul 2015 18:42:08 -0000 1.48
+++ pf_lb.c 3 Aug 2015 01:13:02 -0000
@@ -873,7 +873,7 @@ pf_postprocess_addr(struct pf_state *cur
else if (nr->route.addr.type != PF_ADDR_NONE)
rpool = nr->route;
else
- panic("no appropriate pool");
+ return (0);
if (((rpool.opts & PF_POOL_TYPEMASK) != PF_POOL_LEASTSTATES))
return (0);
