On 2 August 2015 at 15:28, RD Thrush <[email protected]> wrote:
> On 08/01/15 19:31, Jonathan Gray wrote:
>> On Sat, Aug 01, 2015 at 08:46:00PM +0200, Mike Belopuhov wrote:
>>> [... snip ...]
>>> You're slightly overanalyzing here: panic has caught the unhandled
>>> case, but it's not needed per se.
>>>
>>
>> The code directly after the panic assumes rpool is set.
>> Something is clearly wrong in the pf code if this triggers.
>>
>> Without a pf.conf it is hard to guess as to why this triggers...
>
> I've attached a partially sanitized concatenation of pf rules, ifconfig,
> netstat -nr, cat /etc/hostname.$if. Please let me know what more info would
> be helpful.
>
> FWIW, this firewall has been operating successfully with snaps for many
> years. The pf configuration is not tuned as it is somewhat a testbed with an
> accumulation of various failed/successful experiments. Also, the urtwn
> interface has been removed for at least the past month so treat the
> associated rules accordingly.
>
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
cheers,
mike
diff --git sys/net/pf_lb.c sys/net/pf_lb.c
index 4e8d0cd..4cd9b04 100644
--- sys/net/pf_lb.c
+++ sys/net/pf_lb.c
@@ -866,6 +866,7 @@ pf_postprocess_addr(struct pf_state *cur)
}
/* check for appropriate pool */
+ memset(&rpool, 0, sizeof(rpool));
if (nr->rdr.addr.type != PF_ADDR_NONE)
rpool = nr->rdr;
else if (nr->nat.addr.type != PF_ADDR_NONE)
@@ -873,7 +874,8 @@ pf_postprocess_addr(struct pf_state *cur)
else if (nr->route.addr.type != PF_ADDR_NONE)
rpool = nr->route;
else
- panic("no appropriate pool");
+ panic("no appropriate pool for %d/%d", cur->rule.ptr ?
+ cur->rule.ptr->nr : -1, nr->nr);
if (((rpool.opts & PF_POOL_TYPEMASK) != PF_POOL_LEASTSTATES))
return (0);
