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

Mon Feb 20 18:28:07 EST 2006

On Mon, 2006-02-20 at 16:41 -0500, Steven Stimpson (N1OHX) wrote:

> ----- Original Message ----- 
> From: "George (Skip) VerDuin" <k8rra at ameritech.net>
> To: "TAPR xNOS - Mail List" <nos-bbs at lists.tapr.org>
> Sent: Sunday, February 19, 2006 7:20 PM
> Subject: [nos-bbs] Maybe for the next standards revision?
> 
> 
> > 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.
> 
>  Hi Skip. There is an open connection, k8rra-15 sent an SABM to n8yjt.

Actually as far as k8rra is concerned at 19:32 the connection is not
open yet, k8rra is attempting to SABM.
Back in time to 19:28 n8yjt did DISC(P) and k8rra did UA(F) to close the
link from k8rra viewpoint only - my observation is that n8yjy did not
receive the UA and continued to try to DISC plus RR(P).  

That may be the physical condition at the time but that is not my point.
My point is that k8rra did receive the RR(P) and did not consider the RR
improper during the SABM attempt.
Interestingly enough, when k8rra received the DISC(P) it responded with
a DM (too busy doing SABM).

My bottom line contention is that the DM response to the RR(P) could be
correct, raising an error flag to terminate the SABM process and alert
upstream that the process downstream is really unreliable...  Perhaps
the standard as it exists is more robust than I perceive at this moment,
however this process looks unstable to me.

> In all probability k8rra didn't recieve the UA, there is welcome text to
> send,
> and so n8yjt is (P)olling k8rra-15 to sync the link. Or, k8rra-15 got the
> UA,
> but didn't get the first frame. the fact that NR=0 clues that this is a new
> 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.]
> 
> 
> Hmmm.Hard to comment on that, there is no 19:28:30 traced here.

I'm sorry - I did not include it to shorten the mail message, it does
exist.  See above.

> 
> > 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.
> 
>  AN (P)oll frame, the first one sent out by the station that is being
> connected TO, should be ignored by the station that send the SABM
> if it has not yet recieved an UA. SO Jnos ignoring the RR(P) and
> going on with the connect attempt is proper. Most of my packet

I'm sorry but I beg to differ - the RR(P)oll frame should not be ignored
by k8rra because that frame
demonstrates that n8yjt is in a connected state thus not able to process
a SABM(P)? 
Per my read of the standard, no provision is made for a "hot restart" by
n8yjt.

> activity is on H.F., where supervisory frames are missed constantly.
> A third party will monitor the following frequently:

Remember now - k8rra is first party, n8yjt is second party, no third
party in this trace...
I have seen the below as a third party...  no problem.  n1ohx needs to
remove the banana?

> 
> n1ohx>n1llu SABM
> n1llu>n1ohx UA
> n1llu>n1ohx welcome to blah blah blah
> n1llu>n1ohx RR(P) NR=0
> n1ohx>n1llu SABM
> 
>  Assume n1ohx didn't recieve the UA or welcome message, but
> DID recieve the (P)oll frame. If this frame was not ignored, n1ohx would
> need
> to send a DM to indicate that there is no connection between the two yet.
> This could cause problems. It's better to just ignore all responses
> during a connect request unless they are a UA, DISC, or DM
> I have never seen a DISC sent as a response to a SABM, if
> a connection is not prudent then usually a DM is sent.
> 
> 
> > 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
> >
>  Msys resets the connection, sets the frame numbers to 0, and issues a UA
> when an SABM is recieved from the same station when there is already
> an connection between them. this seems to work fine. I can't remember

The Msys example is interesting.  It is the "hot restart" I mentioned
above?  For converse it seems OK 
but in the midst of an ftp I wonder.  Does the Msys example lead to
"thrashing"?  
The standard provides for 7 open frames in transit at any time and only
sequential processing 
so perhaps it can sort out where the discontinuity has been in transport
to make restart secure.  
Yet my read suggests that the machine needs to go thru the DM (or DISC)
process
to reset everything before beginning the SABM process to start over. 
Can a simple reset to NS=0 & NR=0 be safe?

Can you point me to what I have missed?

> how jnos handles an incoming SABM when a link is already established,
> but you could test by having someone connect to you, then disable TX,
> do an ax25 reset, enable tx, and then connect again.
> 73,
> steven n1ohx
> 
> 
> _______________________________________________
> nos-bbs mailing list
> nos-bbs at lists.tapr.org
> https://lists.tapr.org/cgi-bin/mailman/listinfo/nos-bbs

73
de Skip k8rra k

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