Re: UDP_ENCAP_ESPINUDP_NON_IKE

[Maxime Villard <max%m00nbsd.net@localhost>]

Le 23/05/2018 à 23:56, Chuck Zmudzinski a écrit :
> Last update on my testing of the proposed racoon patch:
>
> I tested a NetBSD 8.0 RC1 kernel with the attached patch to udp_usrreq.c that
> comments out the branch that processes packets with the
> UDP_ENCAP_ESPINUDP_NON_IKE socket option to test what would happen if we
> remove that from the kernel, and ran my NetBSD 7 system on it with the
> unpatched racoon and with our racoon that has support for ENABLE_NATT_00
> removed. As expected, with the old racoon, the connection attempt fails on
> this kernel because of the bug in racoon that mistakenly causes the kernel
> to use that branch of the kernel that I removed in this kernel. Also, as
> expected, our patch to racoon that removes support for ENABLE_NATT_00 fixes
> the problem on this kernel without UDP_ENCAP_ESPINUDP_NON_IKE so I think this
> solution will work on NetBSD 8.x. This is good news.

Alright, thanks. Note however that your patch is not correct, you also need
to replace INP_ESPINUDP_ALL by INP_ESPINUDP in udp4_realinput().

> The bad news: I started testing with a recent current kernel downloaded from
> daily snapshots. It is about a week old. I ran my NetBSD 7 system on that
> current kernel with the new racoon without support for ENABLE_NATT_00, and as
> expected it connected fine. However, as soon as I disconnected the VPN
> connection on the remote host, the current kernel crashed. I could not
> recover the log to see what happened when I rebooted after the crash.
>
> I think I have done enough testing to show that our patch to racoon is a good
> place to begin, but if you want to test this on the current kernel, be
> prepared to deal with kernel crashes. I guess that is always true when using
> current kernels...

Hum, no, current is not supposed to crash. You tested a kernel downloaded from
the snapshots without patching it, right?

If possible, please re-test; set the following sysctl

	sysctl -w ddb.onpanic=1

and then try to trigger the crash, it should give you a log immediately.

Thanks,
Maxime