<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
<META NAME="GENERATOR" CONTENT="GtkHTML/3.6.2">
</HEAD>
<BODY>
On Mon, 2006-02-20 at 16:41 -0500, Steven Stimpson (N1OHX) wrote:
<BLOCKQUOTE TYPE=CITE>
<PRE>
<FONT COLOR="#000000">----- Original Message ----- </FONT>
<FONT COLOR="#000000">From: "George (Skip) VerDuin" <<A HREF="mailto:k8rra@ameritech.net">k8rra@ameritech.net</A>></FONT>
<FONT COLOR="#000000">To: "TAPR xNOS - Mail List" <<A HREF="mailto:nos-bbs@lists.tapr.org">nos-bbs@lists.tapr.org</A>></FONT>
<FONT COLOR="#000000">Sent: Sunday, February 19, 2006 7:20 PM</FONT>
<FONT COLOR="#000000">Subject: [nos-bbs] Maybe for the next standards revision?</FONT>
<FONT COLOR="#000000">> Greetings,</FONT>
<FONT COLOR="#000000">></FONT>
<FONT COLOR="#000000">> I have a situation that seems like a condition not addressed by the 1998</FONT>
<FONT COLOR="#000000">> AX.25 Link Access Protocol Standard V2.2 nor programmed into jnos.</FONT>
<FONT COLOR="#000000">> Consider the following exchange extracted from a packet trace:</FONT>
<FONT COLOR="#000000">></FONT>
<FONT COLOR="#000000">> Wed Feb 15 19:31:02 2006 - vhf sent: > fourth request</FONT>
<FONT COLOR="#000000">> AX25: K8RRA-15->N8YJT SABM(P)</FONT>
<FONT COLOR="#000000">></FONT>
<FONT COLOR="#000000">> Wed Feb 15 19:31:42 2006 - vhf recv: ERR?> in frame</FONT>
<FONT COLOR="#000000">> AX25: N8YJT->K8RRA-15 RR(P) NR=0</FONT>
<FONT COLOR="#000000">></FONT>
<FONT COLOR="#000000">> [ANALYSIS: This RR(P) should not arrive - it implies an already open</FONT>
<FONT COLOR="#000000">> connection.</FONT>
<FONT COLOR="#000000"> Hi Skip. There is an open connection, k8rra-15 sent an SABM to n8yjt.</FONT>
</PRE>
</BLOCKQUOTE>
Actually as far as k8rra is concerned at 19:32 the connection is not open yet, k8rra is attempting to SABM.<BR>
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). <BR>
<BR>
That may be the physical condition at the time but that is not my point.<BR>
My point is that k8rra did receive the RR(P) and did not consider the RR improper during the SABM attempt.<BR>
Interestingly enough, when k8rra received the DISC(P) it responded with a DM (too busy doing SABM).<BR>
<BR>
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.
<BLOCKQUOTE TYPE=CITE>
<PRE>
<FONT COLOR="#000000">In all probability k8rra didn't recieve the UA, there is welcome text to</FONT>
<FONT COLOR="#000000">send,</FONT>
<FONT COLOR="#000000">and so n8yjt is (P)olling k8rra-15 to sync the link. Or, k8rra-15 got the</FONT>
<FONT COLOR="#000000">UA,</FONT>
<FONT COLOR="#000000">but didn't get the first frame. the fact that NR=0 clues that this is a new</FONT>
<FONT COLOR="#000000">connection.</FONT>
<FONT COLOR="#000000">> The two ends of the link are out-of-sync at this moment.</FONT>
<FONT COLOR="#000000">> The cause may be that N8YJT did not receive the UA(F) frame sent</FONT>
<FONT COLOR="#000000">> 19:28:30</FONT>
<FONT COLOR="#000000">> to acknowledge the DISC from YJT at 19:28:30. The DISC frame at</FONT>
<FONT COLOR="#000000">> 19:32:29</FONT>
<FONT COLOR="#000000">> seems to confirm the cause.]</FONT>
<FONT COLOR="#000000">Hmmm.Hard to comment on that, there is no 19:28:30 traced here.</FONT>
</PRE>
</BLOCKQUOTE>
I'm sorry - I did not include it to shorten the mail message, it does exist. See above.
<BLOCKQUOTE TYPE=CITE>
<PRE>
<FONT COLOR="#000000">> Wed Feb 15 19:32:23 2006 - vhf sent: > fifth request</FONT>
<FONT COLOR="#000000">> AX25: K8RRA-15->N8YJT SABM(P)</FONT>
<FONT COLOR="#000000">></FONT>
<FONT COLOR="#000000">> Wed Feb 15 19:32:29 2006 - vhf recv: > disconnect - connection=</FONT>
<FONT COLOR="#000000">> #3 finish</FONT>
<FONT COLOR="#000000">> AX25: N8YJT->K8RRA-15 DISC(P)</FONT>
<FONT COLOR="#000000">></FONT>
<FONT COLOR="#000000">> Wed Feb 15 19:32:29 2006 - vhf sent: ERR?> busy - connection= #3</FONT>
<FONT COLOR="#000000">> terminated</FONT>
<FONT COLOR="#000000">> AX25: K8RRA-15->N8YJT DM(F)</FONT>
<FONT COLOR="#000000">></FONT>
<FONT COLOR="#000000">> It seems to me that the RR(P) frame needs to be treated as an</FONT>
<FONT COLOR="#000000">> "unexpected response error" in the Data-Link State Machine (appendix C4</FONT>
<FONT COLOR="#000000">> paragraph C4.3. under Error Codes) standards and in jnos. It seems</FONT>
<FONT COLOR="#000000">> certain that jnos ignored the RR frame and continued with the SABM</FONT>
<FONT COLOR="#000000">> sequence.</FONT>
<FONT COLOR="#000000"> AN (P)oll frame, the first one sent out by the station that is being</FONT>
<FONT COLOR="#000000">connected TO, should be ignored by the station that send the SABM</FONT>
<FONT COLOR="#000000">if it has not yet recieved an UA. SO Jnos ignoring the RR(P) and</FONT>
<FONT COLOR="#000000">going on with the connect attempt is proper. Most of my packet</FONT>
</PRE>
</BLOCKQUOTE>
I'm sorry but I beg to differ - the RR(P)oll frame should not be ignored by k8rra because that frame<BR>
demonstrates that n8yjt is in a connected state thus not able to process a SABM(P)? <BR>
Per my read of the standard, no provision is made for a "hot restart" by n8yjt.
<BLOCKQUOTE TYPE=CITE>
<PRE>
<FONT COLOR="#000000">activity is on H.F., where supervisory frames are missed constantly.</FONT>
<FONT COLOR="#000000">A third party will monitor the following frequently:</FONT>
</PRE>
</BLOCKQUOTE>
Remember now - k8rra is first party, n8yjt is second party, no third party in this trace...<BR>
I have seen the below as a third party... no problem. n1ohx needs to remove the banana?
<BLOCKQUOTE TYPE=CITE>
<PRE>
<FONT COLOR="#000000">n1ohx>n1llu SABM</FONT>
<FONT COLOR="#000000">n1llu>n1ohx UA</FONT>
<FONT COLOR="#000000">n1llu>n1ohx welcome to blah blah blah</FONT>
<FONT COLOR="#000000">n1llu>n1ohx RR(P) NR=0</FONT>
<FONT COLOR="#000000">n1ohx>n1llu SABM</FONT>
<FONT COLOR="#000000"> Assume n1ohx didn't recieve the UA or welcome message, but</FONT>
<FONT COLOR="#000000">DID recieve the (P)oll frame. If this frame was not ignored, n1ohx would</FONT>
<FONT COLOR="#000000">need</FONT>
<FONT COLOR="#000000">to send a DM to indicate that there is no connection between the two yet.</FONT>
<FONT COLOR="#000000">This could cause problems. It's better to just ignore all responses</FONT>
<FONT COLOR="#000000">during a connect request unless they are a UA, DISC, or DM</FONT>
<FONT COLOR="#000000">I have never seen a DISC sent as a response to a SABM, if</FONT>
<FONT COLOR="#000000">a connection is not prudent then usually a DM is sent.</FONT>
<FONT COLOR="#000000">> As a secondary thing, when the DISC frame arrived at 19:32:19, the</FONT>
<FONT COLOR="#000000">> respnse of UA seems correct rather than the DM. This is a lesser issue</FONT>
<FONT COLOR="#000000">> because both the UA and DM cause the same result...</FONT>
<FONT COLOR="#000000">></FONT>
<FONT COLOR="#000000">> The workaround for this situation might be to wait until all timers have</FONT>
<FONT COLOR="#000000">> expired and both ends have reset prior to beginning a SABM sequence.</FONT>
<FONT COLOR="#000000">></FONT>
<FONT COLOR="#000000">> 73</FONT>
<FONT COLOR="#000000">> de Skip k8rra k</FONT>
<FONT COLOR="#000000">></FONT>
<FONT COLOR="#000000"> Msys resets the connection, sets the frame numbers to 0, and issues a UA</FONT>
<FONT COLOR="#000000">when an SABM is recieved from the same station when there is already</FONT>
<FONT COLOR="#000000">an connection between them. this seems to work fine. I can't remember</FONT>
</PRE>
</BLOCKQUOTE>
The Msys example is interesting. It is the "hot restart" I mentioned above? For converse it seems OK <BR>
but in the midst of an ftp I wonder. Does the Msys example lead to "thrashing"? <BR>
The standard provides for 7 open frames in transit at any time and only sequential processing <BR>
so perhaps it can sort out where the discontinuity has been in transport to make restart secure. <BR>
Yet my read suggests that the machine needs to go thru the DM (or DISC) process<BR>
to reset everything before beginning the SABM process to start over. <BR>
Can a simple reset to NS=0 & NR=0 be safe?<BR>
<BR>
Can you point me to what I have missed?
<BLOCKQUOTE TYPE=CITE>
<PRE>
<FONT COLOR="#000000">how jnos handles an incoming SABM when a link is already established,</FONT>
<FONT COLOR="#000000">but you could test by having someone connect to you, then disable TX,</FONT>
<FONT COLOR="#000000">do an ax25 reset, enable tx, and then connect again.</FONT>
<FONT COLOR="#000000">73,</FONT>
<FONT COLOR="#000000">steven n1ohx</FONT>
<FONT COLOR="#000000">_______________________________________________</FONT>
<FONT COLOR="#000000">nos-bbs mailing list</FONT>
<FONT COLOR="#000000"><A HREF="mailto:nos-bbs@lists.tapr.org">nos-bbs@lists.tapr.org</A></FONT>
<FONT COLOR="#000000"><A HREF="https://lists.tapr.org/cgi-bin/mailman/listinfo/nos-bbs">https://lists.tapr.org/cgi-bin/mailman/listinfo/nos-bbs</A></FONT>
</PRE>
</BLOCKQUOTE>
<TABLE CELLSPACING="0" CELLPADDING="0" WIDTH="100%">
<TR>
<TD>
<BR>
73<BR>
de Skip k8rra k<BR>
<BR>
<BR>
</TD>
</TR>
</TABLE>
</BODY>
</HTML>