[strongSwan] Charon reset

Martin Willi martin at strongswan.org
Mon Mar 9 15:43:47 CET 2015


Ken,

> The initiator received signal 6 (SIGABRT) after eight hours of operation.

Actually, the offending signal is SIGSEGV (11). charon catches that,
prints a backtrace, and then calls abort() to terminate itself.

> I have a ~182MB core file from the initiator. How can I get it to you?

I don't think that helps much, as I can't analyze that without your
build and environment.

> #2  0x0000000000401393 in segv_handler (signal=11) at charon.c:199
> #5  0x00007f5e63cf48ac in certs_filter (data=0x7f5e280033e0, in=0x7f5e50c6caf8, out=0x7f5e50c6cba8)
>     at credentials/sets/mem_cred.c:93
> #6  0x00007f5e63ce6a55 in enumerate_filter (this=0x7f5e28003000, o1=0x7f5e50c6cba8, o2=0x7f5e63ce6ce0, o3=0x40,
>     o4=0x7f5e28000088, o5=0x1) at collections/enumerator.c:525
> #7  0x00007f5e63ce6953 in enumerate_nested (this=0x7f5e280033a0, v1=0x7f5e50c6cba8, v2=0x7f5e63ce6ce0, v3=0x40,
>     v4=0x7f5e28000088, v5=0x1) at collections/enumerator.c:448
> #8  0x00007f5e63cf35c0 in get_cert (this=<value optimized out>, cert=<value optimized out>, key=<value optimized out>,
>     id=<value optimized out>, trusted=<value optimized out>) at credentials/credential_manager.c:269
> #9  0x00007f5e63890535 in process_certreq (this=0x7f5e34001040, message=<value optimized out>)
>     at sa/ikev2/tasks/ike_cert_pre.c:85
> #10 process_certreqs (this=0x7f5e34001040, message=<value optimized out>) at sa/ikev2/tasks/ike_cert_pre.c:142
> #11 0x00007f5e63890acb in process_i (this=0x7f5e34001040, message=0x7f5e44000ff0) at sa/ikev2/tasks/ike_cert_pre.c:524
> #12 0x00007f5e63886bce in process_response (this=0x7f5e34000b20, msg=0x7f5e44000ff0) at sa/ikev2/task_manager_v2.c:538

charon crashes while looking up the CA certificate that the peer
indicates trust in by sending a CERTREQ payload. Never seen that, likely
that one of the in-memory certificate instances is corrupt, and/or that
something is wrong with the refcounting of such a certificate.

You may further analyze the issue by inspecting the "data" and "cert"
objects in frame #5 at credentials/sets/mem_cred.c:93.

> 01[IKE] reauthenticating IKE_SA cazena-pdc[3]
> [...]
> 09[ENC] parsed IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) CERTREQ N(MULT_AUTH) ]
> [...]
> 09[DMN] thread 9 received 11

Is this issue reproducible every time? With a constant tunnel uptime?
Can you reduce the time-to-crash if you reduce the re-authentication
interval configured with the ipsec.conf ikelifetime option?

Regards
Martin



More information about the Users mailing list