Re: UDP_ENCAP_ESPINUDP_NON_IKE

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

On 5/24/2018 10:55 AM, Chuck Zmudzinski wrote:
> 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):

I have NOT recently built a current kernel. That is what I meant to say...

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