[asterisk-bugs] [JIRA] (ASTERISK-26865) chan_iax2: Reload of iax peer results in loss of host address/port

[Friendly Automation (JIRA)]

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

Friendly Automation commented on ASTERISK-26865:
------------------------------------------------

Change 5204 merged by zuul:
chan_iax2: Reload of iax peer results in loss of host address/port

[https://gerrit.asterisk.org/5204|https://gerrit.asterisk.org/5204]

> chan_iax2: Reload of iax peer results in loss of host address/port
> ------------------------------------------------------------------
>
>                 Key: ASTERISK-26865
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-26865
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Channels/chan_iax2
>    Affects Versions: 13.14.0
>            Reporter: Richard Begg
>         Attachments: iax_reload.patch
>
>
> When reloading the config containing an IAX peer with a destination hostname (rather than IP address), the target address/and port are invalidated resulting in the peer becoming unreachable.
> This is accompanied by errors like this:
> ERROR[734] netsock2.c: Unknown address family '0'.
> ERROR[734] netsock2.c: getnameinfo(): ai_family not supported
> Looking at the code, line 12931 in chan_iax2.c appears to be the cause:
> peer->addr.ss.ss_family = AST_AF_UNSPEC;
> In short, the peer address is being invalidated on the assumption that the subsequent ast_dnsmgr_lookup() call will restore it.  However, if dnsmgr is enabled - then this doesn't happen, as the ast_dnsmgr_lookup() just returns without updating the ast_sockaddr structure if the hostname hasn't changed.  
> I'm not sure whether this is the correct behaviour or not if dnsmgr is not enabled, but it certainly doesn't seem to be if it is.
> Attached is a proposed patch to force a refresh of the dnsmgr entry (if there is one) instead.



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