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
_______________________________________________
Swan-dev mailing list
[email protected]
https://lists.libreswan.org/mailman/listinfo/swan-dev