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

2020-01-24 Thread Andrew Cagney
On Fri, 24 Jan 2020 at 10:47, Antony Antony wrote: > > On Fri, Jan 24, 2020 at 09:10:40AM -0500, Andrew Cagney wrote: > > On Fri, 24 Jan 2020 at 07:49, Paul Wouters wrote: > > > > On Jan 24, 2020, at 13:44, Andrew Cagney > > > >> They do. no = 0, yes = 1 and the man page does not explain this. >

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

2020-01-24 Thread Antony Antony
On Fri, Jan 24, 2020 at 09:10:40AM -0500, Andrew Cagney wrote: > On Fri, 24 Jan 2020 at 07:49, Paul Wouters wrote: > > > On Jan 24, 2020, at 13:44, Andrew Cagney > > >> They do. no = 0, yes = 1 and the man page does not explain this. > > > > > > So if I specify: > > > ipsec-interface=no > > > I

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

2020-01-24 Thread Andrew Cagney
On Fri, 24 Jan 2020 at 07:49, Paul Wouters wrote: > > > > > On Jan 24, 2020, at 13:44, Andrew Cagney wrote: > > > >> > >> They do. no = 0, yes = 1 and the man page does not explain this. > > > > So if I specify: > > ipsec-interface=no > > I get interface 0, and: > > No, you get no interface beca

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

2020-01-24 Thread Paul Wouters
> On Jan 24, 2020, at 13:44, Andrew Cagney wrote: > >> >> They do. no = 0, yes = 1 and the man page does not explain this. > > So if I specify: > ipsec-interface=no > I get interface 0, and: No, you get no interface because 0 means no. This is because the current Linux implementation uses

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

2020-01-24 Thread Andrew Cagney
On Fri, 24 Jan 2020 at 07:34, Paul Wouters wrote: > > On Thu, 23 Jan 2020, Andrew Cagney wrote: > > >> As no other people are weighing in, I'll stop objecting provided the > >> parser crashers are resolved. > > > > How does the manual page describe the behaviour? > > Presumably the meaning of "no"

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

2020-01-24 Thread Paul Wouters
On Thu, 23 Jan 2020, Andrew Cagney wrote: As no other people are weighing in, I'll stop objecting provided the parser crashers are resolved. How does the manual page describe the behaviour? Presumably the meaning of "no", "yes", and do not overlap. They do. no = 0, yes = 1 and the man page

Re: [Swan-dev] reggression testcase ikev2-connswitch-01

2020-01-24 Thread Paul Wouters
On Fri, 24 Jan 2020, Tuomo Soini wrote: It is not a regression. It is a fix. It does show we have another problem with connswitching. This issue, and the OE shunt issue and the two release blockers for 3.30 While it might be a fix it is a regression. It causes first matching connection to fail

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

2020-01-24 Thread Paul Wouters
On Thu, 23 Jan 2020, Antony Antony wrote: 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. Just the option being renamed is different

Re: [Swan-dev] reggression testcase ikev2-connswitch-01

2020-01-24 Thread Tuomo Soini
On Fri, 24 Jan 2020 06:14:51 -0500 (EST) Paul Wouters wrote: > On Fri, 24 Jan 2020, Antony Antony wrote: > > > while testing xfrmi Tuomo noticed reggression in connswitch code. > > It is not a regression. It is a fix. It does show we have another > problem with connswitching. This issue, and

Re: [Swan-dev] reggression testcase ikev2-connswitch-01

2020-01-24 Thread Paul Wouters
On Fri, 24 Jan 2020, Antony Antony wrote: while testing xfrmi Tuomo noticed reggression in connswitch code. It is not a regression. It is a fix. It does show we have another problem with connswitching. This issue, and the OE shunt issue and the two release blockers for 3.30 I didn't yet figu

[Swan-dev] reggression testcase ikev2-connswitch-01

2020-01-24 Thread Antony Antony
while testing xfrmi Tuomo noticed reggression in connswitch code. We lookd further, and found the issue in test cases too, ikev2-connswitch-01. Using git bisect: # first bad commit: [c3ac240cb62e032b3efaebe8cfec79de5ed9ccf2] IKEv2: # !POLICY_ALLOW_NO_SAN was only checked on initiator, not respond