[Openswan dev] Problems with netkey acquires.

[David McCullough]

Jivin Tuomo Soini lays it down ...
> David McCullough wrote:
> 
> > Ok,  I need some more here I think.  The logs actually looked about right to
> > me for some reason :-)
> 
> Yes, log looks quite ok. Tunnel gets added but when tunnel comes up
> these narrow eroutes are left behind. Either narrow hold eroutes should
> not be added with netkey or cleaning up those after tunnel initiates is
> missing. I hit this problem every time because fetching crls causes
> narrow eroute which matches crl fetching and this narrow eroute never
> does go away.
> 
> > What is left over after this that is causing the problem ?
> 
> That's my guess too. I checked your patches several times and they
> really look ok. I just think we really did hit some old problem which
> was never hit before you fixed this.
> 
> > Looks like we add the narrow hold and the bare shunt,  then initiate the
> > tunnel.  Did it not add 87.108.67.176/32 -> 0.0.0.0/0 info somewhere ?  I
> > though that would happen later when the tunnel came up.
> 
> I guess real problem is narrow holds are not cleaned up when tunnel
> initiates.
> 
> > Sorry,  but I'm obviously missing something.  The last bit of an
> > "ipsec auto --status" usually shows up an %acquire* problem,  might help.
> > Netkey is not something I use a lot, so sorry if this is obvious :-)
> 
> I really don't know what should happen on netkey. Should those narrow
> hold eroutes be inserted and then cleaned up after tunnel initiates or
> should those be left out with netkey. But currently they are not cleaned
> away and because they don't even expire they are left behind forever
> (until pluto is restarted).
> 
> I attached ip -s xfrm pol output which clearly show those wrong eroutes.

Ok,  looks like the behaviour of netkey is different to klips.

You said that even without my patch something was broken.  Was it still
basically the same problem ?  Have you compared the 'ip -s xfrm pol' output
with and without the change ?  Might help to figure out where the changes
need to be made.

My guess is that netkey always installs the narrow holds and pluto needs to
know this and cleanup.  So sort of the opposite of what I fixed for klips.
The bug I fixed was that pluto assumed there was a hold when then wasn't.

I'm not really setup to easily test netkey changes, but if I get a chance I
will have a look.

Cheers,
Davidm

-- 
David McCullough,      david_mccullough at mcafee.com,  Ph:+61 734352815
McAfee - SnapGear      http://www.mcafee.com         http://www.uCdot.org