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

Paul Wouters paul at xelerance.com
Tue Jun 26 12:10:01 EDT 2007

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:

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

from _realsetup:

# defaults for "config setup" items

> 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

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.



More information about the Dev mailing list