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

[Antony Antony]

On Wed, Jan 22, 2020 at 05:50:27AM -0500, Paul Wouters wrote:
> On Wed, 22 Jan 2020, Antony Antony wrote:
> 
> > this morning in a testrun I noticed a bunch of coredump from addcon
> > https://swantest.libreswan.fi/s2/v3.28-1487-g3d33747478-testrun-xfrmi/
> > I will investigate addcon crash today.
> 
> > current configuration option is
> > ipsec-interface=no|yes|<n> where n = 1..UINT32_MAX
> 
> I think it might be due to its value being both a number and not. It is
> not following our rules about numbers, time based units, etc. Again, I
> would recommend we only allow regular numbers > 0. No "yes|no" and no
> implied hex (all our parsers treat 0xNNN as hsex, 0sNNN as base64, and
> no prefix as decimal. This should not be different) 
> 
> > Note 0x is necessary.
> 
> That is not how our parser works normally. 

I am not sure what your are implying here.  are you saying 

for example ipsec-interface=2 won't work?

xfrmi branch is using our existing loose enum parsing code and the following 
cases work.
ikev2-xfrmi-06/ipsec.conf:	ipsec-interface=yes
ikev2-xfrmi-07/ipsec.conf:	ipsec-interface=17
ikev2-xfrmi-11-default-route/ipsec.conf:	ipsec-interface=2 

since the parser works I am inclined to keep it this way for now.
I have a feeling we misunderstood the parser. Atleast I did, now I realizing 
there is way to get yes|no|<n> or yes|no|unique|<n> to work.

> > IPv6 and xfrmi may not work in all cases. ipv6 up-down script need more
> > work.
> 
> Sure. I think it is okay to postpone that for after the merge.
> 
> > My plan resolve addconn issue is, a new testrun. If there are no major
> > issues I will merge.
> 
> While you mention looking at the issue I found, you didn't answer about
> my provided patch. Is it correct? Is it wrong? Is there a better way?
> Will it be okay to use before merge? 

I don't know which patch your are talking about. please point me to swan-dev 
archive? Some of the private e-mails you send didn't match any git refereces 
I have. May be the code moved on you. If you are re-sending one please make 
sure the diff to current xfrmi branch.

-antony