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 _______________________________________________ Swan-dev mailing list Swan-dev@lists.libreswan.org https://lists.libreswan.org/mailman/listinfo/swan-dev
