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

Paul Wouters paul at xelerance.com
Tue May 4 14:39:12 EDT 2010

On Tue, 4 May 2010, David McCullough wrote:

>>>>>> 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.
>>>> Ok, my setup is klips-only, so I didn't see that.
>>> I am klips only too,  but I think NETKEY support is enabled in openswan.
>>> I don't have netkey in my kernel.
>>> Not sure when/how the netkey support is enabled.
>> Well, I have "USE_NETKEY := false" in Makefile.inc.local .
>> Is that not sufficient to disable NETKEY?
>>>>> 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 ;-)
>>>> At least one case (I had problems with) is the function delete_ipsec_sa()
>>>> in kernel.c.
>>> What problem are you seeing there ?
>> This is just one case that goes wrong if kern_interface==AUTO_PICK.
>> The SA will not be deleted, you just get the log
>> "Unknown kernel stack in delete_ipsec_sa".
>> For now it works with Pauls (and your) fixes.
> Oh,  good,  I thought something was still broken :-)

There is. The new code does nothing. So I do not believe whatever crasher
is gone. It just cannot be. I bet gcc even optimised those lines out :P

Either my patch worked and testing it was done wrong. Or something fishy
is still broken.


More information about the Dev mailing list