[Swan-dev] puzzled by addcon's use of resolve_defaultroute

[Andrew Cagney]

I asked a slightly different question:

https://lists.libreswan.org/pipermail/swan-dev/2018-July/002580.html
does addconn need to call resolve_defaultroute_one()? ... since pluto
calls it anyway
(so far no response :-)

On Sun, 22 Jul 2018 at 14:31, Paul Wouters <paul at nohats.ca> wrote:
>
> On Sun, 22 Jul 2018, D. Hugh Redelmeier wrote:
>
> > 1) after the commit resolve_defaultroute does nothing if HAVE_NETKEY is
> >   undefined.
> >   (Before the commit it wasn't defined if HAVE_NETKEY were undefined.)

It currently isn't possible to build libreswan (master) without netkey
(with or without HAVE_NETKEY defined) (unless you've local hacks :-).
For instance, there is at least one direct call to the xfrm back-end
that should be routed through the kernel structure.

> It should really be an #ifdef LINUX as this function does not need what
> we call NETKEY (aka XFRM) but it just needs the Linux NETLINK interface.
> Which is technically RFC 3549 https://tools.ietf.org/html/rfc3549 but
> in reality just documents Linux native behaviour

Here's the code defining HAVE_NETKEY:

ifeq ($(USE_NETKEY),true)
# technically netlink?
USERLAND_CFLAGS+=-DHAVE_NETKEY
endif

I took the easy path.

BTW, as a general rule - learnt from autoconf - test for a feature and
not for the OS..  Hence, here: HAVE_NETLINK and then either
defined(NETLINK_XFRM) or HAVE_NETLINK_XFRM (yes, while longer, its a
bigger hint as to where this comes from :-)

> > But wait!  Even before this patch, there were two calls to
> > resolve_defaultroute that were not wrapped in #ifdef HAVE_NETKEY.  How
> > did that even compile if HAVE_NETKEY were undefined?
> >
> > Perhaps HAVE_NETKEY has always been defined and we should just presume
> > it everywhere?
>
> No. Ideally anything HAVE_NETKEY / USE_NETKEY should be split into
> HAVE_NETLINK / USE_NETLINK and HAVE_XFRM.

> > 1) Does the code work without HAVE_NETKEY?
>
> Yes. It just requires netlink.
>
> > 2) how can we rename resolve_defaultroute so as not to be misleading?
> >   Alternatively we could put the ifdefs around each call.

> The name isn't misleading, but we are missing code to accomplish the
> same on *BSD and others.

Right.  That functionality is missing.