[aprssig] Error checking within APRS packets
iz6rdb at trentalancia.com
Tue Jun 21 16:06:54 EDT 2011
Hi Gregg !
On 21/06/2011 05:35, Gregg Wonderly wrote:
> 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
>> 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
> 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.
Yes, something like that should happen, I suppose. The first packet
discarded (as it would be a partial packet with a CRC that does not
match at both ends). The second (loud) packet would probably be accepted
provided that it has both flags and a correct CRC.
> 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.
The receiver would still get the two CRC bytes from the sender (although
they were not intended by the sender to be treated as CRC bytes as they
would be random payload data). When the receiver recalculates the CRC
(for a partial packet that it initially assumes to be a whole packet),
it would realize that the CRC it has recalculated does not match with
the "CRC" that it got from the sender and therefore the packet is
discarded (as it should be because it's a malformed packet).
The receiver has discarded the first packet (because it's malformed) so
it starts all over again and prepares for reception of the next packet.
A second packet arrives immediately afterwards, it has a valid start
flag, it has a valid end flag, if it also has a valid CRC then it is
More or less it's the same that would happen in voice communications. If
a second ham steps on top a a first one (it has more power and/or is
closer to the receiver), it is no longer possible to listen to the first
ham, but as long as the first ham is speaking correct English and using
the proper ham rules and codes, it is possible to copy his/her message.
In analog (but not necessarily digital) voice communications there is no
CRC, but when people spell out (or repeat twice) important details such
as their callsign, something similar to a CRC is actually taking place.
> 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
Well, that's more likely a weakness which also depends on how AX.25 is
used and not entirely on how it was initially designed. For example, if
the data-rate was high enough that transmissions were be much shorter
(provided that the same amount of data is transmitted) and hence there
was more time between packets, consequentially there were less
collisions amongst packets from different users and that particular
network based upon AX.25 would turn out to be more robust in that sense
that the other one working at a slower data-rate. As in APRS 1200 versus
>> On APRS-IS (i.e. through the Internet) we still have packetization
>> 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
>> 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
Unless that interfering transmitter is very close to the serial cable
from the receiveing TNC to the receiving computer, the risk of that
scenario is very low.
For example, in common everyday life, I could only think of problems
arising when someone is using his/her mobile phone very close to that
And there are filters that can be used at both ends of such cable to
minimize to some extent that sort of problems (although they might do
not do miracles).
Least but not last consider that serial interfaces employ a protocol
that also uses safeguards similar in principle to CRCs (the parity bit
for example, although it's much less powerful).
> 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 output.
I am not sure I am getting this right...
An "input" (to a given host) packet has the destination address of that
receiving host. An "output" (from that same given host) packet has a
destination address which is no longer the address of such (now
Also on TCP you have mandatory two-bytes CRC (although it's not
mandatory for UDP). And then lower layers beginning with IP also have
error detection, the most powerful usually being error detection AND
correction capabilities at the physical layer (for example in
fiber-optic networks that made up most of the Internet, supposing that
we are talking about the public, commercial, upper-case Internet and not
any other internet). But let's leave this bottom layers stuff apart, the
very first thing that I mentioned doesn't match...
What am I missing then here ?
Sounds more likely an issue with layers further up than TCP...
More information about the aprssig