On Mon, Aug 03, 2015 at 11:14 +1000, Jonathan Gray wrote:
> 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.
>
Ultimately it's the same fix, but sure, go ahead with this version.
OK mikeb
> 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);
