[asterisk-dev] [IAX2] Question on unrecoverable race condition and VNAK's Oseq

[David Vossel]

----- "Alex Hermann" <alex at speakup.nl> wrote:

> Hello all,
> 
> 
> I'm sometimes seeing a race condition in the IAX2 protocol, from which
> 
> the protocol isn't able to recover. UnThe below table shows the packet
> flow. 
> (as it is the result of a race condition, I haven't been able to
> reproduce 
> it in a labtest, so I have no debug log available)
> 
> 
> Communication is as seen on a 1.4.21 * being called from a 1.2.26 *.
> 
> 
> Dir time  type    Oseq Iseq
> 
> ; Until the ANSWER, all is ok.
> Tx  5260  ANSWER  6    3
> Rx  5260  ACK     3    7
> 
> ; I don't know why this packet is here
> Tx  6263  (14)    7    3
> Rx  6263  ACK     3    8
> 
> ; Here the trouble starts, as both ends send a LAGRQ at the same time
> Rx 10018  LAGRQ   3    8
> Tx 10016  LAGRQ   8    3
> Rx 10016  LAGRP   4    9
> 
> ; And now this node tries to sync from long gone sequence numbers
> Tx 10035  VNAK    3    3
> 
> ; From here this sequence continues endlessly:
> Rx 10018  LAGRQ   3    8
> Tx 10016  LAGRQ   8    3
> Rx 10016  LAGRP   4    9
> Tx <incr> VNAK    3    3
> 
> 
> 
> Any idea what might be going on here? Which host is at fault?
> 
> 
> 
> To me, the VNAK's look suspicious, why would it want to sync those
> very 
> early packets? Should that have been:
> Tx 10035  VNAK    8    3
> 
> Tracking the source, the following function is responsible for that
> seqno 
> in the last parameter. Shouldn't it be iaxs[callno]->oseqno, OR the
> iseqno 
> from the iax_peercallno_pvts variable?
> 
> static int iax2_vnak(int callno)
> {
> 	return send_command_immediate(iaxs[callno], AST_FRAME_IAX,
> IAX_COMMAND_VNAK, 0, NULL, 0, iaxs[callno]->iseqno);
> }
> 
> Can an IAX2 guru give his/her opinion on the correctness of the VNAK
> and/or 
> the above function.
> 
> -- 
> Greetings,
> 
> Alex Hermann
> 
> 
> _______________________________________________
> --Bandwidth and Colocation Provided by http://www.api-digital.com--
> 
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-dev


I've noticed VNAK's seem to always be sent with the same iseq and oseq number.  When a VNAK is received, only packets higher than the VNAK's iseq must be resent. I'd have to look into the code, but I'm not even sure it matters what the oseq number is in a VNAK.  As far as the sequence of events, I don't know why this loop happens.  How often does this occur. Can you get a wireshark log of this?

~Vossel