Re: UDP_ENCAP_ESPINUDP_NON_IKE

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

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