tech-net archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]


A little more about the crash - it is not NAT-specific and also crashes without NAT-T, although the part about creation of multiple phase 1 security associations might be a problem only with NAT-T, and I suspect that might be caused by more bugs in racoon being revealed by more correct kernel code.

When connecting without NAT and with nat-traversal off I don't think it was doing the multiple phase 1s and /var/log/messages does not capture what happened, but it still crashed in if.c. It also happens no matter which racoon I use. With either the official racoon from NetBSD 7 or our patched NetBSD 7 racoon, it crashes.

In summary, this crash can be repeated by setting up an L2TP/IPsec connection on NetBSD 7 or 8 and then replacing with a recent current kernel such as the one I used here. No need to test a configuration with NAT to see this crash.


On 05/24/2018 04:10 PM, Maxime Villard 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

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

Ryota, Kengo, could you have a look?



Home | Main Index | Thread Index | Old Index