[aprssig] Error checking within APRS packets
gregg at wonderly.org
Mon Jun 20 23:35:44 EDT 2011
On 6/20/2011 9:44 PM, Guido Trentalancia wrote:
> On 21/06/2011 00:24, Gregg Wonderly wrote:
> I would perhaps just add: and go, find out.... the framing or "flag" byte is
> 0x7e which coincidentally corresponds in ASCII to ~ (tilde, almost never used by
> humans in normal communications) but most importantly it's forbidden everywhere
> else in the packet (other than at its beginning and end) by the protocol itself !
>> Right. My thoughts are hovering around whether or not these TNC firmwares are
>> paying complete attention to the framing and CRC given some of these
>> discussions that keep coming up from time to time. So, I am just trying to
>> stimulate these discussions of the facts so that everyone can read up and
>> understand what is going on, and think about what is going on with any
>> firmware they are creating for X.25 implementations.
> Well, of course, otherwise they would be called "broken TNCs". I am referring to
> commercial ones, as otherwise they won't survive that long on the market.
That is my hope, and so I'm asking these silly questions to see if there is
something I missed in some discussion that would otherwise demonstrate that
there are some failure modes of TNCs that are not always seen except in
circumstances that are rarely happening. It seems that the general issues of
how the 0x7e and the CRC-16 work is well known, and they take care of keeping
"bad" data from being accepted by the TNC from the X.25 layer and passed to the
user. If there are two overlapping packets as I described, the flag byte should
at least cause the beginning packet to be tossed. I believe the 2 CRC bytes
come before the terminating flag. If so, the TNC could, determine that what
follows the terminating flag was not a starting flag and thus assume that the
scenario I described was happening, and successfully copy the second packet.
This scenario, I think, illustrates why AX.25 degrades so quickly. As time
between packets decreases and the disappears, only the absolutely loudest
stations will be successful, and only in particular time sequences.
> On APRS-IS (i.e. through the Internet) we still have packetization mechanisms
> implemented (they are implemented in the TCP as well as in lower layers). We are
> just riding on top of them, thus we are safe as long as they are safe. And they
> are usually much safer (just as a start, TCP also has a two bytes checksum).
> So if that is happening only over APRS-IS, it should be a problem of the
> specific APRS IGate software and environment (either a misconfiguration or a bug).
For example, the serial path out of the TNC to the computer may be subject to
RFI from the transmit RF of a digi that is also an i-gate I suppose. But there
can be lots of different failure modes I suppose that cause loss of characters
prior to entering the TCP path. Note, that one failure mode, common with some
TCP software, is independent management of the inbound and outbound data paths.
A partially received packet on the input, can be interpreted as a "complete
packet" that is written to the output, without line termination, and then the
next packet received after a reconnect to the source can results in that packet
being appended to the previous packets data if line termination is merely copied
as received data to the output, instead of being stripped on input and forced on
More information about the aprssig