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

[Andrew Cagney]

On Fri, 24 Jan 2020 at 10:47, Antony Antony <antony at phenome.org> wrote:
>
> On Fri, Jan 24, 2020 at 09:10:40AM -0500, Andrew Cagney wrote:
> > On Fri, 24 Jan 2020 at 07:49, Paul Wouters <paul at nohats.ca> wrote:
> > > > On Jan 24, 2020, at 13:44, Andrew Cagney <andrew.cagney at gmail.com>
> > > >> 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 IF_ID which does not see 0 as a valid ID.
> >
> > Should it be =%no - since reserved tokens mostly start with %; then =0
> > can be an error?
>
> %n is an argument for loose enum + string.
> This is loose enum + int. With %no would allow hostname "no" which is not
> necessary here.

I'm not following.

%no and %yes don't necessarily need to map onto the range of valid
ipsec interface numbers.

> >
> > > >  ipsec-interface=1
> > > > I get a random interface?
> > >
> > > You get ipsec1, same as when specifying “yes”.
> >
> > I think that's confusing.  Especially if we've reserved %random or
> > %unique or something as a future enhancement.
>
> my plan is unique note no %
>
> >
> > > In the future, %unique will mean get a (pseudo)random interface name.
> > >
> > > I’m not sure what happens when you pick “10”, as I was confused about the numbers maybe being in hex ?
> >
> > If I use =10, do I see xfrmi10 (or what ever) when listing interfaces?
>
> yes "ipsec10"

good - what I see is what I get

what about:
    ipsec-interface=a
is that an error, or has the kernel shot themselves in the foot by allowing:
   ipseca

and:
  ipsec-interface=0
which would lead to:
  ipsec0
(remember - what I see is what I get) is rejected as it's invalid

> My intention for  no|yes|<n> is to reduce confusion for a simple use case.
> <n> is for advanced use case.

this seems to be trying to combine two separate parameters vis:
  enable-ipsec-interface={yes,no} (default no)
  ipsec-interface=N (default 1)

> current default is "no", however, I assume soon default will be "yes" and
> no|<n> would be advanced use case.