[asterisk-bugs] [JIRA] (ASTERISK-28765) tcptls API: bad file descriptor when connection fails

[Kevin Harwell (JIRA)]

    [ https://issues.asterisk.org/jira/browse/ASTERISK-28765?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=249882#comment-249882 ] 

Kevin Harwell commented on ASTERISK-28765:
------------------------------------------

Yep, trying to close it twice. It appears when creating the client both the tcptls session and underlying stream take "ownership" of the socket. See [here|https://github.com/asterisk/asterisk/blob/master/main/tcptls.c#L638] in _ast_tcptls_client_create_:
{noformat}
fd = desc->accept_fd = socket(ast_sockaddr_is_ipv6(&desc->remote_address) ?
				      AF_INET6 : AF_INET, SOCK_STREAM, IPPROTO_TCP);
{noformat}
And then a [bit further down|https://github.com/asterisk/asterisk/blob/master/main/tcptls.c#L670] when the stream is created:
{noformat}
tcptls_session->stream = ast_iostream_from_fd(&fd);
{noformat}
[_ast_iostream_from_fd_|https://github.com/asterisk/asterisk/blob/master/main/iostream.c#L604] copies the file descriptor, and resets the given one. However the given one is a pointer to a stack variable and not the one "owned" by the parent session:
{noformat}
	if (stream) {
		stream->timeout = -1;
		stream->timeout_reset = -1;
		stream->fd = *fd;
		*fd = -1;
	}
{noformat}
It might be all one has to do is pass in the parent file descriptor when creating the stream instead, but further investigation needs to be done into the possible side effects of doing that.

> tcptls API: bad file descriptor when connection fails
> -----------------------------------------------------
>
>                 Key: ASTERISK-28765
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-28765
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Applications/app_externalivr, Channels/chan_sip/TCP-TLS
>    Affects Versions: 16.3.0
>            Reporter: Jean Aunis - Prescom
>
> When trying to connect to an ExternalIVR() which is not started, a "Bad file descriptor" error is reported.
> Excerpt from the logs:
> {code}
>  -- Executing [2000 at default:1] ExternalIVR("Local/2000 at default-00000000;2", "ivr://127.0.0.1") in new stack
>     -- Called 2000 at default
>        > ExternalIVR received application and arguments: ivr://127.0.0.1
>        > ExternalIVR received options: (null)
>        > Parsing options from: [(null)]
>     -- Answering channel and starting generator
>     -- Local/2000 at default-00000000;1 answered
>        > Launching Wait(1000) on Local/2000 at default-00000000;1
> [Mar  3 11:58:57] ERROR[16427][C-00000001]: tcptls.c:553 ast_tcptls_client_start: Unable to connect IVR to 127.0.0.1:2949: Connection refused
> [Mar  3 11:58:57] ERROR[16427][C-00000001]: iostream.c:569 ast_iostream_close: close() failed: Bad file descriptor
> [Mar  3 11:58:57] ERROR[16427][C-00000001]: app_externalivr.c:529 app_exec: Local/2000 at default-00000000;2: Could not connect to any host.  ExternalIVR failed.
> {code}
> A similar issue happens when using chan_sip with TCP transport.
> It seems that ast_tcptls_client_start closes twice the same file descriptor.
> It can randomly affect Asterisk stability if the same file descriptor is reused in the meantime.



--
This message was sent by Atlassian JIRA
(v6.2#6252)