Bug#718224: UDP_ENCAP kernel definition doesn't match userland
Source: kfreebsd-9
Version: 9.0-10
libc0.1-dev defines UDP_ENCAP as 100 for userland.
kFreeBSD however defines it as 0x01 in the netinet/udp.h used for
kernel compilation.
32609 racoon CALL setsockopt(0x6,0x11,0x64,0x7fffffffd01c,0x4)
32609 racoon RET setsockopt -1 errno 42 Protocol not available
32609 racoon GIO fd 1 wrote 95 bytes
"2013-07-28 18:49:13: WARNING: setsockopt(UDP_ENCAP_ESPINUDP): UDP_ENCAP Protocol not available
This breaks the NAT-T feature of IPSEC, because kFreeBSD doesn't
recognise the value of 100 as a valid setsockopt() optname for UDP.
[In netinet/udp_usrreq.c it will drop out of switch (sopt->sopt_name)].
Linux used 0x01 for its UDP_CORK feature which may explain the
difference. Since our userland netinet/udp.h has defined UDP_ENCAP as
100 until now, some already-built packages such as ipsec-tools and
strongswan will try to use that value. Some code appears to have
possibly hardcoded a value of 100. And even NetBSD seems to have
chosen that value. So I think we should simply change GNU/kFreeBSD to
use 100 in the kernel.
I don't foresee any breakage from such a change. This is only relevant
to IPSEC-enabled kernels anyway, which Debian doesn't currently build.
Alternatively we could even accept *both* values to mean UDP_ENCAP.
-- System Information:
Debian Release: 7.1
APT prefers proposed-updates
APT policy: (500, 'proposed-updates'), (500, 'stable')
Architecture: kfreebsd-amd64 (x86_64)
Kernel: kFreeBSD 9.0-2-amd64-xenhvm
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Reply to: