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

[Antony Antony]

On Wed, Jan 22, 2020 at 04:32:42PM -0500, Paul Wouters wrote:
> On Wed, 22 Jan 2020, Antony Antony wrote:
> 
> > > 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.
> 
> That's not how API's really work. Once we have it, we cannot change it anymore :(

A nice theory.
It sounds more optimism:) and less reality. Also seeing historically we have 
initial_contact initial-contact. 

> That is why I was trying to resolve this situation before release.
> 
> > 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 have seen this. It seems to be a race condition sometimes.

what? "ping: sendmsg: Operation not permitted" was a bug. not a race 
condition! I think it is fixed now. last night run looks better 605 tests 
passed.
Would you take a quick look at the test run
https://swantest.libreswan.fi/s2/v3.28-1497-g79b1171a93-testrun-xfrmi/
See if there are any other regression?
ikev2-xfrmi-02 failing seems odd. I will look at that.

> 
> > 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
> 
> Sure, if you want to wait for RHEL9 that will be useful. But if you want
> to run a newer kernel, you cannot just install a newer kernel-headers file
> because the glibc installed is compiled against the old kernel-headers. so

> then you also need to recompile glibc. So then no one can install just a
> new kernel, like from the elrepo repository, and compile libreswan.
> 
> Since we are only adding a value, it is safe to define it ourselves.

> > you can't ifndef check, it is an enum. which means you would need 
> > something
> > like
> 
> Oh right. That's why I hadnt done it in the past. thanks for reminding me.
> 
> > https://github.com/libreswan/libreswan/pull/212/commits/9126ec99ca9e136666cbba5b48a8a02cb11350e0
> > https://github.com/libreswan/libreswan/pull/212
> > which we are resisting so far?
> 
> Yes we cannot do that without cross compile complications.

That page clearly document it works OpenWRT and crosscompling. However, I 
agree with the decision.

> We could add a USE_XFRM_HEADER_XFRMI?=false that people can set to true?

Sounds like your plan is to compile it by default on CentOS8?

> > 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.
> 
> Well, that should give something like NOTIMP ? :P

Tested outputs welcome than guessing!

> I'm okay with a manual flag to add. That way we can put the compile
> error in the FAQ with the workaround.

I would add only after a clear testing -ve cases. What happens when running 
pluto which is compiled with USE_XFRM_HEADER_XFRMI=yes on older kernel? I 
want to see the output.

Say test with standard CentOS8 and CentOS7 kernel.
So, lets add it after few tests.

-antony