Summary:	ASTERISK-20221: seg fault when register via websocket
Reporter:	Sven Beisiegel (sven.beisiegel@siemens-enterprise.com)	Labels:
Date Opened:	2012-08-13 05:01:14	Date Closed:	2012-08-15 15:44:07
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Channels/chan_sip/WebSocket
Versions:	11.0.0-beta1	Frequency of Occurrence	Constant
Related Issues:
Environment:	debian wheezy: Linux debian 3.2.0-3-686-pae running in a virtual machine	Attachments:	( 0) asterisk-20221-ws-family-filter.diff ( 1) crash_when_register_via_websocket.txt ( 2) james_output.txt
Description:	Asterisk has been compiled with option "--disable-asteriskssl", "DON'T OPTIMIZE"-Flag and "BETTER_BACKTRACES"-Flag A default configuration has been created with "make samples" The default configuration has been adjusted like in the three files below (link to pastbin) httpd.conf: http://pastebin.com/UMmkJqxt extensions.conf: http://pastebin.com/kKa4Mqvi sip.conf: http://pastebin.com/JysvnpS8 The following scenario crashes Asterisk every time: - Register with user 100 or 101 with correct credentials for digest authentication. For registration via websockets, two clients have been used. 1) SIPML5, 2.) SIP-JS (http://code.google.com/p/sip-js) The following does not crash Asterisk at all: - Use a wrong user-id or password for digest authentication, Asterisk tells me that digest credentials are wrong (403 Forbidden - Auth) - Try to register with user credentials where the user is not configured for registration via websockets, Asterisk sends a forbidden as well. The backtrace can be found at pastebin: http://pastebin.com/bhy3RjgC best regards, Sven
Comments:	By: Matt Jordan (mjordan) 2012-08-13 07:58:59.677-0500 FYI: I've attached your backtrace as a text file on this issue. By: Michael L. Young (elguero) 2012-08-14 10:36:52.002-0500 Give this patch a try. With the addition of websockets, the helper function in chan_sip for dns resolution by address family did not recognize the websockets transport type and then sent a null pointer to functions used to determine if we are bound to ANY address ([::]) or not.  This appears to be the cause of this segfault based on the backtrace. By: Sven Beisiegel (sven.beisiegel@siemens-enterprise.com) 2012-08-14 11:33:15.404-0500 This change seems to fix the issue... Asterisk no longer crashes in the described scenario. By: James Mortensen (james.mortensen) 2012-08-14 12:29:22.427-0500 I'm the person who reported the issue on the mailing list, and the patch did not fix the issue. Asterisk is still crashing. I've included more information in the mailing list although it may take a moment for this page to actually update:  http://www.mail-archive.com/asterisk-users@lists.digium.com/msg265621.html Please let me know what additional information I can provide. Thank you!  James By: James Mortensen (james.mortensen) 2012-08-14 12:46:07.112-0500 This is what I see in the terminal when trying to "Login" from the SIP client. Note at the end where the server crashes. Also, note the 401 Unauthorized response to my login attempt.  (See "james_output.txt") By: Michael L. Young (elguero) 2012-08-14 12:53:10.470-0500 James, thanks for the extra info.  I hadn't seen that thread on the mailing list. What we need is a backtrace[1] from the core file produced after the crash.  Also, be sure you have DONT_OPTIMIZE enabled in menuselect within the Compiler Flags section, then: make install After enabling, reproduce the crash, and then execute the backtrace[1] instructions. When complete, attach that file to this issue report. [1] https://wiki.asterisk.org/wiki/display/AST/Getting+a+Backtrace By: James Mortensen (james.mortensen) 2012-08-14 15:12:55.425-0500 Hi Michael, I apologize. It looks like the patch did fix the crash. I had two instances of Asterisk running, discovered after running "ps -C asterisk u".  One must have been the previous instance, before applying the patch and recompiling.   While the server isn't crashing anymore, I'm still getting the 400 Bad Request and the 401 Unauthorized when trying to login.  From what I hear, this could be something that needs to be modified in the sipML5 library itself. Thus, I'll see what I can find. If anyone knows why I'm getting the unauthorized and bad requests, please let me know.  I'll update the mailing list as well. Thanks again! James By: Matt Jordan (mjordan) 2012-08-14 17:36:31.897-0500 Michael - thanks for jumping on this so quickly.  If you'd like to commit that patch to 11/trunk, it looks good to go. By: Michael L. Young (elguero) 2012-08-14 20:59:47.904-0500 Matt - no problem.  I am sending an email to Jason.  I tried to commit to branch 11 and I am getting access forbidden from SVN.