[nos-bbs] Maybe for the next standards revision?

[George (Skip) VerDuin]

Greetings,

I have a situation that seems like a condition not addressed by the 1998
AX.25 Link Access Protocol Standard V2.2 nor programmed into jnos.
Consider the following exchange extracted from a packet trace:

Wed Feb 15 19:31:02 2006 - vhf sent:        > fourth request
AX25: K8RRA-15->N8YJT SABM(P)

Wed Feb 15 19:31:42 2006 - vhf recv:    ERR?> in frame
AX25: N8YJT->K8RRA-15 RR(P) NR=0

[ANALYSIS: This RR(P) should not arrive - it implies an already open
connection.
   The two ends of the link are out-of-sync at this moment.
   The cause may be that N8YJT did not receive the UA(F) frame sent
19:28:30 
      to acknowledge the DISC from YJT at 19:28:30.  The DISC frame at
19:32:29
      seems to confirm the cause.]

Wed Feb 15 19:32:23 2006 - vhf sent:        > fifth request
AX25: K8RRA-15->N8YJT SABM(P)

Wed Feb 15 19:32:29 2006 - vhf recv:        > disconnect - connection=
#3 finish
AX25: N8YJT->K8RRA-15 DISC(P)

Wed Feb 15 19:32:29 2006 - vhf sent:    ERR?> busy - connection= #3
terminated
AX25: K8RRA-15->N8YJT DM(F)

It seems to me that the RR(P) frame needs to be treated as an
"unexpected response error" in the Data-Link State Machine (appendix C4
paragraph C4.3. under Error Codes) standards and in jnos.  It seems
certain that jnos ignored the RR frame and continued with the SABM
sequence.  

As a secondary thing, when the DISC frame arrived at 19:32:19, the
respnse of UA seems correct rather than the DM.  This is a lesser issue
because both the UA and DM cause the same result...

The workaround for this situation might be to wait until all timers have
expired and both ends have reset prior to beginning a SABM sequence.  

73
de Skip k8rra k


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tapr.org/pipermail/nos-bbs_lists.tapr.org/attachments/20060219/40deea9b/attachment.html>