[Swan-dev] IKEv1: Remove all IPsec SA's of a connection when newest SA is removedrefs/heads/master

[Antony Antony]

On Wed, Aug 26, 2015 at 11:26:08AM -0400, Lennart Sorensen wrote:
> On Wed, Aug 26, 2015 at 11:23:39AM -0400, Paul Wouters wrote:
> > On Wed, 26 Aug 2015, Lennart Sorensen wrote:
> > 
> > >>>Aug  5 14:50:13 ruggedcom pluto[8239]: "Test" #3: ignoring Delete SA payload:
> > >>>PROTO_IPSEC_ESP SA(0xbd111c17) not found (our SPI - bogus implementation)
> > 
> > >>Although why am I not seeing the spi 0xbd111c17 anywhere? Does your bug
> > >>report have more plutologs that we can trace down 0xbd111c17 and see if
> > >>this is indeed an ESP SPI and not an ISAKMPD SPI?
> > 
> > >Aug 11 09:08:22 ruggedcom pluto[25039]: "Test" #44: STATE_QUICK_R2: IPsec SA established tunnel mode {ESP=>0xe701c648 <0x43b180e5 xfrm=3DES_0-HMAC_MD5 NATOA=none NATD=none DPD=none}
> > >Aug 11 09:08:23 ruggedcom pluto[25039]: "Test" #45: transition from state STATE_QUICK_R1 to state STATE_QUICK_R2
> > >Aug 11 09:08:23 ruggedcom pluto[25039]: "Test" #45: STATE_QUICK_R2: IPsec SA established tunnel mode {ESP=>0x20e9b4b8 <0x65bd9c08 xfrm=3DES_0-HMAC_MD5 NATOA=none NATD=none DPD=none}
> > 
> > the SPI's don't match and neither do the state numbers. The delete is
> > from state #3 but the SPIs are from #44 and #45 :)
> > 
> > These are nog the logs we are looking for :)
> 
> Well Jeff is off today, but maybe tomorrow he can run the test again
> and capture logs that match.
> 
> Any particular debug options you would like enabled?

I am wondering woudn't this situation avoided by enabling "initial-contact"? 


> At least you seem to have an idea where the problem occurs now.
> 
> -- 
> Len Sorensen
> _______________________________________________
> Swan-dev mailing list
> Swan-dev at lists.libreswan.org
> https://lists.libreswan.org/mailman/listinfo/swan-dev
>