[aprssig] Error checking within APRS packets

[Guido Trentalancia]

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

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.

See above.

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

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

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

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

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

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

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

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

> Gregg

Regards,

Guido, IZ6RDB