[asterisk-bugs] [JIRA] (ASTERISK-24832) DTLS-crashes within openssl

[Rusty Newton (JIRA)]

    [ https://issues.asterisk.org/jira/browse/ASTERISK-24832?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=225551#comment-225551 ] 

Rusty Newton commented on ASTERISK-24832:
-----------------------------------------

bq. When i tried to add my patch to review board manually with https://reviewboard.asterisk.org/r/new/ it complained about the format of my patch Unable to parse diff revision header '2015-02-25 14:47:25.772839327 +0100'

Was the patch in unified diff format? It must be. 'svn diff' should get what you want, or otherwise :

{noformat}diff -u original/some_file.c modified/some_file.c > my_fancy_patch.diff{noformat}

bq. When i tried to use the other way with svn and rbt i didn't know what svn checkout command that would checkout the same source code as was tar'ed by (Havent used those tools before)
bq. wget http://downloads.asterisk.org/pub/telephony/asterisk/releases/asterisk-13.1.0.tar.gz

You should make your patch on the latest checkout of 13, not on the archived release files.

{noformat}
svn co http://svn.asterisk.org/svn/asterisk/branches/13 asterisk-13
{noformat}

That command would checkout the latest of the 13 branch to the 'asterisk-13' folder.

bq. Moreover, the wiki said that if the patch is not in a final form it should be documented as such but i saw no such field in the form in https://reviewboard.asterisk.org/r/new/

Just make a comment in the description field.

bq. Also what should be written in the Base Directory "The absolute path in the repository the diff was generated in." for me? The patch wasn't generated in a repository, just in an untarred asterisk source folder

If using the latest SVN revision of the 13 branch as instructed above, then 'branches/13/' should work if you generated the patch from the root of the Asterisk checkout. You could probably put the same thing if your patch was from the root of your unpacked Asterisk tarball for 13.

> DTLS-crashes within openssl 
> ----------------------------
>
>                 Key: ASTERISK-24832
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-24832
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Resources/res_rtp_asterisk
>    Affects Versions: 13.1.0
>         Environment: Fedora 20 x86_64, openssl-1.0.1e-41.fc20.x86_64, Asterisk 13.1.0, Chrome SIPML5 chan_sip peers with transport WSS
>            Reporter: Stefan Engström
>            Assignee: Rusty Newton
>         Attachments: crash1.txt, crash2.txt, crash3.txt, crash4.txt, crash5.extralog, crash5.txt, CUSTOMERRORDEBUGLOG, DTLSfailure6ErrorlogNocrashUsingNewPatch.txt, DTLSREVIEWMEcodecontribution.patch, DTLSREVIEWME.patch, SIPCONF.txt, TESTDTLS.patch
>
>
> I'm using 4 chan sip peers with transport WSS. They all use Chrome SIPml5 webrtc. 2 of them call a queue and the other 2 answer. Every 100-1000 calls or so, asterisk gets a crash due to segmentation fault or abort signal within openssl.
> Since it's load-related it's hard to provide enough information but ill try add more continuously.
> ISSUE-0
> First thing i noticed was  that dtls_perform_handshake was called too many times but that was fixed by compensating for ASTERISK-24830 
> By code inspection and tracing logs; it looks like the crashes mostly occur for dtls->ssl instances where asterisk has role: server, (SSL_set_accept_state(dtls->ssl) has been called.) 
> EDIT -- This JIRA is getting a little bigger. It seems there are many sub-problems which are all related to DTLS though... not all sub-issues below may be real issues, some are just me asking questions about code. I'd be happy if a developer took a look at it and answered questions or discussed some of the issues and possible fixes.
> ISSUE-1 - crash3 seems to prove a concurrency issue:
> thread 5 leaving asterisk code at dtls_perform_handshake is performing ssl3_clear on the same ssl struct as that which is sent to ssl_read from __rtp_recvfrom in thread 1
> ISSUE-2: Im curious about the behavior of ast_rtp_on_ice_complete() {
> ...
>         dtls_perform_handshake(instance, &rtp->dtls, 0);
>         if (rtp->rtcp) {
>                 dtls_perform_handshake(instance, &rtp->rtcp->dtls, 1);
>         }
> ...
> }
> chan_sip seems to call process_sdp which eventually calls res_asterisk_rtp::dtls_set_setup which ultimately sets SSL_set_connect_state(ssl) OR SSL_set_accept_state(ssl) on both (RTP+RTCP) ssl sessions. But this races with the firing of  dtls_perform_handshake(instance, &rtp->dtls, 0); from ast_rtp_on_ice_complete. I'm not sure if this is a problem but in my last crash crash4 the ast_ice_on_ice_complete fired before dtls_set_setup which i have never noticed during non-crash-calls,
> the big question is why is dtls_perform_handshake() called at all if we are passive? After I added a patch it doen't seem to crash anymore, but I'm pretty sure the patch is not a full fix -- note that the patches labeled test are just for the debugging process
> Possibly related to ASTERISK-24651
> Requires patch from ASTERISK-24711
> Requires patch from ASTERISK-24830  (the obvious fix of replacing USE_PJPROJECT WITH HAVE_PJPROJECT...)



--
This message was sent by Atlassian JIRA
(v6.2#6252)