[Home]

Summary:ASTERISK-16490: [patch] tcptls.c:350 Unable to connect SIP socket Connection refused
Reporter:Simon M (smallet)Labels:
Date Opened:2010-08-02 14:06:01Date Closed:2010-11-11 16:01:17.000-0600
Priority:CriticalRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/TCP-TLS
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) bug17779.patch
( 1) module.unload.crash
Description:Steps to reproduce:

<ol>
<li>Add a peer information as shown in graph 1 below in sip.conf.</li>
<li>do asterisk -r, then sip reload.</li>
<li>That server has connection refused so the asterisk debug will start complaining it can't connect to the server.</li>
<li>Do sip show peers, you will see the peer with a status of UNREACHABLE.</li>

So far so good...<br />

<li>Remove The whole graph 1 from your sip.conf file.</li>
<li>Do a sip reload again. the sip show peers will not show the peer anymore.</li>
<li>The connection refused will keep going on and on forever unless you actually restart asterisk completely.</li>
</ol>

Is there a way to bypass this or is this a bug?

[Aug  2 14:53:56] ERROR[13926]: tcptls.c:350 ast_tcptls_client_start: Unable to connect SIP socket to 192.168.0.228:5060: Connection refused
[Aug  2 14:54:10] ERROR[13997]: tcptls.c:350 ast_tcptls_client_start: Unable to connect SIP socket to 192.168.0.228:5060: Connection refused
[Aug  2 14:54:24] ERROR[14002]: tcptls.c:350 ast_tcptls_client_start: Unable to connect SIP socket to 192.168.0.228:5060: Connection refused
[Aug  2 14:54:38] ERROR[14011]: tcptls.c:350 ast_tcptls_client_start: Unable to connect SIP socket to 192.168.0.228:5060: Connection refused
[Aug  2 14:54:52] ERROR[14016]: tcptls.c:350 ast_tcptls_client_start: Unable to connect SIP socket to 192.168.0.228:5060: Connection refused
[Aug  2 14:55:06] ERROR[14089]: tcptls.c:350 ast_tcptls_client_start: Unable to connect SIP socket to 192.168.0.228:5060: Connection refused
[Aug  2 14:55:20] ERROR[14099]: tcptls.c:350 ast_tcptls_client_start: Unable to connect SIP socket to 192.168.0.228:5060: Connection refused

****** ADDITIONAL INFORMATION ******

Graph 1:
[192.168.0.228]
type = friend
host = 192.168.0.228
insecure = port,invite
disallow = all
allow = ulaw
context = gateway
transport = TCP
qualify = yes
Comments:By: Paul Belanger (pabelanger) 2010-08-03 09:01:14

I can confirm.  'sip show peers' is empty, but tcptls.c still generates errors.  Unloading the modules causes a core dump.  Up loading shortly.
By: Simon M (smallet) 2010-08-05 14:03:52

Now my question is this:
Does this mean any TCP connection always hang and is never closed properly for all calls? Or does this affect only SIP options?

You can see that if you change your IP address multiple times that it will try every 15 seconds to connect to each IP address forever.. It's kind of ugly :/.

I read there was a fix for TCP connections (memory leak) in 1.6.1.x branch but sadly it did not fix this error.

Also when do you think there will be a patch available to fix this?
Thanks.
By: Leif Madsen (lmadsen) 2010-08-05 15:15:56

A patch available to fix this would be based on the priority it gets assigned prior to our next sprint, and whether it gets assigned to a developer. Beyond that, it would either be up to the reporter or a community developer to take on this issue themselves to produce a patch.

No ETA can be given.
By: David Vossel (dvossel) 2010-08-18 10:58:27

I believe the problem here is with the qualify=yes option.  When the peer is removed from the config and a 'sip reload' is issued, the peer is removed from the peers table but the qualify scheduler item still contains a reference to that peer for some reason.
By: Jeff Peeler (jpeeler) 2010-10-08 15:28:22

I haven't been able to reproduce the connection failures to continue forever. The attached patch does stop them immediately though after the removal of the peer after a sip reload.
By: Simon M (smallet) 2010-10-08 15:34:32

Thank you for the quick response on this! I will try it on Monday and see if it works for me.
I will then let you know.
Thanks.
By: Jeff Peeler (jpeeler) 2010-10-11 16:15:54

And the result was? Just giving you a reminder in case you forgot.
By: Simon M (smallet) 2010-10-12 15:32:59

Sorry! Monday was an Holiday and Tuesday (today) I was busy on other projects, will do it tomorrow morning first thing, promised ;p
By: Simon M (smallet) 2010-10-13 09:48:20

Ok, so before applying the patch I could reproduce the issue. See how .13 and .14 both trigger errors but in my peer conf file I just have .14 defined.

[Oct 13 10:09:53] ERROR[4308]: tcptls.c:350 ast_tcptls_client_start: Unable to connect SIP socket to 192.168.0.14:5060: No route to host
[Oct 13 10:09:54] NOTICE[3118]: chan_sip.c:23322 sip_poke_noanswer: Peer '192.168.0.14' is now UNREACHABLE!  Last qualify: 0
[Oct 13 10:10:00] ERROR[4309]: tcptls.c:350 ast_tcptls_client_start: Unable to connect SIP socket to 192.168.0.13:5060: Connection refused
[Oct 13 10:10:07] ERROR[4360]: tcptls.c:350 ast_tcptls_client_start: Unable to connect SIP socket to 192.168.0.14:5060: No route to host
[Oct 13 10:10:14] ERROR[4365]: tcptls.c:350 ast_tcptls_client_start: Unable to connect SIP socket to 192.168.0.13:5060: Connection refused

