| |
G3ZFR > AX25 31.07.95 21:43l 37 Lines 1307 Bytes #-11383 (0) @ EU
BID : 22237_GB7COV
Read: DH1FBK DG4MLA DG7DAH DB7YI DJ1HG OE8DJK GUEST
Subj: Baycom protocol bug?
Path: DB0AAB<DB0MWS<DB0LAN<DB0RGB<DB0SL<OE3XBS<OM0PBB<HA5KDF<HA1VH<9A1CRA<
S50BOX<S50BBS<IV3AVQ<IW3QQV<IW3GS<I3NXU<IW4CNQ<IK2FMJ<IW2KTL<IK1MSL<
I1NHK<I1DEP<I1VDM<I1YLM<IK1MAP<IW1BBL<IK2HDG<GB7DEO<GB7BST<GB7SRC<
GB7AVM<GB7WAR<GB7COV<GB7COV
Sent: 950729/0914Z @:GB7COV.#29.GBR.EU #:22237 [Coventry-local] $:22237_GB7COV
From: G3ZFR@GB7COV.#29.GBR.EU
To : AX25@EU
Hi
A couple of my users (who run Baycom) have reported problems accessing the
BBS (GB7COV). It either appears to lock up or throws them off.
I have observed the AX25 protocol when this happens and have noticed some
strange things.
The Baycom systems appear to repeat the same I-frame (same sequence number)
several times WITHOUT waiting for an RR interchange between them. This
naturally causes a number of REJ frames to be sent back from the BBS.
The system eventually goes into a state where the BBS (wishing to send the
next I-frame to the user) sends REJ with the p-bit set. The Baycom system
totally ignores this. It does not respond with an RR with the f-bit set as it
should do. Instead it continues to send the PREVIOUS I-frame. The result
is total lock-up.
The BBS is running FBB with BPQ. The users are running a Baycom system (I
don't know which version). I don't get this problem with users running other
systems. Unfortunately I know nothing about Baycom, so I can't advise them.
Have they set the parameters up wrong? Are they using an old version?
Please help! I'm worried that these users will try to blame the BBS, whereas
my own investigations show that their systems are disobeying the AX25 protocol
rules.
73s
Roger
(Sysop GB7COV)
Read previous mail | Read next mail
| |
