[Openswan dev] Problems with netkey acquires.

[Tuomo Soini]

David McCullough wrote:
>>
>> 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.

Without your patch (and possibly some other patch since 2.6.24) acquire
messages only caused initiating tunnel. But acquire states were left
behind and they were visible in ipsec auto --status output. But narrow
eroutes were not inserted and tunnel just initiated.

My guess without knowing deeply how this should be done is narrow
eroutes are not needed at all with netkey. Netkey is different, it
doesn't do first packet caching so when kernel does send acquire packet
is already lost.

> 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.

No before post 2.6.24 changes narrow eroutes are not inserted with
netkey and everything works. Expect one strange issue, these sates are
left behind in ipsec auto --status output and they never go away:

000 192.168.4.27/32:4318 -6-> 192.168.20.40/32:445 => %hold 0
%acquire-netlink
000 192.168.4.27/32:1903 -6-> 192.168.20.40/32:445 => %hold 0
%acquire-netlink
000 192.168.4.27/32:8 -1-> 192.168.20.40/32:0 => %hold 0    %acquire-netlink

These acquires sill cause tunnel to initiate on 2.6.24, even when they
are not cleaned out.

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

I was asking you because your changes seem to cause these narrow eroutes
which never are cleaned away.

-- 
Tuomo Soini <tis at foobar.fi>
Foobar Linux services
+358 40 5240030
Foobar Oy <http://foobar.fi/>