On Wed, Mar 29, 2017 at 10:40:08AM +0200, Mathieu BLANC wrote:
> On Tue, Mar 28, 2017 at 05:58:02PM +0200, Hiltjo Posthuma wrote:
> > On Tue, Mar 28, 2017 at 02:39:44PM +0200, Mathieu BLANC wrote:
> > > On Tue, Mar 28, 2017 at 02:22:28PM +0200, Mathieu BLANC wrote:
> > > > I can reproduce the bug (on the slave firewall) as many times as I want.
> > > >
> > >
> > > I've just read https://www.openbsd.org/ddb.html and saw that you need a
> > > trace
> > > for all cpu.
> > >
> > > http://www.hostingpics.net/viewer.php?id=238876panic9.jpg
> > > http://www.hostingpics.net/viewer.php?id=275943panic10.jpg
> > > http://www.hostingpics.net/viewer.php?id=375143panic11.jpg
> > > http://www.hostingpics.net/viewer.php?id=220012panic12.jpg
> > >
> > > (it's a different crash from the last screenshots i've made, if it's not
> > > good i
> > > can provide a full new set of pics)
> > >
> > > --
> > > Mathieu
> > >
> >
> > Hey,
> >
> > Can you also provide your pf.conf ?
> >
> > Can you test if it also happens on -current?
> >
> > --
> > Kind regards,
> > Hiltjo
>
> Hello,
>
> Unfortunately, i can't provide pf.conf as is (too many references to
> customers,
> ips, etc...). But i think i can work on a minimal file which triggers the bug.
> I'll see that.
>
It also kernel panics with just this pf rules :
# cat pf_minimal.conf
set limit { states 100000 }
set skip on lo
anchor "relayd/*"
pass
--
Mathieu
