Hi,
there is a function called pf_get_sport in /usr/src/sys/netpfil/pf/pf_lb.c
which contains a do while loop, the guard is ! PF_AEQ(&init_addr, naddr, af)).
We put a counter in this loop and we saw it spin 431728 times, this appears to
coincide with a lockup. we'll continue investigating tomo
On Thu, Mar 1, 2018 at 9:43 AM, Joe Jones
wrote:
> Hi Kristo,
>
> It's just the master that crashed, the backup can take over.
>
> We think the panic we got by compiling with witness and invariant may be a
> red herring.
>
> We are now looking rules like
>
> nat on $isp_if from to any -> sticky
Hi Kristo,
It's just the master that crashed, the backup can take over.
We think the panic we got by compiling with witness and invariant may be
a red herring.
We are now looking rules like
nat on $isp_if from to any -> sticky-address
if we replace the external_napts table with a single a
Hi Kristof,
yes we use pfsync. Yesterday we tried with pfsync switched off, the box
still locked up but this time without a panic.
We make the DIOCRADDADDRS ioctl on the master and the backup (we use
CARPed pairs).
Regards Joe Jones
On 01/03/18 03:00, Kristof Provost wrote:
On 28 Feb 2018
On 1 Mar 2018, at 15:37, Joe Jones wrote:
yes we use pfsync. Yesterday we tried with pfsync switched off, the
box still locked up but this time without a panic.
We make the DIOCRADDADDRS ioctl on the master and the backup (we use
CARPed pairs).
Interesting. It might be related to pfsync. Is
