[Openswan Users] Pluto Segmentation fault in 2.4.7

[Pompon]

Hi list,

Unfortunately, we are no more able to reproduce the bug. It seems that we
haven't done any modifications but switching PFS off on both side.
Switching PFS on again on both side doesn't reproduce the bug, but I can't
guarantee that our partner hadn't modified something else in his
configuration.

For informations, the Mathias's patch was :

--- openswan-2.4.7/programs/pluto/demux.c Fri Jan 12 11:35:21 2007
+++ openswan-2.4.7-debug /programs/pluto/demux.c Fri Jan 12 12:16:07 2007
@@ -2411,7 +2411,7 @@
      * we can only be in calculating state if state is ignore,
      * or suspended.
      */
-    passert(result == STF_IGNORE || result == STF_SUSPEND ||
st->st_calculating==FALSE);
+    passert(result == STF_INLINE || result == STF_IGNORE || result ==
STF_SUSPEND || st->st_calculating==FALSE);

We have applied this patch on our production server and will survey how they
work.

Thanks,
Jean-Michel.


2007/3/5, Paul Wouters < paul at xelerance.com>:
>
> On Mon, 5 Mar 2007, Pompon wrote:
>
> > Subject: Re: [Openswan Users] Pluto Segmentation fault in 2.4.7
> >
> > 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 :
>
>
> > #0  fmt_log (buf=0xbfe61780 "", buf_len=1024, fmt=0x80bdf20 "ASSERTION
> > FAILED at %s:%lu: %s", ap=0x0) at log.c:149
> > 149             snprintf(bp, be - bp, "\"%s\"", c->name);
> >
> > (gdb) bt
> > #0  fmt_log (buf=0xbfe61780 "", buf_len=1024, fmt=0x80bdf20 "ASSERTION
> > FAILED at %s:%lu: %s", ap=0x0) at log.c:149
> > #1  0x08056cd1 in openswan_loglog (mess_no=135371408, message=0x8119a90
>
> The logging routines in 2.4.7 had a problem with displaying certain
> options. Can you verify that openswan 2.4.8rc1 (available in the testing/
> subdirectory) still has this problem? It looks like a diffrent bug, but
> before we start hunting ghosts, I'd like to be sure.
>
> > "Hy\227\021\b", '' <repeats 192 times>...) at log.c:434
> > #2  0x08057c30 in passert_fail (pred_str=0x8119a90 "Hy\227\021\b", ''
> > <repeats 192 times>...,
> >    file_str=0x8119a90 "Hy\227\021\b", '' <repeats 192 times>...,
> > line_no=135371408) at log.c:606
> > #3  0x0807b3c4 in complete_state_transition (mdp=0x80edd6c,
> > result=STF_INLINE) at demux.c:2738
> > #4  0x080795f5 in process_packet (mdp=0x80edd6c) at demux.c:2352
> > #5  0x0807bcbc in comm_handle (ifp=0x8116500) at demux.c:1223
> > #6  0x0805d070 in call_server () at server.c:1166
> > #7  0x0805b0d1 in main (argc=12, argv=0xbfe62264) at plutomain.c:787
> >
> >
> > 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 :
>
> What was Matthias's patch?
>
> > Mar 5 10:12:52 tamerlane pluto[12459]: "faulty_connection" #10:
> responding
> > to Main Mode
> > Mar 5 10:12:52 tamerlane pluto[12459]: "faulty_connection" #10:
> > OAKLEY_DES_CBC is not supported. Attribute OAKLEY_ENCRYPTION_ALGORITHM
> > Mar 5 10:12:52 tamerlane pluto[12459]: "faulty_connection" #10:
> > OAKLEY_DES_CBC is not supported. Attribute OAKLEY_ENCRYPTION_ALGORITHM
> > Mar 5 10:12:52 tamerlane pluto[12459]: "faulty_connection" #10:
> transition
> > from state STATE_MAIN_R0 to state STATE_MAIN_R1
> > Mar 5 10:12:52 tamerlane pluto[12459]: "faulty_connection" #10:
> > STATE_MAIN_R1: sent MR1, expecting MI2
> > Mar 5 10:12:55 tamerlane pluto[12459]: "faulty_connection" #10:
> transition
> > from state STATE_MAIN_R1 to state STATE_MAIN_R2
> > Mar 5 10:12:55 tamerlane pluto[12459]: "faulty_connection" #10:
> > STATE_MAIN_R2: sent MR2, expecting MI3
> > Mar 5 10:13:10 tamerlane pluto[12459]: "faulty_connection" #10: Main
> mode
> > peer ID is ID_IPV4_ADDR: '222.126.123.139'
> > Mar 5 10:13:10 tamerlane pluto[12459]: "faulty_connection" #10: I did
> not
> > send a certificate because I do not have one.
> > Mar 5 10:13:10 tamerlane pluto[12459]: "faulty_connection" #10:
> transition
> > from state STATE_MAIN_R2 to state STATE_MAIN_R3
> > 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}
> > Mar 5 10:13:10 tamerlane pluto[12459]: "faulty_connection" #10: Dead
> Peer
> > Detection (RFC 3706): not enabled because peer did not advertise it
> > Mar 5 10:13:11 tamerlane pluto[12459]: "faulty_connection" #11: only
> > OAKLEY_GROUP_MODP1024 and OAKLEY_GROUP_MODP1536 supported for PFS
> > Mar 5 10:13:11 tamerlane pluto[12459]: "faulty_connection" #11: sending
> > encrypted notification BAD_PROPOSAL_SYNTAX to 222.126.123.139:500
>
> The other end is configured with 1des/3des and DH group1 (modp768) which
> are too
> weak and not supported per default on openswan. But of course, we
> shouldn't
> crash on this.
>
> > Switching off the PFS on both side make the tunnel works using either
> the
> > patched or not patched pluto binary.
>
> Yes, then you are not stuck on the remote's flawed proposal of modp768.
>
> I guess we didnt catch this because our automatic testing all uses the
> same
> pluto binary, so either both ends support or or both ends do not.
>
> Thanks for the report,
>
> Paul
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openswan.org/pipermail/users/attachments/20070307/98509387/attachment.html