Re: [Ipsec-tools-devel] rapid repeat acquires

[VANHULLEBUS Y. <va...@fr...>]

Hi.


On Tue, Feb 17, 2009 at 08:13:33AM +0200, Timo Ters wrote:
> Paul Moore wrote:
> > when an acquire triggers a ph2 and that in turn fires a ph1 creation no
> > flags are set in the ph2 entry that makes it look pending
> > 
> > this means that if another acquire arrives very quickly then the waiting
> > ph2 get killed as a zombie in getph2byid call in pk_recvacquire
> >[snip]
> > 
> > although I think an explicit 'waiting for phase1' state would be better
> 
> To me, it looks like the whole test in getph2byid() is a bit funny.
> Furthermore, it returns on first match, so it might or might not
> expire the ph2 depending on various things.
> 
> I'm guessing the intent is to check there if there is a ph2 that has
> been there for a long time, but has not been killed for some reason
> (bug in the other parts of code: e.g. timers not expiring or the
> checkph1 logic failing).
> 
> My opinion is to just remove the "Zombie check" getph2byid().
> Emmanuel, Yvan, any ideas why that check is there?

The "zombie check" is an ugly hack I made a while ago, because we knew
we had some race conditions where such zombie handlers could be
created and block the whole tunnel until you restart racoon, but we
didn't understood at that time what were exactly those race
conditions.

I believe we fixed those race conditions now (does anyone has a
"zombie" in his logs ?), the check has just been kept because we were
not sure that *all* those race conditions have been fixed....


Note about the context on Solaris: racoon should have a better
reaction when getting faster acquire requests, but it is a quite bad
idea to send such acquires so fast (well, it is at least useless: we
do know that a negociation in the real world takes at least 1-2
seconds).


Yvan.