[aprssig] Error checking within APRS packets

[Gregg Wonderly]

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

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.

> 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

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

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.

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?

Gregg Wonderly

> Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32
>
>
> _______________________________________________
> aprssig mailing list
> aprssig at tapr.org
> https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig
>