[Openswan dev] Problems with netkey acquires.

[Tuomo Soini]

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.

-- 
Tuomo Soini <tis at foobar.fi>
Foobar Linux services
+358 40 5240030
Foobar Oy <http://foobar.fi/>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: ip_-s_xfrm_pol.txt
Url: http://lists.openswan.org/pipermail/dev/attachments/20100311/9b7ddcd4/attachment-0001.txt