> Am 03.08.2015 um 03:14 schrieb Jonathan Gray <[email protected]>:
>
>> 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.
So the pf_postprocess_addr() only reduces state counters in the least-states
case.
As far as I understand, in the given triggering ruleset there is no
least-states involved
with mentioned rule 23 thus the function returns two lines later anyway, right?
However, panic() seems too much here, as in worst case decrease of least-states
counters
just may not work (and thus somewhat breaks least-states).
So, ok jung@ for the diff below.
> 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);
>
