On Wed, 22 Jan 2020, Antony Antony wrote:
I still believe yes/no is not appropriate here. As for using numbers or
%unique, we already have that being used for the mark keyword(s) in the
parser. So that functionality is already there.
I disagree. I think no|yes|<n> is cleaner for this kind of option.
Hence I choose the new convention.
As no other people are weighing in, I'll stop objecting provided the
parser crashers are resolved.
https://lists.libreswan.org/pipermail/swan-dev/2020-January/003540.html
I just checked and the code has not changed. I will try later today or
tomorrow to confirm the patch is still needed but it seems very likely.
thanks for digging out the patch.
as far as I see the code changed. next hop and route issues you mentioned
are resolved.
Please test with latest code and let me know. It is better to investigate
before the merge.
I grabbed the latest code.
It still has this issue on machines with newer kernel but older glibc
(and thus older kernel-haeders):
-c
/root/rpmbuild/BUILD/libreswan-3.28rc1494_g7c7a490_xfrmi/programs/pluto/xfrm_interface.c
/root/rpmbuild/BUILD/libreswan-3.28rc1494_g7c7a490_xfrmi/programs/pluto/xfrm_interface.c:
In function 'link_add_nl_msg':
/root/rpmbuild/BUILD/libreswan-3.28rc1494_g7c7a490_xfrmi/programs/pluto/xfrm_interface.c:176:30:
error: 'IFLA_XFRM_IF_ID' undeclared (first use in this function)
nl_addattr32(&req->n, 1024, IFLA_XFRM_IF_ID, if_id);
^
/root/rpmbuild/BUILD/libreswan-3.28rc1494_g7c7a490_xfrmi/programs/pluto/
My fix was:
diff --git a/include/libreswan.h b/include/libreswan.h
index c3bab15..b134435 100644
--- a/include/libreswan.h
+++ b/include/libreswan.h
@@ -18,6 +18,9 @@
#ifndef _LIBRESWAN_H
#define _LIBRESWAN_H /* seen it, no need to see it again */
+#define IFLA_XFRM_IF_ID 2
+#define IFLA_XFRM_LINK 1
+
#include "err.h"
#include <stdbool.h>
It should probably do an ifndef check first. And possibly do this not in
libreswan.h but in kernel_netlink.h.
Otherwise, the branch compiled and ran, and no longer needs my patch.
Traffic flows from/to the VPN client properly.
Paul
_______________________________________________
Swan-dev mailing list
[email protected]
https://lists.libreswan.org/mailman/listinfo/swan-dev
