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

[Sven Schiwek]

Paul Wouters wrote:
> 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.


Oh yes, sorry for my mistake. I read a good info in the 2.4.15 manpage:
"The action restart is used on tunnels that need to be permanently up,
and have static IP addresses".
I'm missing this text in 2.6.24 - then it would be clearer :-)


>>> 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.


Yes, I have rekey=no
The whole connection config is:

----8<----
conn rv042
        type=tunnel
        compress=no
        authby=secret
        pfs=no
        keyingtries=1
        ikelifetime=12h
        keylife=12h
        rekey=no
        left=xxx.xxx.xxx.xxx
        leftsubnet=0.0.0.0/0
        right=%any
        rightsubnet=192.168.11.0/24
        auto=add
        dpddelay=30
        dpdtimeout=120
        dpdaction=clear
        # dpdaction=restart
---->8----

Cheers,
Sven