Hello, I can't compile asterisk13 with libressl-devel 2.5.3 but I guess the problem appeared with asterisk13 13.15.0. The error I'm getting is: tcptls.o: In function `tcptls_stream_close': tcptls.c:(.text+0x2be6): undefined reference to `SSL_is_server' c++: error: linker command failed with exit code 1 (use -v to see invocation) gmake[2]: *** [Makefile:333: asterisk] Error 1 The bug may have appeared because of some changes regarding OpenSSL 1.1.0 support: https://github.com/asterisk/asterisk/commit/2c8d0764de87037ce52656e13b36de5d9876aeaa#diff-54de6d3af0677bc949151c2d9a9b3d91 I've found some patches from OpenBSD: https://github.com/openbsd/ports/tree/master/telephony/asterisk/patches I'll try "patch-main_libasteriskssl_c" and "patch-main_tcptls_c" and I'll report back. Best Regards, Olivier
Well, I've been able to successfully compile asterisk13 with libressl-devel 2.5.3 by adding this two patches: https://github.com/openbsd/ports/blob/master/telephony/asterisk/patches/patch-main_libasteriskssl_c https://github.com/openbsd/ports/blob/master/telephony/asterisk/patches/patch-main_tcptls_c Asterisk seems to work but after the end of a call, it crashes. I've reinstalled a previous version of asterisk13 (13.14.0) and libressl-devel 2.5.2 and I've the same behavior… I'm trying to investigate why it does crash.
I'm not using libressl so I can't reproduce this right away. The libressl port was updated to 2.5.3 yesterday. Was the problem present before this update? Could you test with the old libressl library? Also, are you using poudriere(or other similar tools) built packages or building from ports? Asterisk has many dependencies and various modules, which depend on various parts from other ports. When using ssl I've noticed crashes are often cause by different asterisk parts ending up linked to multiple SSL libraries. I also have seen other misalignments. You should check the "lld" output for asterisk and each asterisk module you're loading and make sure they are all linking with the correct ssl library and ONLY that one. Beware of indirect linking. For example I happened to have it crashing because the main executable was linked with base OpenSSl, while the curl module was indirectly linked to ports provided OpenSSL library, due to libcurl.so being linked with that. The above example isn't your case but you could have some similar issue on your system, which could be fixed by recompiling/reinstalling the required ports/pkgs so that every relevant part is linked correctly. Please look at the 20150323 UPDATING entry about a similar problem. This obviously does not exclude some asterisk bug, not a libressl bug.
(In reply to Guido Falsi from comment #2) > This obviously does not exclude some asterisk bug, not a libressl bug. s/not a libressl/nor a libressl/
Hello Guido and thanks for your help! Until today, I was using asterisk13 13.14.0 with pjsip 2.6 and libressl-devel 2.5.2 and it was working perfectly. I've tried to recompile several previous versions of asterisk13, pjsip and libressl-devel without success : asterisk always crash at the end of a SIP call, without any log. I've also tried to recompile asterisk13 and pjsip with OpenSSL from base: still crash. But, you may have found the problem: I haven't recompiled curl with OpenSSL from base, so it's still using LibreSSL 2.5.x. I've checked with LDD and I've a mix of "libssl.so.43 => /usr/local/lib/libssl.so.43 (0x8016ed000)" and "libssl.so.8 => /usr/lib/libssl.so.8 (0x80122b000)" Yes, I'm building packages with poudriere. So, I'll rebuild everything with OpenSSL from base, uninstall LibreSSL and reinstall every packages, just to be sure there's no OpenSSL/LibreSSL mixing. It's late here in France, so I'll probably won't have time to test until tomorrow evening. Best Regards.
I'm From Italy, so I'm on the same TZ as you. Please let me know if your tests will work. I'm available but I'm having a short vacation, so I could take a little time to notice your feedback here.
BTW I'm testing the patches you pointed me to, they are anyway useful. Thanks!
Hello, I really don't understand what's happening. I've rebuilt all of my package with OpenSSL from base and also asterisk13 13.13.1_1 and pjsip 2.5.5_2 ("old" versions I had working in the past). I've uninstalled every packages, rebooted and installed the new packages I had just rebuilt and... it continues to crash :-( Now I'll uninstall again my packages and will install asterisk13 from FreeBSD repository, not mine. I'll report back later. BTW: I'm running FreeBSD 11.0-RELEASE-p9, with the two updates from yesterday: https://www.freebsd.org/security/advisories/FreeBSD-SA-17:03.ntp.asc https://www.freebsd.org/security/advisories/FreeBSD-EN-17:05.xen.asc
With every packages from FreeBSD ports, it doesn't crash anymore! :-D (with asterisk13 13.15.0, pjsip 2.6, mysql-client 5.6) Well, now I have to find out what makes it crash when I compile myself... I have, since about forever, this options for asterisk13: net_asterisk13_UNSET+=DAHDI net_asterisk13_UNSET+=LUA net_asterisk13_UNSET+=MYSQL net_asterisk13_SET+=G729 net_asterisk13_SET+=BASE net_asterisk13_UNSET+=GCC net_asterisk13_UNSET+=SRTP net_asterisk13_UNSET+=FREETDS net_asterisk13_UNSET+=LDAP net_asterisk13_UNSET+=RADIUS net_asterisk13_UNSET+=NEWG711 net_asterisk13_SET+=ODBC net_asterisk13_UNSET+=PGSQL net_asterisk13_UNSET+=SQLITE2 And for pjsip: net_pjsip_SET+=G711 net_pjsip_SET+=G722 net_pjsip_SET+=G7221 net_pjsip_SET+=GSM net_pjsip_SET+=ILBC net_pjsip_SET+=IPV6 net_pjsip_SET+=L16 net_pjsip_SET+=OPENH264 net_pjsip_SET+=VIDEO I'm connecting to my database with ODBC and MariaDB 10.1 client. So I plan to test with CDR disabled. PS: I'm not sure it's appropriate that I continue posting here, because my crash isn't related to this PR and now seems coming from something "unique" of my setup.
(In reply to OlivierW from comment #8) > > I'm connecting to my database with ODBC and MariaDB 10.1 client. So I plan > to test with CDR disabled. I've observed that ODBC in asterisk can be a cause of instability. That is ODBC problems can trigger asterisk crashes. You should make sure the ODBC module, library and the backend DB are each at a version tested to be compatible with each other. You should make sure you recompile the whole chain (Database software, ODBC base library, ODBC module for your DB and asterisk) to avoid any misalignment.
Yes, since I'm using Asterisk on FreeBSD, I've always built it with MariaDB client 10.x, unixODBC, mysql-connector-odbc-unixodbc-mysql101m, and probably others dependencies. I just can't understand why just now it start to crash. It was working so well before. Now I'm 100% sure it's related to ODBC with MariaDB because if I set "enable=no" in "/usr/local/etc/asterisk/cdr.conf", I don't have the crash anymore. Tested with asterisk 13.13.1_1 + pjsip 2.5.5_2 and asterisk 13.15.0 + pjsip 2.6. I'll try to downgrade mariadb101-client to 10.1.21, as I'm not sure I was previously using 10.1.22. But it looks like it won't be fun to debug :-(
Well, the bug isn't in Asterisk at all, just ODBC + MariaDB 10.1.22. To test, I just have to run: "odbcinst -s -q" to get my ODBC source ("MySQL-asterisk" in my case). Then: "isql -v MySQL-asterisk". With MariaDB 10.1.21, I'm getting a successful: "+---------------------------------------+ | Connected! | | | | sql-statement | | help [tablename] | | quit | | | +---------------------------------------+ SQL>" With MariaDB 10.1.22, I'm getting an error: /usr/local/lib/libmyodbc5w.so: Undefined symbol "strmov" For each of my tests, I've rebuilt and reinstalled unixODBC mariadb101-client mysql-connector-odbc mariadb101-server. I'll continue to investigate more and I'll open a PR where it's needed (so, not asterisk13 port :-) )
Sorry for all the off-topic noise… I think I've found the bug, at least the one which break the "isql" command line tool. mysql-connector-odbc 5.3.4 isn't compatible with recent versions of MariaDB and MySQL, more informations here: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218645 Guido, while searching about this bug, I found out OpenBSD was using "iodbc" instead of "unixodbc": https://github.com/openbsd/ports/blob/master/telephony/asterisk/Makefile#L189-L196 I don't know if it would be a good idea to do the same for FreeBSD? Or maybe leave the choice to users? Best Regards, Olivier
(In reply to OlivierW from comment #12) > Sorry for all the off-topic noise… > > I think I've found the bug, at least the one which break the "isql" command > line tool. > mysql-connector-odbc 5.3.4 isn't compatible with recent versions of MariaDB > and MySQL, more informations here: > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218645 > > Guido, while searching about this bug, I found out OpenBSD was using "iodbc" > instead of "unixodbc": > https://github.com/openbsd/ports/blob/master/telephony/asterisk/ > Makefile#L189-L196 > > I don't know if it would be a good idea to do the same for FreeBSD? Or maybe > leave the choice to users? > Asterisk has options for both unixodbc and iodbc, so I'd rather add a "SINGLE" option and let the user choose, leaving the default at unixodbc for historical reasons. Maybe it could even not be a "SINGLE", I don't know if asterisk can have support for both simultaneously, I'll need to investigate. I'll put adding a iodbc option on my TODO list. Does not look too hard to do. Thanks for the suggestion!
A commit references this bug: Author: madpilot Date: Sun Apr 16 07:45:33 UTC 2017 New revision: 438620 URL: https://svnweb.freebsd.org/changeset/ports/438620 Log: - Add patches to fix build with LibreSSL [1] - Add dependencies and new SHEBANG_FILE to per stage-qa warnings - Stop istalling python script to avoid stage-qa error about wrong python shabang(adding a python dependency just for a contributed python script seems overkill) PR: 218599 [1] Submitted by: OlivierW <olivierw1+bugzilla-freebsd@hotmail.com> Obtained from: https://cvsweb.openbsd.org/cgi-bin/cvsweb/ports/telephony/asterisk/patches/ [1] Changes: head/net/asterisk13/Makefile head/net/asterisk13/files/patch-contrib_Makefile head/net/asterisk13/files/patch-main_libasteriskssl.c head/net/asterisk13/files/patch-main_tcptls.c head/net/asterisk13/pkg-plist
I added the patches you suggested to fix the build with libressl. I'm closing this PR, The iODBC option requires a little time for proper testing, but is really unrelated with the problem reported here. Thanks!
A commit references this bug: Author: madpilot Date: Sun May 21 09:02:23 UTC 2017 New revision: 441360 URL: https://svnweb.freebsd.org/changeset/ports/441360 Log: MFH: r437954 r438620 r441292 Update net/asterisk13 to 13.15.0. - Add patches to fix build with LibreSSL [1] - Add dependencies and new SHEBANG_FILE to per stage-qa warnings - Stop istalling python script to avoid stage-qa error about wrong python shabang(adding a python dependency just for a contributed python script seems overkill) PR: 218599 [1] Submitted by: OlivierW <olivierw1+bugzilla-freebsd@hotmail.com> Obtained from: https://cvsweb.openbsd.org/cgi-bin/cvsweb/ports/telephony/asterisk/patches/ [1] - Update net/asterisk13 to 13.15.1 - Import patches to fix security issues in net/pjsip [1] - While here regenerate net/pjsip patches Obtained from: Asterisk 13.15.1 distribution file [1] Security: 0537afa3-3ce0-11e7-bf9d-001999f8d30b Security: fab87bff-3ce5-11e7-bf9d-001999f8d30b Approved by: ports-secteam (miwi) Changes: _U branches/2017Q2/ branches/2017Q2/net/asterisk13/Makefile branches/2017Q2/net/asterisk13/distinfo branches/2017Q2/net/asterisk13/files/patch-contrib_Makefile branches/2017Q2/net/asterisk13/files/patch-main__Makefile branches/2017Q2/net/asterisk13/files/patch-main_libasteriskssl.c branches/2017Q2/net/asterisk13/files/patch-main_tcptls.c branches/2017Q2/net/asterisk13/pkg-plist branches/2017Q2/net/pjsip/Makefile branches/2017Q2/net/pjsip/files/patch-aconfigure branches/2017Q2/net/pjsip/files/patch-build.mak.in branches/2017Q2/net/pjsip/files/patch-pjlib_src_pj_ssl__sock__ossl.c branches/2017Q2/net/pjsip/files/patch-pjmedia_build_os-auto.mak.in branches/2017Q2/net/pjsip/files/patch-pjsip_src_pjsip_sip__multipart.c branches/2017Q2/net/pjsip/files/patch-pjsip_src_pjsip_sip__transaction.c branches/2017Q2/net/pjsip/files/patch-third__party_build_os-auto.mak.in