[Openswan dev] Patch for review

[David McCullough]

Jivin Tuomo Soini lays it down ...
> David McCullough wrote:
> 
> >> I'm actually quite sure that state didn't work for you. I did more
> >> changes. Now it might work with both klips and netkey but interface for
> >> that must be somehow changed to be cleaner.
> > 
> > So if I set up a tunnel with dpdaction=hold,  what is the sequence I need to
> > reproduce the use of that state ?  (saves me thinking about it too hard :-)
> 
> Then you need to cause dpd to tear tunnel into hold and then get network
> back up and give ping or other traffic reason to get tunnel up so that
> pluto will renegotiate.
> 
> > I only use dpdaction = clear | restart(_by_peer) as a rule,  I haven't seen a
> > reason to use hold before now,  but happy to test it if I have process to
> > try,
> 
> Hold is used for static tunnels when you don't want traffic to pass
> clear over internet.

Is that under netkey only ?

I ask because using klips I haven't seen this behaviour.  Esp. on a static
tunnel.  I think the only cases on clear text I have seen with klips are
before pluto has started, or before the tunnel has been started (most likely
routed).  If this isn't right I'd like to know ;-)

> Real problem with the initate code is that netkey does generate acquires
> even when you have permanent, working ipsec tunnel up and running and
> packets are traveling tunnel. That's why I needed to make sure rekeying
> won't happen with CK_PERMANENT state. On one system I got 500 tunnels
> instead of one in some minutes without that check and traffic was not
> flowin because of continues rekeyings - each packet caused rekeying
> after your changes. On 2.6.24 same situation caused tons of unhandled
> acquire states which were visible with ipsec auto --status but there was
> no way to remove them.

At the time I made those changes I dodn't even think netkey used eroutes ;-)
I thought the netkey backend just played long to make life easier for pluto.
Definately been an education in what netkey does.

Cheers,
Davidm

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