Hi list,<br><br>Following our last week experiment with Segmentation fault, we moved the connection to a staging platform, and we've got a backtrace of the bug :<br><br>tamerlane:root# gdb /usr/local/libexec/ipsec/pluto /etc/core
<br>GNU gdb 6.3-debian<br>Core was generated by `/usr/local/libexec/ipsec/pluto --nofork --secretsfile /etc/ipsec.secrets --ipse'.<br>Program terminated with signal 11, Segmentation fault.<br><br>warning: current_sos: Can't read pathname for load map: Input/output error
<br><br>Reading symbols from /usr/lib/libgmp.so.3...done.<br>Loaded symbols for /usr/lib/libgmp.so.3<br>Reading symbols from /lib/tls/libresolv.so.2...done.<br>Loaded symbols for /lib/tls/libresolv.so.2<br>Reading symbols from /lib/tls/libc.so.6...done.
<br>Loaded symbols for /lib/tls/libc.so.6<br>Reading symbols from /lib/ld-linux.so.2...done.<br>Loaded symbols for /lib/ld-linux.so.2<br>#0 fmt_log (buf=0xbfe61780 "", buf_len=1024, fmt=0x80bdf20 "ASSERTION FAILED at %s:%lu: %s", ap=0x0) at
log.c:149<br>149 snprintf(bp, be - bp, "\"%s\"", c->name);<br><br>(gdb) bt<br>#0 fmt_log (buf=0xbfe61780 "", buf_len=1024, fmt=0x80bdf20 "ASSERTION FAILED at %s:%lu: %s", ap=0x0) at
log.c:149<br>#1 0x08056cd1 in openswan_loglog (mess_no=135371408, message=0x8119a90 "Hy�\227\021\b", '' <repeats 192 times>...) at log.c:434<br>#2 0x08057c30 in passert_fail (pred_str=0x8119a90 "Hy�\227\021\b", '' <repeats 192 times>...,
<br> file_str=0x8119a90 "Hy�\227\021\b", '' <repeats 192 times>..., line_no=135371408) at log.c:606<br>#3 0x0807b3c4 in complete_state_transition (mdp=0x80edd6c, result=STF_INLINE) at demux.c:2738
<br>#4 0x080795f5 in process_packet (mdp=0x80edd6c) at demux.c:2352<br>#5 0x0807bcbc in comm_handle (ifp=0x8116500) at demux.c:1223<br>#6 0x0805d070 in call_server () at server.c:1166<br>#7 0x0805b0d1 in main (argc=12, argv=0xbfe62264) at
plutomain.c:787<br><br><br>The PFS is declared on both side, and our partner use a linksys VPN (and not openswan as I first thought). Applying the Matthias's patch make pluto not crashing even if the tunnels don't go up. In this case, here is the related auth-log :
<br><br>
<meta http-equiv="CONTENT-TYPE" content="text/html; charset=utf-8"><title></title><meta name="GENERATOR" content="OpenOffice.org 2.0 (Linux)"><meta name="AUTHOR" content="Jean-Michel Bonnefond"><meta name="CREATED" content="20070305;10544800">
<meta name="CHANGED" content="16010101;0">
<style type="text/css">
<!--
@page { size: 21cm 29.7cm; margin: 2cm }
P { margin-bottom: 0.21cm }
-->
</style>
<p style="margin-bottom: 0cm;">Mar 5 10:12:52 tamerlane pluto[12459]:
"faulty_connection" #10: responding to Main Mode<br>Mar 5 10:12:52 tamerlane pluto[12459]:
"faulty_connection" #10: OAKLEY_DES_CBC is not supported.
Attribute OAKLEY_ENCRYPTION_ALGORITHM<br>Mar 5 10:12:52 tamerlane pluto[12459]:
"faulty_connection" #10: OAKLEY_DES_CBC is not supported.
Attribute OAKLEY_ENCRYPTION_ALGORITHM<br>Mar 5 10:12:52 tamerlane pluto[12459]:
"faulty_connection" #10: transition from state
STATE_MAIN_R0 to state STATE_MAIN_R1<br>Mar 5 10:12:52 tamerlane pluto[12459]:
"faulty_connection" #10: STATE_MAIN_R1: sent MR1, expecting
MI2<br>Mar 5 10:12:55 tamerlane pluto[12459]:
"faulty_connection" #10: transition from state
STATE_MAIN_R1 to state STATE_MAIN_R2<br>Mar 5 10:12:55 tamerlane pluto[12459]:
"faulty_connection" #10: STATE_MAIN_R2: sent MR2, expecting
MI3<br>Mar 5 10:13:10 tamerlane pluto[12459]:
"faulty_connection" #10: Main mode peer ID is ID_IPV4_ADDR:
'<a href="http://222.126.123.139">222.126.123.139</a>'<br>Mar 5 10:13:10 tamerlane pluto[12459]:
"faulty_connection" #10: I did not send a certificate
because I do not have one.<br>Mar 5 10:13:10 tamerlane pluto[12459]:
"faulty_connection" #10: transition from state
STATE_MAIN_R2 to state STATE_MAIN_R3<br>Mar 5 10:13:10 tamerlane pluto[12459]:
"faulty_connection" #10: STATE_MAIN_R3: sent MR3, ISAKMP SA
established {auth=OAKLEY_PRESHARED_KEY cipher=oakley_3des_cbc_192
prf=oakley_sha group=modp1024}<br>Mar 5 10:13:10 tamerlane pluto[12459]:
"faulty_connection" #10: Dead Peer Detection (RFC 3706):
not enabled because peer did not advertise it<br>Mar 5 10:13:11 tamerlane pluto[12459]:
"faulty_connection" #11: only OAKLEY_GROUP_MODP1024 and
OAKLEY_GROUP_MODP1536 supported for PFS<br>Mar 5 10:13:11 tamerlane pluto[12459]:
"faulty_connection" #11: sending encrypted notification
BAD_PROPOSAL_SYNTAX to <a href="http://222.126.123.139:500">222.126.123.139:500</a><br>Mar 5 10:13:33 tamerlane pluto[12459]:
"faulty_connection" #12: responding to Main Mode<br>Mar 5 10:13:33 tamerlane pluto[12459]:
"faulty_connection" #12: OAKLEY_DES_CBC is not supported.
Attribute OAKLEY_ENCRYPTION_ALGORITHM<br>Mar 5 10:13:33 tamerlane pluto[12459]:
"faulty_connection" #12: OAKLEY_DES_CBC is not supported.
Attribute OAKLEY_ENCRYPTION_ALGORITHM<br>Mar 5 10:13:33 tamerlane pluto[12459]:
"faulty_connection" #12: transition from state
STATE_MAIN_R0 to state STATE_MAIN_R1<br>Mar 5 10:13:33 tamerlane pluto[12459]:
"faulty_connection" #12: STATE_MAIN_R1: sent MR1, expecting
MI2<br>Mar 5 10:13:35 tamerlane pluto[12459]:
"faulty_connection" #12: transition from state
STATE_MAIN_R1 to state STATE_MAIN_R2<br>Mar 5 10:13:35 tamerlane pluto[12459]:
"faulty_connection" #12: STATE_MAIN_R2: sent MR2, expecting
MI3</p>
<br><br>Switching off the PFS on both side make the tunnel works using either the patched or not patched pluto binary.<br><br>Jean-Michel.<br><br><br><br><div><span class="gmail_quote">2007/3/2, Paul Wouters <<a href="mailto:paul@xelerance.com">
paul@xelerance.com</a>>:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">On Fri, 2 Mar 2007, Pompon wrote:<br><br>> We encountered a bug in openswan
2.4.7 running on debian kernel 2.6.8 with<br>> Klips stack that crashes our entire production platform tunnels !!<br>><br>> After investigations, this is due to a new connection we have just declared<br>> that seems perfectly normal compared to our hundred others. When this
<br>> connections goes up, pluto end with a "Segmentation fault", then pluto is<br>> endless restarted and faulting every 30 seconds making all other tunnels<br>> unusable !<br><br>Please enable dumpdir=/tmp in config setup, crash openswan, and use the
<br>source and core dump in /tmp/ to give us a full backtrace.<br><br>> --- openswan-2.4.7/programs/pluto/demux.c Fri Jan 12 11:35:21 2007<br>> +++ openswan-2.4.7-debug/programs/pluto/demux.c Fri Jan 12 12:16:07 2007
<br>> @@ -2411,7 +2411,7 @@<br>> * we can only be in calculating state if state is ignore,<br>> * or suspended.<br>> */<br>> - passert(result == STF_IGNORE || result == STF_SUSPEND ||<br>> st->st_calculating==FALSE);
<br>> + passert(result == STF_INLINE || result == STF_IGNORE || result ==<br>> STF_SUSPEND || st->st_calculating==FALSE);<br><br>This is already incorporated into 2.4.8rc1.<br><br>Paul<br>--<br>Building and integrating Virtual Private Networks with Openswan:
<br><a href="http://www.amazon.com/gp/product/1904811256/104-3099591-2946327?n=283155">http://www.amazon.com/gp/product/1904811256/104-3099591-2946327?n=283155</a><br></blockquote></div><br>