soundmodem HDLC compatibility problem

soundmodem HDLC compatibility problem

[Dave Platt]

I ran into an interesting compatibility problem recently, between
soundmodem 0.7 and a new KISS-mode-only TNC kit (www.tnc-x.com).

The symptom was that if my Linux system send multiple AX.25
frames back-to-back in a single transmission, the TNC-X would
properly receive only the first, and would drop the second and
subsequent ones on the floor almost all of the time.  The
problem did not occur in the reverse direction.  Both the
soundmodem and the TNC-X had no problem communicating with
other TNCs.

The problem turned out to be a minor deficiency in the soundmodem
HDLC encoder, which was tripping up the HDLC parser in the
TNC-X.

The soundmodem HDLC encoder takes as input a packet of data to
be sent (an integral number of bytes) and encodes this into
HDLC frames, storing the HDLC-encoded bits in a circular buffer.  
The circular-buffer management is also being done in increments 
of 1 byte, and as a result it's quite common for the second of
the two flags at the end of the frame to be truncated.  This
doesn't seem to have any bad effect when only single frames are
transmitted, but it causes problems when back-to-back frames
are encoded.  The HDLC data ends up looking like:

 (flag) (flag) [frame 1] (flag) (fla) (flag) [frame 2] (flag) (fl)

The partial flag in between the two frames isn't quite kosher,
according to the recommendations in the AX.25 spec.  Due to the
way the TNC-X HDLC parser is implemented, the partial flag causes
the TNC-X to lose sync with the incoming data - [frame 1] is
processed properly, but the TNC fails to resynchronize in time
to receive [frame 2].  Most other TNCs seem to have more robust
intra-frame flag synchronization, and aren't confused by the
few bits of garbage.

The net result with a TNC-X is a severe loss of useful bandwidth, 
as the lost frames must be retransmitted when the higher-level 
protocols time out.

The fix was relatively simple.  The soundmodem HDLC encoder can
be modified to pack both of the terminating (flag) bytes into the
HDLC buffer, and (if another frame is encoded before the data
is transmitted) to pack that frame's leading (flag) immediately
after the last bits of the trailing (flag).  This brings the
transmission into compliance with the AX.25 spec's recommendations,
and cures the problem.

Patches for this can be found at 

  http://www.radagast.org/~dplatt/hamradio/soundmodem-0.7a.patch
  http://www.radagast.org/~dplatt/hamradio/soundmodem-0.7b.patch

The "a" version is more conservative, in that it guarantees
three (flag) bytes between back-to-back frames... the two which
were encoded to terminate [frame 1] and one which is encoded
to start [frame 2].  The "b" version of the patch eliminates the
third (flag) in this case.

A more aggressive patch would go even further, and use just one
"shared" flag as is permitted by the spec, but I haven't been
able to test this with enough TNCs to be confident that it
wouldn't tickle problems in some TNCs.

Re: soundmodem HDLC compatibility problem

[Robin Gilks]

> I ran into an interesting compatibility problem recently, between
> soundmodem 0.7 and a new KISS-mode-only TNC kit (www.tnc-x.com).
>
> The symptom was that if my Linux system send multiple AX.25
> frames back-to-back in a single transmission, the TNC-X would
> properly receive only the first, and would drop the second and
> subsequent ones on the floor almost all of the time.  The
> problem did not occur in the reverse direction.  Both the
> soundmodem and the TNC-X had no problem communicating with
> other TNCs.
>
> The problem turned out to be a minor deficiency in the soundmodem
> HDLC encoder, which was tripping up the HDLC parser in the
> TNC-X.
>
> The soundmodem HDLC encoder takes as input a packet of data to
> be sent (an integral number of bytes) and encodes this into
> HDLC frames, storing the HDLC-encoded bits in a circular buffer.   The
> circular-buffer management is also being done in increments
> of 1 byte, and as a result it's quite common for the second of
> the two flags at the end of the frame to be truncated.  This
> doesn't seem to have any bad effect when only single frames are
> transmitted, but it causes problems when back-to-back frames
> are encoded.  The HDLC data ends up looking like:
>
>  (flag) (flag) [frame 1] (flag) (fla) (flag) [frame 2] (flag) (fl)
>
> The partial flag in between the two frames isn't quite kosher,
> according to the recommendations in the AX.25 spec.  Due to the
> way the TNC-X HDLC parser is implemented, the partial flag causes
> the TNC-X to lose sync with the incoming data - [frame 1] is
> processed properly, but the TNC fails to resynchronize in time
> to receive [frame 2].  Most other TNCs seem to have more robust
> intra-frame flag synchronization, and aren't confused by the
> few bits of garbage.
>
> The net result with a TNC-X is a severe loss of useful bandwidth,  as
> the lost frames must be retransmitted when the higher-level
> protocols time out.
>
> The fix was relatively simple.
[snip]

Indeed it is simple - fix the tnc-x as this is what has the problem. I've
implemented similar code on an AVR for 9k6 full duplex operation* so a PIC
shouldn't have any problems keeping up at 1200bps.

HDLC is a bit oriented protocol and as such what the soundmodem sends is
quite valid since each frame is correctly bounded by flags. Any number of
odd bits although perhaps not the best result is perfectly acceptable in
protocol terms.



* www.tvipug.org - IPRI (a SLIP based IP only TNC that doesn't require any
AX25 layer at all - or you can run it as a KISS TNC)

-- 
Robin Gilks (g8ecj, zl3rob)
Internet: robin@gilks.org    http://www.gilks.org
Tel:      (+64) (3) 347 4370