[asterisk-dev] AMI Disconnect/Sudden "Asterisk Call Manager/1.3" received

[Daniel McFarlane]

On 05/06/2014 06:35 PM, Tony Mountifield wrote:
> In article <53695C95.9060105 at szeto.ca>,
> Daniel McFarlane <daniel at szeto.ca> wrote:
>> Hi Tony,
> Hi Daniel,
>
>> See my answers inline.
>>
>>
>> On 05/06/2014 12:11 PM, Tony Mountifield wrote:
>>> In article <5368ED8B.4080103 at szeto.ca>,
>>> Daniel McFarlane <daniel at szeto.ca> wrote:
>>>> Hi All,
>>>>
>>>> I've been working with Asterisk for 2.5 years now but I am new to the
>>>> mailing list.  Hoping to get some answers here..
>>>>
>>> It would be worthwhile mentioning which version of Asterisk you are using.
>> As I added in my last email: I'm running Asterisk 11.2.1
>> Thank you for the in-dept usage information for TCP dump and your
>> suggested script, btw.
>>
>> I have investigated with Wireshark, reproduced the problem and confirmed
>> that Asterisk is resetting the connection.  I see a [RST, ACK] being
>> issued from the Asterisk AMI port to my software.  My software then
>> re-initializes the connection with a [SYN].
>>
>> I'm new to the mailing list so how do we proceed to find a working
>> solution from here?
> Well, a few ideas:
>
> 1. Try turning up debugging with "core set debug 5". You might need to
> edit logger.conf to ensure that debug message get sent to the console
> or to the full log, as desired.
>
> 2. Try updating Asterisk from 11.2.1 to the latest in the 11.x series,
> to see if something was fixed. You can browse the changes at
> http://svnview.digium.com/svn/asterisk/branches/11/
>
> 3. Dive into the code in main/manager.c !
>
> Cheers,
> Tony
>

Hi All,

I will reply to all emails I received (i.e.: From Olle, Tony & Dan) 
here, in order:

Olle:

"I wonder how an operating system treats an overflowing TCP buffer... Just guessing here."

Well, theoretically the OS should fill up the it's TCP buffer and my 
application would no longer
be able to write.  It is then up to my application to buffer the 
commands, which I do.

Note: In my Wireshark analysis I do see evidence of Asterisk not 
reading/processing fast enough
           and the TCP buffer reaching full capacity, i.e.: In the form 
of "TCP Window Full" and "TCP
           ZeroWindow" events.  Coincidently I also noticed some "TCP 
Retransmission" events, but
           I don't think these are relevant as this is all handled 
internally by TCP/IP.


Tony: Thank you for your suggestions:

1. I had my debugging set to "core set debug 9". It's at that time that 
I found
the logs (in res_security_log.c.) showing the apparently lost/cleared 
AccountID,
which I included in one of my earlier emails.

2. I will try this to see if it makes a difference as soon as I get a 
chance. I have a
lot of other high priority items on my plate as well, as well as some 
other questions
to post here eventually..one of which `might` also help shed some lights 
on this issue
as from the CLI output I found it appears to be a memory buffer 
overrun.  Not sure
it it's related to the manager user getting kicked out/connection reset, 
but it is an
IAX message I noticed while performing my stress testing.  Should I post 
it now?
In this thread or a new one?

3. To be honest, I tried grep'ing and looking for the source of the 
other problem I mentioned
in #2 above.  I found myself going through a complicated path of 
functions calls, a lot of which
I didn't understand.  I have no experience in working with Asterisk 
internals, so honestly I'm not
the best to deal with that.  I signed up to this mailing list in the 
hopes of finding a solution.

I am willing to provide any information I can to help isolate the 
problem in order to help get
this fixed though.

Is their a way to escalate this to place it on a bug list or something?


Dan Jenkins:

Thank you for your input.  It's nice to know I'm not to only one to have 
this problem.  Hopefully
this can be fixed now that I'm able to reproduce it..

Thank you again all,

Daniel