[Openswan dev] [Commits] [OPENSWAN.git] Changes to ref refs/heads/master

[David McCullough]

Jivin Paul Wouters lays it down ...
> On Fri, 30 Apr 2010, davidm at vault.xelerance.com wrote:
> 
> >    Fix assertion failure when removing routes
> >
> >    In delete_states_by_connection:
> >
> >    ASSERTION FAILED at .../programs/pluto/state.c:691: sr->eroute_owner == SOS_NOBODY
> >
> >    kernel_interface was left set to AUTO_PICK even though USE_KLIPS had been
> >    selected by the code.  Note sure if this actually affected netkey or others
> >    but it may.
> >
> >    This change makes sure that, once an interface is selected,  everything points
> >    to that interface being the one.
> >
> >    This was a subtle side affect of fdfb59b413eec432969014762ceb847ef7e5e9a4 :-)
> 
> I don't understand. The code reads (with + for your added lines)
> 
> switch(kern_interface) {
>      case AUTO_PICK:
>  	[...]
> 
>      case USE_KLIPS:
> +        kern_interface = USE_KLIPS;
>  	[...]
> 
>   #if defined(BSD_KAME)
>       case USE_BSDKAME:
> +       kern_interface = USE_BSDKAME;
>  	[...]
> 
> Aren't you just setting it to the value it must have because otherwise it would
> never end up in the switch statement to begin with? I mean, it won't hurt, but
> I don't think this can be fixing any assertion failed that you saw.

A small change at the top this funciton meant that on an openswan userland
compiled for both netkey and klips,  but using klips,  it would drop through
to the switch statement with kern_interface = AUTO_PICK,  so it would then
go an setup the klips interface by falling through the switch statement,
but kern_interface was left set to AUTO_PICK, later I would see the assertion
failure.

This was running on the head of git master completely unmodified.

Obviously somewhere else in pluto is using kern_interface to make decisions
and getting it wrong when kern_interface==AUTO_PICK.  I didn't go looking
for the offender.  I actually found this use 'git bisect',  decided that
there was no way that fdfb59b413eec432969014762ceb847ef7e5e9a4 could be the
cause and then went through it all by hand again,  and still didn't believe
it ;-)

I would have liked a cleaner patch, but this seemed like the simplest way to
get it right esp. since you are close to a release.

Cheers,
Davidm

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