[asterisk-bugs] [Asterisk 0019289]: [patch] ast_tcptls_server_start fails second attempt to bind

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=19289 
====================================================================== 
Reported By:                wdoekes
Assigned To:                dvossel
====================================================================== 
Project:                    Asterisk
Issue ID:                   19289
Category:                   Core/Netsock
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     assigned
Target Version:             1.4/1.6.2 Issues (Final Release)
Asterisk Version:           1.6.2.17.3 
JIRA:                       SWP-3465 
Regression:                 No 
Reviewboard Link:            
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Request Review:              
====================================================================== 
Date Submitted:             2011-05-13 07:14 CDT
Last Modified:              2011-05-22 09:18 CDT
====================================================================== 
Summary:                    [patch] ast_tcptls_server_start fails second attempt
to bind
Description: 
Hi,

just now I had to kill -9 asterisk in a nightly job because of a deadlock.
(Infinite trylock restart situation to be exact.) I suspected
init.d/asterisk stop wouldn't complete and I was right.. kill -9 solved
that.

But, unfortunately, it looked like SO_REUSEADDR didn't do its job
properlywhen immediately starting asterisk after that. (I don't know how
that is possible, but it was.) I missed out on my two TCP listening
sockets: manager at 5038 and tcp sip at 5060.

This is when I found out that doing 'manager reload' or 'sip reload'
manually at a later point in time doesn't work.

Why is that? Because the ast_tcptls_server_start() thinks that "nothing
has changed".
====================================================================== 

---------------------------------------------------------------------- 
 (0135227) wdoekes (reporter) - 2011-05-22 09:18
 https://issues.asterisk.org/view.php?id=19289#c135227 
---------------------------------------------------------------------- 
18:42 <@The_Boy_Wonder> wdoekes2: issue
https://issues.asterisk.org/view.php?id=19289  does it look like my change
will work?
22:56 < wdoekes2> The_Boy_Wonder: for my particular case it would work
indeed (failure on bind). if you would manage to get an error on the
earlier socket call, it wouldn't. (I don't know if there are common socket
errors, apart from running out of fd's)
23:11 <@The_Boy_Wonder> wdoekes2: ah alright. We'll go with your version
23:34 < wdoekes2> The_Boy_Wonder: we might want to add a desc->master =
AST_PTHREADT_NULL after the if().. otherwise that code could be run several
times and I'm not sure if it's wise to pthread_join() a thread that is
already gone
23:35 < wdoekes2> or does someone else clear ->master?
23:41 <@The_Boy_Wonder> no clue


Ok. I checked, and no one clears ->master, but they should. In the
unpatched version, you can pthread_cancel a thread multiple times by
binding to (configuring) different used ports after it was bound to a valid
one once. In the patched version, it's even easier, but the problem already
existed.

Adding a desc->master = AST_PTHREADT_NULL solves this. (It probably works
fine without, until that one moment when you actually do have a valid
thread handle by accident and you shoot down a completely wrong thread.
Note that there are other places in the source with a similar lack of
AST_PTHREADT_NULL setting.)

New patch (issue19289_delay_old_address_setting_tcptls_2.patch) is against
trunk, btw. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2011-05-22 09:18 wdoekes        Note Added: 0135227                          
======================================================================