[Swan-dev] expirimental : ipsec device/interface aka XFRMi

Paul Wouters paul at nohats.ca
Fri Jan 24 12:29:13 UTC 2020


On Thu, 23 Jan 2020, Antony Antony wrote:

>> That's not how API's really work. Once we have it, we cannot change it anymore :(
>
> A nice theory.
> It sounds more optimism:) and less reality. Also seeing historically we have
> initial_contact initial-contact.

Just the option being renamed is different. And we keep kt_alias with
the old name around for years. This would be about changing the values
accepted by the option.

>> Well, that should give something like NOTIMP ? :P
>
> Tested outputs welcome than guessing!

036 ipsec-interface=1 not supported. may be missing CONFIG_XFRM_INTERFACE support in kernel

Note that it is using a whack error code in the wrong range. And "may
be" should be "maybe".

>> I'm okay with a manual flag to add. That way we can put the compile
>> error in the FAQ with the workaround.
>
> I would add only after a clear testing -ve cases. What happens when running
> pluto which is compiled with USE_XFRM_HEADER_XFRMI=yes on older kernel? I
> want to see the output.

See above. Note that we already default to using a copy of the xfrm.h by
default via USE_XFRM_HEADER_COPY?=true

Because we know we are often on newer kernels than the installed
combination of xfrm.h/kernel-headers/glibc and we know XFRM people
only add to the API and not modify the API. So using an updated
header file works fine.

> Say test with standard CentOS8 and CentOS7 kernel.
> So, lets add it after few tests.

I tested using kernel-2.6.32-696.16.1.el6.x86_64 on centos6

Paul


More information about the Swan-dev mailing list