On Wed, Jan 22, 2020 at 03:08:45PM -0500, Paul Wouters wrote: > 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.
thanks! lets give the new idea a shot. The crasher is gone since this afternoon. another xauth error appeared. https://swantest.libreswan.fi/s2/v3.28-1496-g02dec310b1-testrun-xfrmi/xauth-pluto-27/OUTPUT/road.console.diff I pushed a fix for and starting testrun. > I grabbed the latest code. > > It still has this issue on machines with newer kernel but older glibc > (and thus older kernel-haeders): Is it from glibc? As far as I see it is in kernel-headers-5.4.7-100.fc30.x86_64 If the kernel and headers match IFLA_XFRM_IF_ID will be defined. grep IFLA_XFRM_IF_ID /usr/include/linux/if_link.h IFLA_XFRM_IF_ID, IFLA_XFRM_IF_ID dnf provides /usr/include/linux/if_link.h > > -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 note it is an enum not define. /* XFRM section */ enum { IFLA_XFRM_UNSPEC, IFLA_XFRM_LINK, IFLA_XFRM_IF_ID, __IFLA_XFRM_MAX }; > #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. you can't ifndef check, it is an enum. which means you would need something like https://github.com/libreswan/libreswan/pull/212/commits/9126ec99ca9e136666cbba5b48a8a02cb11350e0 https://github.com/libreswan/libreswan/pull/212 which we are resisting so far? One concern is if we add a local defination for this enum and compile on CentOS7, at run time on old kernel dragons way be woken up:) Try compiling with enum defination and run it on CentOS/RHEL 7 or old Fedora. > Otherwise, the branch compiled and ran, and no longer needs my patch. > Traffic flows from/to the VPN client properly. that is promising. thanks for testing. _______________________________________________ Swan-dev mailing list Swan-dev@lists.libreswan.org https://lists.libreswan.org/mailman/listinfo/swan-dev