[aprssig] Error checking within APRS packets

[Gregg Wonderly]

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

Gregg