Re: UDP_ENCAP_ESPINUDP_NON_IKE

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

On Wed, May 30, 2018 at 7:02 AM Chuck Zmudzinski <frchuckz%gmail.com@localhost> wrote:
>
> Ryota,
>
> Here is what I am getting with the crash. I do not know how to decode
> it.

Please do
  addr2line -f -e <kernel_binary> <address>
for each address.

Or
  objdump -d  <kernel_binary>
and search functions containing each address from the output by hand.

Or if you can do, build a kernel with 'makeoptions    DEBUG="-g"'
and use it, then you can get a backtrace with symbols on a panic.

Thanks,
  ozaki-r

> 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
>