On Mon, 27 May 2019, Computerisms Corporation wrote:
Thanks for responding, much appreciated.
It is part of the kernel, and is created by enabling
CONFIG_XFRM_STATISTICS.
Acknowledged and understood.
Does your system have /proc/sys/net/core/xfrm_acq_expires ? Maybe we
need to switch to that to test whether XFRM support is available.
Apparently so:
ls -al /proc/sys/net/core/xfrm_acq_expires
-rw-r--r-- 1 root root 0 May 27 17:24 /proc/sys/net/core/xfrm_acq_expires
So, did I find a real problem, or am I just in need of someone to point
out a glaringly obvious error on my part?
It's not you, it's us :)
Phew, not that I am happy to pass my troubles to others or anything ;)
I've created a patch:
https://github.com/libreswan/libreswan/commit/716f4b712724c6698469563e531dea3667507ceb
(if you want a text based patch for use with "patch", append ".patch" to the
above URL
It should fix the XFRM detection for you.
Okay, so custom kernels are within my skill set, but I don't really want to
be creating a new custom kernel for every firewall I have under my thumb.
Pretty sure one of the happiest days in my computing career was finding
linux-image in the apt repos. Is there an immediate workaround short of
installing an older version? can I change the _stackmanager.in file to look
for this /proc/sys/net/core/xfrm_acq_expires file instead? or will that just
move me to the next problem?
That's only part of the problem. pluto itself also checks. So best to
just apply the above patch :)
Paul
_______________________________________________
Swan mailing list
[email protected]
https://lists.libreswan.org/mailman/listinfo/swan
