Re: UDP_ENCAP_ESPINUDP_NON_IKE

[Chuck Zmudzinski <frchuckz%gmail.com@localhost>]

Ryota,

Here is what I am getting with the crash. I do not know how to decode 
it. I type bt and just get a bunch of hex numbers that I do not know how 
to interpret. I try sync and get a messages that dumping to dev 142,1 
(offset=6291455, size=0): not possible. After reboot, there is no core 
dump in /var/crash. Maybe it is somewhere else. I checked that I do have 
a dump device configured and I think I am still using the default values 
for savecore. What else can I try to decode this? I tried using a 
separate larger partition for /var/crash but that didn't make any 
difference.

Chuck

Here is the output from bt and sync from the db prompt:

db{1}> bt
?() at ffffffff80205845
?() at ffffffff804ee4e8
?() at ffffffff805ec155
?() at ffffffff8057ef93
?() at ffffffff802ce97c
?() at ffffffff802d333f
?() at ffffffff805af696
?() at ffffffff805b2aac
?() at ffffffff805b0c8a
?() at ffffffff80520989
?() at ffffffff80505e28
?() at ffffffff804fa433
?() at ffffffff804fa539
?() at ffffffff8020f2bc
db{1}> sync

[ 1634.8391410] dumping to dev 142,1 (offset=6291455, size=0): not possible
[ 1634.8391410] rebooting...


On 05/29/2018 04:42 AM, Ryota Ozaki wrote:
> 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