After applying the patch, I did the same steps, and now I see errors only coming from the Peer that is defined in the conf file. The other warnings have disappeared.

The patch works!
By: Jeff Peeler (jpeeler) 2010-10-13 11:37:32

Thanks for reporting back, this will be fixed when another related issue is completed.
By: Digium Subversion (svnbot) 2010-11-11 15:57:32.000-0600

Repository: asterisk
Revision: 294733

_U  branches/1.6.2/
U   branches/1.6.2/channels/chan_sip.c

------------------------------------------------------------------------
r294733 | jpeeler | 2010-11-11 15:57:22 -0600 (Thu, 11 Nov 2010) | 25 lines

Merged revisions 294688 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

........
 r294688 | jpeeler | 2010-11-11 15:12:27 -0600 (Thu, 11 Nov 2010) | 18 lines
 
 Fix problem with qualify option packets for realtime peers never stopping.
 
 The option packets not only never stopped, but if a realtime peer was not in
 the peer list multiple options dialogs could accumulate over time. This
 scenario has the potential to progress to the point of saturating a link just
 from options packets. The fix was to ensure that the poke scheduler checks to
 see if a peer is in the peer list before continuing to poke. The reason a peer
 must be in the peer list to be able to properly manage an options dialog is
 because otherwise the call pointer is lost when the peer is regenerated from
 the database, which is how existing qualify dialogs are detected.
 
 (closes issue ASTERISK-14500)
 (closes issue ASTERISK-16490)
 Reported by: lftsy
 Patches:
       bug16382-3.patch uploaded by jpeeler (license 325)
 Tested by: zerohalo
........

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=294733
By: Digium Subversion (svnbot) 2010-11-11 15:58:36.000-0600

Repository: asterisk
Revision: 294734

_U  branches/1.8/
U   branches/1.8/channels/chan_sip.c

------------------------------------------------------------------------
r294734 | jpeeler | 2010-11-11 15:58:26 -0600 (Thu, 11 Nov 2010) | 32 lines

Merged revisions 294733 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2

................
 r294733 | jpeeler | 2010-11-11 15:57:22 -0600 (Thu, 11 Nov 2010) | 25 lines
 
 Merged revisions 294688 via svnmerge from
 https://origsvn.digium.com/svn/asterisk/branches/1.4
 
 ........
   r294688 | jpeeler | 2010-11-11 15:12:27 -0600 (Thu, 11 Nov 2010) | 18 lines
   
   Fix problem with qualify option packets for realtime peers never stopping.
   
   The option packets not only never stopped, but if a realtime peer was not in
   the peer list multiple options dialogs could accumulate over time. This
   scenario has the potential to progress to the point of saturating a link just
   from options packets. The fix was to ensure that the poke scheduler checks to
   see if a peer is in the peer list before continuing to poke. The reason a peer
   must be in the peer list to be able to properly manage an options dialog is
   because otherwise the call pointer is lost when the peer is regenerated from
   the database, which is how existing qualify dialogs are detected.
   
   (closes issue ASTERISK-14500)
   (closes issue ASTERISK-16490)
   Reported by: lftsy
   Patches:
         bug16382-3.patch uploaded by jpeeler (license 325)
   Tested by: zerohalo
 ........
................

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=294734
By: Digium Subversion (svnbot) 2010-11-11 16:01:14.000-0600

Repository: asterisk
Revision: 294735

_U  trunk/
U   trunk/channels/chan_sip.c

------------------------------------------------------------------------
r294735 | jpeeler | 2010-11-11 16:01:03 -0600 (Thu, 11 Nov 2010) | 39 lines

Merged revisions 294734 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8

................
 r294734 | jpeeler | 2010-11-11 15:58:25 -0600 (Thu, 11 Nov 2010) | 32 lines
 
 Merged revisions 294733 via svnmerge from
 https://origsvn.digium.com/svn/asterisk/branches/1.6.2
 
 ................
   r294733 | jpeeler | 2010-11-11 15:57:22 -0600 (Thu, 11 Nov 2010) | 25 lines
   
   Merged revisions 294688 via svnmerge from
   https://origsvn.digium.com/svn/asterisk/branches/1.4
   
   ........
     r294688 | jpeeler | 2010-11-11 15:12:27 -0600 (Thu, 11 Nov 2010) | 18 lines
     
     Fix problem with qualify option packets for realtime peers never stopping.
     
     The option packets not only never stopped, but if a realtime peer was not in
     the peer list multiple options dialogs could accumulate over time. This
     scenario has the potential to progress to the point of saturating a link just
     from options packets. The fix was to ensure that the poke scheduler checks to
     see if a peer is in the peer list before continuing to poke. The reason a peer
     must be in the peer list to be able to properly manage an options dialog is
     because otherwise the call pointer is lost when the peer is regenerated from
     the database, which is how existing qualify dialogs are detected.
     
     (closes issue ASTERISK-14500)
     (closes issue ASTERISK-16490)
     Reported by: lftsy
     Patches:
           bug16382-3.patch uploaded by jpeeler (license 325)
     Tested by: zerohalo
   ........
 ................
................

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=294735