Re: UDP_ENCAP_ESPINUDP_NON_IKE

[Ryota Ozaki <ozaki-r%iij.ad.jp@localhost>]

On Fri, May 25, 2018 at 5:20 AM Maxime Villard <max%m00nbsd.net@localhost> wrote:

> Le 24/05/2018 à 21:13, Chuck Zmudzinski a écrit :
> > Well, the crash is repeatable on the one week old daily snapshot current
> > kernel. Again, here is the current kernel I am using:
> >
> > NetBSD 8.99.17 (XEN3_DOMU) #0: Wed May 16 21:54:38 UTC 2018
> > mkrepro%mkrepro.NetBSD.org@localhost:/usr/src/sys/arch/xen/compile/XEN3_DOMU
> >
> > What is happening is ... crazy.
> >
> > With the current kernel, when the remote client connects, we get caught
in
> > an endless loop of creating ipsec security associations. The log shows
phase1
> > is created, then the phase2 associations, then we respond to negotiate
a new
> > phase1 and two new phase 2's, and I think this loop just continued
until we
> > ran out of memory. The windows client actually thought we were
connected and
> > showed it was connected in the network control panel, but the racoon log
> > never reported that a ppp interface was up. When you look at the
attached
> > snippets from the logs, I bet you will agree that many ppp interfaces
and
> > ipsec SAs were created and when we finally ran out of memory to create
> > another one, we crashed. I say this because the trace indicated the
crash
> > occurred at this branch. [1]. From the console at the start of the crash
> > report, I got this:
> >
> > [ 334.5292103] panic: kernel diagnostic assertion "IFNET_LOCKED(ifp)"
failed: file "/usr/src/sys/net/if.c", line 3595
> >
> > I don't understand line 3595 because if.c only has 661 lines, unless
there
> > was a mistake in how I copied it from the log.

> You're looking at the wrong revision of if.c, yours seems to be [1].

> The main issue here is that we reach this place with ifp unlocked. It's
> probably not related to the system running out of memory.

> That several entries get created in a loop, appears to be a separate
problem.

> I know that several changes were made in netbsd-current for MPification.
It
> may be that you exercise a particular condition that breaks an assumption
> somewhere.

> Ryota, Kengo, could you have a look?

I'm sorry I've looked the mail now.

Chuck, could you decode the backtrace of the panic? In this case the path
to the assertion (probably in if_mcast_op) is important.

Thanks,
   ozaki-r


> Thanks,
> Maxime

> [1] https://nxr.netbsd.org/xref/src/sys/net/if.c?r=1.423#3595