[asterisk-bugs] [JIRA] (ASTERISK-18827) iax2 peer/trunk unreachable

[Alec Davis (JIRA)]

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

Alec Davis commented on ASTERISK-18827:
---------------------------------------

Added reviewboard link https://reviewboard.asterisk.org/r/2427/

The review will fix startup that will prevent network messages to enter before all iax helper threads were ready.

The helper thread is required to be sleeping before any messages arrive, expecting to be woken up by the network thread.

 

                
> iax2 peer/trunk unreachable 
> ----------------------------
>
>                 Key: ASTERISK-18827
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-18827
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Channels/chan_iax2
>    Affects Versions: 1.8.7.0
>         Environment: opensuse 11.4 virtual machine on esxi 4.1
>            Reporter: andrea lanza
>         Attachments: iax_18827.diff2.txt, iax_18827.diff.txt
>
>
> After upgrading vm to opensuse 11.4 and asterisk 1.8.x (tested 1.8.5; 1.8.7.1) iax2 peer/trunk becomes unreachable from virtual to physial; no problem on the wayback (phys to virt); rolling back to asterisk 1.6.20 link is again OK. 
> Debugging with tcpdump on the virtual machine, shows virtual sending POKE messages to physical peer; peer answers PONG which is received by the vm; vm anyway doesn't send ACK, probably meaning PONG in not "undestood" by chan_iax; changing the port of the link back, or changing the ip address (i.e: the two servers have 2 network cards in 2 different nets; link phys to virt is done on the first net; link back virt to phys on the other net) solves the problem.
> No changes setting trunk=yes or no
> No problems seems to exists on physical machines-pairs (link-trunk between physical machines) having the same os/asterisk versions of the faulty ones.
> Reproduced in 3 different situations on various esxi versions and in esx 3.5
> Maybe some timing issues ?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.asterisk.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira