| |
G3ZFR > AX25 10.08.95 14:43l 82 Lines 3790 Bytes #-11373 (0) @ EU
BID : 21982_G3ZFR
Read: DL3MGQ DL3MDI GUEST
Subj: Baycom protocol error - more
Path: DB0KCP<DB0AAB<DB0PV<DB0MFG<OE7XCI<IW3AQL<IN3TUR<IK4NZD<IW2KTL<IK2HDG<
GB7DEO<GB7BST<GB7SRC<GB7AVM<GB7WAR<GB7COV<G3ZFR
Sent: 950809/2309Z @:G3ZFR.GB7COV.#29.GBR.EU #:21982 [Coventry] $:21982_G3ZFR
From: G3ZFR@G3ZFR.GB7COV.#29.GBR.EU
To : AX25@EU
Hi everyone
A couple of weeks ago I sent out a bulletin outlining an apparent problem
that one of my users was having with accessing the BBS.
I stated that the user was using Baycom. In fact he was using a Baycom board
attached to an Amiga. The software was Amicom, which I know nothing about,
but I presume that it is an equivalent of Baycom for the Amiga. There appear
to be some differences from Baycom, for instance the FRACK value is in 10ms
units instead of 100ms (he has it set to 700). There is also no reference to
"Ipoll" in his user instructions.
I was prompted to send the bulletin because I had observed some strange
things in the protocol. It appeared that the Baycom (Amicom) software was
repeating I-frames. I observed this on more than one station who was using
Baycom (or Amicom), but never saw it with any other software. This led me
to believe that this apparent protocol violation could be causing the
problem that my user was having.
Thanks to the replies I received from a number of people, I now know that
this is a feature of Baycom known as "Ipoll". It is provided in order to speed
up the transfer on good links. It is doubtful whether it provides any useful
purpose on a user access frequency and a number of people have advised that
it should be set to zero in this case. It certainly violates the protocol
defined in my copy of AX25 version 2.0.
The on-line help menu from an official version of Baycom 1.6 states that
"Ipoll is an invention which actually violates the AX.25 protocol". However,
I have been told that the feature may be included in later versions of the
protocol specification.
Now that I know what "Ipoll" is, I am happy that it is *NOT* the direct cause
of my user's problem and that it can, in some circumstances, be useful. I am
also happy that my node/BBS software (BPQ4.08) is handling it correctly.
Now to the real problem.
The problems were observed on a fairly busy user access frequency. Many frames
were getting lost (in both directions). There was also some queueing of
outgoing frames in the TNC, due to the squelch being open a lot. Some people
replied to me and quite rightly pointed out that queueing in the TNC causes
more retries than normal and a lot of REJ frames.
After the initial interchange of I-frames, including several repeated frames
due to "Ipoll", the BBS went into a state where it was sending REJ frames
with the P-bit set. The Baycom (Amicom) software was ignoring these.
One reply to my bulletin stated that "when BPQ is sending REJ with POLL-pit,
this is really a BUG! REJ must never have the P-bit set!"
However, in the ARRL spec (AX25 version 2.0 Oct 1984), the final
paragraph of 2.3.4.2.3 says "The status of the DXE at the other end of
the link can be requested by sending a REJ command frame with the P bit
set to one."
I agree that the state tables for state S6 (REJ frame sent) imply that you
should send RR, rather than REJ in this particular case. However, It is
still apparently within the rules to send REJ with the P-bit.
What the state tables *DO* say is that a REJ with P-bit may be *RECEIVED*,
in which case, it MUST BE TREATED THE SAME FOR AN RR WITH P-BIT. In the
protocol problem I observed, the user's software was definitely ignoring
REJ with P-bit and was therefore violating the protocol rules. This was the
direct cause of the lock-up.
It may be that this a problem peculiar to the Amicom software that my user
was using, and that it is not a problem with Baycom in general. However,
I would appreciate any further comments from anyone who is more familiar
with these software packages than I am.
I would like to take this opportunity to thank all of those who took the
trouble to reply.
73s
Roger
(Sysop GB7COV)
Read previous mail | Read next mail
| |
