[Openswan dev] Patch for review

David McCullough david_mccullough at mcafee.com
Fri Apr 23 00:03:03 EDT 2010


Jivin Tuomo Soini lays it down ...
> David McCullough wrote:
> > Jivin Tuomo Soini lays it down ...
> >> Does this break klips?
> > 
> > Almost certainly,  but I haven't tried it yet :-)
> > 
> >> It seem to work perfectly on netkey.
> >>
> >> This is not complete fix yet, Real fixing requires removing checking of
> >> initiate_ondemand_body return codes, This just hardcodes return code so
> >> it works and returns code to the state it was before all my experiments.
> > 
> > Just restating that I haven't tried this patch,  but it seems unlikely to
> > work for KLIPS.  The bug we had with klips was that if we didn't do anything
> > with the tunnel in initiate_ondemand,  then the kernel installed bare_shunt
> > would stay and cause problems.  Always removing the bare_shnut is just as
> > likely to cause problems later when we expect it to be there.  The klips ops
> > are very unforgiving,  if you call update,  it has to exist,  if you call
> > create it must not exist,  if you call delete,  it must exist.
> 
> That's the netkey problem. Bare shunt is always left behind on same
> situations and that doesn't work.

The two interface just work differently I guess.

> > Would it be possible for you to explain the bug you are trying to fix
> > when running with netkey ?  Is it for demand tunnels or not ? What is going
> > wrong and when ?
> 
> On netkey every run where initiate_ondemand_body leave eroute into xfrm
> policy causing packets never flow for the conn causing on-demand tunnel
> negotiation.
> 
> This happens for both CK_INSTANCE and CK_PERMANENT state tunnels if
> there is acquire by kernel.
> 
> Even with my fixes there usually is tunnel negotiation and immidiate
> rekey but that can't be avoided without code properly checking if there
> already is ongoing negotiation and ignoring it.
> 
> > Comments below on how the patch can easily be made klips safe if that is the
> > right thing to do.
> > 
> >> commit 42e9ba4cd79187d0fe32ae6c1e29cf7e2ef7f916
> >> Author: Tuomo Soini <tis at foobar.fi>
> >> Date:   Thu Apr 22 12:42:43 2010 +0300
> >>
> >>     This commit reverts changes which did fix spurious tunnel rekeyings
> >>     because of netkey acquires. But unlike those work-arounds this
> >>     change removes reason for those commits by always returning with 0 from
> >>     initiate_ondemand_body. And those reverted changes broke on-demand tunneling
> >>     by %hold state.
> >>     
> >>     If we return with non-0 value bare shunts are left behind and never
> >>     cleaned away causing invalid hold eroutes on netkey.
> >>
> >> diff --git a/programs/pluto/initiate.c b/programs/pluto/initiate.c
> >> index e2e1c96..9d828ac 100644
> >> --- a/programs/pluto/initiate.c
> >> +++ b/programs/pluto/initiate.c
> >> @@ -717,7 +717,7 @@ initiate_ondemand_body(struct find_oppo_bundle *b
> >>      int hisport;
> >>      char demandbuf[256];
> >>      bool loggedit = FALSE;
> >> -    int work = 1; /* assume we did some */
> >> +    int work = 0; /* This is ugly fix, we just always return 0 - Tuomo */
> > 
> > How about:
> > 
> > 	/* on klips/mast assume we will do something something */
> > 	work = (kern_interface == USE_KLIPS || kern_interface == USE_MASTKLIPS);
> 
> That's ok for me.
> 
> >>      
> >>      /* What connection shall we use?
> >>       * First try for one that explicitly handles the clients.
> >> @@ -780,15 +780,19 @@ initiate_ondemand_body(struct find_oppo_bundle *b
> >>  
> >>  	if(c->kind == CK_INSTANCE)
> >>  	{
> >> +	    char cib[CONN_INST_BUF];
> >>  	    /* there is already an instance being negotiated, do nothing */
> >> -	    return 0;
> >> +	    openswan_log("rekeying existing instance \"%s\"%s, due to acquire"
> >> +			 , c->name
> >> +			 , (fmt_conn_instance(c, cib), cib));
> >> +
> >> +	    /*
> >> +	     * we used to return here, but rekeying is a better choice. If we
> >> +	     * got the acquire, it is because something turned stuff into a
> >> +	     * %trap, or something got deleted, perhaps due to an expiry.
> >> +	     */
> > 
> > 		work = 0; /* klips/mast need to know we are doing nothing */
> > 
> >>  	}
> >>  
> >> -	if(c->kind == CK_PERMANENT)
> >> -	{
> >> -	    /* there is already a tunnel, do nothing */
> >> -	    return 0;


Perhaps then:

	if ((kern_interface == USE_KLIPS || kern_interface == USE_MASTKLIPS) &&
			c->kind == CK_PERMANENT)

I am not sure if the alternative is ok,  but I know that leaving this in for
klips is ok.
	
> > Restore this, with the work = 0 and for netkey ot will be a NOOP.
> 
> We can't restore this. If we return here we never initiate on-demand on
> netkey.
> 
> > 		work = 0; /* klips/mast need to know we are doing nothing */
> 
> You didn't check end of the function. Using return 0 is same as setting
> work = 0;

I just prefer not to mix up my return mechanisms within the same function.
I did realise it was the same :-)

> >> -	}
> >>  	/* otherwise, there is some kind of static conn that can handle
> >>  	 * this connection, so we initiate it */
> 
> If we ever return with non-zero status eg work != 0 netkey leaves hold
> eroute behind and those are not cleaned away.

Thats fine,  but right now I have no known problems with klips and
eroutes/shunts so I'd prefer to reserve the changes only for netkey and
leave it as is for klips.

Cheers,
Davidm

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


More information about the Dev mailing list