On Mon, Aug 03, 2015 at 12:55:46AM +0200, Mike Belopuhov wrote: > On 2 August 2015 at 22:00, RD Thrush <openbsd-t...@thrush.com> 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);