[Swan-dev] expirimental : ipsec device/interface aka XFRMi
paul at nohats.ca
Wed Jan 22 20:08:45 UTC 2020
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.
>> 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):
/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);
My fix was:
diff --git a/include/libreswan.h b/include/libreswan.h
index c3bab15..b134435 100644
@@ -18,6 +18,9 @@
#define _LIBRESWAN_H /* seen it, no need to see it again */
+#define IFLA_XFRM_IF_ID 2
+#define IFLA_XFRM_LINK 1
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.
More information about the Swan-dev