[Home]

Summary:ASTERISK-24549: on 'iax2 reload' all peers are announced as unreachable via AMI
Reporter:Birger "WIMPy" Harzenetter (wimpy)Labels:
Date Opened:2014-11-22 09:24:53.000-0600Date Closed:
Priority:MinorRegression?No
Status:Open/NewComponents:Channels/chan_iax2
Versions:11.14.0 13.18.4 Frequency of
Occurrence
Related
Issues:
Environment:Listening for status information on AMIAttachments:( 0) astdebug-short
Description:After doing an 'iax2 reload' you get extensionstatus 4 events for all peers. Unfortunately they don't clear on the next successful qualify.
So if you track the state of your peers, they stay in the unreachable state until the next call passes on that peer.
Comments:By: Matt Jordan (mjordan) 2014-11-23 19:51:57.168-0600

We require a complete debug log to help triage the issue. This document will provide instructions on how to collect debugging logs from an Asterisk machine for the purpose of helping bug marshals troubleshoot an issue: https://wiki.asterisk.org/wiki/display/AST/Collecting+Debug+Information



By: Birger "WIMPy" Harzenetter (wimpy) 2014-12-02 09:45:40.457-0600

It happened several times while reconfiguring Asterisk, but now that I try to reproduce it, it fails to fail.
But I captured the exact opposite issue last week.
The *CLI reported a peer as UNREACHABLE and while I was trying to find out where it had gone, I found that my ststus display, which listens on AMI, changed it to green again, yet the *CLI never reported it as REACHABLE again.
Several minutes earlier another peer had a small glitch but there both messages appeared.

[Nov 26 13:36:31] NOTICE[30448]: chan_iax2.c:12387 __iax2_poke_noanswer: Peer 'hbc-pgsw' is now UNREACHABLE! Time: 56
[Nov 26 13:36:37] NOTICE[30448]: chan_iax2.c:11217 socket_process_helper: Peer 'hbc-pgsw' is now REACHABLE! Time: 56
[Nov 26 13:59:19] NOTICE[30447]: chan_iax2.c:12387 __iax2_poke_noanswer: Peer 'hbc-grau' is now UNREACHABLE! Time: 58

'iax2 show peers' showed it as OK as well, but no further message ever appeared.


By: Birger "WIMPy" Harzenetter (wimpy) 2014-12-02 20:39:24.469-0600

Ok, this time I got a partial one. The hints for 3 peers went to unavailable.
I removed the unaffected peers/hints to make things more readable.
The configuration script reloads dialplan, sip and iax.

[Dec  3 03:21:45]  Reloading SIP
[Dec  3 03:21:45] NOTICE[23562]: chan_iax2.c:12444 iax2_poke_peer: Still have a callno...
[Dec  3 03:21:45] NOTICE[23562]: chan_iax2.c:12444 iax2_poke_peer: Still have a callno...
[Dec  3 03:21:45] NOTICE[23562]: chan_iax2.c:12444 iax2_poke_peer: Still have a callno...
[Dec  3 03:21:45] NOTICE[23562]: chan_iax2.c:12444 iax2_poke_peer: Still have a callno...
[Dec  3 03:21:45] NOTICE[23562]: chan_iax2.c:12444 iax2_poke_peer: Still have a callno...
[Dec  3 03:21:45] NOTICE[23562]: chan_iax2.c:12444 iax2_poke_peer: Still have a callno...
[Dec  3 03:21:45] NOTICE[23562]: iax2-provision.c:558 iax_provision_reload: No IAX provisioning configuration found, IAX provisioning disabled.
miranda*CLI> iax2 show peers
Name/Username    Host                 Mask             Port          Status      Description                    
hbc-hah/hbc-hah  87.122.129.253  (D)  255.255.255.255  4569 (T)      OK (25 ms)                                  
s-mn24/s-mn24    87.139.190.172  (D)  255.255.255.255  4569 (T)      OK (30 ms)                                  
yetim-lmaa/yeti  91.35.39.23     (D)  255.255.255.255  4569 (T)      OK (20 ms)                                  
16 iax2 peers [7 online, 9 offline, 0 unmonitored]
miranda*CLI> core show hint ::iax2:
        ::iax2:hbc-hah@hints               : iax2/hbc-hah          State:Idle            Watchers  0
     ::iax2:yetim-lmaa@hints               : iax2/yetim-lmaa       State:Idle            Watchers  0
         ::iax2:s-mn24@hints               : iax2/s-mn24           State:Idle            Watchers  0



So far everything looks ok, but on AMI I received:



[03:21:45.587 -9999] event:                     extensionstatus ::iax2:s-mn24: 4
extensionstatus: iax2/s-mn24:unreachable
[03:21:45.587 -   0] event:                     extensionstatus ::iax2:hbc-hah: 4
extensionstatus: iax2/hbc-hah:unreachable
[03:21:45.589 -   2] event:                     extensionstatus ::iax2:yetim-lmaa: 4
extensionstatus: iax2/yetim-lmaa:unreachable



The hints in the dialplan:



exten => ::iax2:s-mn24,hint,iax2/s-mn24
exten => ::iax2:hbc-hah,hint,iax2/hbc-hah
exten => ::iax2:yetim-lmaa,hint,iax2/yetim-lmaa



No further messages have been received via AMI for those peers so they seem to be unavailable until they change state for another reason.

By: Rusty Newton (rnewton) 2014-12-05 08:31:38.050-0600

I'm not sure we have much to go on here without a DEBUG log or being able to reproduce it reliably.

How difficult is it to reproduce and can you provide an example configuration to do so?

By: Birger "WIMPy" Harzenetter (wimpy) 2014-12-06 16:36:00.980-0600

Here is a full debug of a reload resulting in all iax peers looking unavailable to AMI client(s).

Made it a little more readable by hiding anything sip and dialplan except hints:
grep -vi chan_sip astdebug | grep -v "priority [0-9]" > astdebug-short