[Openswan Users] 2.6.24rc1 (klips) segfault on client ip change

[Paul Wouters]

On Thu, 29 Oct 2009, Sven Schiwek wrote:

>>> I have retested the VPN connection and can definitely say that the
>>> dpdaction=clear is working with Road Warriors.
>>>
>>> With the option dpdaction=restart the pluto process dies approximate 2
>>> minutes after the client disappear which is not surprising with the
>>> option "dpdtimeout=120". The first initial connection is working
>>> without any problems.

First, if you are using right=%any (eg roadwarrior) then you cannot rekey
or initiate.  Therefor, doing dpdaction=restart is wrong. However, we should
not crash. We should probably disallow loading such connections.

>> Please add dumpdir=/tmp/ to "config setup" and re-crash it to get a
>> stacktrace and run gdb on it with a "bt full". That should provide us
>> with information required to pinpoint the issue.
>
> OK, now I have a 400k core file in /tmp. Attached you'll find the
> corresponding pluto stacktrace.

It shows:

Program terminated with signal 11, Segmentation fault.
[New process 12729]
#0  0x000000000041c5ef in handle_next_timer_event () at
/data/pub/LinuxSoftware/Openswan/openswan-2.6.24rc1/programs/pluto/timer.c:479
479             peer = c->spd.that.host_addr;
(gdb) bt full
#0  0x000000000041c5ef in handle_next_timer_event () at
/data/pub/LinuxSoftware/Openswan/openswan-2.6.24rc1/programs/pluto/timer.c:479
         c = (struct connection *) 0x0
         tm = 1256837145
         ev = (struct event *) 0x12c6ba0
         type = 5
         st = (struct state *) 0x12c7e20

The connection struct is null. So we cannot reference the peer from it. We
should never get here. When it crashes, do you have rekey=no? I wonder if
we get strange things when defining rekey=no with dpdaction=restart.

Paul