[aprssig] Error checking within APRS packets

[Guido Trentalancia]

On 21/06/2011 00:24, Gregg Wonderly wrote:
> On 6/20/2011 4:32 PM, Lynn W. Deffenbaugh (Mr) wrote:
>> On 6/20/2011 2:38 PM, Gregg Wonderly wrote:
>>> Do we have any real examples of how the quiet TX 1/2 through packet 
>>> followed
>>> by loud TX complete packet can result in a "packet" too long that would
>>> corrupt internal TNC buffers?
>>>
>>> Will the start of the "loud" packet result in an end of packet 
>>> recognition of
>>> the "quiet TX" packet.
>>
>> AX.25 packets on the air not only carry a CRC-16 (which is the error 
>> checking
>> that PASSALL ignores), but also carry framing bits that positively 
>> identify the
>> start and end of a packet. "Bit-stuffing" is used to ensure that a 
>> framing bit
>> sequence doesn't occur within a packet. So, if a TNC is receiving a 
>> packet and
>> another packet stomps over it, the framing is the first line of 
>> defense to drop
>> the first packet and restart receiving with the new packet. When the 
>> start/end
>> framing sequences have been identified, then the CRC-16 is used to 
>> ensure that
>> everything within the frame is good (hence the name FCS for Frame 
>> Check Sequence).

Excellent explanation Lynn !

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.

If it is DIY TNCs (perhaps made and tested by only one ham) then there 
might be chances that something has been left over, but otherwise...

Surely they must be doing it (those that create the implementations). 
And these are the very basics of the protocol.

In fact, if something wrong happened or will ever happen, the most 
likely cause would be a local misconfiguration (especially if it's some 
widely used or well trusted commercial TNC).

>> AX.25 bit streams are documented for those that really want to know 
>> the nitty
>> gritty details. APRS is transmitted as UI AX.25 packet, so ALL of the 
>> AX.25
>> packet framing and error checking applies. APRS doesn't use any of the
>> connection-oriented AX.25 packet types, but only the single UI packet 
>> type.
>
> Yep

And it's really excellent specifications (extremely well written, very 
clear, concise and without any ambiguity).

>>> How does all of this play out to indicate that there are failure 
>>> modes that
>>> we've seen but not been able to identify the cause of?
>>
>> If you are observing these "corrupted" and/or "concatentated" packets 
>> directly
>> on RF, then this discussion makes sense. If you are seeing apparent
>> concatenations of two packets on APRS-IS, there seems to be a server 
>> out there
>> at times that has been doing this for over a month now. Those 
>> concatenated
>> packets are happening on the -IS only and are not actually going over 
>> RF unless
>> a message packet happens to get concatenated which was my first 
>> discovery of
>> those particular errors.
>
> Again, I'm just trying to understand what everyone thinks about these 
> issues to make sure that we all agree.  I did think that the framing 
> and CRC-16 should be the line in the sand that would make it most 
> unlikely that two packets which were concatenated in some form should 
> not live to be output by a standards compliant TNC.
>
> CRC-16 can be fairly strong in such short packets, so while it can 
> seem problematic to some, there is ample world experience to 
> demonstrate that between the framing bits and the CRC-16 the chance of 
> concatenated packets surviving as a single packet could only happen 
> with a software bug, or when passthru (or whatever option ignores the 
> CRC) is on.

Supposedly PASSTROUGH (or whatever option ignores the CRC) would not 
change the behaviour with respect to the start/end flag byte (so there 
would still be some sort of "defence" in place and thanks again to Lynn 
for pointing that out).

However, see Bob's message: this "defence" turns out to be ineffective 
or even counterproductive in practice (start_2 flag ends up being 
confused with end_1 flag)...

> It is interesting that we get these things happening on the APRS-IS 
> too, where a simple loss of line-separator can create havoc, because 
> we don't have a "packetization" mechanism implemented/available there.

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).

> Are the problems still happening so prolifically as to be problematic 
> continuously and new people are just finding the same old problems 
> that have never been solved, or are there new cases each time and the 
> solutions have to be discovered each time?

I suppose there will be both new and recurring problems from time to 
time because for example misconfigurations are very common, but perhaps 
I haven't got enough experience to be more precise on this.

> Gregg Wonderly
>
>> Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32

73,

Guido IZ6RDB