bug report (auto=add &auto=start)

Hello dev experts,

Few days ago i posted here a message being in doubt who is
responsabile for a 
strange message in my syslog.
See my old posts here:
http://lists.openswan.org/pipermail/dev/2007-June/0
01593.html
or here
http://lists.openswan.org/pipermail/users/2007-Ju
ne/012591.html

Jun 15 14:04:22 dev13 ipsec_setup: ...Openswan IPsec
started
Jun 15 14:04:22 dev13 ipsec_setup: Starting Openswan IPsec
2.4.8...
Jun 15 14:04:23 dev13 ipsec__plutorun: 104 "z1"
#1: STATE_MAIN_I1: initiate
Jun 15 14:04:23 dev13 ipsec__plutorun: ...could not start
conn "z1" 
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
^^^^

Now i come back with some explanations and open a bug
report:

Below, comes my ipsec.conf file (the same on booth
routers):
$ cat /etc/ipsec.conf
version 2.0
conn z1
    authby=secret
    left=1.2.3.4
    leftsubnet=192.168.13.0/24
    leftnexthop=1.2.3.111
    right=5.6.7.8
    rightsubnet=10.0.100.0/24
    rightnexthop=5.6.7.222
    keyexchange=ike
    ike=3des-md5-modp1024
    auth=esp
    esp=3des-md5-96
    pfs=no
    auto=start
include /etc/ipsec.d/examples/no_oe.conf

If, on one router i change from auto=start to auto=add, the
message disappear 
and i have a clean syslog on this router (but the same
stupid message appear 
on the second router, where i keeped auto=start):

Jun 15 15:02:23 dev13 kernel: NET: Registered protocol
family 15
Jun 15 15:02:23 dev13 ipsec_setup: NETKEY on eth0
1.2.3.4/255.255.255.0 
broadcast 1.2.3.255
Jun 15 15:02:24 dev13 ipsec_setup: ...Openswan IPsec
started
Jun 15 15:02:24 dev13 ipsec_setup: Starting Openswan IPsec
2.4.8...

The main problem is that i can't use auto=add on booth
routers.... How can be 
turned off this stupid message!

Regards,
Alex

PS: and yes, /var/log/secure does not show up some errors!
_______________________________________________
Dev mailing list
Devopenswan.org
http:/
/lists.openswan.org/mailman/listinfo/dev

Hi Paul & Michael,

See my comments inline:

> Interesting. The return code should not be non-zero,
since your logs below
> show that absolutely nothing went wrong. It is probably
non-zero,
> because the ipsec auto command returns before knowing
if the connection
> succeeded, because of the default --asynchronous flag.
It does a "fire
> and forget".
>
> Michael: Should we change auto to return 0 for this? Or
change _plutorun
> to not care about the return code?

Is this problem handled by anybody or is considered closed.
I couldn't see any 
fix about this bug.

> > So, a quick fixto this problem is to add to
/etc/ipsec.conf:
> > config setup
> >     plutowait=yes
> > ^^^^^^^^^^^^^^^^
>
> This is the wrong fix, because of you have dozens or
hunderds of tunnels
> you will now start them up one after the other, instead
of parallel.
>

OK, i agree with you, but what is the correct fix?

Regards,
Alex
_______________________________________________
Dev mailing list
Devopenswan.org
http:/
/lists.openswan.org/mailman/listinfo/dev

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


>>>>> "Alex" == Alex  <linuxvfemail.net> writes:
    Alex> See my comments inline:

    >> Interesting. The return code should not be
non-zero, since your
    >> logs below show that absolutely nothing went
wrong. It is
    >> probably non-zero, because the ipsec auto
command returns before
    >> knowing if the connection succeeded, because of
the default
    >> --asynchronous flag. It does a "fire and
forget".
    >> 
    >> 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. 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,
but that doesn't mean that the tunnel won't succeed when
the
network/remote-note/DNS/etc. comes back to life.
  You could change the behaviour about releasing whack if
you wanted.

    >> > So, a quick fixto this problem is to add
to /etc/ipsec.conf: >
    >> > config setup > plutowait=yes >
^^^^^^^^^^^^^^^^
    >> 
    >> This is the wrong fix, because of you have
dozens or hunderds of
    >> tunnels you will now start them up one after
the other, instead
    >> of parallel.

    Alex> OK, i agree with you, but what is the correct
fix?

  plutowait= actually probably isn't implemented in 2.5
either.
  
  The question is, if the tunnel failed to be created, what
are you
going to do differently?  Do you want to do the same thing
if the tunnel
fails later on?
  
- -- 
]            Bear: "Me, I'm just the shape of a
bear."          |  firewalls  [
]   Michael Richardson,    Xelerance Corporation, Ottawa, ON
   |net architect[
] mcrxelerance.com      http://www.san
delman.ottawa.on.ca/mcr/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel
hacking, security guy"); [


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Finger me for keys

iQEVAwUBRoEG3oCLcPvd0N1lAQK4uggAiKx2/gW45xi5t3WK6XmHNn+RVTfq
pUBg
MNrhkHqfZsI+u9LDCKcuLYKWzWTnTjRZycuatGq0dxCl1H+33AAhoHdP1rKB
tT5t
YPBcKTfBrMPp5ee7noo5XpFVCs/WMxtu3HeAEe8Fk0xeF1weezpBKEVGjMDG
Tanw
Rzk60TBtSEui+JPfFid6eizc36QeR4n/aG1sKKhZ763bRrRRw2CeZbN8DkHr
2RpF
RjfXgIi/QXEB5G2MIaY7unmNADg63Htv+je8BPRO0wglCGpy5EfJor8wRRhH
RPLr
nNSRimLAQtQDFnF2MgZhcu6U9C5ciej6hzgy3UO1ZFtIP4NKZEN3BQ==
=DAlg
-----END PGP SIGNATURE-----
_______________________________________________
Dev mailing list
Devopenswan.org
http:/
/lists.openswan.org/mailman/listinfo/dev

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
_______________________________________________
Dev mailing list
Devopenswan.org
http:/
/lists.openswan.org/mailman/listinfo/dev