[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
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
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
this kernel because of the bug in racoon that mistakenly causes the
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
the problem on this kernel without UDP_ENCAP_ESPINUDP_NON_IKE so I
solution will work on NetBSD 8.x. This is good news.
Alright, thanks. Note however that your patch is not correct, you also
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
daily snapshots. It is about a week old. I ran my NetBSD 7 system on
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
Hum, no, current is not supposed to crash. You tested a kernel
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]
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
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.
Thank you also,
Main Index |
Thread Index |