[Openswan dev] bug report (auto=add &auto=start)

[Paul Wouters]

On Tue, 26 Jun 2007, Michael Richardson wrote:

>     >> Michael: Should we change auto to return 0 for this? Or change
>     >> _plutorun to not care about the return code?
>
>     Alex> Is this problem handled by anybody or is considered closed. I
>     Alex> couldn't see any fix about this bug.
>
>   --asynchronous makes "ipsec auto" not wait at all, and it isn't on by
> default.

It is the default. From _plutoload:

async=
if test " $plutowait" = " no"
then
        async="--asynchronous"
fi
for tu in $plutostart
do
        ipsec auto --up $async $tu ||
                echo "...could not start conn \"$tu\""
done

from _realsetup:

# defaults for "config setup" items
[...]
IPSECplutowait=${IPSECplutowait:-no}
[...]

> What may be happening is that pluto will release whack after
> some time efforts to bring up the tunnel.
>   Perhaps that situation should return a clear non-zero error code,

That is not the case we are talking about. This is the standard case
where auto=start brings up a tunnel, and no plutowait= is specified
in config setup, so plutowait=no, so --asynchronous is used, resulting
in a non-zero return code for successfully sending the ipsec auto
command.

Since sending the command to pluto succeeds, I suggest we change
_plutorun to return 0 for these cases, instead of the instance number.

>   plutowait= actually probably isn't implemented in 2.5 either.

So this case will remain. Though I am confused about what will happen if
you then manually run "ipsec auto --up". Isn't that normally run with
plutowait=yes since you keep your controlling terminal and get all the
output from bringing the tunnel up?

So we have three options:

1) leave as is - people should ignore the non-fatal error/warning
2) change it so the return code does not generate a warning. Scripts
   can then still use the return code in other ways (eg positive number
   gives them the instance id)
3) change the return code to 0.

Michael?

Paul