[Swan-dev] expirimental : ipsec device/interface aka XFRMi

[Antony Antony]

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.