[OpenSIPS-Devel] [ opensips-Bugs-3552688 ] opensips crash with TLS

SourceForge.net noreply at sourceforge.net
Wed Aug 29 15:25:11 CEST 2012

Bugs item #3552688, was opened at 2012-07-31 09:28
Message generated for change (Comment added) made by dragosoancea
You can respond by visiting: 

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: core
Group: 1.7.x
Status: Open
Resolution: Accepted
Priority: 5
Private: No
Submitted By: Dragos Oancea (dragosoancea)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: opensips crash with TLS 

Initial Comment:

Hi all,

opensips 1.7.2 crashes when using  TLS with create_dialog("Pp")  in the routing script -  that would send OPTIONS (nat ping) both to caller and callee during a dialog . 

The TLS-related relevant lines in the routing script are: 

tls_verify_server = 1
tls_verify_client = 0
tls_require_client_certificate = 0
tls_method = TLSv1
tls_certificate = "/etc/pki/CA/certs/x.crt"
tls_private_key = "/etc/pki/CA/private/x.key"
tls_ca_list = "/etc/pki/CA/certs/ca.crt"

listen = tls:X.X.X.X:5061
listen = tcp:X.X.X.X:5060




Apparently it crashes just after trying to send an OPTIONS or BYE to a device that is not there anymore (it's not on the socket opensips expects it to be - opensips
usually generates a "477 SendFailed" reply in situations like this) .

and interesting enough, if I add an udp port to listen to with "listen=udp:X.X.X.X:5060" does not crash anymore.



>Comment By: Dragos Oancea (dragosoancea)
Date: 2012-08-29 06:25


It happened again. This time I had only two phones registered via TLS and I
was just making a call between them.


log (stderr):

can someone confirm it is related to 3522861 ? 



Comment By: Dragos Oancea (dragosoancea)
Date: 2012-08-16 04:00


I think there is only one problem.
so because the OPTIONS is sent to the wrong interface , no reply will come
back , and opensips will generate and send a BYE bothways. but in my case
everything is running fine..with OPTIONS being sent to the right places at
first , then something happends (memory corruption) , and maybe the
function that does the pinging is first to access some unallocated memory.
The crash could also happen when the callee or the caller sends  BYE.

Some extra informations: 

There are mobile devices under NAT running on TCP or  TLS involved in this
whole scenario. So when the mobile device is not there anymore (it ran out
of battery durring a call for example) , the crash is most likely to
Also , I noticed that there is no problem if I only listen to tls (not
listening on tcp, not listening on udp).
But I need tcp , so I cannot disable it.

another gdb backtrace :


I hope to replicate this in a controlled environment with memlog/memdump
soon and let you.


Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2012-08-15 06:16

Probably related to 3522861


Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2012-08-08 08:55


I see here 2 issues - one is the crash itself (which seems to be a memory
corruption) ; second one is related to pinging, which seems not to choose
the right interface (selects a UDP one instead TLS).

I suggest first trying to identify the mem issue, and for this you need to
recompile with memory debugging support
(http://www.opensips.org/Resources/DocsTsMem , set memlog=6, memdump=1) .
most probably the interface issues  triggers some bogus mem ops..



You can respond by visiting: 

More information about the Devel mailing list