tech-net archive

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

Re: UDP_ENCAP_ESPINUDP_NON_IKE



On 5/24/2018 1:23 AM, Maxime Villard wrote:
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().

I realize that. I have already discarded that patch and kernel. That patch was just a quick and dirty test to verify we are on the right track to a correct patch.

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?

Yes, it was an unpatched kernel. I have recently built a current kernel. It was this kernel (I copied this from my log after it reboot):

May 23 11:52:40 ave /netbsd: [   1.0000000] NetBSD 8.99.17 (XEN3_DOMU) #0: Wed May 16 21:54:38 UTC 2018 May 23 11:52:40 ave /netbsd: [   1.0000000] mkrepro%mkrepro.NetBSD.org@localhost:/usr/src/sys/arch/xen/compile/XEN3_DOMU

By the way, more recent daily snapshots for amd64 are not available. It seems recent autobuilds are not producing amd64 current kernels. One recent autobuild only has the misc.tgz set on amd64, no other sets and no kernels...


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.

If I can trigger the crash again, I will also reconfigure my test setup without NAT-T to see if the crash is specific to the NAT-T case.

Thanks,
Maxime

Thank you also,

Chuck


Home | Main Index | Thread Index | Old Index